Guidelines for services: using convenient multi-factor authentication. Part 1 || Рекомендации сервисам по использованию удобной мультифакторной аутентификации. Часть 1

  

По просьбам читателей продолжаю цикл заметок с тезисным обзором хороших практик по удобной аутентификации в сервисах, изложенных в рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. Предыдущая заметка была про пароли, сегодня - про мультифакторную аутентификацию (MFA). Часть 1. Как было верно подмечено коллегами, лучшая практика обезопасить пароли - это не использовать их. Точнее, добавить второй и/или третий фактор, который необходимо будет предъявить пользователю при входе помимо логина/пароля. В классической многофакторной модели подтверждение личности достигается благодаря указанию комбинации из трех параметров:

1. То, что я знаю (помню)
2. То, что у меня есть (физически)
3. То, кто я (что-то неотъемлемое от меня)

В обозреваемом документе NIST приводятся рекомендации относительно реализации 7 видов аутентификации, которые можно отнести к MFA:

1. Отдельный канал связи до выделенного устройства (Out-of-Band Devices)
2. Простой генератор одноразовых паролей (Single-Factor OTP Device)
3. Мультифакторный генератор одноразовых паролей (Multi-Factor OTP Device)
4. Ключ, хранимый в софте/на диске (Single-Factor Cryptographic Software)
5. Ключ, хранимый на подключаемом устройстве (Single-Factor Cryptographic Devices)
6. Ключ, хранимый в софте/на диске + другой фактор Multi-Factor Cryptographic Software
7. Ключ, хранимый на подключаемом устройстве + другой фактор (Multi-Factor Cryptographic Device)

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

Отдельный канал связи до выделенного устройства (Out-of-Band Devices)

Предполагает использование физического устройства (самое простое - телефона), верификация с помощью которого осуществляется по иному каналу, нежели ввод логина-пароля в браузере для доступа к сервису. Реализует принцип "то, что у меня есть". Такой метод может быть реализован отправкой смс (или push-уведомления) или необходимостью действий в специальном приложении на телефоне (нажать подтверждение, отсканировать QR-код и т.п.). Методы передачи и получения второго фактора могут быть совершенно разными, чаще всего одни из трех (передача на устройство и последующий ввод в сервисе, отображение в сервисе и последующий ввод на устройстве, отображение и передача одного и того же секрета с необходимостью подтверждения да/нет на устройстве). Не зависимо от них необходимо следовать следующим рекомендациям:

1. Канал передачи второго фактора должен быть независим от первого (однако, допускается реализовывать их на одном устройстве) 
2. Устройство должно однозначно адресоваться, а аутентификационная информация - шифроваться при передаче
3. Устройство должно однозначно аутентифицировать себя: либо с помощью зашитого ключа (TPM, TEE и т.п.), либо уникального ID SIM-карты (например, IMSI)
4. Секреты не должны отображаться на заблокированном телефоне
5. При обратной передаче сервису подтверждения второго фактора необходимо проверять целостность (консистентность) транзакции, чтобы исключить подмену
6. Устройство не должно хранить секрет подтверждения второго фактора в открытом виде, для передачи его сервису необходимо применять хэширование
7. Ждать подтверждения необходимо не более 10 минут в рамках одной сессии, потом нужно повторить операцию
8. Случайные генерируемые секреты должны иметь энтропию как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)
9. Передавать второй фактор через публичные телефонные сети (PSTN) крайне не рекомендуется, но если сервис это делает, то необходимо учитывать риски подмены SIM, перехвата сообщений, подмены портов и т.п. 

Простой генератор одноразовых паролей (Single-Factor OTP Device)

Могут быть как отдельными устройствами, так и приложением на телефоне. Реализует принцип "то, что у меня есть". Алгоритм генерации паролей вместе с секретным ключом зашиты в устройство (о них, конечно, знает и сам сервис) и может быть основан на времени, счетчике, специальных словах и т.п. При использовании такого типа аутентификации необходимо придерживаться следующих рекомендации:

1. Алгоритм, секретное слово должны удовлетворять минимальным требованиям безопасности (быть по крайней мере 112 бит)
2. Алгоритм, секретное слово и другие определяющие одноразовый пароль инструменты должны гарантировать его (пароля) постоянную уникальность
3. Устройства должны препятствовать возможности скопировать (клонировать) одноразовый пароль
4. Отображаемый на устройстве после всех вычислений одноразовый пароль может быть в итоге сокращен до 6 числовых значений (энтропия примерно 20 бит)
5. Пароли, очевидно, не должны повторяться
6. Если в качестве входных данных для вычисления одноразового пароля используется текущее время, то оно должно меняться не реже чем раз в 2 минуты
7. Симметричные ключи, используемые для генерации одноразовых паролей, необходимо защищать от компрометации как на стороне устройства, так и на стороне сервиса, поскольку очевидно, что они - одни и теже
8. При вводе пароля на стороне сервиса должна применяться надежная защита (об этом можно почитать в предыдущей статье про пароли) от компрометации и MitM атак
9. OTP устройства должны выдаваться (привязываться) однократно одному пользователю на весь период действия 
10. При генерации одноразовых паролей энтропию должна составлять как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)

Мультифакторный генератор одноразовых паролей (Multi-Factor OTP Device)

Основное отличие от простого генератора - дополнительный второй фактор, усиливающий операцию генерации одноразового пароля. Таким фактором может быть подключенный считыватель биометрии, устройство для ввода пин-кода или просто порт (например USB). Реализует сразу два принципа: "то, что у меня есть" совместно с "тем, что я знаю"/"тем, кто я". Таким образом, вся процедура делится на 2 шага: активация самого OTP и получение с помощью OTP второго фактора для аутентификации на сервисе. Для самого сервиса в итоге такой тип устройства выглядит как обычный однофакторный. Очевидно, все рекомендации из предыдущих разделов (простые пароли и простой генератор одноразовых паролей) справедливы и для текущего. Однако, вот, на что дополнительно (кроме уже упомянутого) стоит обратить внимание:

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

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

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

Читайте также: MFA. Часть 1, Удобные пароли

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

Due to requests of my readers, I'm about to continue the notes with a brief overview of the best practices for convenient authentication in services, set out in a NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. The previous part was about passwords. Today I'd like to discuss multi-factor authentication (MFA). Part 1. As my colleagues mentioned in the comments, the best practice for password security is... don't use them at all =) (better not just them). More precisely, add a second or third factor that the user will be also associated with, except for the single password. In the MFA paradigm stronger authentication is achieved through a mix of three so-called possession-based concepts:

1. Something you know
2. Something you have
3. Something you are

In the observed document NIST serves recommendations for 7 the most popular types of MFA:

1. Out-of-Band Devices
2. Single-Factor OTP Device
3. Multi-Factor OTP Device
4. Single-Factor Cryptographic Software
5. Single-Factor Cryptographic Devices
6. Multi-Factor Cryptographic Software
7. Multi-Factor Cryptographic Device

Obviously, it's much more expensive to offer MFA technologies for services (even in the simple case - SMS or mobile app). However, this is much more secure than using a single password and provides additional protection for both the client and the service itself. Let's drill into all of these types and highlight the most valuable points that will help services make security reliable and convenient for users. In this post we'll take a look at types from 1 to 3, and leave the rest (from 4 to 7) for Part 2.

Out-of-Band Devices

Assumes the use of a physical device (the simplest - mobile phone) that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. Implements the concept "something you have". This method can be carried out through the special mobile app (press "confirm", scan QR code, etc.) or just by SMS. The out-of-band authenticator can operate in one of the following ways: the claimant transfers a secret received by the out-of-band device via the secondary channel to the verifier using the primary channel (typically a digit code), the claimant transfers a secret received via the primary channel to the out-of-band device for transmission to the verifier via the secondary channel (e.g., QR code), the claimant compares secrets received from the primary channel and the secondary channel and confirms the authentication via the secondary channel (e.g., confirm/decline). Regardless of them, the following recommendations should be followed:

1. The out-of-band authenticator shall establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request (however, it's allowed to perform it on a single device) 
2. The out-of-band device should be uniquely addressable and communication over the secondary channel shall be encrypted unless sent via the public switched telephone network (PSTN)
3. The out-of-band authenticator shall uniquely authenticate itself in one of the following ways when communicating with the verifier: Establish an authenticated protected channel to the verifier using approved cryptography using the key, stored in suitably secure storage (e.g., keychain storage, TPM, TEE, secure element) or Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device
4. The device should not display the authentication secret while it is locked by the owner 
5. The authenticator shall present a secret received via the secondary channel from the verifier and prompt the claimant to verify the consistency of that secret with the primary channel, prior to accepting a yes/no response 
6. The verifier shall not store the identifying key itself, but shall use a verification method (e.g., an approved hash function)
7. In all cases, the authentication shall be considered invalid if not completed within 10 minutes, then it's allowed to try again
8. The verifier shall generate random authentication secrets with at least 20 bits of entropy and if the authentication secret has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism (nevertheless, it's never superfluous =) )
9. Use of the PSTN for out-of-band verification is undesirably, but if verifiers use it, it should consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret

Single-Factor OTP Device

This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. OTP implements the concept "something you have". Single-factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically and independently generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier. Single-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock. When using this type of authentication, the following recommendations should be followed:

1. The secret key and its algorithm shall provide at least the minimum security strength (112 bits)
2. The nonce shall be of sufficient length to ensure that it is unique for each operation of the device over its lifetime
3. OTP authenticators — particularly software-based OTP generators — should discourage and shall not facilitate the cloning of the secret key onto multiple devices
4. The authenticator output may be truncated to as few as 6 decimal digits (approximately 20 bits of entropy)
5. Passwords should obviously not be repeated
6. If the nonce used to generate the authenticator output is based on a real-time clock, the nonce shall be changed at least once every 2 minutes
7. The symmetric keys used by authenticators are also present in the verifier, and shall be strongly protected against compromise (on both sides - device and verifier) 
8. The verifier shall use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and MitM attacks
9. In order to provide replay resistance, verifiers shall accept a given time-based OTP only once during the validity period
10. If the authenticator output has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account

Multi-Factor OTP Device

The main difference from the simple OTP - additional factor, which augments the one-time password generation. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Implements two concepts at once: "something you have" with "something you know or something you are". The OTP is displayed on the device and manually input for transmission to the verifier. Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators, except that they require the entry of either a memorized secret or the use of a biometric to obtain the OTP from the authenticator. Each use of the authenticator require the input of the additional factor. Certainly for the service this type of MFA looks like an single-factor OTP. All the previous recommendation (Memorized passwords пароли, single-factor OTP) works for multi-factor OTPs. Yet there is a few more pieces of advice:

1. Any memorized secret used by the authenticator for activation shall be a randomly-chosen numeric secret at least 6 decimal digits in length
2. A biometric activation factor shall meet the requirements of limits on the number of consecutive authentication failures and other tips (more detailed - in the Part 2)
3. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an OTP has been generated
4. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers may warn the claimant in case an attacker has been able to authenticate in advance

Generally, the analyzed today's recommendations are primarily concerned with security, not really the convenience of the user (as you could see in my post about passwords). Nevertheless, the modern MFA use cases provided by services offer comfort by default. This  essentially reduces several requirements (and thus the risks) of using the strongest, but unmemorable passwords.  

In the MFA. Part 2 I'm going to talk about using secret keys as a MFA in various forms.

See also: MFA. Part 2, Convenient passwords

Stay on the light side. R.Z.

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.