In Russia when we are talking about "Information security" it's often the case to discuss law, regulations, perimeter defending (or it no longer exists again), security products, SOC and even Security as a Service. We don't talk much about such an important area as the Cloud Security, and it is not a regular part of our industry events. However, cloud technologies are confidently moving around the world and I'm convinced that in the near future they'll break the ice in Russia. Just look at .gov services (e.g. we can order a new passport directly from our mobile phone), smart cities, industrial IoT, whatever. Thus clouds will come inevitably. There will be clear future, our controllers will issue regulatory requirements. By the way, without ones it is difficult to force organizations to consider about cloud security, isn't it? No matter what country you're from, it may be usefull to talk about the "golden" standard in cloud security from Cloud Security Alliance - "Security Guidance for Critical Areas of Focus in Cloud Computing" and the CCM - "Cloud Controls Matrix" (a cybersecurity control framework, composed of 133 control objectives that are structured in 16 domains covering all key aspects of the cloud technology). Let's do it with a short review, starting with the Part 1 in this post.
Document CSA Security Guidance for Critical Areas of Focus in Cloud Computing has been developing from 2009 and now the current version is 4.0 (2017), it can be downloaded from official web resource after the registratioin. First of all, document is good because it is by-design based on cloud-native concept and models. It's necessary to clearly understand all key features of the cloud technology and difference from classic IT acrchitecture, otherwise you won't get all tremendous benefts in agility, resiliency, and economy. The Guidance is structured by
The domains are divided into two broad categories: governance and operations. The governance domains are broad and address strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture. I'd like to highlight, that a detailed description about particular security tasks is provided in each domain. It's important and usefull to show how cloud security model can be distinguished from classic on-prem one.
Domain 1. Cloud Computing Concepts and Architectures.
Let's get started with basic concepts. CSA has created the document in accordance with best well-known practices and guidances in the field of cloud computing. I'd like to notice NIST SP 800-145 “Definition of Cloud Computing” and ISO 17789 “Information technology — Cloud computing — Reference architecture”. As for me, the best definition of the main term is contained in the second one: "Cloud computing" - paradigm for enabling network access to a scalable nd elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand. Two key The key techniques to create a cloud are abstraction and orchestration. We abstract the resources from the underlying physical infrastructure to create our pools, and use orchestration (and automation) to coordinate carving out and delivering a set of resources from the pools to the consumers. As you will see, these two techniques create all the essential characteristics we use to define something as a "cloud". In other words, multitenancy is a native property of cloud technologies. Diving deeper, all cloud services can be defined through 5 essentials characteristics, 3 cloud service models, and 4 cloud deployment models.
- Broad network access - means that all resources are available over a network, without any need for direct physical access; the network is not necessarily part of the service
- Rapid elasticity - allows consumers to expand or contract the resources they use from the pool (provisioning and deprovisioning), often completely automatically. This allows them to more closely match resource consumption with demand (for example, adding virtual servers as demand increases, then shutting them down when demand drops)
- Measured service - meters what is provided, to ensure that consumers only use what they are allotted, and, if necessary, to charge them for it. This is where the term utility computing comes from, since computing resources can now be consumed like water and electricity, with the client only paying for what they use
- On-demand self-service - means that consumers provision the resources from the pool by themselves, without having to talk to a human administrator
- Resource pooling - means that the provider abstracts resources and collects them into a pool, portions of which can be allocated to diﬀerent consumers (typically based on policies)
- SaaS - Software as a Service – is a full application that’s managed and hosted by the provider, consumers access it with a web browser, mobile app, or a lightweight client app
- PaaS – Platform as a Service – abstracts and provides development or application platforms, such as databases, application platforms (e.g. a place to run Python, PHP, or other code), file storage and collaboration, or even proprietary application processing (such as machine learning, big data processing, or direct Application Programming Interfaces (API) access to features of a full SaaS application)
- IaaS – Infrastructure as a Service – oﬀers access to a resource pool of fundamental computing infrastructure, such as compute, network, or storage
- 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-premises or oﬀpremises
- Community cloud – the cloud infrastructure is shared by several organizations and supports a specifc 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-premises or oﬀ-premises
- 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)
As a result, cloud service models can be represented in the following diagram:
Finally, it's important to mention about logical layers model based on functionality. This is useful to illustrate the diﬀerences between the diﬀerent computing models themselves. From bottom-to-top they can be divided into
4 logical levels:
- Infrastructure – the core components of a computing system: compute, network, and storage. The foundation that everything else is built on. The moving parts.
- Metastructure – the protocols and mechanisms that provide the interface between the infrastructure layer and the other layers. The glue that ties the technologies and enables management and confguration
- Applistructure – the applications deployed in the cloud and the underlying application services used to build them. For example, Platform as a Service features like message queues, artifcial intelligence analysis, or notifcation services.
- Infostructure – the data and information. Content in a database, fle storage, etc.
The key diﬀerence between cloud and traditional computing is the metastructure. Cloud metastructure includes the management plane components, which are network-enabled and remotely accessible. Another key diﬀerence is that, in cloud, you tend to double up on each layer. Infrastructure, for example, includes both the infrastructure used to create the cloud as well as the virtual infrastructure used and managed by the cloud user. Now it's time to move closer to the security.
Cloud Security Scope and Models
In each specific cloud service model, it is logical to divide the areas of responsibility for security between the provider and the client.
- SaaS – the cloud provider is responsible for nearly all security, since the cloud user can only access and manage their use of the application, and can’t alter how the application works. For example, a SaaS provider is responsible for perimeter security, logging/monitoring/auditing, and application security, while the consumer may only be able to manage authorization and entitlements.
- PaaS – the cloud provider is responsible for the security of the platform, while the consumer is responsible for everything they implement on the platform, including how they confgure any oﬀered security features. The responsibilities are thus more evenly split. For example, when using a Database as a Service, the provider manages fundamental security, patching, and core confguration, while the cloud user is responsible for everything else, including which security features of the database to use, managing accounts, or even authentication methods.
- IaaS – just like PaaS, the provider is responsible for foundational security, while the cloud user is responsible for everything they build on the infrastructure. Unlike PaaS, this places far more responsibility on the client. For example, the IaaS provider will likely monitor their perimeter for attacks, but the consumer is fully responsible for how they defne and implement their virtual network security, based on the tools available on the service.
Obviously, in each certain project the provider and the client have to negotiate about areas of responsibility. It’s less important if any particular cloud provider oﬀers a specifc security control, as long as you know precisely what they do oﬀer and how it works. You can fll the gaps with your own controls, or choose a diﬀerent provider if you can’t close the controls gap. Your ability to do this is very high for IaaS, and less so for SaaS. This is the essence of the security relationship between a cloud provider and consumer. What does the provider do? What does the consumer need to do? Does the cloud provider enable the consumer to do what they need to? What is guaranteed in the contract and service level agreements, and what is implied by the documentation and specifcs of the technology? The Cloud Security Alliance (CSA) provides two tools to help meet these requirements:
- The Consensus Assessments Initiative Questionnaire (CAIQ) - a standard template for cloud providers to document their security and compliance controls.
- The Cloud Controls Matrix (CCM) - which lists cloud security controls and maps them tomultiple security and compliance standards. The CCM can also be used to document securityresponsibilities. This tool will be reviewed in next parts.
Cloud security models are tools to help guide security decisions. The term “model” can be used a
little nebulously, so for our purposes we break out the following
- Conceptual models or frameworks – include visualizations and descriptions used to explain cloud security concepts and principles, such as the CSA logical model in this document.
- Controls models or frameworks – categorize and detail specifc cloud security controls or categories of controls, such as the CSA CCM.
- Reference architectures – are templates for implementing cloud security, typically generalized (e.g. an IaaS security reference architecture). They can be very abstract, bordering on conceptual, or quite detailed, down to specifc controls and functions.
- Design patterns – are reusable solutions to particular problems. In security, an example is IaaS log management. As with reference architectures, they can be more or less abstract or specifc, even down to common implementation patterns on particular cloud platforms.
Oviously, architecture solutions and certain security measures strongly depend on specific provider, using techlogies and basic requirements. However, any organization can follow regular steps to achieve results, there is a relatively straightforward, high-level
process for managing cloud security:
- Identify necessary security and compliance requirements, and any existing controls
- Select your cloud provider, service, and deployment models
- Define the architecture
- Assess the security controls
- Identify control gaps
- Design and implement controls to fill the gaps
- Manage changes – this is an absolutely necessary step, because security is not a project, but a continuous process, so you need to review your model and controls
In summary, when we are about to start cloud security project, it will be useful to emphazise common but
- Really clearly understand the diﬀerences between cloud computing and traditional infrastructure or virtualization, and how abstraction and automation impact security
- Use existing best practices, models and tools, such as NIST model for cloud computing and the CSA reference architecture
- Use tools such as the CSA Consensus Assessments Initiative Questionnaire (CAIQ) to evaluate and compare cloud providers
- Ensure, that cloud provider clearly document its security controls and features and publish them using tools like the CSA CAIQ
- Use tools like the CSA Cloud Controls Matrix to assess and document cloud project security and compliance requirements and controls, as well as who is responsible for each
- Use a cloud security process model to select providers, design architectures, identify control gaps, and implement security and compliance controls
In the introductory Domain 1 CSA authors describe the fundamentals. They help us answer two main questions that should be in our mind before launching a cloud (of course with security) project:
- What's it all about?
- What should we start with?
The following 13 Domains are more specific and directly focus on strategic and tactical cloud security implementations.
To be contunued. Stay tuned.
Stay on the light side. R.Z.