How services can make using passwords convenient || Как сервисам сделать использование паролей удобным

 

Тема создания безопасных, надежных, но в тоже время "запоминабельных" паролей, пожалуй, стара, как мир. Шутка ли, до сих пор встречаешь в реальной жизни те самые стикеры на мониторах, записки в блокноте на столе, а так же... пароли и пин-коды открытым текстом в адресной книге или в заметках на телефоне, да еще и выведенные виджетом на главный экран. Знакомо? Значит, заметка имеет шанс оказаться полезной. Но что, если немного подумать о пользователях и не "вешать" всю ответственность только лишь на них? Рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management, о выдержках из которых сегодня пойдет речь, также не новые, однако, регулярно обновляются (последняя редакция от 2020 года). Кроме того, в последнее время я фиксирую повышенное внимание к этой теме со стороны СМИ и в целом людей вокруг.

 

Безопасность должны быть удобной - я это повторяю постоянно. Коллеги из NIST выпустили рекомендации главным образом для порталов, приложений и сервисов, которыми мы с вами пользуемся. Следуя им, пользователям будет выгоднее и легче использовать надежные пароля, при этом не нужно требовать от них постоянного усложнения, лишних действий и длиннющих инструкций. За некоторые положения реально хочется пожать руку, ведь они развенчивают кучу мифов.

На самом деле, публикация NIST большая и охватывает все возможные аспекты жизненного цикла "секретов", а также 9 типов аутентификации. Мы же сегодня - исключительно про пароли (Memorized Secret Authenticators).

1. Пароли должны быть не менее 8 символов, если придумываются пользователем сервиса и не менее 6, если создаются генератором (например, встроенным в сам сервис), они могут состоять только из цифр.
2. Сервису рекомендуется автоматически проверять, не "засветились" ли пароли в слитых базах
3. Сервис не должен разрешать использовать "словарные" и очень уж простых простые пароли, благо сравнение с таким справочником сделать несложно, они есть в открытом доступе
4. Сервис должен запрещать пароли, содержащие имя пользователя или его часть
5. Отдельно оговаривается то, что для нашего уха (профдеформированного разного рода РД и НПА) может показаться странным: никаких дополнительных требований, кроме длины, к паролю предъявлять не стоит (разные наборы символов и т.п.). 
6. Сервис должен технически предоставить пользователю возможности придумать пароль длиной 64 символа (или больше)
7. В паролях должны поддерживаться все символы ASCII [RFC 20], включая пробелы
8. Unicode [ISO/ISC 10646] кодировка также должна поддерживаться (эмодзи в том числе), включая такую нормализацию, при которой 1 введенный символ в UNICODE эквивалентен 1 в ASCII
9. Запрещаются всякого рода всплывающие подсказки (помните, в прошлых версиях Windows были такие?) на формах ввода логина/пароля
10. Напротив, сервис должен объяснить пользователю, чтобы тот не использовал подсказки вида "имя питомца, фамилия матери и т.п." и не мог используя лишь только их сбросить пароль
11. Сервису необходимо приводить примеры пользователю и объяснять, почему выбранный им пароль вдруг не безопасен
12. Количество неверных попыток ввода пароля должно быть лимитировано. Приводится конкретное довольно большое число - 100, с оговоркой, что лучше использовать дополнительные механизмы (капча, лимит времени между попытками и т.п.)
13. Еще одно разрушение мифов: сервисы не должны требовать принудительной смена пароля периодически (раз в месяц, год и т.п.). Вместо этого необходимо мониторить утечки паролей и своевременно предупреждать пользователя о возможной компрометации.
14. Вопреки расхожему мнению, сервисы должны разрешать функцию "вставить" при вводе пароля. Иначе пользователи вместо сложного пароля из менеджера паролей будут придумывать и использовать менее сложные.
15. Сервис должен позволять посмотреть введенный "звездочками" (*) пароль, чтобы пользователь проверил его корректность. Также актуальным (особенно для мобильных устройств) будет показывать каждый вводимый символ на несколько секунд.
16. К сервису также предъявляются требования по надежному хранению пароля и защите при его запросе (передаче), такие как хэш с "солью", шифрование связи и т.п.

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

Читайте также: MFA. Часть 1, MFA. Часть 2

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

 

"How to set a strong, unique and memoriaable user password" - this topic has been winning today the first lines in articles about cybersecurity. It often happens that I still see stickers on monitors, notes written on a piece of paper and.... for sure, passwords and PINs written by plain text in the address book, notes app or even home screen widget. However, what if you think a little about the users and don't just give them all the full responsibility? Issued by NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management offers recommendations for service providers, portals and others whether they are cloud based or on-premises. This is not a new document, but it is periodically updated (the latest version is dated 2020) and is still relevant.

Security should be comfortable, I keep saying that. It is gratifying that the guys from NIST worrying about users created best practices for services. Following them, it will be more profitable and easier for users to use well-made passwords, while you do not need to require them to constantly complicate, unnecessary actions and lengthy instructions. For some provisions, I really want to shake hand, because they do debunk a lot of myths.

Actually NIST SP 800-63B contains many aspects of the password management lifecycle and 9 types of authentication. Let me talk today about the only one of them 

(Memorized Secret Authenticators).

1. Passwords must be at least 8 characters long if they are created by the user, and at least 6 characters long if they are generated automatically. Important: Passwords may be entirely numeric
2. The service is recommended to check passwords based on their appearance in the black list of compromised values 
3. The service should not allow the use of "dictionary" or simple passwords (111, aaaa, qwerty, etc.). Fortunately, there are many such lists on the Internet to check.
4. The service sholud prohibit passwords that contain the username or part of it
5. Very important (and sometimes a popular myth): No other complexity requirements for memorized secrets should be imposed (like variety of chars, case, digits). 
6. The service shuold technically support the use of passwords of at least 64 characters in length
7. All printing ASCII [RFC 20] characters should be acceptable, including spaces
8. Unicode [ISO/ISC 10646] characters (including emojis!) should be acceptable, including normalization and equal number of symbols (1 UNICODE = 1 ASCII)
9. The service shall not permit the user to store a “hint” that is accessible to an unauthenticated claimant (Do you remember hints in earlier Windows versions on the login page?)
10. Conversely, the service shall not prompt subscribers to use specific types of information and help them not to use typical phrases (e.g., “What was the name of your first pet?”)
11. The service should show examples and explain to users why his or her password is not secure and refuse to use it if it matches a blacklist or dictionary
12. The service shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account (in fact, the number given is quite high - 100, however, it's good practice to use additional mechanisms such as captcha, time limit between attempts, etc.)
13. Ones more myths breaking: the service should not require passwords to be changed arbitrarily (e.g., periodically). Instead the service shall force a change if there is evidence of compromise of the authenticator.
14. The service should permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
15. The service should offer an option to display the secret — rather than a series of dots or asterisks ("*"). It's also useful to permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry (particularly applicable on mobile devices).
16. The service also has requirements for reliable password storage and protection when it is requested (transmitted), such as a hash with a "salt", communication encryption, etc.

These recommendations are based on practical experience and many (especially large services) have already implemented them. However, if you are designing your own service or application, it is useful to familiarize yourself with it.

See also: MFA. Part 1, MFA. Part 2

Stay on the light side. R.Z.

The IT Roadmap for Cybersecurity by Gartner || Свежий гайд Gartner IT Roadmap for Cybersecurity.

Совсем недавно аналитическое агентство Gartner выпустило верхеуровневое руководство по построению ИБ в компаниях (The IT Roadmap for Cybersecurity (excerpt)). Предлагаю вашему вниманию кратенький обзор с моими комментариями и выводами. 

Уважаемые коллеги определяют три ключевых вопроса для каждой новой инициативы по кибербезопасности:

1. Как она будет влиять на усиление устойчивости бизнеса и достижение целей компании, при снижении рисков
2. Как придерживаться ориентированного на результат подхода для обоснования приоритетов и вложений в кибербезопасность
3. Какие подразделения должны быть вовлечены

На основании опыта работы с клиентами по всему миру Gartner определяет ключевые стадии для запуска каждого нового проекта по ИБ, которые включают 5 шагов.

Следование этим шагам поможет как упорядочить движение в рамках самой активности, так и прозрачно вовлечь все заинтересованные стороны, в том числе для понимания со стороны руководства. Кратко рассмотрим каждый из указанных шагов.

Построение стратегии

Этот шаг необходим для постановки целей и приведения конкретных бизнес-кейсов, которые решает проект ИБ. Конкретные задачи таковы:

1. Описание ключевых бизнес-приоритетов проекта (согласование с миссией), определение технологических, организационных предпосылок и угроз-драйверов
2. Определение целей проекта, его значимости, а так же ключевых вовлеченных людей со стороны менеджмента, их ролей и ответственности
3. Выбор конкретных мер (контролей) для реализации проекта, в соответствии со стратегией и одним (или несколькими) стандартом (фреймворком или требованием)
4. Получение обратной связи от менеджмента, корректировка целей, утверждение дорожной карты (или иного документа) по проекту

Важным итогом этапа должно стать общее понимание целей и бенефитов проекта ИБ всех вовлеченных руководителей, включая их формальное согласование.

Разработка плана действий

Конечно, план может варьироваться в зависимости от компании и конкретного проекта ИБ, но придерживаться стоит следующих задач:

1. Комплексный анализ безопасности: выявление уязвимостей, пентест и т.п.
2. По итогам отчета формирование картины текущего состояния ИБ, определить, что необходимо сделать, чтобы достичь целей реализуемого проекта (см. шаг "Построение стратегии")
3. Определение и согласование бюджета и ресурсов на проект со стороны руководства компании
4. Разработка архитектуры безопасности и определение конкретных решений

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

Начало выполнения

Далее важно определить структуру команду и роли на проект. Задачи следующие:

1. Оценка и выбор возможностей команды, инструментов и технологий
2. Распределение ролей внутри команды, с обязательным процессом согласования и информирования всех вовлеченных руководителей
3. Подтверждение необходимых для проекта компетенций у членов команды и, при необходимости, их наращивание
4. Выбор метрик и форм отчетности для улучшения управляемости проекта

Важно отметить, что четкость распределения задач и информированность всех участников (включая руководителей) - это то, чего часто не хватает при реализации проектов ИБ.

Разработка и непрерывное повышение зрелости важных программ (процессов)

1. Разработка процесса реагирования на инциденты
2. Разработка процесса мониторинга и борьбы с угрозами (в том числе целевыми атаками)
3. Внедрение процесса управления навыками кибербезопасности среди сотрудников и проведение тренингов
4. Разработайте четкий план по отчетности и коммуникациям в случае инцидентов

Обратите внимание, что именно указанные выше процессы должны быть спланированы в обязательном порядке, про них нередко забывают при реализации проектов ИБ.

Пересмотр и оптимизация

1. Определение способа донесения ценности (результатов) проекта высшему руководству компании
2. Сбор и тщательный анализ метрик (см. предыдущий шаг) с целью повышения эффективности, проведения каких-либо изменений в проекте
3. Пересмотр и переоценка нового (актуального) уровня зрелости ИБ, чтобы внести корректировки в проект

Дополнительно Gartner советую вовлекать в проекты ИБ (кроме, конечно CISO и CIO) команды со следующими ролями:

1. Менеджера проекта со стороны ИБ (Application leader) - ключевая роль по непосредственной реализации проекта
2. Менеджер по качеству (процессам) в компании (Enterprise architecture leader) - поможет грамотно встроить проект ИБ в общие процессы компании
3. Менеджер по инфраструктуре (Infrastructure and operations leader) - поможет встроить конкретные элементы проекта ИБ в текущую инфраструктуру компании
4. Менеджер по рискам (Security and risk leader) - поможет встроить проект ИБ в текущую модель управления рисками и соответствия требованиям
5. Команда инженеров (Technical professional team) - реализует конкретные технические меры проекта ИБ, если нужно - дорабатывает архитектуру

В предложенной Gartner модели можно увидеть элементы классического цикла Деминга (Plan - Do - Check - Act), что облегчит ее встраивание в текущие процессы компании. Возможно, для кого-то модель будет банальной, но есть уверенность, что не в каждой компании (особенно SMB) реализация новых проектов ИБ до конца поставлена на "рельсы". 

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

 

Recently research and advisory company Gartner has issued top-level guidance so-called The IT Roadmap for Cybersecurity (excerpt). I offer you this brief overview with my comments and conclusions. Analytics from Gartner define three key questions for the new cybersecurity initiative:

1. How will this support business resilience and growth goals while reducing risk?
2. How can we use an outcome-driven approach to establish cybersecurity priorities and investments?
3. Which leaders and teams need to be involved?

Based on clients experience all around the world Gartner suggests to establish main stages for launching every new cybersecurity projecs, which include five steps:

Following these steps will help you to set objectives, to arrange activities and to engage all necessary teams. Moreover, this approach would be useful for aligning managers and all stakeholders. Let's take a look at these steps in a bit more detail.

This is necessary to set goals and identify valuable business cases addressed by the cybersecurity initiative. Specific tasks:

1. Understand key business priorities, define program mission and vision and identify business, technology and threat drivers
2. Identify goals, program value and key stakeholders’ roles and responsibilities
3. Define security controls in line with organizational strategies and map them to a standardized security framework
4. Get stakeholder feedback, define key objectives and finalize initial summary of security strategy document

An important outcome of the stage should be a common understanding of the goals and benefits of the is project for all involved managers, including their formal approval.

Obviously, plan may vary due to particular company and certain project. However it's a good practice to follow these tasks: 

1. Conduct vulnerability assessment and penetration testing
2. Establish current maturity baseline, define target state and conduct gap analysis
3. Get executive or board buy-in and resource backing
4. Develop security architecture, policy framework and solution layer

The developed plan will allow you to determine the focus and not be distracted by non-priority tasks within the project.

Before starting the project it's important to design and adjust team structure. Tasks are as follows:

1. Integrate capabilities, tools and technologies
2. Establish security team roles and responsibilities and identify stakeholders to be accountable, consulted and informed
3. Develop critical competencies and train for desired of missing skills
4. Use metrics and incentives to drive accountability among owners

I'd like to highlight that a clear tasks setting and awareness of all participants (including managers and stakeholders) is something that is often lacking in the implementation of information security projects.

Maintain accountability and assurance through governance. Selected tasks include:

1. Develop critical incident response capability and an action plan in case of breaches
2. Develop a program structure to monitor and combat advanced threats
3. Instill a culture of secure employee behavior and initiate tailor training and awareness campaigns
4. Develop advanced reporting and response and craft a communications plan for cyber breaches

Please note that the above-mentioned processes must be planned without fail, and they are often forgotten when implementing information security projects.

Communicate program value. Selected tasks include:

1. Create a plan to communicate value to the organization and the board
2. Track metrics and seek feedback to assess and improve program effectiveness
3. Revisit maturity assessment to further optimization

A lot of steps are meant to draw attention for engaging managers. This is the key to success for any project, cybersecurity is no exception.

As a bonus, Gartner recommends that teams and leaders (along with CISO and CIO, of course) must be involved in cybersecurity projects in the following roles:

1. Applications leader and team - Key partner for the CISO, assist with implementation and operation of key elements of security programs and operations
2. Enterprise architecture leader and team - Collaborate with the CISO and other IT leaders to make sure that security strategy and architecture are aligned and incorporated into overall enterprise architecture
3. Infrastructure and operations team and leader - Key partner for the CISO, assist with implementation and operation of key elements of security program and operations
4. Security and risk management leader and team - Partner with the CISO to incorporate cybersecurity into overall governance, risk and compliance program and processes
5. Technical professionals team - Design, implement, or improve and maintain security architectures, policies and procedures, monitor and evaluate ybersecurity performance, and improve it on the basis of new threats, improve skills as needed

The model provided by Gartner includes elements of the classic Deming cycle (Plan-Do-Check-Act), which will facilitate its integration into the company's current processes. Perhaps, for some, the model will be obviuos, but I'm convinced that not every company (especially SMB) has put the implementation of new information security projects on the "rails" to the end.

Stay on the light side. R.Z.

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.

Свежий Gartner Hype Cycle и информационная безопасность

Неделю назад уважаемое агентство Gartner опубликовало свежий обзор «The Gartner Hype Cycle for Emerging Technologies 2020». Исследование касается новых технологий (ИТ и не только) в общем, и в сети уже появилось немалое количество переводов на русский. В заметке я хочу поделиться своими мыслями, как публикация касается темы нашей с вами информационной безопасности. Ожидаемо, темы удаленки и COVID-19 нашли свое отражение в прогнозах аналитиков, но не ими едиными. Обо всем – по порядку.

Напомню, что Garter примерно раз в год выпускает свое видение по поводу актуальности, перспективности и продуктивности применения так называемых «прорывных технологий» в виде графика, который называется «Hype Cycle». Они разложены по 5-ти стадиям «хайпа о них» (триггер инновации, пик завышенных ожиданий, разрушение иллюзий, область просветления, плато продуктивности) и степени ожидания от них, а также времени прихода в нашу жизнь.

Собственно, сам Hype Cycle 2020 выглядит следующим образом:

Прямо из картинки можно сделать несколько занятных выводов.

Во-первых, развитие менее чем в 2-х годичной перспективе «Паспорта здоровья» и «Технологий социального дистанцирования». И это уже происходит, подтвердить, что вы «не заразный» с помощью приложений можно уже в Китае, Индии, Австралии, ОАЭ. А по поводу дистанции - буквально сегодня в FB видел рекламу сервиса по поиску коворкингов с соблюдением «режима»:

В эту же группу трендов можно отнести развитие в перспективе 2-5 лет BYOI («Принеси свою собственную идентичность»), а в 5-10 лет - «Подтвержденное происхождение», «Дифференциальная приватность» и «Цифровые двойники». Вызовы в контексте кибербезопасности здесь очевидны и аналогичны таковым в отношении цифровых паспортов, биометрии и т.п. Это – разного рода дипфейки, взломы, шантаж, мошенничество. Далеко не всегда текущие средства защиты способны противостоять такого рода угрозам, ждем появления новых (вроде «Подтверждение происхождения» и других). Кроме того, достаточно одного-двух «темных» случаев, чтобы отбросить степень доверия к технологии далеко назад, особенно, когда речь идет о здоровье или ограничении свобод. Поэтому, как мне кажется, разрушение иллюзий мы здесь еще увидим. Живя в мире постоянных утечек и фейков, уже трудно доверять кому-либо в принципе – тут я соглашусь с Gartner. Поэтому каждый будет стараться составить свой собственный «рейтинг доверия» (при этом, доверяя не источнику, а алгоритму), используя при этом базы с механизмами «избирательной приватности».

Во-вторых, не отпускает тема искусственного интеллекта и всего, что с ней связано. В 2-5 лет уложатся «Генеративный, состязательный и композитный ИИ», а в 5-10 лет - «Дизайн с помощью ИИ», «Двустороннее взаимодействие машина-человек», «Адаптивное машинное обучение», «Ответственный ИИ», «Дополненная ИИ разработка», «Объяснимый ИИ». Общий посыл – все больше разнообразных операций мы сможет доверить не просто роботам, а именно ИИ, который способен изменяться, подстраиваться, состязаться друг с другом в выборе лучшего варианта, словом, по-настоящему думать и принимать решения. Про Скайнет я рассуждать не буду, а вот более реалистичные примеры из сферы ИБ вполне имеют право на жизнь. Это было бы очень круто, если бы ИИ в условном SOC вылавливал реальную атаку, отбрасывая все false, а потом принимал решение об оптимальном сценарии реагирования, при этом на каждом шаге возможны новые внешние вводные + обучение на собственных же действиях. При этом закреплена его четкая ответственность, в идеале - с применением мер наказания. А иначе как направить энергию только в мирное русло, и не подсадить его на написание создание фейковых личностей, фейковых новостей и т.п. Кстати, по поводу последнего, совсем недавно выяснилось, что блог, который вел исключительно ИИ, стал самым популярным на ресурсе “Hacker news” среди обычных читателей.

Может, и хорошо, что пока у нас есть только разной степени продвинутости ML, а не полноценный ИИ, готовы ли мы к нему.

В-третьих, наконец, массовая удаленка еще больше подхлестнула к быстрому внедрению корпоративной мобильности и связанной с ней автоматизации или, если хотите, коммодизации безопасности. В разрезе 2-5 лет ожидаем развитие «Встроенного ИИ», «Дешевых вычислений на конечных точках», а 5-10 лет - «Фабрик данных», «Частного 5G», SASE («Безопасный доступ как сервис»). Как мне кажется, движение в эту сторону и так активно идет, а новые технологии – это, скорее, просто упрощение и модернизация подходов Нулевое доверие («Zero trust», Безопасность как сервис, BYOD наивысшего уровня зрелости, Повсеместная контейнеризация и т.п. Периметра и так уже давно нет, видимо, скоро его не станет «совсем-совсем».

 

Выводы

Некоторые выводы Gartner я умышленно обошел стороной, поскольку они представляются делами уж совсем далекого будущего, либо лично мне менее интересными. Если сравнивать с предыдущими прогнозами Gartner, данный мне показался излишне однонаправленным и даже более осторожным. В остальном – обращаем внимание на то, что практическая безопасность (разве есть уже средства защиты от угроз новым технологиям? А ведь они уже среди нас!), увы, отстает от ИТ-трендов в целом, а злоумышленники, напротив, уже сегодня «вооружаются» самыми современными технологиями. Однако, принцип «когда петух клюнет» все же трансформируется в принцип «security by design», поэтому при сколь-нибудь широком распространении той или иной инновации, привлечение экспертизы ИБ неизбежно. Иначе – потребители самой технологии стремительно сокращаются. Мир слишком быстро меняется, и доверие – стало ключевой разменной монетой. А его, как известно, трудно заработать, но просто потерять.

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