Sunday, April 30, 2017

SECTION III :: DOMAIN 7 // OPERATING IN THE CLOUD


TRADITIONAL SECURITY, BUSINESS CONTINUITY, & DISASTER RECOVERY


         With the emergence of cloud computing as a preferred technology for outsourcing IT operations, the security issues inherent in the hosting model have assumed greater significance and criticality.

      Inherent in the concept of cloud computing are the risks associated with entrusting confidential and sensitive data to third parties or pure-play cloud service providers (CSP)

        The evolution of cloud services has enabled business entities to do more with less: fewer resources and better operating efficiency.

       This has many tangible benefits for business, yet there are inherent security risks that must be evaluated, addressed, and resolved before businesses will have confidence in securely outsourcing their IT requirements to cloud service providers.    

       One purpose of this domain is to assist cloud service users to share a common understanding of traditional security (physical security) with cloud service. Traditional security can be defined as

       Traditional security can be defined as the measures taken to ensure the safety and material existence of data and personnel against theft, espionage, sabotage, or harm.

      In the context of cloud information security, this is about information, products, and people.

      Proper information security deploys many different layers to achieve its goal. This is referred to as "layered security” or “defense in depth.”

      When implementing security measures, managers should acknowledge that no measure is one hundred percent secure. Information security uses the depth of its layers to achieve a combined level of security.
   
      A weakness in any one of these layers can cause security to break.

      Physical protection is the initial step in a layered approach to cloud information security.

     If it is nonexistent, implemented incorrectly, weak, exercised inconsistently, treated as a project (fire-n-forget), or properly reviewed and maintained, the best logical security measures will not make up for the physical security weakness, and security overall can fail.
   
    An effective traditional security program flows from a well-developed series of risk assessments, vulnerability analysis, BCP/DR policies, processes, and procedures that are reviewed and tested on a regular basis

   Well-developed physical security programs will result in physical security that is scalable with the business, repeatable across the organization, measurable, sustainable, defensible, continually improving, and cost-effective on an ongoing basis. 

  Some of the security risks associated with cloud computing are unique, and it is in this context the business continuity, disaster recovery, and traditional security environments of a cloud service provider need to be assessed thoroughly (e.g., using standard industry guidelines such as TOGAF, SABSA, ITIL, COSO, or COBIT).

CSP - Cloud Service Provider
TOGAF - The Open Group Architecture Framework
SABSA - Sherwood Applied Business Security Architecture
ITIL - Information Technology Infrastructure Library
COSO - Committee of Sponsoring Organizations

COBIT - Control Objectives for Information and Related Technology


This domain addresses:


(I) Establishing a Physical Security Function
(II) Human Resources Physical Security
(III) Business Continuity

(IV) Disaster Recovery



7.1 Establishing a Traditional Security Function


    Outdated security for IT equipment, network technology, and telecommunications is often overlooked in many organizations.

    This has resulted in many organizations installing computer equipment, networks, and gateways in buildings that did not have proper physical facilities designed to secure the assets or maintain availability.    
     
    To establish proper physical security for IT equipment, network technology, and telecommunications assets in a cloud environment, it is important that responsibilities be assigned to personnel who are appropriately placed in a cloud provider’s organization. 

    An individual in a management position within a cloud provider is responsible for managing planning, implementation, and maintenance of relevant plans and procedures.

   Personnel responsible for physical security need to be trained and have their performance evaluated. 

   In establishing a physical security function within a cloud environment, the following must be considered:


(A) The security needs for the equipment and services being protected

(B) The human resources that are in place for physical security

(C) How legacy physical security efforts have been managed and staffed prior to transition to cloud

(D) Financial resources available for these efforts



   Physical security can be as simple as adding a locked door or as elaborate as implementing multiple layers of barriers and armed security guards.

  Proper physical security uses the concept of layered defense in appropriate combinations for managing risk by deterring and delaying physical security threats.

  
 Physical threats to infrastructure, personnel, and systems are not limited to intrusions. To mitigate these risks, combinations of both active and passive defense are deployed, to include having measures such as:


(A) Obstacles to deter and delay events, incidents, and attacks

(B) Detection systems to monitor security and environmental conditions

(C) Security response designed to repel, apprehend, or discourage attackers



Physical security normally takes one of several forms in design and implementation:

(A) Environmental design

(B) Mechanical, electronic, and procedural controls

(C) Detection, response, and recovery procedures

(D) Personnel identification, authentication, authorization, and access control


(E) Policies and procedures, including training of staff


7.1.1 Evaluation of Traditional Physical Security


   When evaluating the traditional security of a CSP, consumers consider the aspects of the infrastructure as a service/physical presence of the foundational data center provider. These include the physical location of the facility and the documentation of critical risk and recovery factors.

  
 7.1.1.1 Physical Location of the CSP Facility

   Consumers should conduct a critical evaluation of the data center’s physical location. If they are dependent on a cloud supply chain, it is important to understand the cloud infrastructure on which they depend.

The following are suggestions in evaluating the physical location of the facility:

(A) Check if the location of the facility falls under any active seismic zone and the risks of seismic activity

(B) The facility should not be located in a geographic region which is prone to: flooding, landslides, or other natural disasters

(C) The facility should not be in an area with high crime, political or social unrest

(D) Check the accessibility of the facility’s location (and frequency of inaccessibility)
    

7.1.1.2 Documentation Review

    The documentation supporting recovery operations is critical in evaluating the readiness of the hosting company to recover from a catastrophic event

    The following sets of documentation should be inspected prior to engagement of a physical data center provider:

(A) Risk Analysis

(B) Risk Assessments

(C) Vulnerability Assessments

(D) Business Continuity Plans

(E) Disaster Recovery Plans

(F) Physical and Environmental Security Policy

(G) User Account Termination Procedures


(H) Contingency Plan, including test protocols

(I) Incident Reporting and Response Plan, including test protocols

(J) Emergency Response Plan

(K) Facility Layout – emergency exits, positioning of CCTV cameras, secure entry points

(L) Fire Exit Route Map and Fire Order Instructions

(M) Emergency Evacuation Plan and Procedures

(N) Crisis Communication Procedures

(O) Emergency Contact Numbers

(p) User Facility Access Review/Audit Records

(Q) Security Awareness Training documentation, presentation, handouts, etc.

(R) Security Awareness Attendance Records

(S) Succession Planning for key executives

(T) Technical Documents – electrical wiring diagrams, BMS, UPS, AHU details

(U) Maintenance Schedule of Electrical, Generator, and CCTV

(V) Emergency fuel service providers contracts

(W) List of Authorized Personnel allowed entry inside facility

(X) Security Staff profiles – bio and background information

(Y) Background Check Reports of Security Staff (must be performed every year)


(Z) Annual Maintenance Contracts for key equipment and devices (focus on SLA’s39 for equipment/devices downtime and restoration)


  When inspecting the documents, there are areas of critical focus that the purchaser of cloud services should focus on to ensure that his/her risk is mitigated. 

  The following advice may prove critical in securing a cloud consumer’s business interest when transitioning to cloud:

(A) Check whether all the documents are up to date and current. These documents must be reviewed by the CSP at least once a year. The revision dates and sign off by management must be included and validated as proof of them being reviewed internally.

(B) Further, the policy and procedure documents (that are suitable for employee viewing) should be made available through a common Intranet site where authorized employees of the CSP can access them anytime for reference. Adequate care must be taken by the security team to ensure the uploaded documents are the latest versions duly approved by management.

(C) All policies and procedures will be effective only when employees are aware of them. To this end, check whether a CSP has security awareness program in place. At the minimum, the CSP should ensure that employees are given adequate security awareness training at least once each year and receive sign off from them

     Also, new employees joining the organization shall undergo a security orientation session as part of the induction program where key policies and procedures are to be covered with formally signed attendance records maintained and available for review at any time.

     To make the program effective, senior staff from the security team must conduct the session.


7.1.1.3 Compliance with International/Industry Standards on Security


   Ensure that the CSP is compliant with global security standards like ISO 27001 ISMS or other industry-standards such as TOGAF, SABSA, ITIL, COSO, or COBIT. 

   These activities will prove invaluable in assessing the CSP’s level of security and its maturity.

(A) Verify the compliance certificate and its validity.

(B) Look for verifiable evidence of resource allocation, such as budget and manpower to sustain the compliance program.


(C) Verify internal audit reports and evidence of remedial actions for the findings.


7.1.1.4 Visual Walk-Through Inspection of the CSP’s facility

Area Coverage

Data Center Perimeter Security should be evaluated when determining what areas require physical coverage. The following are high-risk areas that should be secured:

(A) Administrative areas

(B) Reception

(C) Parking Area

(D) Storage Area

(E) Fire Exits

(F) CCTV Command Center

(G) Air Handling Unit (AHU) Room

(H) Locker Room

(I) UPS Room

(J) Generator Room


(K) Fuel Storage Tanks


Signage


Look for the following signage that must be displayed prominently in the facility at appropriate places:

(A) Fire Escape Route Maps and Emergency Exits

(B) Fire Order Instructions

(C) Fire Safety Signages

(D) Security Posters and instructions

(E) Anti-tailgating Posters

(F) Temperature/Humidity-related information

(G) Warning and Instructional Signage

(H) Emergency Contact Numbers


(I) Escalation Chart


7.1.2 Security Infrastructure



   Perimeter security is important as it serves as the first line of protection against intruders and unwanted visitors. 

  The principles of perimeter security has undergone sea change with technological advancements. 

  The Four D’s of Perimeter Security consists of Deter, Detect, Delay and Deny phases for intruders wanting access to the facility.

   The following qualities are preferential when selecting a physical infrastructure provider. Depending on the design and function of the cloud service provider, the following list should be closely adhered to in the selection process.

   Due care should be taken to ensure the physical infrastructure is adequate for the facility’s size and nature and scale of operations. Security controls must be strategically positioned and conform to acceptable quality standards consistent with prevalent norms and best practices.


(A) Secure Entry Points – Access control systems (proximity cards/biometric access)

(B) Access Control System linked with fire control panel for emergency release

(C) Motion-sensing alarms, thermal tracking devices, glass-breakage detection

(D) Fire safety equipment – wet riser, hydrants, hoses, smoke detectors and water sprinklers

(E) Fire extinguishers

(F) Fire exits (must not be locked or blocked)

(G) Panic Bars in fire exit doors

(H) Alarm sirens and lights

(I) CCTV Cameras and DVR server (including backup timelines)

(J) Door closures and time-delay door alarms

(K) Gas-based fire suppressants inside Data Centers

(L) Paper Shredders near printers

(M) Degaussing devices or disk shredders

(N) Emergency Response Team Kit (ERT Kit)

(O) Two-way Radio devices (Walkie-talkie handsets) for security staff

(P) Duress Alarms underneath security desk and vantage (concealed) points

(Q) Door Frame Metal Detectors at entrance and Hand-held Metal Detectors (if needed)


(R) Fire-proof Safe to safe keep important documents/media




7.2 Human Resources Physical Security


The purpose of the human resources physical control is to minimize the risk of the personnel closest to the data disrupting operations and compromising the cloud.

A knowledgeable actor with physical access to a console can bypass most logical protective measures by simply rebooting the system or accessing a system that is already turned on with root or administrator access.

A wiring closet can provide hidden access to a network or a means to sabotage existing networks. Consider the following measures:

(A) Roles and responsibilities (e.g., through a RACI-style matrix)

(B) Background verification and screening agreements

(C) Employment agreement (e.g., NDA’s)

(D) Employment termination


(E) Awareness and training of company policies (i.e., Code or Business Conduct)


  Roles and responsibilities are part of a cloud environment, in which people and processes, along with technology, are integrated to sustain tenant security on a consistent basis.


  Segregation of duties, requires at least two persons with separate job responsibilities to complete a transaction or process end-to-end


  Avoidance of conflict of interest is essential to the protection of cloud consumers and measures should be implemented to monitor or avoid this risk.


  Segregation of duties originated in accounting and financial management; its benefits extend to other risk mitigation needs, such as physical security, availability, and system protection.


   Segregation of duties is implemented via eliminating high-risk role combinations, e.g., not having the same person who approves a purchase order also able to facilitate payment.


   The principle is applied to role division in cloud development and operations, as well as a software development life cycle. 

    An example common to cloud software development would be the separation of those who develop applications from the staff who operate those systems.

   Ensure there are no unauthorized backdoors remaining in the final delivered product. Ensure different personnel manage different critical infrastructure components.

 Additionally, granting staff the least amount of access privilege required for them to perform their duties will further reduce but not eliminate risk.


  The segregation of duties and least privilege/access are principles that support a cloud provider’s goal to protect and leverage the organization's information assets. A cloud security management program requires the assignment of key roles and responsibilities that may be held by individuals or groups.


 These roles and responsibilities must be formally defined in the organization’s information security policy framework and formally reviewed and approved by senior management in line with their fiduciary GRC (Governance Risk and Compliance) duties and responsibilities.

  
 Additionally, the development of effective HR security must include employment and confidentiality agreements, background checks (when legally permitted), and legally sound hiring and termination practices. 

  Additional measures to consider, if they are applied across all areas of the organization, include formalized job descriptions, appropriate training, security clearances, job rotation, and mandatory vacations for staff in sensitive or high risk roles.



7.3 Assessing CSP Security


  Some of the security risks associated with cloud computing are unique, partly due to an extended data centric chain of custody, and it is in this context the business continuity, disaster recovery, and traditional security environments of a cloud service provider need to be assessed thoroughly and in reference to industry standards.

    
 Traditional or Physical Security of the cloud computing service provider’s facility is important and needs to be thoroughly assessed from various parameters. This is an area of highest similarity – the security requirements of a cloud and non-cloud data center are fairly similar.


  A holistic view and understanding of the “people, process, technology” model or philosophy of the CSP would immensely help in evaluating the maturity of the CSP and flag open issues with their approach towards security which must be resolved, approved, and closed before proceeding.


  Organizational maturity and experience contributes a great deal to the effective handling of physical security programs and any contingencies that may arise. Invariably, there is a strong human element involved in the effective administration of physical security programs

  The level of management support and the caliber of the security leadership are significant factors in protecting company assets with management support being critical.

  Physical security is generally the first line of defense against unauthorized as well as authorized access to an organization’s physical assets and the physical theft of records, trade secrets, industrial espionage, and fraud.

  
7.3.1 Procedures


  Cloud service providers should ensure that the following documents are made available for inspection on demand by clients:

(A) Background Checks (once yearly) by third party vendors

(B) Non-Disclosure Agreements

(C) Implement “need to know” and “need to have” policies for information sharing

(D) Separation of duties

(E) User Access Administration

(F) Defined Job Description (Role and Responsibilities)

(G) Role-based Access Control System


(H) User Access Reviews



7.3.2 Security Guard Personnel


Where human monitoring and intervention are necessary, physical security staff comprised of guards, supervisors and officers should be posted (on 24/7 basis) at the CSP’s facility.


Among other things, the Site and Post instructions should include the following:


(A) Checking employee, contract staff, and visitor credentials and use of the sign-in log

(B) Issuing and recovering visitor badges

(C) Curbing tail-gating by employees

(D) Handling visitors and movement within the facility

(E) Handling security-relevant phone calls

(F) Monitoring intrusion, fire alarm systems and dispatch personnel to respond to alarms

(G) Controlling movement of materials into and out of the building and enforcing property pass regulations

(H) Enforcing rules and regulations established for the building

(I) Patrolling inside facility

(J) CCTV monitoring

(K) Key control and management

(L) Executing emergency response procedures

(M) Escalating security-related issues to security manager

(N) Accepting and dispatching mail


(O) Escorting unattended business visitors inside the office



7.3.4 Environmental Security


   The CSP’s facilities should protect both personnel and assets by implementing controls that will protect the environment from environmental hazards.

   These controls may include but are not limited to: temperature and humidity controls, smoke detectors and fire suppression systems.


7.3.4.1 Environmental Controls

(A) The data center should be equipped with specific environmental support equipment according to published internal standards, local and/or regional rules 
or laws including an emergency/uninterruptible power supply.


(B) Equipment/devices required for environmental controls must be protected to reduce risks from environmental threats and hazards and to reduce the risk of unauthorized access to information.



7.3.4.2 Equipment Location and Protection


The following controls must be considered for systems classified as containing Restricted or Confidential information:

(A) Equipment is located in a physically secure location to minimize unnecessary access.

(B) Environmental conditions such as humidity that could adversely affect the operation of computer systems are monitored.

(C) Security staff shall take into account the potential impact of a disaster happening in nearby premises, e.g., a fire in a neighboring building, water leaking from the roof or in floors below ground level, or an explosion in the street.


(D) Methods for thoroughly destroying and disposing of discarded media (e.g., disk drives)


7.3.4.3 Equipment Maintenance


To ensure continued availability and integrity, equipment is properly maintained with equipment maintenance controls, including:

(A) Maintaining equipment in accordance with the supplier’s recommended service intervals and specifications

(B) Permitting only authorized maintenance personnel to carry out repairs and service equipment

(C) Maintaining records of suspected or actual faults and all preventive and corrective maintenance.

(D) Using appropriate controls when sending equipment off premises for maintenance. 

     Examples of appropriate controls include proper packaging and sealing of containers, storage in safe and secure places, and clear and complete shipping and tracking instructions.


(E) Maintaining appropriate policies and procedures for asset control, including records retention for all hardware, firmware, and software encompassing traceability, accountability, and ownership


   A thorough review of the CSP’s facility would enable the prospective client to understand and evaluate the maturity and experience of the security program

   Generally, with the focus on IT security, physical security gets limited attention

     However, with the range of threat scenarios prevalent today it is imperative that the physical security receives the attention it deserves, especially, in an environment where the clients’ data may be co-resident with a number of other clients (including competitors), physical security assumes greater significance. 

   Physical Security is one of many interconnected lines of defense against intruders and corporate saboteurs who may want access to a CSP’s facility for nefarious purposes.



7.4 Business Continuity


   Traditionally, the three tenets of information security are confidentiality, integrity, and availability. Business Continuity deals with the continuity component of those three requirements. 

   The transition to a Cloud Service Provider includes an assessment of the uptime the provider contractually commits to. However, this Service Level Agreement (SLA) may not be enough to satisfy the customer. 

   Consideration should be made to the potential impact should a significant outage occur. Based on recent high profile service disruptions into third party provisioned services, the authors would suggest that maintaining continuity of service is a critical dependency on the business to maintain operations.


   The following guidelines should be considered with regard to maintaining the continuity of a given service. Although many of these guidelines will likely apply for internally provisioned services as they would for third party provisioned services (e.g. Cloud), these guidelines are written with the pretext that the responsibility rests with the third party.



7.5 Disaster Recovery


    One of the most interesting aspects of cloud storage for IT is how it can be leveraged for backup and disaster recovery (DR). 

    Cloud backup and DR services are targeted at reducing the cost of infrastructure, applications, and overall business processes

    Cloud backup and DR must aim to make reliable data protection affordable and easy to manage. The challenges to cloud storage, cloud backup, and DR in particular involve mobility, information transfer to and from the cloud, availability, assuring optimal business continuity, scalability and metered payment. 

    Cloud disaster recovery solutions are built on the foundation of three fundamentals:

     a fully virtualized storage infrastructure, a scalable file system and a compelling self-service disaster recovery application that responds to customers’ urgent business requirements.


Customers transitioning disaster recovery operations to the cloud should review the existence of the following organizations or teams within the service provider’s disaster recovery program:

(A) Emergency Response Team (ERT)

(B) Crisis Management Team

(C) Incident response team


   The composition of the above teams should be reviewed in detail along with crisis communication procedure.



7.5.1 Restoration Priorities


    Review the service providers documented restoration plan: This plan should include details on the priorities regarding restoration sequencing.

   This should correlate directly with the SLA, as contractually committed, with regards to the services acquired by the customer and the criticality of the service. 

   The Restoration plan should incorporate and quantify the RPO
(Recovery Point Objective) and RTO (Recovery Time Objective) for services.

   Detail the Information security controls that are considered and implemented during the restoration process, which should include as an example:

(A) Clearances of staff involved during the restoration process

(B) Physical security controls implemented at alternate site

(C) Specified dependencies relevant to the restoration process (suppliers and outsource partners)

(D) Minimum separation for the location of the secondary site if the primary site is made unavailable



7.6 Permissions


(A) Ensure proper facility design.

(B) Adopt integrated physical and logical security systems that reinforce one another.


(C) Establish service level agreements that require the inheritance of employment security obligations and responsibilities by later levels of the supply chain.


7.7 Recommendations



7.7.1 Policy Recommendations


(A) Cloud providers should consider adopting as a security baseline the most stringent requirements of any customer, such that systems, facilities, and procedures are at a system high level

     To the extent these security practices do not negatively impact the customer experience, stringent security practices should prove to be cost effective and quantified by reducing risk to personnel, revenue, reputation, and shareholder value.

(B) Alternately, providers may target a set of users with lower security requirements, or offer a baseline level to all customers with the potential to up-sell and implement additional measures for those who value them. 

    In the latter case, it should be recognized that some customers will be interested only in providers that deliver uniformly high security. This balancing act includes systems, facilities, and documented procedures.


(C) Providers should have robust compartmentalization of job duties, perform background checks, require and enforce non-disclosure agreements for employees, and restrict employee knowledge of customers to a least privilege, need to know basis.


7.7.2 Transparency Recommendations


(A) Transparency regarding the security posture of the CSP should be required. Onsite visit to the CSP’s facility or data center will help in performing an on-the-spot assessment and gaining a clear understanding of the different security measures that have been put in place.

   However, due to the on-demand provisioning and multi-tenant aspects of cloud computing, traditional forms of audit and assessment may not be available, or may be modified (e.g., shared access to a third-party inspection).

(B) To enhance effectiveness of the onsite assessment, the visit to the CSP facility or data center should be carried out unannounced (if need be with the CSP being informed about a broad time window rather than specific times).

   This will enable to have real assessment on the ground on a normal business day instead of giving an opportunity to the CSP to ‘keep up appearances’ during a client or third-party visit.

(C) When direct examination is pursued, the assessment team should comprise at least two members or more with specialists drawn from IT, Information Security, Business Continuity, Physical Security, and Management (e.g., department heads or data owners) functions.


(D) Customers should request and acquire business continuity planning and disaster recovery documentation prior to visit, including relevant certifications (e.g., based on ISO, ITIL standards), and audit reports and test protocols.



7.7.3 Human Resources Recommendations



(A) Consumers should check to see if the CSP deploys competent security personnel for its physical security function.

   A dedicated security manager is highly recommended to provide the necessary leadership and drive to the physical security program. Leading industry certifications such as CISA, CISSP, CISM, ITIL, or CPP (from ASIS) would be helpful in validating the incumbent’s knowledge and skills in physical security.


(B) Consumers should request a thorough review of the reporting structure of the security manager. This will help in determining whether the position has been given due significance and responsibilities. 

   The security manager should report to a functional superior and his/her GRC Committee if one exists. They should not report to Facilities or IT.

    It would be better if this position reports to the CEO through another chain (e.g., through the CRO or head counsel) in terms of independence and objectivity of the position.


CISA - Certified Information Security Auditor
CISSP - Certified Information System Security Professional
CISM - Certified Information Security Manager
CPP - Certified Privacy Professional

ASIS - American Society for Industrial Security



7.7.4 Business Continuity Recommendations


(A) The customer should review the contract of third party commitments to maintain continuity of the provisioned service. 

    However, the customer should strongly consider further analysis. Typically the customer acts as the Data Controller and where personal data is held, there are likely to be specific regulatory requirements to ensure appropriate controls are employed. 

    Such requirements apply even in the event that a third party data processor is utilized.

(B) The customer should review the third party Business Continuity processes and any particular certification. 

    For example, the CSP may adhere and certify against BS 25999, the British Standard for Business Continuity Management (BCM). The customer may wish to review the scope of the certification and documented details of the assessment.

(C) The customer should conduct an onsite assessment of the CSP facility to confirm and verify the asserted controls used to maintain the continuity of the service. It may not be entirely necessary to conduct this unannounced assessment of the CSP facility for the sole purpose of verifying specific BCP controls, as typically such controls are only likely to be engaged when a disaster/event were to occur.

(D) The customer should ensure that he/she receives confirmation of any BCP/DR tests undertaken by the CSP. While many of the recommendations already mentioned focus on documented assertions that the service will maintain continuity, the true test of these is in the event of a significant incident. 

     Without awaiting an actual disaster to occur, the customer should stress the importance of getting formal confirmation of BCP/DR tests, and whether the tests satisfied the SLAs contractually committed.



7.7.5 Disaster Recovery Recommendations


  Cloud customers should not depend on a singular provider of services and should have a disaster recovery plan in place that facilitates migration or failover should a supplier fail.

(A) IaaS providers should have contractual agreements with multiple platform providers and have the tools in place to rapidly restore systems in the event of loss.

(B) Data validation should be an automated or user initiated validation protocol that allows the customer to check their data at any time to ensure the data’s integrity.

(C) Incremental backups should frequently update a replica of all protected systems or snapshots at intervals set by the user for each system, so the consumer determines the settings according to recovery point objectives.

(D) Full site, system, disk, and file recovery should be accessible via a user-driven, self-service portal that allows the user the flexibility to choose which file disk or system they want to recover.

(E) The cloud provider should implement fast SLA-based data recovery.

(F) The SLA should be negotiated up front, and the customer should pay for the SLA required to ensure that there is no conflict of interest. No data, no file or system disk, should take more than 30 minutes to recover.

(G) WAN optimization between the customer and the physical site should be in place so that the cloud enables full data mobility at reduced bandwidth, storage utilization, and cost.



7.8 Requirements



(A) All parties must ensure proper structural design for physical security.

(B) All supply chain participants must respect the interdependency of deterrent, detective, and authentication solutions.


(C) End consumers must inspect, account for, and fix personnel risks inherited from other members of the cloud supply chain. They must also design and implement active measures to mitigate and contain personnel risks through proper separation of duties and least privilege access.


--== || END ||==--








   
    

Saturday, April 29, 2017

Section II :: DOMAIN 6


INTEROPERABILITY AND PORTABILITY

   
     Gaining the benefits of more elastic environment requires both interoperability and portability to be the design goals of any cloud-implemented system, from IaaS through to SaaS.

   At one end of the scale, Interoperability and Portability allows you to scale a service across multiple disparate providers on a global scale and have that system operate and appear as one system.

   At the other end, Interoperability and Portability allows the easy movement of data and applications from one platform to another, or from one service provider to another.

   Portability and interoperability are not considerations unique to cloud environments and their related security aspects are not new concepts brought about by cloud computing.

   However, the open and often shared processing environments that exist within the cloud bring a need for even greater precautions than are required for traditional processing models.

  Multi-tenancy means data and applications reside with data and applications of other companies and that access to confidential data (intended or unintended) is possible through shared platforms, shared storage, and shared networks.

6.1 An Introduction to Interoperability


      Interoperability is the requirement for the components of a cloud eco-system to work together to achieve their intended result.

   In a cloud computing eco-system the components may well come from different sources, both cloud and traditional, public and private cloud implementations (known as hybrid-cloud).

  Interoperability mandates that those components should be replaceable by new or different components from different providers and continue to work, as should the exchange of data between systems.


Businesses, over time, will make decisions that lead to the desire to change providers.

  Reasons for this desired change include:


 (A) An unacceptable increase in cost at contract renewal time

 (B) The ability to get the same service at a cheaper price

 (C) A provider ceases business operations

 (D) A provider suddenly closes one or more services being used without acceptable migration plans

 (E) Unacceptable decrease in service quality, such as a failure to meet key performance requirements or achieve service level agreements (SLA’s)

 (F) A business dispute between cloud customer and provider


** A lack of interoperability (and also portability) can lead to being locked to a particular cloud service provider.


    The degree to which interoperability can be achieved or maintained when considering a cloud project often will depend on the degree to which a cloud provider uses open, or published, architectures and standard protocols and standard API’s.

   Though many vendors of “open” and “standards based” cloud provision provide propriety hooks and extensions (e.g. Eucalyptus) and enhancements that can impede both interoperability and portability.

6.2 An Introduction to Portability


     Portability defines the ease of ability to which application components are moved and reused elsewhere regardless of provider, platform, OS, infrastructure, location, storage, the format of data, or API’s.

    Portability and interoperability must be considered whether the cloud migration is to public, private, or hybrid cloud deployment solutions.

    They are important elements to consider for service model selection regardless of whether a migration strategy is to Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS).
   
    Portability is a key aspect to consider when selecting cloud providers since it can both help prevent vendor lock-in and deliver business benefits by allowing identical cloud deployments to occur in different cloud provider solutions, either for the purposes of disaster recovery or for the global deployment of a distributed single solution.

   Achieving portability for a cloud service is generally reliant on the two services operating in the same architectural octant of the Cloud Cube, as defined in Domain One. Where services operate in different octants, then porting a service usually means migrating the service back “in-house” before re-outsourcing it to an alternative cloud service.

   Failure to appropriately address portability and interoperability in a cloud migration may result in failure to achieve the desired benefits of moving to the cloud and can result in costly problems or project delays due to factors that should be avoided such as:

(A) Application, vendor, or provider lock-in – choice of a particular cloud solution may restrict the ability to move to another cloud offering or to another vendor

(B) Processing incompatibility and conflicts causing disruption of service – provider, platform, or application differences may expose incompatibilities that cause applications to malfunction within a different cloud infrastructure

(C) Unexpected application re-engineering or business process change – moving to a new cloud provider can introduce a need to rework how a process functions or require coding changes to retain original behaviors

(D) Costly data migration or data conversion — lack of interoperable and portable formats may lead to unplanned data changes when moving to a new provider

(E) Retraining or retooling new application or management software

(F) Loss of data or application security – different security policy or control, key management or data protection between providers may open undiscovered security gaps when moving to a new provider or platform

   Moving services to the cloud is a form of outsourcing; the golden rule of outsourcing is “understand up-front and plan for how to exit the contract”. Portability (and to an extent interoperability) should therefore be a key criterion of any organizations strategy to move into cloud services, allowing for a viable exit strategy to be developed.

6.3 Recommendations


6.3.1 Interoperability Recommendations

Hardware – Physical Computer Hardware

    The hardware will inevitably vary or change over time and from provider to provider leaving unavoidable interoperability gaps if direct hardware access is required.


(A) Whenever possible, use virtualization to remove many hardware level concerns, remembering that virtualization doesn’t necessarily remove all hardware concerns, especially on current systems.

(B) If hardware must be directly addressed, it is important to ensure that the same or better physical and administrative security controls exist when moving from one provider to another.
    

Physical Network Devices



   The network devices including security devices will be different from service providers to service providers along with its API and configuration process.

 (A) To maintain interoperability the Network physical hardware and network & security abstraction should be in virtual domain. As far as possible API’s should have the same functionally.



Virtualization

   While virtualization can help to remove concerns about physical hardware, distinct differences exist between common hypervisors (such as ZEN, VMware and others).

(A) Using open virtualization formats such as OVF to help ensure interoperability.

(B) Document and understand which specific virtualization hooks are used no matter the format. It still may not work on another hypervisor.


Frameworks

  
   Different platform providers offer different cloud application frameworks and differences do exist between them that affect interoperability.

(A) Investigate the API’s to determine where differences lie and plan for any changes necessary that may be required to application processing when moving to a new provider.

(B) Use open and published API’s to ensure the broadest support for interoperability between components and to facilitate migrating applications and data should changing a service provider become necessary.

(C) Applications in the cloud often interoperate over the Internet and outages can be anticipated to occur. Determine how failure in one component (or a slow response) will impact others and avoid stateful dependencies that may risk system data integrity when a remote component fails.


Storage

   Storage requirements will vary for different types of data. 

   Structured data will most often require a database system, or require application specific formats.

   Unstructured data will typically follow any of a number of common application formats used by Word Processors, Spreadsheets and Presentation Managers
   Here the concern should be to move data stored with one service to another seamlessly.

 (A) Store unstructured data in an established portable format.

 (B) Assess the need for encryption for the data in transit.

 (C) Check for compatible database systems and assess conversion requirements if needed.


Security


    Data and applications in the cloud reside on systems the user doesn’t own and likely has only limited control over.

 A number of important items to consider for interoperable security include:


(A) Use SAML or WS-Security for authentication so the controls can be interoperable with other standards-based systems.  

(B) Encrypting data before it is placed into the cloud will ensure that it cannot be accessed inappropriately within cloud environments.  

(C) When encryption keys are in use, investigate how and where keys are stored to ensure access to existing encrypted data is retained.  

(D) Understand your responsibilities and liabilities should a compromise occur due to unanticipated “gaps” in protection methods offered by your service provider.

(D) Log file information should be handled with the same level of security as all other data moving to the cloud. Ensure that log files are interoperable to ensure continuity of log analysis pre-and post move as well as compatibility with whatever log management system is in use.

(E) When completing a move ensure that all data, logs, and other information is deleted from the original system.


6.3.2 Portability Recommendations



   Portability considerations and recommendations that impact moving to the cloud include :


(A) Service Level : SLA’s will differ across providers, and there is a need to understand how this may affect your ability to change providers.

(B) Different architectures : Systems in the cloud may reside on disparate platform architectures. 

     It is important to be aware of how these will limit portability by understanding service and platform dependencies, which may include API’s, hypervisors, application logic, and other restrictions.

(C) Security integration : Cloud systems introduce unique portability concerns for maintaining security, including:

 -  Authentication and identity mechanisms for user or process access to systems now must operate across all components of a cloud system. 

 -  Using open standards for Identity such as SAML will help to ensure portability. 

 - Developing internal IAM system to support SAML assertions and internal system to accept SAML will aid future portability of system to the cloud.

 - Encryption keys should be escrowed locally, and when possible maintained locally

 - Metadata is an aspect of digital information that is often and easily overlooked as (typically) metadata is not directly visible when working with files and documents

 - Metadata becomes an important consideration in the cloud, because metadata moves with the document. When moving files and their metadata to new cloud environments ensure copies of file metadata are securely removed to prevent this information from remaining behind and opening a possible opportunity for compromise.


6.3.3 Recommendations for Different Cloud Models


     There are a number of generic risks and recommendations that are common to all cloud models.

(I) When substituting cloud providers it is normal to expect resistance from the legacy cloud provider. This must be planned for in the contractual process as outlined in Domain 3, in your Business Continuity Program as outlined in Domain 7, and as a part of your overall governance in Domain 2.

(II) Understand the size of data sets hosted at a cloud provider. The sheer size of data may cause an interruption of service during a transition, or a longer transition period than anticipated. Many customers have found that using a courier to ship hard drives is faster than electronic transmission for large data sets.

(III) Document the security architecture and configuration of individual component security controls so they can be used to support internal audits, as well as to facilitate migration to new providers and aid the validation of the new environment.


Infrastructure as a Service (IaaS)



   Where the responsibility of the cloud provider is to provide basic computing utilities such as storage, computing power, etc., the cloud customer is responsible for a majority of application design tasks related to interoperability.

    The cloud provider should provide standardized hardware and computing resources that can interact with various disparate systems with minimal efforts

    The cloud provider should strictly adhere to industry standards to maintain interoperability. The provider should be able to support complex scenarios such as cloud brokerage, cloud bursting, hybrid clouds, multi- cloud federation, etc.


(A) Understand how virtual machine images can be captured and ported to new cloud providers and who may use different virtualization technologies. 

    Example: Distributed Management Task Force (DMTF) Open Virtualization format (OVF).


(B) Identify and eliminate (or at least document) any provider-specific extensions to the virtual machine environment.


(C) Understand what practices are in place to make sure appropriate de-provisioning of VM images occurs after an application is ported from the cloud provider.

(D) Understand the practices used for decommissioning of disks and storage devices.


(E) Understand hardware/platform based dependencies that need to be identified before migration of the application/data.

(F) Ask for access to system logs, traces, and access and billing records from the legacy cloud provider.

(G) Identify options to resume or extend service with the legacy cloud provider in part or in whole if new service proves to be inferior.

(H) Determine if there are any management-level functions, interfaces, or API’s being used that are incompatible with or unimplemented by the new provider.

(I) Understand costs involved for moving data to and from a cloud provider

(J) Determine what means are supported for moving data as efficiently to the cloud as possible through using standard capabilities such as data compression.


(K) Understand what security is provided and who maintains access to encryption keys.


Platform as a Service (PaaS)



    The cloud provider is responsible to provide a platform on which the consumers can build their systems. They provide with a runtime environment and an integrated application stack.

    It allows developers to quickly develop and deploy custom applications on the offered platforms without the need to build the infrastructure.

    The cloud provider provides the entire infrastructure and its maintenance to its consumers.

   
(A) When possible, use platform components with a standard syntax, open API’s, and open standards
     
      e.g. Open Cloud Computing Interface (OCCI)

(B) Understand what tools are available for secure data transfer, backup, and restore.

(C) Understand and document application components and modules specific to the PaaS provider and develop application architecture with layers of abstraction to minimize direct access to proprietary modules.

(D) Understand how base services like monitoring, logging, and auditing would transfer over to a new vendor.

(E) Understand what protections are provided for data placed into the cloud and data generated and maintained in the cloud.

(F) Understand control functions provided by the legacy cloud provider and how they would translate to the new provider.

(G) When migrating to a new platform, understand the impacts on performance and availability of the application and how these impacts will be measured.

o Understand how testing will be completed prior to and after migration to verify that the services or applications are operating correctly. Ensure that both provider and user responsibilities for testing are well known and documented.


Software as a Service (SaaS)


      The cloud provider provides application capabilities over the cloud, and the client just manages his/her operations and the information flowing in and out of the system.

      The client needs a browser, and majority of the administrative at all the levels rests with the provider.

    
(A) Perform regular data extractions and backups to a format that is usable without the SaaS provider.

(B) Understand whether metadata can be preserved and migrated.

(C) If needed use data escrow services.

(D) Understand that any custom tools will have to be redeveloped, or the new vendor must provide those tools, or commit to port (and support) these tools.


(E) Review and audit to ensure the consistency of control effectiveness across old and new providers.

(F) Ensure backups and other copies of logs, access records, and any other pertinent information which may be required for legal and compliance reasons can be migrated.

(G) Understand the management, monitoring, and reporting interfaces and their integration between environments.


(H) Test and evaluate all applications before migration, and dual run if feasible prior to cut-over.


Private Cloud


      Private cloud is when the consumer runs a cloud environment / service within their enterprise or uses private cloud offering from the cloud providers (typically extending the internal network into a service providers hosting centre).

(A) Ensure interoperability exists between common hypervisors such as KVM, VMware, Xen.


(B) Ensure standard API’s are used for management functions such as users and their privilege management, VM image management, Virtual Machine management, Virtual Network management, Service management, Storage management, Infrastructure management, Information Management, etc.


Public Cloud

     Interoperability in public cloud means exposing most common cloud interfaces. They may be vendor specific or open specifications and interfaces such as OCCI, libcloud, etc.


(A) Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering.



Hybrid Cloud


     In this scenario the consumer’s local private infrastructure should have the capability to work with external cloud providers.

    A common scenario is “cloud bursting”, where an enterprise shares the load with external cloud providers to meet peak demands.

(A) Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering.


(B) Ensure the ability to federate with different cloud providers to enable higher levels of scalability.



---=== || END ||===----