Процесс оценивания безопасности «облачных» компонент информационных технологий

Лившиц Илья Иосифович
Доктор техн. Наук, Университет ИТМО, г. Санкт-Петербург.
Livshitz.il@yandex.ru
+7 (921) 934-48-46

Аннотация

В последние годы значительно возросло внимание к обеспечению безопасности ИТ-компонент, в том числе – к обеспечению информационной безопасности различных объектов, использующих «облачную» инфраструктуру. В статье рассматриваются различные мнения российских и иностранных экспертов по широкому диапазону вопросов процесса обеспечения информационной безопасности как отдельных ИТ-компонент, так и «облачных» сервисов в целом.
Предпринята попытка анализа «облачных» сервисов не с коммерческой позиции популярного маркетингового продукта, а с позиции системного анализа. Введенный ранее назад порядок уже не является стабильным, поскольку у конечного пользователя уже нет 100% гарантии доступа ко всем ИТ-компонентам, а тем более с учетом удаленного и неподконтрольного «облачного» сервиса [1]. В ряде обзоров отмечается рост усилий по созданию сетевой безопасной архитектуры и способность обеспечивать непрерывный контроль отклонений от установленных бизнес-целей. В частности, в отчете «Cloud Security Alliance» [2] показано, что организации, изначально внедряющие безопасность в жизненный цикл ПО, демонстрируют лучшие результаты. В отличие от моделей Zero Trust и Zero Trust eXtended, согласно которым на существующие ИТ-компоненты «накладываются» дополнительные функции безопасности, предлагается рассматривать совокупность ИТ-компонент как новую сущность – систему обработки информации. Предлагается перейти к формальным процессам оценивания степени соответствия существующих и перспективных ИТ-компонент при обеспечении безопасности «облачных» сервисов.

В статье предложен новый процесс оценивания на базе ранее разработанной «гибридной методики» с использованием формальных процедур на базе двух систем критериев – оценивания степени соответствия систем менеджмента (на базе ИСО/МЭК серии 27001) и оценивания требований функциональной безопасности (на базе МЭК серии 61508 и ИСО/МЭК серии 15408). Предложенный процесс позволяет получить расчетные результаты процесса оценивания рисков безопасности «облачных» ИТ-компонент в заданных ограничениях. Достаточные и корректные контрмеры обеспечивают минимизацию риска (остаточного риска) для активов. Этот процесс дает воспроизводимые и объективные свидетельства оценивания, которые могут быть предъявлены для проверки независимой группе оценщиков, имеющих должную квалификацию. Эти результаты могут быть применимы при формировании независимой оценки, в том числе объектов критической инфраструктуры, с требуемой точностью.

1. Введение. В последние годы значительно возросло количество фактов реализации угроз информационной безопасности (ИБ) и в этой связи малоизученная проблема оперативного оценивания безопасности информационных технологий (ИТ) для различных объектов критической информационной инфраструктуры (КИИ) становится особенно актуальной [3 – 8]. Очевидно, это обстоятельство справедливо и для ИТ-компонент, размещенных или планируемых для размещения в «облаке» [9 – 21].

Необходимо точно определить, это новый маркетинговый ход для продвижения очередного «инновационного» продукта или новый процесс управления ИТ-сервисами. Соответственно, проблема оценивания для такого класса объектов КИИ должна решаться в соответствии с установленными требованиями (например, ФЗ-187, постановление правительства № 127, приказы ФСТЭК России № 235 и № 239), а также с использованием соответствующих процессов, позволяющих выполнять аудит безопасности требуемых ИТ-компонент на соответствующих уровнях [16, 22, 23], и в том числе, на уровне программного обеспечения (ПО) [10, 13, 15, 24, 25]. В сборнике [26] можно отметить несколько статей по данной тематике (Лесковец и Белоусовой – об исследовании статистических показателей наиболее распространенных угроз ИБ; Похачевского – о доверенной вычислительной среде и Сикорского – об аудите ИБ).

В отличие от известных моделей Zero Trust и Zero Trust eXtended), в которых на существующие ИТ-компоненты «накладываются» дополнительные функции безопасности (ФБ), предлагается рассматривать совокупность таких ИТ-компонент в составе КИИ как новую сущность (предложена Андреем Неклюдовым) – систему обработки информации (СОИ) [1, 27, 28]. В этом случае появляется возможность для коммерческого успеха «облачных» сервисов оптимизировать затраты путем использования уже существующих и практически отработанных ФБ в составе СОИ. Для «облачных» компонент эффективным решением (помимо маркетингового блеска в глянцевых журналах) будет оценивание уже имеющегося изначально уровня безопасности в ИТ-компонентах, обусловленного существующей архитектурой СОИ и полученного в результате сочетания ИТ-компонентов и ФБ. По итогам оценивания возможно принятие обоснованного и объективного решения о реализации новых и/или дополнительных ФБ (в том числе для КИИ).

2. Существующие решения. Важным аспектом для бизнес-заказчиков является предоставление гарантий обеспечения заданного уровня ИБ для различных типов ИТ-компонент [12, 16, 19]. В частности, кричным может оказаться недостаточный контроль предоставления доступа (в равной степени – отзыв прав доступа) к различным видам «облачных» хранилищ чувствительных корпоративных данных [16]. В новых решениях к сетевой безопасности, конечно, учтены требования бизнеса к внутренним шифрованным коммуникациям, сетевой сегментации и детальному мониторингу. В ряде обзоров отмечается постоянный рост усилий по разработке политик для систем управления и создания сетевой безопасной архитектуры, а также обеспечения способности быстрой интеграции [29]. В обзоре IEEE [30] отражены решения быстрой интеграции, интероперабельности и способности обеспечивать измерения стандартными процедурам, обеспечивающие непрерывный контроль отклонений от установленных бизнес-целей. Рассмотрим характерный пример недостаточного контроля [31]: «Главной причиной неавторизованного доступа к облачным базам данных становятся ошибки конфигурации из-за низкой квалификации администраторов этих баз данных... Кроме того, … по содержимому открытой базы данных не всегда можно идентифицировать ее владельца, а хостеры не выдают такую информацию, потому непонятно, кому сообщить о том, что доступ к ней нужно закрыть».

Процесс оценивания можно рассмотреть и с позиции значимости нашего отечественного сегмента рынка ИТ-компонентов по сравнению с мировыми тенденциями и оценить объем новых технологий, способных «проникать» в РФ. Например, в обзоре [32]: показано, что «несмотря на популярность облачных и прочих сервисов, российский рынок ИТ-услуг еще далек от того, чтобы называться развитым: весь ИТ-рынок России составляет примерно 2% от мирового, а сегмент ИТ-услуг занимает только 0,5% от общего «пирога», по данным Gartner и IDC». Отчасти этот мизерный уровень является не только отражением способности оценить (в том числе и в аспекте ИБ) новые предлагаемые «облачные» сервисы, как было показано на примере нормативно-методических документов (НМД) ФСТЭК, но также связан с проблемами квалификации обслуживающего персонала.

В аналитическом обзоре «Rise of Legitimate Services for Backdoor Command and Control» [33] отмечается: «Атаки осуществляются через бреши в обороне, которые в основном появляются в связи с расширением Интернета вещей (IoT) и использованием облачных сервисов». Соответственно, совокупное применение небезопасных «модных» технологий IoT и активно рекламируемых как «мировая панацея», но недоверенных «облачных» сервисов, могут привести к появлению еще большего количества комбинаций для компрометации ИТ-компонент, особенно на объектах КИИ [1, 24, 25, 28]. Следует учесть, что любые ИТ могут выступать и как инструмент бизнеса и как оружие против него, в том случае, если они не прошли в установленном порядке процесс оценивания безопасности. Это предположение подтверждается тезисом в отчете Cisco [39]: «У злоумышленников все лучше получается обходить препятствия и применять в качестве оружия облачные сервисы и другие технологии, используемые в легитимных целях».

В отчете «After MongoDB, Ransomware Groups Hit Exposed Elasticsearch Clusters, Lucian Constantin» [34]: показано: «Вместо настройки серверов C2 с шифрованием или встраивания шифрования во вредоносную программу, злоумышленники просто используют SSL-сертификат легитимного сервиса». В данном случае для противодействия данной атаке, использующей легитимные сервисы, применяют следующие факторы, например: частый обмен сертификатами с легитимными сервисами и выявление большого объема образцов, попадающих в «песочницу» в связи с подозрительными DNS-обращениями на легитимные сервисы. Но, к сожалению, не предложено идей и примеров практической реализации, как это можно достоверно доказать и обеспечить практически. И в технической литературе достаточно негативных примеров и результатов такой беспомощности [35]. Отметим, что «лидерство» по утечкам из «облачных» хранилищ несколько лет подряд удерживает Amazon (см. рис. 1).

Вопросы измерения и мониторинга безопасности ИТ-компонент рассмотрены в отчете SANS [36] «Common and Best Practice for Security Operation Centers Result of the 2019 SOC Survey». В частности, рассмотрен ряд «барьеров», которые препятствуют созданию эффективных Security Operation Centers (SOC). Для целей данной публикации отметим аспекты, которые позволяют выполнить определение вероятности преодоления защиты с позиции «облачных» сервисов:

• Нехватка квалифицированного персонала;
• Отсутствие интеграции между ИТ-компонентами;
• Недостаточная поддержка руководства;
• Недостаточное документирование процессов;
• Отсутствие кооперации между службами;
• Недостаточное выполнение требований регуляторов.

Рис. 1. Распределение скомпрометированных «облачных» хранилищ (данные InfoWatch)

Соответственно, можно предположить, насколько сложно обеспечить измерение и мониторинг достижения установленных метрик ИБ для потенциально небезопасных «облачных» сервисов, если даже для собственных SOC, с учетом известной практики, эксперты признают ряд серьезных проблем [9, 16, 20]. В отчете «State of Threat Detection Report» [37] отмечается важность и приоритетность автоматизации функций ИБ (более 57%), что значительно увеличивает риски при внедрении новых ИТ. В этом отчете отмечено, что новые ИТ-компоненты добавляются «стихийно», а времени на обучение сотрудников и полного изучения функционала (в контексте обзора следует понимать – ФБ) не хватает.
Следует полагать с высокой вероятностью, что в результате в безопасности предприятия появляются серьезные пробелы [38]. В отчете Cisco [39] приведен пример исследования базы 150 тыс. пользователей, которое выявило, что всего 0,5% пользователей совершают подозрительные действия. Показано, что эта мизерная группа пользователей смогла скачать 3,9 млн. документов из корпоративных «облачных» систем или, в среднем, более 5 тыс. документов на пользователя за 1,5 месяца, при этом примерно 60% скачиваний выполнено в рабочие часы, а 40% - в выходные. Далее, в том же отчете показано, что 27% специалистов по безопасности используют внешние частные «облака» (динамика стабильно растущая за последние 3 года), а 52% сообщили, что их сети размещены на локальном частном «облаке». Из организаций, использующих «облачные» сервисы, 36% размещают в «облаке» до 50 % своей инфраструктуры, а 35% размещают в «облаке» более 50 % своей инфраструктуры (рис. 2).

Рис. 2. Размещение инфраструктуры в «облаке» (данные Cisco)

Очевидно, следует задаться вопросом – а как же обеспечивается безопасность ИТ-компонент при таком широком распространении частных «облаков» для бизнес-заказчиков? Следующий не менее важный вопрос, может звучать так – как именно обеспечивается доказательство для бизнеса соответствия заданного уровня ИБ для конкретных приложений, перенесенных в «облако»? Обратимся к факту, согласно которому бизнес-заказчики чаще всего называют именно безопасность как ключевое преимущество размещения своей ИТ-инфраструктуры в «облаке». Например, по данным того же отчета Cisco [39] около 57% размещаются в «облаке» из-за более высокого уровня защиты данных; 48% – из-за масштабируемости, а 46% – из-за удобства использования. Тем не менее, часть критической инфраструктуры может остаться в будущем под управлением собственных ИТ (ИБ) служб. Как показал отчет «IT Key Metrics Data 2019» (Gartner) [40], полностью корпоративные ЦОД не исчезнут, и некоторая часть компаний будет размещать on‑premise критически важные бизнес-процессы (см. рис. 3).

Рис. 3. Прогноз сокращения собственных дата-центров (данные Garther)

Для целей данной публикации важно, что эта часть компаний (примерно 20%) весьма обеспокоена обеспечением необходимого для собственных бизнес-процессов уровнем безопасности и не готова доверять «облачным» провайдерам ни при каких соглашениях (SLA). Эти данные будут хорошей отправной точкой для формирования проблемы исследования и анализа возможных вариантов решения проблемы [24, 41, 42].

3. Формирование проблемы. Как показано в [1, 28], проблемы получения «оценки соответствия» (в формулировке стандартов ISO/IEC [43 – 45]) в определенной предметной области могут быть решены при наличии следующих экспертиз (см. табл. 1):

Таблица 1. Типы экспертиз для получения процесса оценивания соответствия

Наименование типа экспертизы	Достоинства	Недостатки
Индивидуальная экспертиза (ИЭ)	Оперативно, конфиденциально, просто	Низкая объективность и достоверность
Шаблонная экспертиза (ШЭ)	Требования доступны и стандартизированы	Значительная погрешность в силу слишком большого обобщения требований
Расчетная экспертиза (РЭ)	Точность, обусловленная квалифицированным выбором методик измерения и современным уровнем инженерных и научных задач	Требуется высокая квалификация для выбора методики измерения и интерпретации результатов

Графически пространство исходных комбинаций экспертиз можно представить в виде треугольника (см. рис. 4). Как показывает практика [1, 42], значительный объем проблем может быть успешно решен как при использовании только любой одной экспертизы, так и произвольной их комбинации. Например, для многих заказчиков в РФ вполне достаточно только ШЭ (на соответствие, например, НМД ФСТЭК России) или только ИЭ (например, для создания различных программных компонент, к которым изначально не предъявляются требования оценивания соответствия [24, 25, 42]). Вопрос – в поиске оптимального сочетания экспертиз, обеспечивающего взаимную компенсацию недостатков и максимальное усиление достоинств. Вершины треугольника символизируют «полюса» экспертиз (см. рис. 4).

Рис. 4. Схема видов экспертиз оценки соответствия

Точка внутри треугольника «Б», либо на стороне («А»), символизирует некоторое частное предпочтительное сочетание экспертиз. Существующее состояние дел в области оценки безопасности ИТ таково:

• Для отдельных ИТ-компонент (относительно простые объекты ИТ) оценка безопасности выполняется на основе, как правило, одного типа экспертизы.
• Для СОИ (достаточно сложные объекты, полученные в результате композиции более простых объектов ИТ) оценка безопасности, как правило, производится на основе сочетания двух типов экспертиз – ИЭ и ШЭ.

Формулировка проблемы – предложить новый процесс оценивания безопасности ИТ-компонентов, предоставляющий количественные оценки, которые могут быть независимо проверены.
Мы видим, что подавляющее большинство проектов (работ) в области создания защищенных ИТ (в данном случае не важно, изначально проектируемых в защищенном исполнении по ГОСТ Р 51583-2014, или с последующим добавлением ФБ) проходят экспертизу ИЭ, и лишь некоторые демонстрируют результаты прохождения ШЭ. Этот тезис, высказанный ранее [27, 28], можно подтвердить доступными актуальными данными: в частности, в отчете «Cloud Security Alliance» [2] показано, что организации, внедряющие изначально безопасность в жизненный цикл (ЖЦ) ПО, демонстрируют лучшие результаты в обеспечении ИБ. Такие же данные приводятся в отчете «2017 State of Application Security: Balancing Speed and Risk» [46] о формальном соответствии (compliance) требованиям известного стандарта ISO/IEC 27000. В простейшем случае ШЭ выполняется по требованиям ФСТЭК и/или ФСБ, для более серьезных и весьма редких проектов выполняется ШЭ на требования по функциональной безопасности SIL дополнительно [47 – 49]. Технически необходимо точку сочетания экспертиз «сдвинуть» со стороны ИЭ-ШЭ внутрь треугольника в направлении вершины РЭ (точка «Б», см. рис. 4), добавив точный расчет и формируя область оптимума для конкретных применений (см. рис. 5).

Рис. 5. Поиск оптимума видов экспертиз

Состояние российских ИЭ и ШЭ, к сожалению, далеко от необходимого уровня, диктуемого современными вызовами «противоборствующих» сторон. Именно поэтому для России очень важна «подвижка» точки сочетания экспертиз от стороны треугольника ИЭ-ШЭ в направлении вершины РЭ. Для этой цели в России могут применяться нормативные документы ГОСТ Р, идентичные международным стандартам, для наполнения полюса ШЭ:

• ISO/IEC серии 15408 [43 – 45];
• ISO/IEC серии 27001 [50];
• ISO/IEC серии 27005 [51].

Необходимо сделать замечание о том, что ISO/IEC серии 15408 может быть использован не только для «полюса» ШЭ, но и для «полюса» РЭ, что обусловлено достаточно мелкой ценой деления и заложенной возможностью практически любой адаптации различных множеств требований ФБ и требований доверия к безопасности под текущие потребности для конкретных решений (см. рис. 6).

Рис. 6. Сопоставление компонент 27001 и 15408

4. Расширение возможностей для шаблонной экспертизы. Ранее предложенная «гибридная модель» постоянно развивается с целью соответствия все новым частным отраслевым требованиям [1, 28]. Отметим, что в семействе стандартов ISO/IEC 27000 вышли новые «отраслевые» требования (см. табл. 2):

Таблица 2. Новые стандарты для процесса оценивания по отраслевым нормам

Отрасль	Стандарт	Основные преимущества
Частная безопасность	ISO/IEC 27701:2019 Security techniques – Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management – Requirements and guidelines	Определяет требования для разработки, внедрения, поддержки и постоянного совершенствования системы управления частной информацией (Privacy Information Management System, PIMS)
Энергетика	ISO/IEC 27019:2017 Information technology – Security techniques – Information security controls for the energy utility industry	Определяет требования для мониторинга процессов генерации, передачи, хранения и распределения электроэнергии, газа, нефти и тепла, а также соответствующих поддерживающих процессов для ИТ-компонент объектов КИИ
Телеком	ISO/IEC 27011:2016 Information technology – Security techniques – Code of practice for Information security controls based on ISO/IEC 27002 for telecommunications organizations	Формирует рекомендации для внедрения мер и средств обеспечения ИБ в организациях телекоммуникационной отрасли и определяет базовый уровень ИБ для целей обеспечения конфиденциальности, целостности, доступности и иных применимых свойств безопасности
Медицина	ISO 27799:2016 Health informatics – Information security management in health using ISO/IEC 27002	Предоставляет руководство для применения практик менеджмента ИБ для защиты медицинской информации и обеспечения соответствующего уровня конфиденциальности, целостности и доступности
Сетевая безопасность	ISO/IEC 27033-1:2015 Information technology – Security techniques –Network security – Part 1: Overview and concepts	Предоставляет руководство по обеспечению безопасности сетевых устройств, приложений, сервисов и дополнительной защиты передаваемой информации.

Для целей данной публикации важно, что в стандарте ISO/IEC 27019:2017 определены процессы оценивания, для которых может быть применим данный стандарт, в частности:

• Системы контроля (центральные и распределенные), технологии мониторинга и автоматизации информационных систем, такие как программируемые и параметрические устройства;
• Цифровые контроллеры и компоненты автоматизации, такие как программируемые логические контроллеры (PLC) для полевых и управляющих устройств;
• Метрологические системы, в т.ч. интеллектуальные;
• Системы цифровой защиты и обеспечения безопасности, в т.ч. контроллеры, системы аварийной автоматики;
• Программное обеспечение, в т.ч. специальное встроенное.

В завершение анализа формирования «полюса» ШЭ можно отметить статистику Gartner (см. рис. 7), согласно которой примерно 20% компаний разрабатывают для оценки соответствия собственный «фреймворк», еще примерно 20% комбинируют компоненты иных способов экспертизы, а 23% используют стандарты (NIST, ITIL и пр.).

Рис. 7. Статистика использования способов экспертизы (Gartner)

После краткого анализа международной экспертизы, обратимся к практике РФ, точнее к Положению Банка России от 9 июня 2012 г. N382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств». В Приложении 2 к Положению 382-П указано требование категории проверки (подпункт 2.5.5.1), в котором определено, что оператору необходимо обеспечить использование для осуществления переводов денежных средств ПО, сертифицированное ФСТЭК, или в отношении которого проведен анализ уязвимостей по требованиям к оценочному уровню доверия (ОУД) не ниже чем ОУД 4 в соответствии с требованиями ISO/IEC 15408-3 [45]. В указанном стандарте установлены требования для ОУД4 – обеспечение доверие посредством задания по безопасности (ЗБ) с полным содержанием и посредством анализа выполнения ФБ из данного ЗБ с использованием функциональной спецификации, полной спецификации интерфейсов, руководств, описания базового модульного проекта ОО, а также подмножества реализации для понимания режима безопасности (см. табл. 3, фрагмент).

Таблица 3. Оценочный уровень доверия ОУД 4 (Фрагмент)

Класс доверия	Компоненты доверия
ALC: Поддержка жизненного цикла	ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизации
	ALC_CMS.4 Охват УК отслеживания проблем
	ALC_DEL.1 Процедуры поставки
	ALC_DVS.1 Идентификация мер безопасности
	ALC_LCD.1 Определенная разработчиком модель ЖЦ
	ALC_TAT.1 Полностью определенные инструментальные средства разработки

Известно, что ОУД4 представляет значимое увеличение доверия по сравнению с ОУД3, требуя более детальное описание проекта, представление реализации для всех ФБО и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки [45]. Для целей данной публикации важно, что в класс доверия ACL включены компоненты, ALC_DVS.1 и ALC_LCD.1, что устанавливает, требования по идентификации мер безопасности и наличие определенной разработчиком модели ЖЦ. Эти два компонента применены далее при оценивании безопасности ИТ-компонент в «облаке».

5. Примеры реализации атак. Рассмотрим несколько примеров реализация атак на СОИ, которые известны для «классических» ИТ:

• Атаки на инфраструктуру. Из отчета Sophos [52] известно, что более 90% ИТ-специалистов полагают, что атаки были успешными, несмотря на использование современных средств защиты. Эти данные приводятся из опроса, в котором приняли участие более 3 тыс. специалистов из 12 стран. Причина данного факта, очевидно, кроется в неустранимых уязвимостях существующих ИТ-компонент и эти скрытые риски не управляются.
• Атаки на цепь поставок (supply chain attack). Известно, что авиакомпания British Airways [53] пострадала от такой атаки, причина которой кроется модификации кода внешнего провайдера для получения доступа к финансовым данным клиентов.
• Атаки на ЦОД. В обзорах, посвященных безопасности новых ЦОД (например, на Калининской АЭС [54]) отражены аспекты обеспечения электропитания, защищенности данных, бесперебойной работы и пр. Но практически не отражены риски для ИТ-компонент инфраструктуры, многие из которых произведены не в РФ и не прошли никакой оценки соответствия в установленном порядке.
• Атаки DDoS. Еще в 2013 г. в Европе [55] была реализована DDoS-атака, мощность которой достигала 300 Гб/сек. В РФ известна длительная (по данным Kaspersky DDoS Prevention [56] – более 80 дней) DDoS-атака, направленная на туристический сайт.
• Атаки на военную инфраструктуру связи. Как следует из официальных данных, новые решения Госкорпорации «Ростех» [57] (по данным 2018 г.) способны отразить кибератаку мощностью до 40 Гбит/с. Но, как указано выше, даже 5 лет назад уже были известны DDoS-атаки значительно мощнее.
• Атаки на уязвимости Microsoft Windows. По данным Qualys Inc., задержки установки обновления безопасности MS17-010 (выпущенного еще 14 марта 2017 г.) значительно отставали даже после серии атак WannaCry, которым подверглись многие организации в мире в мае 2017 г.

Представленные выше примеры удобно рассмотреть как «входы» для возможного применения «гибридной методики» как нового процесса оценивания ИТ-компонент в «облачной» инфраструктуре.

6. Новые решения для оценивания доверия. Известная модель Zero Trust, так же, как и расширенная модель – Zero Trust eXtended (ZTX) [58], является реализацией принципа «Доверяй, но проверяй». Модель предполагает, что к действиям пользователя, находящегося внутри периметра корпоративной сети, надо относиться так же подозрительно, как и к действиям того, кто запрашивает доступ к этой сети извне. Эта модель включает [59] валидацию устройств, оценивание контекста для пользователя, авторизацию доступа, верификацию сети, выявление угроз и восстановления устойчивости перед предоставлением доступа устройств или пользователей. Для целей данной публикации следует заметить, что о концепции Zero Trust говорят в мире более 5 лет, хотя нигде документально не доказано, как обеспечивается безопасность «в облаке». Бизнес должен получить доказательство невозможности какой-либо утечки информации изнутри «облачных сервисов» (в силу «трояна» или инсайда, например), на базе формализации настроек сетевой безопасности. Идеология Zero Trust, как известно, разработана Forrester, и в отчете «The Forrester Wave™: Zero Trust eXtended (ZTX) Ecosystem Providers, Q4 2018» даются, в общем-то, известные рекомендации, в частности, сегментирование сетей и полагание уязвимости перед внешними и внутренними атаками в равной мере. Значительным преимуществом для бизнеса может оказаться система [60] из 15 критериев, которые разделены на группы:

• Текущее предложение (7 компонентов: сетевая безопасность, безопасность данных, безопасность рабочей нагрузки, безопасность устройств, видимость и аналитика, автоматизация и оркестровка, а также управляемость и удобство использования);
• Стратегия (Стратегии поставщиков – улучшения стратегий нулевого доверия);
• Присутствие на рынке (Количество корпоративных клиентов у поставщика).

По оценкам Forbes [61], бизнес готов реагировать на инициативу «Zero-trust policies» в двух основных аспектах. Согласно отчету «5 Key Findings from Forbes Insights’2019 Cybersecurity Survey» это: области обнаружения и идентификации атак (более 80% опрошенных экспертов) и «снижение поверхности атак» (более 50% опрошенных экспертов).

7. Безопасное применение «облачных» сервисов. Очевидно, что необходимо подойти к вопросу обеспечения безопасного применения «облачных» сервисов с позиции «очистки» от рекламных маркетинговых обещаний. Следует опираться на анализ истории развития ИТ и постепенную миграцию от раздельного применения ИТ (ИБ) компонентов к созданию наборов компонентов, безопасных изначально [28]. Введенный 25 лет назад порядок уже не является стабильным, поскольку у конечного пользователя уже нет 100% гарантии доступа ко всем ИТ-компонентам, а тем более с учетом удаленного и абсолютного неподконтрольного «облачного» сервиса [1]. В настоящее время регуляторы в РФ не готовы предложить процессы оценивания соответствия требованиям ИБ для существующих ИТ-компонентов, не говоря уже о перспективных. Проблема усугубляется еще тем, что в РФ нет примеров создания полного стека суверенных ИТ‑компонентов с 1 по 7 уровень классической модели OSI/ISO.

Процесс обеспечения ИБ «облачных» технологий является заботой экспертов почти всех крупных компаний, поскольку статистические данные, экспертные отчеты и публичные аналитические доклады не дают ни одного шанса на спокойствие [1 – 8, 28]. Даже в вопросах наивысшей важности для любого эксперта ИБ – обеспечение государственной тайны, есть серьезные проблемы. Как показано в отчете компании InfoWatch [35], в РФ даже в 2017 г. в общем объеме утечек данных из «облачных» сервисов более почти 7% данных как раз составила информация, отнесенная к государственной тайне (рис. 8).

Рис. 8. Анализ утечек данных из «облачных» серверов

Если на объекте нет «внятной» системы ИБ, чувствительные данные, и, как показал пример выше, даже сведения, отнесенные к государственной тайне, могут беспрепятственно покинуть периметр «облака», особенно если служба ИБ не знает, не умеет или не может обеспечить требуемый уровень безопасности. К сожалению, ни ФСТЭК России, ни ФСБ России в данный момент не могут предоставить действенные процессы оценивания уровня ИБ «в облаке», а существующие НМД по аттестации объектов информатизации не применимы. Для решения данной проблемы может быть применена «гибридная модель» оценивания, поскольку каждый ее компонент: стандарты ИСО/МЭК серии 27001, серии 27005, серии 15408 обеспечивает определение степени безопасности ИТ-компонент. При необходимости могут быть применены дополнительные стандарты МЭК, например, стандарты МЭК серии 61508, 61511 или 62443 для оценивания требований ФБ.

8. Проблема переноса критичных ИТ-компонент в «облако». Известна практика, при которой все критические ИТ-компоненты переносят в «облако», следуя «радужным» обещаниям консалтинговых проектов и стремясь «волшебно» снизить сразу все риски и финансовые издержки. Существует известная проблема, основанная на заблуждении некоторых представителей служб ИТ и ИБ о том, что при переносе ИТ-компонент в «облако» все «унаследованное» разделение ИТ и ИБ поможет обеспечить разом и высокую безопасность, и легкость управления при кардинальном снижении затрат. Объективно, такое заблуждение является только вершиной айсберга, т.к. суровая действительность часто скрыта от лиц, принимающих решение. По данным Cisco, многие заказчики сообщили о значительном увеличении количества взломов, повлиявших более чем на 50% систем, при этом динамика резко нарастающая: 32% в 2017 г. и 15% в 2016 г. соответственно [39]. Этот факт говорит о многом – несмотря на постоянное увеличение статистики взломов, бизнес не останавливается в попытках перенести в «облако» большинство (свыше 50%) ИТ-систем, очевидно, полагая, что обещаемые финансовые выгоды перевесят любые риски по возможным ущербам. Справедливости ради нужно отметить, что определенные меры при переносе ИТ-компонент (возможно и критических ИТ-систем) предпринимаются. По известным данным (отчет Cisco [39]) в состав таких мер входят, к сожалению, не на лидирующих позициях, мероприятия по контролю рисков ИБ, что существенно отличается от тенденций в современных НМД ФСТЭК России и ФСБ России за последние несколько лет (см. рис. 9). В этом аспекте важно принять во внимание особенности формирования контекста (в нотации 27001 [50]), а именно – на точность и полноту определения внешних и внутренних факторов (internal and external issues). Например, могут быть определены «точки контакта», как разнообразные ситуации, места и интерфейсы соприкосновения с услугами.

Рис. 9. Предпринятые меры реагирования (Cisco)

На практике такими универсальными «точками контакта» могут быть сайт, офис, документация, реклама, печать, звонки, сотрудники, продукты (услуги) и др. Соответственно, для них могут быть установлены веса, исходя из доли информации, значимой для потребителя (принятия им решения в пользу предлагаемого сервиса) и поступающей через точку контакта. Известны примеры современных ИТ, которые активно предлагаются как уникальные системы организации работы различных международных команд, например:

• Workplace (запущенная Facebook),
• Slack (корпоративный мессенджер),
• Google Team Drives (общий диск Google),
• Atlassian Confluence (тиражируемая Viki-система),
• Microsoft Skype и др.

Уместно обратить внимание на отчет «Improving Information Risk Management and Assurance in a Cyber World» [63], в котором рассмотрены действительно серьезные факторы оценивания качества и зрелости программ информационной защиты. Речь идет далее новой сущности – непрерывном мониторинге информационной безопасности (information security continuous monitoring, ISCM), которая позволяет, что важно для целей данной статьи, обеспечить необходимую сертификацию. Также отмечается, что общая оценка соответствия (conformity assessment), так как это установлено ISO [64], позволяет обеспечить «набор процессов, которые демонстрируют продукты, услуги или системы, соответствующие требованиям стандарта». Схожая трактовка содержится и в Program Review for Information Security Assistance (PRISMA), разработанной National Institute of Standards and Technology (NIST) [64]. Достаточно интересно представлена взаимосвязь между уровнем безопасности, остаточным риском и уровнем гарантии (см. рис. 10).

Рис. 10. Взаимосвязь между уровнем соответствия, рисками и гарантии

К сожалению, в российской практике аналогов рассмотренных выше процессов мониторинга и/или оценивания [66] нет, но доступны для широкого применения аналоги международных стандартов [45 – 47] в системе ГОСТ Р ИСО/МЭК. В развитие данного тезиса можно проследить другую тенденцию – как меняется значимость процессов аудита в течении ряда лет – с 2104 по 2017 гг. на значительной выборке (отчет Cisco [39]). Некоторый рост и последующую стабилизацию в течении ряда лет на уровне 46-47% для аудита ИБ можно полагать хорошим результатом, поскольку все процессы, в равной мере – реализуемые самостоятельно или с привлечением подрядчиков, нуждаются в экспертизе. Уместно вспомнить «формулу» ISO/IEC (ГОСТ Р ИСО/МЭК) серии 15408 – «доверие через оценку», что в целях данной публикации предоставляет, возможно, единственный процесс получения объективных и количественных данных о предоставляемом уровне обеспечения безопасности для «облачных» сервисов.

9. Описание применения процесса оценивания для «облачных» сервисов. На основании постановленной задачи рассмотрим пример применения «гибридной методики». Поскольку в ISO/IEC серии 15408 «предусмотрена гибкость, допускающая применение множества методов оценки по отношению к множеству свойств безопасности множества информационных продуктов», этот стандарт позволяет избежать усложнения процесса оценивания безопасности объекта оценки (ИТ), например, описания границ доверия (trusted boundary, ТВ), процессов (Р), целей безопасностей, предположений безопасности. Отметим, что в «гибридной методике» вероятности реализации угроз исчисляются на основании статистических данных, в отличие от установленных в НМД РФ. В частности, в НМД среди мер защиты информации в АСУ, содержащихся в Приложении № 2 Приказа ФСТЭК России № 31 (зарегистрирован в Минюсте России 30 июня 2014 г. N 32919), не упомянуты ни оценка рисков, ни оценка остаточных рисков.В новых приказах ФСТЭК России № 235 «Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования» и № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (в ред. приказа ФСТЭК России от 26 марта 2019 г. № 60) также не упоминается управление риском (остаточным риском).

Соответственно, в существующих НМД РФ не обеспечивается прослеживаемость от сформированного множества угроз, полученных оценок рисков, результативности применения рекомендованных средств защиты информации (в том числе сертифицированных), пересчета оценок остаточного риска – к принятию финального решения об общем уровне обеспечения безопасности ИТ. Новой «гибридной методикой» предполагается рассмотрение ИТ как объекта оценивания, функционирующего в ТВ, определяемых на модели СОИ с использованием Data flow diagram (DFD). Именно ТВ в соответствие ставятся, с одной стороны, требования ФБ и требования доверия к безопасности из ISO/IEC серии 15408 и требования к менеджменту ИБ из ISO/IEC серии 27001 (см. табл. 4), а с другой стороны, СОИ, в которых реализуются ТВ. «Гибридная методика» оценивания безопасности ИТ предусматривает следующую последовательность шагов [1, 28]:

• Структурирование ИТ, когда выполняется структурирование всей совокупности ИТ, обеспечивающих автоматизацию бизнес-процессов, на несколько областей (Realm, R);
• Структурирование физического пространства, когда выполняется структурирование пространства, занимаемого ИТ-компонентами, на несколько локаций (Location, L);
• Формирование модели СОИ, когда определяется необходимое количество моделей;
• Определение проблемы безопасности, когда последовательно определяются угрозы ИБ, политики безопасности и предположения безопасности для заданной среды функционирования.
• Определение целей безопасности, когда предоставляется краткое изложение предполагаемого решения проблемы, определенной ранее. Обосновывается заключение, что если все цели безопасности достигнуты, то ранее определенная проблема безопасности решена, всем выявленным угрозам обеспечено эффективное противостояние, а предположения безопасности реализованы.

Таблица 4. Меры обеспечения ИБ для «облачных» сервисов на базе Приложения А ISO 27001 (фрагмент)

ISO/IEC 27001 (Приложение А)	Наименование меры обеспечения
A.6.1.1	Роли и ответственность в рамках ИБ
A.7.1.1	Проверка благонадежности
A.7.2.2	Осведомленность по ИБ, обучение и инструктажи
A.8.1.1	Инвентаризация активов
A.8.2.3	Приемлемое использование активов
A.9.2.2	Инициализация доступа пользователя
A.9.2.3	Управление правами привилегированного доступа
A.9.4.1	Ограничение доступа к информации
A.10.1.1	Политика использования средств криптографии
A.11.2.4	Техническое обслуживание оборудования
А.12.1.2	Управление изменениями
А.12.1.3	Управление мощностями
А.12.3.1	Резервируемая информация
А.13.2.4	Соглашение о неразглашении информации
А.16.1.2	Оповещение о событиях ИБ
А.16.1.5	Реагирование на инциденты ИБ
А.17.1.2	Внедрение непрерывности ИБ
А.18.2.1	Независимый пересмотр (аудит) ИБ
А.18.2.2	Соответствие политикам безопасности и стандартам
А.18.2.3	Проверка соответствия техническим требованиям

На рис. 11 показаны три области (R), включенные в состав одной локации (L).

Рис. 11. Пример описания «локальной» СОИ в нотации «гибридной методики»

Отметим, то указываются процессы (Process, P), которые выполняют обработку информации в составе СОИ и взаимодействующие либо с процессами, либо с конечными сущностями (External Entity, EE). Соответственно, для оценивания рисков (и остаточных рисков) удобно проследить не сам отдельный факт инцидента ИБ (в действительности, только с его дискретной вероятностью и последствиями), а факт наличия в «нужном месте» последовательности реализованных (иногда встроенных) ТВ для СОИ как достаточной оцениваемой преграды для инцидентов ИБ. При необходимости, «гибридная методика» оценивания безопасности ИТ может быть дополнена требованиями ФБ на базе IEC серии 61508 и 61511 (см. табл. 5). Отметим, что дополнение «контролей» ISO/IEC серии 27001 ([50]) требованиями IEC серии 61508 ([47 – 49]) позволяет оценить аспекты безопасности применяемых ИТ-компонент по всей «вертикали» стека ISO/OSI.

Таблица 5. Требования IEC 61508 для «облачных» решений (фрагмент)

Стандарт	Требование
п. 1.2 g) 61508-1	Спецификации требований безопасности систем, связанных с безопасностью, могли быть определены на основе систематического анализа рисков
п. 6.2.1 61508-1	Организация, ответственная за систему, связанную с безопасностью, или за одну или несколько стадий ЖЦ всей системы безопасности, должна выделить … сотрудников, несущих полную ответственность за: координацию действий, связанных с безопасностью, выполняемых на этих стадиях; взаимодействие между этими стадиями и другими стадиями, выполняемыми другими организациями; удостоверение того, что функциональная безопасность достигнута и продемонстрировано соответствие с целями и требованиями настоящего стандарта.
п. 6.2.14 61508-1	Соответствие компетентности должно рассматриваться для конкретной области применения с учетом всех факторов, включая: c) возможные последствия в случае отказа систем, связанных с безопасностью; d) уровни полноты безопасности систем, связанных с безопасностью; h) инженерные знания, соответствующие области применения и технологии; i) инженерные знания в области безопасности, соответствующие применяемой технологии; j) знание законодательной базы и нормативно-правовой базы в области безопасности
п. 7.3.2.2 61508-2	При планировании подтверждения соответствия системы, связанной с безопасностью, должны быть использованы: a) требования, определенные в спецификации требований к системе безопасности и в спецификации требований к проектированию системы; c) процедуры, применяемые для подтверждения соответствия полноте безопасности каждой функции безопасности по критериям «прошла испытания/не прошла испытания»; e) процедуры оценочных испытаний (с обоснованиями).
п. 7.4.1.5 61508-3	Целью является проверка выполнения требований к ПО, связанному с безопасностью (в отношении необходимых функций безопасности и стойкости к систематическим отказам ПО)
п. 7.4.8.2 61508-3	Проверки интеграции системы ПО должны определять: b) контрольные примеры и контрольные данные; c) типы проверок, которые должны быть проведены; d) условия тестирования, конфигурацию и программы; e) условия, при которых проверка считается выполненной; f) процедуры, которые необходимо выполнить, если проверка дала отрицательный результат.

Рассмотрим следующий пример, в котором несколько (R) распределены по нескольким (L), но по-прежнему под контролем собственных ИТ (ИБ) подразделений (см. рис. 12).

Рис. 12. Пример «распределенной» СОИ в нотации «гибридной методики»

С учетом рассмотренных выше примеров отметим, что в «гибридной методике» приведены все необходимые решения, достаточные для обеспечения как «внешних» безопасных коммуникаций (в частности, с внутренними сущностями ЕЕ 1.1. и ЕЕ 1.2, находящимися за периметром R1.1 (L1), так и «внутренних» защищенных соединений (например, пара ТВ2.1 и ТВ 1.4 или пара ТВ1.6 и ТВ 3.1), реализующих фактически VPN. Следует заметить, что для ЕЕ2.1, ЕЕ 1.3 и ЕЕ 3.1. также реализованы ТВ (соответственно, ТВ 2.2, ТВ 1.7 и ТВ 3.2), которые могут быть реализованы техническими средствами (например, доступ в AD), политиками (например, «чистого стола и чистого экрана») или комбинациям нескольких средств (мер) обеспечения ИБ (см. ISO/IEC 27001 [50]) или Приложение 2 к Положению 382-П.

10. Учет угроз безопасности. Угрозы, которым должна противостоять СОИ, определяются по реестру рисков (например, по возрастанию значимости, см ISO/IEC 27005 [51]). Реестр рисков либо формируется по модели СОИ, либо используется уже существующий в организации [68 – 70]. Однако, следует принять во внимание, что объемные каталоги и «таксономии» сотен угроз, применение которых определено в действующих НМД регуляторов в РФ уже не имеют практического применения, как 20-30 лет назад. В частности, это определяется незначительной долей известных уязвимостей, через которые реально можно реализовать угрозы: по данным экспертов Kenna Security [71] только 2-5% от всех критических уязвимостей действительно эксплуатируются в реальных атаках. Схожие данные показаны в исследование центра RAND и компании Cyentia Institute [72]: только 5,5% уязвимостей используются в реальных атаках (из 76 тыс. багов, выявленных в период с 2009 по 2018 гг., эксплуатировались лишь около 4 тыс., и только для половины из этих 4 тыс. уязвимостей были свободно доступны эксплойты). По данным другого отчета «Sabottke, Suciu, and Dumitras» [73] уязвимостей, для которых реально есть эксплойты, всего лишь 1,4%. Здесь необходимо сделать отступление и акцентировать внимание на том, что угрозы определяются именно через риски, как это и принято в международной практике [47 – 45], для объектов реального мира вне зависимости от отраслевой принадлежности (финансы, транспорт, промышленность, здравоохранение, ИТ). Практикуемое в России строительство статичных фиксированных моделей угроз ИБ свидетельствует об игнорировании международного опыта (ISO, NIST, NERC, FIPS, COSO, IATA и пр.) [74].

11. Оценка «облачных» сервисов. В результате проведения по предложенной «гибридной методике» оценивания уровня безопасности ИТ бизнес получает документальные свидетельства достаточности и корректности контрмер (см. ISO/IEC 27001 [50]). Достаточность контрмер определяется в измеряемых единицах – ФБ, сопоставленных ТВ (см. ISO/IEC 15408 [43 – 45]). Корректность контрмер определяется в измеряемых единицах – требованиях доверия к безопасности и требованиях к менеджменту ИБ. Достаточные и корректные контрмеры обеспечивают минимизацию риска (остаточного риска) для активов. Таким образом, достигается «доверие через оценку». Этот процесс дает воспроизводимые и объективные свидетельства оценивания СОИ, которые могут быть предъявлены для проверки независимой группе оценщиков, имеющих должную квалификацию. Отчет об оценивании представляет собой веский аргумент в пользу безопасности ИТ-компонент, выраженный в измеряемых величинах, опирающийся на ГОСТ Р [47 – 45], идентичных соответствующим стандартам ISO и IEC, что позволяет оперировать ими в интересах бизнеса в пределах российской и зарубежных юрисдикций. Продукция и услуги, включающие в себя ИТ, прошедшие независимое оценивание безопасности, обладают неоспоримыми конкурентными преимуществами. При необходимости возможно оценивание ИТ в любой испытательной лаборатории, соответствующей требованиям стандарта ISO/IEC 17025 «General requirements for the competence of testing and calibration laboratories».

Рассмотрим следующий пример описания «облачного» сервиса в нотации «гибридной методики» (см. рис. 13). Унификация описания по сравнению с «классическими» on-premise СОИ (см. рис. 11 и рис. 12) очевидна – используются единые условные элементы, единая нотация и описание. Отличием может быть только определенные дополнительные R (L), в которых размещаются или планируются к размещению «облачные» сервисы. В данном примере показано, что в L4 в едином R4.1 размещены несколько критичных процессов (Р5 – Р7) СОИ, доступ к которым предоставляется по защищенным каналам (пара ТВ1.1 и ТВ 4.1, соответственно, в R1.1 и R 4.1). Обратим внимание, что указанная пара на практике может быть реализована как VPN и даже с резервированием (проводной основной канал и спутниковый резервный, например), но описание СОИ и суть выполнения «оценки через доверие» от этого не изменяются.

Рис. 13. Пример описания «облачного» сервиса в нотации «гибридной методики»

Также обратим внимание, что бизнес-заказчик может принять во внимание свои резоны при проектировании защищенного доступа к «облачным» сервисам, например, обеспечивая единый доступ к провайдеру только одним внешним каналом (пара ТВ1.1 и ТВ 4.1), реализуя собственными силами и по своим регламентам внутренние коммуникации – например, пары ТВ1.6 и ТВ 3.1 и пары ТВ1.4 и ТВ 2.1. Но, с другой стороны, бизнес-заказчик контролирует через «свои» ТВ (ТВ1.2, ТВ 1.1, ТВ 1.5, ТВ 2.2 и ТВ3.2) только «свои» ЕЕ (в частности, ЕЕ1.1, ЕЕ1.2, ЕЕ1.3, ЕЕ2.1 и ЕЕ3.1), но вынужден доверять провайдеру «облачных» сервисов в части обеспечения безопасного доступа к «чужим» ЕЕ4.1, ЕЕ 4.2, ЕЕ4.3 и ЕЕ4.4. Даже предположив, что все указанные ЕЕ4.* «оснащены» достаточным количеством эффективных ТВ, следует продумать систему оценивания соответствия в R4.1 (L4), например, в установленном порядке аудита (см. ISO/IEC 27001 [50] или PCI DSS).

12. Допущения и ограничения. «Гибридная методика» отличается для процесса оценивания преимуществом, которое позволяет вычислять априорные риски с учетом множества угроз ИБ, характерных для каждой конкретной ИТ-компоненты и в целом для СОИ. Это требование может быть применимо и для НМД в российской юрисдикции (например, ФСТЭК), и международной (например, ISO/IEC серии 15408 или IEC серии 61508 и/или 61511). Например, при исследовании оценок рисков безопасности ИТ для современного морского порта, такими ИТ-компонентами могут быть промышленные контроллеры Honeywell котельной и очистных сооружений, станции промышленной сети Wi-Fi Huawei и пр. В соответствии с классическим процессом, для оценивания рисков ИБ применялись компоненты «ущерб» (size of impact) и «вероятность» (probability), точно, как при определении риска в ISO/IEC ([50, 51]). В новом процессе оценивания в едином контексте определяются и оцениваются существующие конкретные TB в модели СОИ. Далее владельцем СОИ определяется необходимый уровень детализации, в частности, фиксируются ТВ, контекст, меры (средства) обеспечения ИБ и пр. Соответственно, все оценки для СОИ формируются в расчетных (проверяемых) оценках вероятности. Например, для терминалов промышленной сети Wi-Fi могут быть определены статистические данные отказов, основанные как на данных владельца (FW, SIEM, IPS/IDS, SOC и пр.), так и поставщиков в данном конкретном регионе с учетом температурно-влажностного режима. При оценивании рисков СОИ для исследуемой области Ri может быть применена формула (1):

где:
Rapr i      – оценка априорного риска для Ri области
V(k)ij     – априорная вероятность реализации j-угрозы Ri области
S(n)ij      – априорное значение ущерба j-угрозы Ri области
V max    – максимальная величина вероятности реализации угрозы
S max     – максимальная априорная ущерба реализации угрозы
k          – максимальное значение вероятности (количественная оценка)
n          – максимальное значение ущерба (количественная оценка)

Установлены ограничения при расчете по формуле (1):
0 ≤ Rapr i ≤ 1
V(k)i ≤ k
S(n)i ≤ n

В табл. 6 представлен пример расчета рисков для ИТ-компонент СОИ, представленной на рис. 13, размещенных в R4.1 (L4). Выбраны наиболее значимые (по итогам предпринятого ранее анализа) угрозы (на основании Приложения «С» ISO/IEC 27005), которые можно ожидать для каждой из 4-х областей (Ri) в полной совокупности рассматриваемых локаций (L). Значения вероятности (V) находится в диапазоне (0;1), значение ущерба (S) находится в диапазоне (0;3), значения Rj (для одной угрозы) и Rapr i (общий) находятся в диапазоне (0;1). Критерий принятия риска для данного конкретного примера (Rcr) определен как 10%.

Таблица 6. Пример расчета по формуле (1)

Угроза	Уязвимость	P (1;7)	Vj (0;1)	Sj (0;3)	R j (0,1)	Rcr (10%)	TB
Подслушивание	Плохой менеджмент паролей	Р5	0,50	2	0,33		А.10.1.1. А.12.1.2
Злоупотребление правами	Незащищенное хранение	Р7	0,25	2	0,17		А.9.2.2 А.16.1.2
Отказ телеком. оборудования	Единственная точка отказа	Р5	0,25	1	0,08	ОК	А.10.1.1 А.17.1.2
Преступное использование ПО	Недостатки найма персонала	Р6	0,05	3	0,05	ОК	А.8.1.2 А.16.1.2
Незаконная обработка данных	Малое число ревизий	Р7	0,05	2	0,03	ОК	А.9.4.1 А.18.2.3

Необходимо дать некоторые пояснения по расчету отдельных рисков для конкретных угроз Rj: для угрозы «преступное использование ПО» (например, при обеспечении процесса бухгалтерского учета) вероятность реализации угрозы определена V(1)4 = 0,05, уровень величины ущерба составляет S(3)4 = 3 (максимальный), что по формуле (1) при V max = 1 и S max = 3 позволяет определить значение риска R4 = 0,05. Можно отметить, что вероятность (V(1)4) 5% получена ранее на основе статистики в ряде проектов, и такие же данные были позже представлены в ежегодном отчете Cisco [39], т.е. все эти исходные данные могут быть верифицированы надежно и независимо. По аналогии могут быть вычислены и ранжированы по убыванию риски реализации для иных угроз (см. табл. 6), и совокупно, с учетом превышения (Rj > Rcr) суммарный априорный риск для данного примера составит 25%:

Очевидно, может возникнуть вопрос, как отличались бы риски, рассчитанные по формуле (1) тех же угроз для ИТ-компонентов «распределенной» СОИ, например, находящейся под полным контролем бизнеса (пример на рис. 13). Ответ может быть предоставлен следующий – для точного результата «гибридной методики» необходимы данные реализованных мер защиты (в частности ТВ), отражающие текущий уровень безопасности. Например, для рассмотренной «распределенной» СОИ при допущении более строгих мер контроля, в том числе встроенных ФБ (см. табл. 4) в применяемое ПО и дополнительных рутинных процедур, реализованных по требованиям бизнеса, можно ожидать более низкий уровень величины ущерба S(3)j. Но в любом случае, это предположение должно быть проверено в рамках выполняемого периодического оценивания (аудита) до принятия решения о переходе к «облачным» сервисам.

13. Определение ожиданий или предположений безопасности. Как отмечалось выше, ИТ (ИБ) службы должны предоставить бизнес-заказчикам достоверные и объективные расчеты безопасного перехода на «облачные» сервисы. Хорошей стартовой точкой будет определение, какие из предложенных провайдером «облачных» сервисов действительно приемлемы для бизнеса, например, не только с точки зрения «классической триады», но и с точки зрения критичности и/или обеспечения доступности. Например, расчеты могут выполняться по «гибридной методике», ранжируя в итоговой таблице значения по аналогии с наибольшей вероятностью (V(1)1 = 0,5) или значения ущерба (S(3)4 = 3) для выбранных угроз. Хорошей практикой будет использование в этой процедуре оценивания широко известных каталогов угроз из стандарта ISO/IEC 27005 ([51]) или банка данных угроз безопасности информации ФСТЭК. Основные шаги процедуры определения ожиданий и предположений безопасности для «облачных» сервисов включают:

• Определение общего списка сервисов, имеющихся в компании («как есть»);
• Определение метрик, по которым будет определяться (оцениваться) требуемый уровень безопасности (ISO, NIST, IEC);
• Определение готовности «облачного» провайдера действительно их предоставить (аудит соответствия ISO, PCI DSS, TIER и пр.);
• Определение состава подрядчиков у провайдера «облачных» сервисов (степень и меры их контроля со стороны провайдера);
• Определение степени влияния регуляторов на деятельность провайдера «облачных» сервисов (ФЗ-161, ФЗ-184, ФЗ-187);
• Определение средств измерения и формирования отчетности (со стороны провайдера «облачных» сервисов);
• Определение порядка мониторинга и реагирования на инциденты (со стороны провайдера «облачных» сервисов);
• Определение каналов коммуникаций с провайдером «облачных» сервисов (в т.ч. экстренных);
• Определение ответственности (в т.ч. санкций) со стороны провайдера «облачных» сервисов

14. Заключение. В представленной статье рассмотрена проблема формирования процесса оценивания информационной безопасности как важного этапа общего процесса обеспечения безопасности ИТ-компонент в «облачных» системах и, в определённой степени, обеспечении национального ИТ-суверенитета. Обращено внимание, что недостаточно следовать только рекламным маркетинговым инициативам от иностранных провайдеров. Для решения данной проблемы оценивания предложена «гибридная методика», основанная на современных риск-ориентированных стандартах ISO/IEC серии 27001 и 15408, и иных стандартах для оценивания функциональной безопасности и аудита систем менеджмента. Применение «гибридной методики» позволяет получить расчетные результаты в процессе оценивания уровня безопасности ИТ-компонент в ограничениях размещения и состава с требуемой точностью.

Литература

1. Лившиц И.И., Неклюдов А.В. Применение гибридной методики при оценке безопасности информационных технологий для сложных промышленных объектов // Менеджмент качества. – 2018. – № 1. – С. 48-61.
2. Six Pillars of DevSecOps. URL: https://cloudsecurityalliance.org/artifacts/cloud-security-complexity, 2019 (дата обращения 01.11.2019).
3. Bandyopadhyay T, Liu D, Mookerjee VS, Wilhite AW. Dynamic competition in it security: A differential games approach. Information Systems Frontiers 16(4):643-661, 2014.
4. Matsukawa Bakuei, Ryan Flores, Vladimir Kropotov, and Fyodor Yarochkin Securing Smart Factories: Threats to Manufacturing Environments in the Era of Industry 4.0
5. The 2019 Study on the Cyber Resilient Organization. Ponemon Institute, April 2019
6. Matthew P Barrett. Framework for Improving Critical Infrastructure Cybersecurity Version 1.1, 2018.
7. Tyler Moore, Scott Dynes, and Frederick R Chang. Identifying How Firms Manage Cybersecurity Investment. In Workshop on the Economics of Information Security (WEIS) 2016, pages 1-27, 2016.
8. Christina Y Jeong, Sang-Yong Tom Lee, and Jee-Hae Lim. Information Security Breaches and IT Security Investments: Impacts on Competitors. Information & Management, In Press, 2018.
9. Malladi A., Potluri S. A study on technologies in Cloud-based design and manufacturing. International Journal of Mechanical and Production Engineering Research and Development. 2018. V. 8. N 6. Pp. 187-192.
10. Souri A., Rahmani A.M., Navimipour N.J. Formal verification approaches and standards in the Cloud computing: A comprehensive and systematic reviews. Computer Standards & Interfaces. 2018. V. 58. Pp. 1-22.
11. Yin C., Lv H., Cui Z., Li T., Liu Y., Wang J., Cheng L. BD Code: An Erasure Code algorithm for big data storage system. Journal of University of Science and Technology of China. 2016. V. 46. N 3. Pp. 188-199.
12. Tan D.-P., Li L., Zhu Y.-L., Zheng S., Ruan H.-J., Jiang X.-Y. An Embedded Cloud Database service Method for distributed industry monitoring. IEEE Transactions on Industrial Informatics. 2018. V. 14. N 7. Pp. 2881-2893.
13. Bologa R., Lupu A.-R., Boja C., Georgescu T.M. Sustaining employability: A process for introducing Cloud computing, big data, social networks, mobile programming and cybersecurity into academic curricula. Sustainability. 2017. V. 9. N 12. P. 2235.
14. Kobayashi N., Kume S., Lenz K., Masuya H. Riken metadatabase: A database platform for health care and life sciences as a microcosm of linked open data cloud. International Journal on Semantic Web and Information Systems. 2018. V. 14. N 1. Pp. 140-164.
15. Manoj Kumar M., Nandakumar A.N. Exploring multilateral Cloud computing security architectural design debt in terms of technical debt. Smart Innovation, Systems and Technologies. 2018. V. 78. Pp. 567-579.
16. Hudic A., Smith P., Weippl E.R. Security assurance assessment methodology for hybrid Cloud. Computers & Security. 2017. V. 70. Pp. 723-743.
17. Jun Z. A security architecture for Cloud computing alliance. Recent Advances in Electrical and Electronic Engineering. 2017. V. 10. N 3. Pp. 195-201.
18. Matri P., Pérez M.S., Costan A., Bougé L., Antoniu G. Keeping up with storage: decentralized, write-enabled dynamic Geo-replication. Future Generation Computer Systems. 2018. V. 86. Pp. 1093-1105.
19. Akbaripour H., Houshmand M., van Woensel T., Mutlu N. Cloud manufacturing service selection optimization and scheduling with transportation consideration: mixed-integer programming model. The International Journal of Advanced Manufacturing Technology. 2018. V. 95. N 1-4. Pp. 43-70.
20. Bangui H., Ge M., Buhnova B., Pitner T., Rakrak S., Raghay S. Multi-criteria decision analysis methods in the mobile Cloud offloading paradigm. Journal of Sensor and Actuator Networks. 2017. V. 6. N 4. Pp. 25.
21. Goyal T., Rathi R., Jain V.K., Pilli E.S., Mazumdar A.P. Big data handling over Cloud for internet of things. International Journal of Information Technology and Web Engineering. 2018. V. 13. N 2. Pp. 37-47.
22. Липатников В.А., Шевченко А.А. Модель процесса управления информационной безопасностью распределенной информационной системы на основе выявления и оценки уязвимостей // Информационные системы и технологии. – 2018. – № 1 (105) . – С. 114-123.
23. Липатников В.А., Сахаров Д.В., Кузнецов И.А. Управление АСМК организации интегрированной структуры с прогнозированием состояния информационной безопасности // Электросвязь. – 2016. – № 3. – С. 28-36.
24. Cockburn, Alistair and Williams, Laurie .The Costs and Benefits of Pair Programming in Extreme Programming Examined. Addison Wesley, 2001. [Электронный ресурс] – Режим доступа: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF . – Дата доступа: 12.04.2019.
25. Shane Mcintosh, Yasutaka Kamei, Bram Adams and Ahmed E. Hassan, ``The Impact of Code Review Coverage and Code Review Participation on Software Quality: A Case Study of the Qt, VTK, and ITK Projects,'' In Proceedings of International Working Conference on Mining Software Repositories (MSR 2014), pp.192-201, June 2014. (Hyderabad, India).
26. Комплексная защита информации: материалы XХIV науч.-практ. конф., Витебск, 21-23 мая 2019 г. – Витебск : ВГТУ, 2019. – 406 с. ISBN 978-985-500-865-2.
27. Лившиц И.И., Неклюдов А.В. Гибридная методика оценки безопасности информационных технологий // Автоматизация в промышленности. – 2017. – № 7. – С. 36-41.
28. Лившиц И.И., Неклюдов А.В. Гибридная методика безопасности информационных технологий для критически важных объектов энергетики // Энергобезопасность и энергосбережение. – 2017. – № 4. – С. 5-11.
29. By Jon Oltsik. URL: https://www.csoonline.com/article/3406475/must-have-features-in-a-modern-network-security-architecture.html , 2019 (дата обращения 01.11.2019).
30. Using standards to mitigate risks. URL: https://www.dhs.gov/sites/default/files/publications/2018_AEP_Artificial_Intelligence.pdf , 2019 (дата обращения 01.11.2019).
31. Кристина Жукова. URL: https://www.kommersant.ru/doc/3939724?from=four_tech , 2019 (дата обращения 01.11.2019).
32. Наталья Рудычева. URL:http://www.cnews.ru/reviews/rynok_ituslug_2018/articles/vse_kak_servis_rynok_ituslug_rastet_ne_tolko_v_dengah, 2019 (дата обращения 01.11.2019).
33. Rise of Legitimate Services for Backdoor Command and Control.
    URL: https://www.anomali.com/resources/anomali-labs-reports/rise-of-legitimate-services-for-backdoor-command-and-control , 2019 (дата обращения 01.11.2019).
34. Lucian Constantin. URL: pcworld.com/article/3157417/security/after-mongodb-ransomware-groups-hit-exposed-elasticsearch-clusters.html, 2019 (дата обращения 01.11.2019).
35. Исследование утечек конфиденциальной информации через незащищенные облачные хранилища.
    URL:https://www.infowatch.ru/sites/default/files/report/analytics/russ/InfoWatch_Report_open_servers_2016_2018.pdf?rel=1, 2019 (дата обращения 01.11.2019).
36. Chris Crowley. URL: https://www.sans.org/media/vendor/Common-and-Best-Practices-for-Security-Operations-Centers.pdf, 2019 (дата обращения 01.11.2019).
37. The State of Threat Detection Report 2019. URL: https://www.fidelissecurity.com/resource/report/threat-detection-2019 , 2019 (дата обращения 01.11.2019).
38. Отсутствие автоматизации остается главной проблемой для безопасников. URL: https://www.securitylab.ru/news/500340.php , 2019 (дата обращения 01.11.2019).
39. Threats are rising. URL: cisco.com/c/m/en_au/products/security/offers/cybersecurity-reports.html, 2019 (дата обращения 01.11.2019).
40. Strategic planning guides for leaders across the enterprise. URL:https://www.gartner.com/en/insights/strategic-planning, 2019 (дата обращения 01.11.2019).
41. Соколов Б.В., Юсупов Р.М. Неокибернетика в современной структуре системных знаний // Робототехника и техническая кибернетика, 2014, вып. 3, стр. 3 – 11.
42. Сборник работ лауреатов международного конкурса научных, научно-технических и инновационных разработок, направленных на развитие топливно-энергетической и добывающей отрасли. — М.: Министерство энергетики Российской Федерации, ООО «Технологии развития», 2019. ISBN: 978-5-7688-1169-3
43. ГОСТ Р ИСО/МЭК 15408-1 – 2012 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель // М.: ФАТРиМ, 2012.
44. ГОСТ Р ИСО/МЭК 15408-2 – 2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности // М.: ФАТРиМ, 2013.
45. ГОСТ Р ИСО/МЭК 15408-3 – 2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности // М.: ФАТРиМ, 2013.
46. State of Application Security: Balancing Speed and Risk. URL: https://www.sans.org/reading-room/whitepapers/analyst/2017-state-application-security-balancing-speed-risk-38100 , 2019 (дата обращения 01.11.2019).
47. ГОСТ Р МЭК 61508-1—2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования».
48. ГОСТ Р МЭК 61508-2—2012 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам».
49. ГОСТ Р МЭК 61508-3—2018 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению».
50. ISO/IEC 27001:2013 Information technology – Security techniques – Information security management systems – Requirements, International Organization for Standardization, 2013. – 23 pages.
51. ISO/IEC 27005-2018 Information technology — Security techniques — Information security risk management, International Organization for Standardization, 2011.– 68 pages.
52. 68% ИТ-специалистов не могут защититься от кибератак. URL: https://www.securitylab.ru/news/499965.php , 2019 (дата обращения 01.11.2019).
53. Supply chain attack. URL: https://www.cloudav.ru/mediacenter/news/business-risks-supply-chain-attacks, 2019 (дата обращения 01.11.2019).
54. «Автодор» и «Росэнергоатом» приступили к тестированию нового ЦОДа. URL:http://www.cnews.ru/news/line/2019-01-15_avtodor_i_rosenergoatom_pristupili_k_testirovaniyu, 2019 (дата обращения 01.11.2019).
55. Одна из самых больших DDoS-атак в истории. URL: https://habr.com/ru/post/174483 , 2019 (дата обращения 01.11.2019).
56. Самая долгая DDoS-атака в России продолжалась 80 дней. URL: https://texnomaniya.ru/internet-news/samaja-dolgaja-ddos-ataka-v-rossii-prodolzhalas-80-dnejj.html , 2019 (дата обращения 01.11.2019).
57. 73 тысячи «показных» боеприпасов. URL: http://nvo.ng.ru/realty/2019-07-12/14_15_1052_army2019.html , 2019 (дата обращения 01.11.2019).
58. Forrester оценила поставщиков решений для реализации стратегии ZTX. URL: https://www.securitylab.ru/news/496550.php , 2019 (дата обращения 01.11.2019).
59. Zero Trust redefines security in a perimeter-less world. URL: https://www.mobileiron.com/en/solutions/zero-trust , 2019 (дата обращения 01.11.2019).
60. The Forrester Wave™: Zero Trust eXtended (ZTX) Ecosystem Providers, Q4 2018. URL: https://reprints.forrester.com/?fbclid=IwAR3iPICwQnteW1BF7VgoISlz0P2d5nVB11aoQsrEqYbHu4R2USf6wrFUG7w#/assets/2/219/RES141666/reports , 2019 (дата обращения 01.11.2019).
61. 5 Key Findings from Forbes Insights’ 2019 Cybersecurity Survey. URL:https://www.vmware.com/radius/forbes-insights-cybersecurity-strategy-report, 2019 (дата обращения 01.11.2019).
62. Improving Information Risk Management  and Assurance in a Cyber World. URL: https://hitrustalliance.net/content/uploads/Improving-Risk-Management-Assurance.pdf , 2019 (дата обращения 01.11.2019).
63. Conformity assessment. URL: https://www.iso.org/conformity-assessment.html , 2019 (дата обращения 01.11.2019).
64. Results for algorithms submitted to NIST in late 2018. URL: https://www.nist.gov/programs-projects/face-recognition-vendor-test-frvt-1n-2018-evaluation , 2019 (дата обращения 01.11.2019).
65. What are Standards? Why are They Important. URL: https://beyondstandards.ieee.org/general-news/what-are-standards-why-are-they-important , 2019 (дата обращения 01.11.2019).
66. Лившиц И. И. Методика оптимизации программы аудита интегрированных систем менеджмента // Труды СПИИРАН. – 2016. – № 5. – С. 52–68.
67. Лившиц И. Система менеджмента информационной безопасности по международным стандартам // Управление качеством. 2011. № 9. С. 6-11.
68. Лившиц И.И. Проектирование, создание и внедрение комплексных систем обеспечения информационной безопасности на базе ISO/IEC 27001:2005 // Электросвязь. 2010. № 4. С. 49-51.
69. Лившиц И.И., Лившиц Н.В. Подходы к синтезу моделей систем менеджмента информационной безопасности при оценке утечек конфиденциальных данных // Лизинг. 2013. № 3. С. 70-80.
70. Представлена система оценки вероятности использования уязвимостей в реальных атаках. URL: https://www.securitylab.ru/news/500398.php , 2019 (дата обращения 01.11.2019).
71. Только 5,5% уязвимостей используются в реальных атаках. URL:https://www.securitylab.ru/news/499359.php , 2019 (дата обращения 01.11.2019).
72. Improving Vulnerability Remediation  Through Better Exploit Prediction. URL:https://weis2019.econinfosec.org/wp-content/uploads/sites/6/2019/05/WEIS_2019_paper_53.pdf, 2019 (дата обращения 01.11.2019).
73. Artificial Intelligence: Potential Benefits and Ethical Considerations. URL: http://www.europarl.europa.eu/RegData/etudes/BRIE/2016/571380/IPOL_BRI(2016)571380_EN.pdf , 2019 (дата обращения 01.11.2019).