SECTION I // CLOUD ARCHITECTURE:

SECTION I // CLOUD ARCHITECTURE:

DOMAIN 1 //
CLOUD COMPUTING ARCHITECTURAL FRAMEWORK:

1.1 What Is Cloud Computing?

1) Cloud computing is a disruptive technology that has the potential to enhance collaboration, agility, scaling, and availability, and provides the opportunities for cost reduction through optimised and efficient computing

2) Cloud computing will impact the organizational, operational, and technological approaches to data security, network security, and information security good practice

3) CSA guide V3 focuses on a definition that is specifically tailored to the unique perspectives of IT network and security professionals

1.2 What Comprises Cloud Computing?

    This version of the Cloud Security Alliance’s Guidance features definitions that are based on published work of the scientists at the U.S. National Institute of Standards and Technology (NIST) and their efforts around defining cloud computing


 NIST defines cloud computing by describing five essential characteristics, three cloud service models, and four cloud deployment models.

   1.3 The Characteristics of Cloud Computing

1) Cloud services are NOT always utilize virtualization by hypervisor or operating system containers.

2) Further, it should be noted that multi-tenancy is not called out as an essential cloud characteristic by NIST but is often discussed as such

3) Although not an essential characteristic of cloud computing in the NIST model, CSA has identified multi-tenancy as an important element of cloud.

1.4 Multi-Tenancy

1) Multi-tenancy in its simplest form implies use of same resources or application by multiple consumers that may belong to same organization or different organization

 2) The impact of multi-tenancy is visibility of residual data or trace of operations by other user or tenant.

3) Multi-tenancy in cloud service models implies a need for policy-driven enforcement, segmentation, isolation, governance, service levels, and chargeback/billing models for different consumer constituencies.

4) From a provider’s perspective, multi-tenancy suggests an architectural and design approach to enable economies of scale, availability, management, segmentation, isolation, and operational efficiency

   - Infrastructure as a Service (IaaS):  delivers computer infrastructure

   - Software as a service (SaaS) : sometimes referred to as "on-demand software

   - Platform as a service (PaaS) : is the delivery of a computing platform and solution stack as a service

5) Cloud deployment models place different importance on multi-tenancy. 

Thus, multi-tenancy concerns should always be considered.

1.5 Cloud Reference Model:

     IaaS is the foundation of all cloud services, with PaaS building upon IaaS, and SaaS in turn building upon PaaS as described in the Cloud Reference Model diagram

   In this way, just as capabilities are inherited, so are information security issues and risk.

 1) IaaS includes the entire infrastructure resource stack from the facilities to the hardware platforms that reside in them.

 2) IaaS provides a set of API’s, which allows management and other forms of interaction with the infrastructure by consumers.

 3) PaaS sits on top of IaaS and adds an additional layer of integration with application development frameworks, middleware capabilities, and functions such as database, messaging, and queuing.

 4)  SaaS in turn is built upon the underlying IaaS and PaaS stacks and provides a self-contained operating environment that is used to deliver the entire user experience, including the content, its presentation, the application(s), and management capabilities.

 5) Generally, SaaS provides the most integrated functionality built directly into the offering, with the least consumer extensibility, and a relatively high level of integrated security (at least the provider bears a responsibility for security).

 6) PaaS is intended to enable developers to build their own applications on top of the platform.

 7) IaaS provides few if any application-like features, but enormous extensibility. This model requires that operating systems, applications, and content be managed and secured by the cloud consumer.

 8) The key takeaway for security architecture is that the lower down the stack the cloud service provider stops, the more security capabilities and management consumers are responsible for implementing and managing themselves.

   There are two types of SLA’s, negotiable and non-negotiable.

9) In the absence of an SLA, the consumer administers all aspects of the cloud under its control.

10) When a non-negotiable SLA is offered, the provider administers those portions stipulated in the agreement.

11) In the case of PaaS or IaaS, it is usually the responsibility of the consumer’s system administrators to effectively manage the residual services specified in the SLA, with some offset expected by the provider for securing the underlying platform and infrastructure components to ensure basic service availability and security.

1.5.1 Cloud Security Reference Model

1) Public or private clouds may be described as external or internal, which may not be accurate in all situations.

2) The notion of a well-demarcated perimeter is an anachronistic concept for most organizations.

3) Ubiquitous connectivity, the amorphous nature of information interchange, and the ineffectiveness of traditional static security controls which cannot deal with the dynamic nature of cloud services, all require new thinking with regard to cloud computing

4) The Jericho Forum has produced a considerable amount of material on the re- perimeterization of enterprise networks, including many case studies

5) The deployment and consumption modalities of cloud should be thought of not only within the context of ‘internal’ versus ‘external’ as they relate to the physical location of assets, resources, and information; but also by whom they are being consumed; and who is responsible for their governance, security, and compliance with policies and standards.


6)  This is not to suggest that the on- or off-premise location of an asset, a resource, or information does not affect the security and risk posture of an organization because they do — but to underscore that risk also depends upon:

   A) The types of assets, resources, and information being managed
   B) Who manages them and how
   C) Which controls are selected and how they are integrated
   D) Compliance issues

   For example, a LAMP9 stack deployed on Amazon’s AWS EC2 would be classified as a public, off-premise, third-party managed IaaS solution, even if the instances and applications/data contained within them were managed by the consumer or a third party. A custom application stack serving multiple business units, deployed on Eucalyptus under a corporation’s control, management, and ownership, could be described as a private, on-premise, self-managed SaaS solution. Both examples utilize the elastic scaling and self-service capabilities of cloud.

The following table summarizes these points:

 

7) Another way of visualizing how combinations of cloud service models, deployment models, physical locations of resources, and attribution of management and ownership, is the Jericho Forum’s Cloud Cube Model

8) The Cloud Cube Model illustrates the many permutations available in cloud offerings today and presents four criteria/dimensions in order to differentiate cloud “formations” from one another and the manner of their provision, in order to understand how cloud computing affects the way in which security might be approached.

9) The Cloud Cube Model also highlights the challenges of understanding and mapping cloud models to control frameworks and standards such as ISO/IEC 27002, which provides “...a series of guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organisation.”

10) Unless cloud providers can readily disclose their security controls and the extent to which they are implemented to the consumer and the consumer knows which controls are needed to maintain the security of their information, there is tremendous potential for misguided risk management decisions and detrimental outcomes.

11) First, one classifies a cloud service against the cloud architecture model. Then it is possible to map its security architecture as well as business, regulatory, and other compliance requirements against it as a gap-analysis exercise. The result determines the general “security” posture of a service and how it relates to an asset’s assurance and protection requirements.


12) The figure below shows an example of how a cloud service mapping can be compared against a catalogue of compensating controls to determine which controls exist and which do not — as provided by the consumer, the cloud service provider, or a third party. 

13) This can in turn be compared to a compliance framework or set of requirements such as PCI DSS, as shown.

14) Once this gap analysis is complete, per the requirements of any regulatory or other compliance mandates, it becomes much easier to determine what needs to be done in order to feed back into a risk assessment framework. This, in turn, helps to determine how the gaps and ultimately risks should be addressed: accepted, transferred, or mitigated.

15) It is important to note that the use of cloud computing as an operational model does not inherently provide for or prevent achieving compliance.

1.5.2 What Is Security for Cloud Computing?

1) Security controls in cloud computing are, for the most part, no different than security controls in any IT environment.

2) An organization’s security posture is characterized by the maturity, effectiveness, and completeness of the risk-adjusted security controls implemented.

3) These controls are implemented in one or more layers ranging from the facilities (physical security), to the network infrastructure (network security), to the IT systems (system security), all the way to the information and applications (application security).

4) Additionally, controls are implemented at the people and process levels, such as separation of duties and change management, respectively.

5) As described earlier in this document, the security responsibilities of both the provider and the consumer greatly differ between cloud service models. 
  
    Example :- Amazon’s AWS EC2 infrastructure as a service offering,  includes vendor responsibility for security up to the hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. 

   The consumer, in turn, is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data.

6) The inverse is true for Salesforce.com’s customer resource management (CRM) SaaS offering. Because Salesforce.com provides the entire “stack,” the provider is not only responsible for the physical and environmental security controls, but it must also address the security controls on the infrastructure, the applications, and the data. This alleviates much of the consumer’s direct operational responsibility.

7) There is currently no way for a naive consumer of cloud services to simply understand what exactly he/she is responsible for [though reading this guidance document should help], but there are efforts underway by the CSA and other bodies to define standards around cloud audit.

8) One of the attractions of cloud computing is the cost efficiencies afforded by economies of scale, reuse, and standardization.

9) To bring these efficiencies to bear, cloud providers have to provide services that are flexible enough to serve the largest customer base possible, maximizing their addressable market.

10) Unfortunately, integrating security into these solutions is often perceived as making them more rigid.

11) This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT.

12) This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls, especially at the network layer.

   In SaaS environments the security controls and their scope are negotiated into the contracts for service; service levels, privacy, and compliance are all issues to be dealt with legally in contracts.

  In an IaaS offering, while the responsibility for securing the underlying infrastructure and abstraction layers belongs to the provider, the remainder of the stack is the consumer’s responsibility.

          PaaS offers a balance somewhere in between, where securing the platform falls onto the provider, but both securing the applications developed against the platform and developing them securely, belong to the consumer. 

13) Understanding the impact of these differences between service models and how they are deployed is critical to managing the risk posture of an organization.


1.5.3 Beyond Architecture: The Areas of Critical Focus

The thirteen other domains which comprise the remainder of the CSA guidance highlight areas of concern for cloud computing and are tuned to address both the strategic and tactical security ‘pain points’ within a cloud environment and can be applied to any combination of cloud service and deployment model.

     The domains are divided into two broad categories: governance and operations.


     A) The governance domains are broad and address strategic and policy issues within a cloud computing environment.

    B)  While the operational domains focus on more tactical security concerns and implementation within the architecture.


Governance Domains:

1) Governance and Enterprise Risk Management :

    The ability of an organisation to govern and measure enterprise risk introduced by cloud computing.

    Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues.

2) Legal Issues: Contracts and Electronic Discovery

      Potential legal issues when using cloud computing.

     Issues touched on in this section include protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws, etc.


3) Compliance and Audit :

     Maintaining and proving compliance when using cloud computing.

     Issues dealing with evaluating how cloud computing affects compliance with internal security policies, as well as various compliance requirements (regulatory, legislative, and otherwise) are discussed here.

     This domain includes some direction on proving compliance during an audit.

4) Information Management and Data Security :

     Managing data that is placed in the cloud.

     Items surrounding the identification and control of data in the cloud, as well as compensating controls that can be used to deal with the loss of physical control when moving data to the cloud, are discussed here. Other items, such as who is responsible for data confidentiality, integrity, and availability are mentioned.


5) Portability and Interoperability :


    The ability to move data/services from one provider to another, or bring it entirely back in-house. 

    Together with issues surrounding interoperability between providers.


6) Traditional Security, Business Continuity and Disaster Recovery :


    How cloud computing affects the operational processes and procedures currently used to implement security, business continuity, and disaster recovery.

    The focus is to discuss and examine possible risks of cloud computing, in hopes of increasing dialogue and debate on the overwhelming demand for better enterprise risk management models.   

    Further, the section touches on helping people to identify where cloud computing may assist in diminishing certain security risks, or entails increases in other areas.


7) Data Center Operations :

    How to evaluate a provider’s data center architecture and operations.

    This is primarily focused on helping users identify common data center characteristics that could be detrimental to on-going services, as well as characteristics that are fundamental to long-term stability.


8) Incident Response, Notification and Remediation :

   
    Proper and adequate incident detection, response, notification, and remediation.

    This attempts to address items that should be in place at both provider and user levels to enable proper incident handling and forensics.

    This domain will help you understand the complexities the cloud brings to your current incident-handling program.   


9) Application Security :


    Securing application software that is running on or being developed in the cloud.

   This includes items such as whether it’s appropriate to migrate or design an application to run in the cloud, and if so, what type of cloud platform is most appropriate (SaaS, PaaS, or IaaS).

10) Encryption and Key Management :

     Identifying proper encryption usage and scalable key management.

     This section is not prescriptive, but is more informational in discussing why they are needed and identifying issues that arise in use, both for protecting access to resources as well as for protecting data.


11) Identity and Access Management :

   Managing identities and leveraging directory services to provide access control.

   The focus is on issues encountered when extending an organization’s identity into the cloud.

   This section provides insight into assessing an organization’s readiness to conduct cloud-based Identity, Entitlement, and Access Management (IdEA).

12) Virtualization :

   The use of virtualization technology in cloud computing.

   The domain addresses items such as risks associated with multi-tenancy, VM isolation, VM co-residence, hypervisor vulnerabilities, etc.

   This domain focuses on the security issues surrounding system/hardware virtualization, rather than a more general survey of all forms of virtualization.

13) Security as a Service :

     Providing third party facilitated security assurance, incident management, compliance attestation, and identity and access oversight.
    Security as a service is the delegation of detection, remediation, and governance of security infrastructure to a trusted third party with the proper tools and expertise.

    Users of this service gain the benefit of dedicated expertise and cutting edge technology in the fight to secure and harden sensitive business operations.   

1.6 Cloud Deployment Models

      Regardless of the service model utilized (SaaS, PaaS, or IaaS), there are four deployment models for cloud services with derivative variations that address specific requirements.

 1) It is important to note that there are derivative cloud deployment models emerging due to the maturation of market offerings and customer demand.

  An example of such is virtual private clouds — a way of utilizing public cloud infrastructure in a private or semi-private manner and interconnecting these resources to the internal resources of a consumer’s datacenter, usually via virtual private network (VPN) connectivity.

 2) The architectural mind-set used when designing “solutions” has clear implications on the future flexibility, security, and mobility of the resultant solution, as well as its collaborative capabilities.

 3) As a rule of thumb, perimeterized solutions are less effective than de-perimeterized solutions in each of the four areas.     

 4) Careful consideration should also be given to the choice between proprietary and open solutions for similar reasons.

Deployment models

   Public Cloud : The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

   Private Cloud : The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or by a third party and may be located on-premise or off-premise.

   Community Cloud : The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, or compliance considerations). It may be managed by the organizations or by a third party and may be located on-premise or off-premise.

   Hybrid Cloud : The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).  

 1.7 Recommendations

  Cloud service delivery is divided among three archetypal models and various derivative combinations.

  The three fundamental classifications are often referred to as the “SPI Model,” where “SPI” refers to Software, Platform or Infrastructure (as a Service), respectively.

  Cloud Software as a Service (SaaS) :

    The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure.

    The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email).

    The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities with the possible exception of limited user-specific application configuration settings.

  
   Cloud Platform as a Service (PaaS) :

     The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider.

      The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. 
    
   
   Cloud Infrastructure as a Service (IaaS) :

     The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which could include operating systems and applications.

     The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

  
 1) The NIST model and this document do not directly address the emerging service model definitions associated with cloud service brokers, those providers that offer intermediation, monitoring, transformation/portability, governance, provisioning, and integration services and negotiate relationships between various cloud providers and consumers.

 2) In the short term, as innovation drives rapid solution development, consumers and providers of cloud services will enjoy varied methods of interacting with cloud services in the form of developing API’s and interfaces and so cloud service brokers will emerge as an important component in the overall cloud ecosystem.

 3) Cloud service brokers will abstract these possibly incompatible capabilities and interfaces on behalf of consumers to provide proxy in advance of the arrival of common, open, and standardized ways of solving the problem longer term with a semantic capability that allows the consumer a fluidity and agility in being able to take advantage of the model that works best for their particular needs.

 4) It is also important to note the emergence of many efforts centered on the development of both open and proprietary API’s, which seek to enable things such as management, security, and interoperability for cloud.

    Some of these efforts include the Open Cloud Computing Interface Working Group, Amazon EC2 API, VMware’s DMTF-submitted vCloud API, Sun’s Open Cloud API, Rackspace API, and GoGrid’s API, to name just a few.

 5) Open, standard API’s will play a key role in cloud portability and interoperability as well as common container formats such as the DMTF’s Open Virtualization Format (OVF).

1.8 Requirements

     Cloud services exhibit five essential characteristics that demonstrate their relation to, and differences from, traditional computing approaches.

  On-demand self-service :

       A consumer can unilaterally provision computing capabilities such as server time and network storage as needed automatically without requiring human interaction with a service provider.


  Broad network access : 

      Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDA’s)12 as well as other traditional or cloud-based software services.

  Resource pooling :
      The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. 

      There is a degree of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

     Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. Even private clouds tend to pool resources between different parts of the same organization.

     
   Rapid elasticity : 

     Capabilities can be rapidly and elastically provisioned — in some cases automatically — to quickly scale out; and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.


    Measured service : 

      Cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, or active user accounts). 

      Resource usage can be monitored, controlled, and reported — providing transparency for both the provider and consumer of the service.

   
  1) The keys to understanding how cloud architecture impacts security architecture are a common and concise lexicon coupled with a consistent taxonomy of offerings by which cloud services and architecture can be deconstructed, mapped to a model of compensating security and operational controls, risk assessment frameworks, and management frameworks; and in turn to compliance standards.


  2)  Understanding how architecture, technology, process, and human capital requirements change or remain the same when deploying cloud-computing services is critical. Without a clear understanding of the higher-level architectural implications, it is impossible to address more detailed issues rationally.