Cloud Security. Cloud Security Alliance (CSA) Guidance. Part 1. || Безопасность Облаков. Лучшие практики. Фреймворк от Cloud Security Alliance (CSA). Часть 1.

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. 

Introduction

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 14 domains: 

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.

Essentials characteristics:

1. 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
2. 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)
3. 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
4. On-demand self-service - means that consumers provision the resources from the pool by themselves, without having to talk to a human administrator
5. Resource pooling - means that the provider abstracts resources and collects them into a pool, portions of which can be allocated to different consumers (typically based on policies)

Service models:

1. 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
2. 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)
   
   
   
3. IaaS – Infrastructure as a Service – offers access to a resource pool of fundamental computing infrastructure, such as compute, network, or storage
   

Deployment Models:

1. 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
2. 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 offpremises
3. 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 off-premises
4. 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 differences between the different computing models themselves. From bottom-to-top they can be divided into

4 logical levels:

1. Infrastructure – the core components of a computing system: compute, network, and storage. The foundation that everything else is built on. The moving parts.
2. 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
3. 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.
4. Infostructure – the data and information. Content in a database, fle storage, etc.

The key difference between cloud and traditional computing is the metastructure. Cloud metastructure includes the management plane components, which are network-enabled and remotely accessible. Another key difference 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.

1. 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.
2. 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 offered 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.
3. 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 offers a specifc security control, as long as you know precisely what they do offer and how it works. You can fll the gaps with your own controls, or choose a different 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:

1. The Consensus Assessments Initiative Questionnaire (CAIQ) - a standard template for cloud providers to document their security and compliance controls.
2. The Cloud Controls Matrix (CCM) - which lists cloud security controls and maps them to
   multiple security and compliance standards. The CCM can also be used to document security
   responsibilities. 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 

model types:

1. 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.
2. Controls models or frameworks – categorize and detail specifc cloud security controls or categories of controls, such as the CSA CCM.
3. 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.
4. 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:

1. Identify necessary security and compliance requirements, and any existing controls 
   
2. Select your cloud provider, service, and deployment models
3. Define the architecture
4. Assess the security controls
5. Identify control gaps
6. Design and implement controls to fill the gaps
7. 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 

important recommendations:

1. Really clearly understand the differences between cloud computing and traditional infrastructure or virtualization, and how abstraction and automation impact security
2. Use existing best practices, models and tools, such as NIST model for cloud computing and the CSA reference architecture
3. Use tools such as the CSA Consensus Assessments Initiative Questionnaire (CAIQ) to evaluate and compare cloud providers
4. Ensure, that cloud provider clearly document its security controls and features and publish them using tools like the CSA CAIQ
5. 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
6. 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:

1. What's it all about?
2. 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.

Когда мы поднимаем тему «Информационной безопасности» в России обычно обсуждаются законы, регуляторы, периметр и в очередной раз его отсутствие, средства защиты информации, даже, прости господи, SOC и аутсорсинг ИБ. Про безопасность облачной инфраструктуры у нас говорить особо не принято, и эта тема обычно не в топе отраслевых мероприятий. Я верю, что этот тренд сломается в обозримом будущем. Посмотрите хотя бы на то, что представляют из себя современные «Госуслуги», куда развиваются «Безопасные города», «Умные производства» и т.п. И вот тогда заживем: нашим регуляторам некуда будет деваться, придется писать требования и рекомендации для облаков, ведь без них у нас дела идут туго, «поднадзорные» бездельничают. Откуда брать идеи? Поскольку в Рунете я не смог найти обзорного описания нижеуказанных документов, в сегодняшней заметке поговорим о «золотом» стандарте в этой области - документе от Cloud Security Alliance (Международное объединение по безопасности облаков) – «Security Guidance for Critical Areas of Focus in Cloud Computing» и немного о CCM - Cloud Controls Matrix (набор конкретных мер по безопасности облаков).

Введение

Документ CSA Security Guidance for Critical Areas of Focus in Cloud Computing разрабатывается с 2009 года, текущая актуальная редакция v.4.0 от 2017 года (загрузка доступна на официальном сайте после короткой процедуры регистрации). Хорош он, прежде всего, тем, что сразу отталкивается от cloud-native моделей и в первых разделах предупреждает о том, что «нельзя так просто взять и перенести классические приложения в облако», в этом нет смысла, т.к. нивелируются преимущества облаков. Документ структурирован по 14 доменам:

1. Архитектура и концепции облачных вычислений
2. Управление рисками
3. Юридические вопросы, сервисные договоры, доступы третьих лиц
4. Соответствие требованиям и аудиты
5. Управление информацией (данными) и доступом
6. Менеджмент структуры управления и планирование восстановления в облаке
7. Безопасность облачной инфраструктуры
8. Безопасность виртуализации и контейнеризации
9. Реагирование на инциденты
10. Безопасность приложений
11. Защита данных и шифрование
12. Управление правами и доступом
13. Безопасность как сервис
14. Сопутствующие облакам технологии

Домены 1-5 образуют группу управленческих мер (Governance), которые покрывают широкий спектр стратегических (и даже политических) вопросов, связанных с облаками, позволяют выработать верхнеуровневые концепции. Домены 6-14 отвечают за операционную безопасность (Operations), то есть направлены на решение тактических и технических задач, описывают конкретные защитные механизмы в облачной инфраструктуре.Важно, что в каждом домене описывается, в том числе, как и почему рассматриваемая задача безопасности для облака отличается от задачи для классической корпоративной (on-prem) архитектуры. 

Домен 1. Архитектура и концепции облачных вычислений (Cloud Computing Concepts and Architectures).

Начнем с базовых понятий и архитектур облаков. CSA разрабатывал документ с учетом лучших общепризнанных практик по облакам, синхронизирован с соответствующими понятиями и определениями. Основными являются NIST SP800-145 “Definition of Cloud Computing” («Облачные вычисления») и ISO 17789 “Information technology — Cloud computing — Reference architecture” («Информационные технологии. Облачные вычисления. Эталонная архитектура»). Лично мне нравится определение основного термина из второго, оно более лаконичное: «Облачные вычисления» (“Cloud computing”) – это концепция осуществления удаленного доступа к масштабируемой и гибкой инфраструктуре, состоящей из разделяемых физических или виртуальных ресурсов, с возможностью самостоятельного управления ими пользователем облака (клиентом). Двумя ключевыми параметрами, определяющими облако, являются абстракция и оркестрация. Мы абстрагируемся от конкретных физических ресурсов для создания «облачного пула ресурсов» и используем автоматизированную оркестрацию для координации, выделения и доставки ресурсов из этого пула пользователям (облачным клиентам). Второе как раз и отличает облака и традиционную виртуализацию, ведь облака – многопользовательские (multi-tenant) по определению, где каждый пул ресурсов разграничен друг от друга. Погружаясь глубже, NIST определяет облака через 5 основных характеристик, 3 сервисные модели и 4 модели развертывания. 

Основные характеристики (essentials characteristics):

1. Доступ отовсюду (Broad network access) – клиент облачного провайдера имеет доступ к своему пулу отовсюду (где есть интернет), без необходимости каким-либо образом организовывать специальный канал до облака
2. Быстрое масштабирование (Rapid elasticity) – позволяет клиентам увеличивать или уменьшать потребляемые облачные ресурсы самостоятельно и желательно полностью автоматически (в пределах условий использования и контракта) в зависимости от реальной потребности
3. Измеримое потребление (Measured service) – означает обязанность облачного провайдера измерять (биллинговать) потребляемые клиентом сервисы и начислять соответствующую плату за их использование (подобно воде и электричеству в квартирах)
4. Самостоятельное управление своим пулом (On-demand self-service) – клиенты провайдера не привлекают администраторов, а сами управляют своими ресурсами
5. Создание пула ресурсов (Resource pooling) – облачный провайдер создает пулы ресурсов, которые выделяет своим клиентам

Сервисные модели (service models):

1. Софт как сервис (SaaS - Software as a Service) – предоставление доступа к конкретному приложению (по web, через мобильное приложение или иным удаленным способом)
2. Платформа как сервис (PaaS – Platform as a Service) – предоставление абстрактной платформы (базы данных, интерпретатора какого-либо языка и т.п.), файлового хранилища или интерфейса (например, API) к технологии (машинное обучение, работа с большими данными)
   
   
   
3. Инфраструктура как сервис (IaaS – Infrastructure as a Service) – предоставление доступа к базовым элементам инфраструктуры: компьютер, сеть или хранилище
   

Модели развертывания (Deployment Models):

1. Публичное облако (Public cloud) – инфраструктура предоставляется облачным провайдером широкому кругу клиентов (не только лишь в рамках одной организации)
2. Частное облако (Private cloud) - инфраструктура предоставляется в рамках одной организации (или группы компаний), при этом облако может управляться (располагаться) как самой организацией, так и аутсорсинговым провайдером (но только в интересах этой организации)
3. Облако сообщества (Community cloud) – инфраструктура предоставляется нескольким организациям в рамках созданного ими объединения на основании общих интересов (одна миссия, задача, требования или политики безопасности и т.п.), при этом облако может управляться (располагаться) как одной из таких организаций, так и аутсорсинговым провайдером (но только в интересах этих организаций)
4. Гибридное облако (Hybrid cloud) – облачная инфраструктура построена исходя из комбинации моделей (1-3), но объединена общим технологическим подходом. Гибридным облаком также часто называют необлачный ЦОД, подключенный к облачному провайдеру.
   
   
   

Таким образом, обобщая, архитектурно модели предоставления сервисов можно представить следующим образом: 

Наконец, стоит упомянуть о логической модели облачных сред, чтобы оперировать разными уровнями абстракции, исходя из функциональности. 

Выделяют 4 логических уровня от нижнего – к верхнему:

1. Инфраструктура (Infrastructure) – компьютеры, сети, хранилища, т.е. фундамент всех остальных логических уровней
2. Метаструктура (Metastructure) – протоколы и механизмы, обеспечивающие интерфейс обмена данными между уровнем инфраструктуры и остальными уровнями (связка базовых технологий и способов управления)
3. Апплиструктура (Applistructure) – приложения и сервисы, развернутые в облаке для работы пользователей (например, к ним относятся PaaS инструменты, такие как ML/AI-анализ, службы уведомлений, сервис очереди сообщений)
4. Инфоструктура (Infostructure) – информация и данные (в базах данных, хранилищах и т.п.)

Одно из ключевых отличий облаков от традиционной инфраструктуры – это наличие слоя Метаструктура, который обеспечивает механизмы конфигурирования компонентов облака и удаленного управления. Другое важное отличие – удвоение «забот» на каждом слое. Это означает, что слой Инфраструктура, например, предполагает управление как инфраструктурой для поддержания самого облака, так и для клиентского сегмента. Теперь – переходим ближе к безопасности.

Границы ответственности и модели безопасности.

В зависимости от сервисной модели облачной услуги логично разделить и зоны ответственности за безопасность между клиентом и провайдером.

 

1. SaaS – на провайдере лежит максимум ответственности за безопасность, поскольку при такой модели он предоставляет клиенту софт и тот должен заботится, пожалуй, только о ролях и доступе, тогда как защиту периметра, логирование, аудит, защиту приложения обеспечивает провайдер
2. PaaS – провайдер отвечает за безопасность платформы (например, патчинг БД, безопасность самого сервера БД), а клиент – за все остальное, включая пользователей (в т.ч. администраторов), схемы управления доступом и безопасности
3. IaaS – клиент полностью отвечает за безопасность выделенной ему виртуальной инфраструктуры, провайдер защищает только периметр и средства построения этой инфраструктуры

Конечно, в каждом конкретном проекты провайдер и клиент должны договариваться о том, как именно будут разграничены зоны ответственности. При этом выбор защитных мер сильно зависит от возможностей самого облака. Многие провайдеры предоставляют максимально полный набор защитных сервисов для своих клиентов по тем же самым трем моделям на выбор. Однако, никто не запрещает клиенту внедрять свои собственные решения. CSA предоставляет 2 удобных инструмента, которые помогут провайдеру и клиенту документировать разделение зон ответственности и выбрать необходимый набор мер безопасности. Первый – Чек-лист с вопросами для оценки соответствия и документирования (Consensus Assessments Initiative Questionnaire (CAIQ)). Второй – Матрица мер безопасности для облаков (Cloud Controls Matrix (CCM)), о ней мы еще поговорим отдельно.

Чтобы построить комплексную безопасность облаков, очевидно, необходим некий инструментарий (framework): стандарты, инструкции, руководства, примеры, иными словами, модель безопасности. Говоря о моделях безопасности и способах их построения, необходимо различать следующие

уровни абстракции:

1. Концептуальная модель (Conceptual models or frameworks) – нужна, чтобы принять базовые архитектурные принципы безопасности (например, утвердить, что мы отталкиваемся от модели 4-х логических уровней, которые описывали чуть выше)
2. Модель мер безопасности (Controls models or frameworks) – категорирует и детализирует конкретные применяемые меры безопасности (организационные и технические), если необходимо – в соответствии со стандартами или нормативными требованиями
3. Эталонная архитектура (Reference architectures) – шаблоны (и примеры) построения архитектуры безопасности для конкретной сервисной модели (SaaS, PaaS и IaaS), могут описываться конкретные решения или классы средств защиты
4. Шаблоны проектирования защитных мер (Design patterns) – описывают реализацию конкретной технологии, направленной на решение какой-либо задачи безопасности (например, лог-менеджмент, защита приложения и т.п.), могут описываться конкретные решения или классы средств защиты

Очевидно, что архитектурные решения и конкретные меры безопасности сильно зависят от специфики облачного провайдера, технологий и предъявляемых изначально требований. В общем виде клиенту рекомендуется в следующей последовательности выстраивать 

процессы безопасности:

1. Определение требований (Identify requirements) – определение и утверждение необходимых верхнеуровневых требований по безопасности, в том числе исходя из специфики нормативного регулирования, каких-либо внутренних документов и собственного опыта (видения)
2. Выбор провайдера и моделей (Select Provider, Service, and Deployment Models) – важно не просто выбрать лучшего провайдера на рынке, но и сразу учитывать потребности в конкретных сервисных услугах и моделях развертывания
3. Определить архитектуру (Define the architecture)
4. Оценить существующие меры безопасности (Assess the security controls)
5. Выявить недостающие меры безопасности (Identify control gaps)
6. Спроектировать и внедрить недостающие меры безопасности (Design and implement controls)
7. Управлять изменениями (Manage changes) – безопасность – это, несомненно, не проект, а процесс, поэтому необходимо периодически оценивать изменившуюся обстановку и пересматривать модель и меры безопасности

Чтобы помочь подступиться к теме облачной безопасности, ниже приведены несколько 

полезных и важных рекомендаций:

1. Важно действительно понять разницу между традиционной инфраструктурой, классической виртуализацией и облачной парадигмой, а также как на безопасность влияют абстракция и оркестрация
2. Используйте уже существующие подходы, модели и лучшие практики построения облачной инфраструктуры и обеспечения безопасности (NIST, CSA)
3. Используйте CSA CCIQ и CCM для формализации отношений с провайдером
4. Облачный провайдер обязан предоставить полную информацию обо всех принимаемых мерах безопасности, в идеале, если клиенту предоставляется выбор из них
5. Нужно разграничить зоны ответственности (можно использовать CCM) между провайдером и клиентом, с учетом требований и нормативных особенностей в разрезе каждой меры безопасности
6. Двигайтесь по описанной выше пошаговой последовательности при построении системы безопасности (выбирайте провайдера, определяйте архитектуру, стройте модели и т.д.)

В вводном Домене 1 описаны базовые вещи, позволяющие ответить на 2 главных вопроса при выборе любой новой для себя технологии. Первый – «что это такое?». Второй –«с чего начать?». Следующие 13 Доменов уже более конкретные и посвящены непосредственно вопросам построения облачной безопасности.

Продолжение следует, не переключайтесь.

Оставайтесь на светлой стороне. R.Z.