Модель угроз фстэк сценарии

Содержание данной статьи проверено и подтверждено:

Что такое модель угроз

Модель угроз (безопасности информации) — это физическое, математическое, описательное представление свойств или характеристик угроз безопасности информации.
Угроза безопасности информации — это совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации.

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

Соответственно, модель угроз — это документ, назначение которого— определить угрозы, актуальные для конкретной системы. Только по факту наличия у организации подобного документа законодательные требования по моделированию будут выполнены.

Процесс разработки модели угроз

Содержимое модели угроз полностью описано новой методикой оценки ФСТЭК, выпущенной 5 февраля 2021, она пришла на смену полностью устаревшей базовой модели угроз 2008 года. Новая методика диктует следующие требования к содержанию модели:

• определить все последствия, которые могут возникнуть в случае использования угроз (ущерб рядовым гражданам или компаниям, ущерб государству);
• определить все возможные объекты для атак, перечислить функционирующие в ИС системы и сети, каналы связи;
• оценить возможности вероятных злоумышленников, иными словами – определить источники атак;
• оценить способы атак, вероятные для исследуемой системы;
• оценить возможности по выполнению атак и определить актуальность угроз;
• оценить вероятные сценарии атак в Ваших сетях.

Это обобщённое наполнение реальной модели угроз, но всё же дословно следовать этому списку не следует. При разработке собственного документа можно и нужно опираться на приложение 3 новой методики ФСТЭК, на его основе можно сразу составить оглавление:

1. Введение.
2. Описание систем и сетей. Должен включать в себя наименования, классы защищённости, задачи, бизнес-процессы, архитектуру, описание групп пользователей, интерфейсов нормативно-правовую базу функционирования конкретных систем, в общем, исчерпывающую информацию о всех функционирующих системах и сетях.
3. Возможные последствия. Должен содержать описание видов ущерба, актуальных для владельца ИС, а также негативных последствий, которые повлекут за собой описанный ущерб.
4. Возможные объекты воздействия. Требуется наличие наименований и назначения компонентов систем и сетей, воздействие на которые может привести к нежелательным последствиям.
5. Источники. Должен включать категории возможных нарушителей, их характеристику и возможности.
6. Способы. Здесь необходимо описать способы реализации угроз, которые могут быть использованы возможными нарушителями, а также описать интерфейсы, через которые наиболее вероятные нарушители могут реализовать атаки.
7. Актуальные угрозы. Финальный список всех возможных угроз, составленный на основе всех предыдущих глав. Также должен включать описание вероятных сценариев реализации и выводы об актуальности угроз. Главы 2–5 методики ФСТЭК дают исчерпывающие рекомендации по разработке каждого элемента модели угроз. Приложения 4–11 дают примеры таблиц, которые должны быть приведены в документе, опираясь на них, вполне возможно создать собственную модель угроз.

Модель угроз: основные моменты

Подводя итоги: модель угроз — это один из главных элементов всего пакета внутренних документов ИБ, который должен содержать выявление вероятных угроз для Вашей информационной системы. Требования к структуре и содержанию предъявляет новая методика оценки угроз безопасности информации ФСТЭК, она же даёт подробные рекомендации по разработке частной модели угроз.

Всем привет, мы продолжаем свой цикл статей по «бумажной безопасности». Сегодня поговорим о разработке модели угроз. Если цель прочтения этой статьи в получении практических навыков, то лучше сразу скачать наши шаблоны документов, в котором есть и шаблон модели угроз. Но и без шаблона под рукой со статьей тоже можно ознакомиться в общеобразовательных целях.

Зачем нужна модель угроз?

Необходимость разработки модели угроз регламентирована рядом нормативных документов. Вот некоторые из них.

Часть 2 статьи 19 закона №152-ФЗ «О персональных данных»:

2. Обеспечение безопасности персональных данных достигается, в частности:

1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных;

Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных (утверждены приказом ФСТЭК России от 18 февраля 2013г. №21):

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

Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены ФСТЭК России от 11 февраля 2013г. №17)

Формирование требований к защите информации… в том числе включает:
…
определение угроз безопасности информации, реализация которых может привести к нарушению безопасности информации в информационной системе, и разработку на их основе модели угроз безопасности информации;
…

Требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды (утверждены приказом ФСТЭК России от 14 марта 2014г. №31):

Формирование требований к защите информации в автоматизированной системе управления… в том числе включает:
…
определение угроз безопасности информации, реализация которых может привести к нарушению штатного режима функционирования автоматизированной системы управления, и разработку на их основе модели угроз безопасности информации;

Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (утверждены приказом ФСТЭК России от 25 декабря 2017г. №239):

11. Разработка организационных и технических мер по обеспечению безопасности значимого объекта осуществляется субъектом критической информационной инфраструктуры… и должна включать:

а) анализ угроз безопасности информации и разработку модели угроз безопасности информации или ее уточнение (при ее наличии);

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

Содержание модели угроз

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

В качестве хрестоматийного примера описания содержания модели угроз можно привести 17 приказ ФСТЭК:

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

Вы не поверите, но это все. Но с другой стороны, хоть текста и не много, но он довольно содержательный. Давайте еще раз перечитаем и выпишем, что должно быть в нашей модели угроз:

• описание информационной системы;
• структурно-функциональные характеристики;
• описание угроз безопасности;
• модель нарушителя;
• возможные уязвимости;
• способы реализации угроз;
• последствия от нарушения свойств безопасности информации.

Это по законодательству, что требует ФСТЭК. Так же дополнительно есть требования ФСБ (о них чуть позже) и некоторые неофициальные требования-пожелания от ФСТЭК, с которыми мы столкнулись в процессе согласования моделей угроз государственных информационных систем.

Вступительная часть модели угроз

Хорошо, давайте уже перейдем к содержанию документа.

Думаю про титульный лист, список сокращений, терминов и определений все понятно. Хотя, пожалуй, стоит поподробнее остановиться на… внезапно титульном листе.

В шаблоне его подписывает именно руководитель владельца информационной системы. Это не просто так.

Постановление Правительства РФ от 11 мая 2017г. №555:

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

Естественно, если информационная система не государственная и оператор системы не является органом исполнительной власти, то подписывать модель угроз может кто угодно. Просто мы не раз сталкивались, когда при выполнении вышеуказанных условий (государственная информационная система органа исполнительной власти) заказчик нас просил изменить титульный лист, чтобы там были подписи только представителей компании-лицензиата (то есть – наши). Приходилось объяснять, почему такую модель угроз ФСТЭК вернет на доработку.

Раздел «Нормативно-методическое обеспечение»

Здесь хотелось бы вспомнить, о том, что модель угроз может разрабатываться для очень разных систем – от ИСПДн до КИИ. Поэтому и список нормативной документации может отличаться. Например, если мы разрабатываем модель угроз для АСУ ТП, то из шаблона нужно убрать 21 и 17 приказы ФСТЭК и добавить 31-й.

Документы, помеченные аббревиатурой «СКЗИ» это нормативные документы ФСБ, регламентирующие обращение с шифровальными средствами. Если криптосредства в информационной системе не используется (сейчас это редкость, но все же), то эти нормативные документы из списка необходимо удалить.

Частой ошибкой здесь бывает добавление различных ГОСТ и прочих нормативных документов (очень любят сюда вписывать СТР-К), никак не связанных с моделированием угроз. Либо отмененных документов. Например, часто в моделях угроз можно встретить в списке нормативных документов ФСБшные так называемые «Методические рекомендации…» и «Типовые требования…», которые давно не актуальны.

Общие положения

Здесь в шаблоне представлена стандартная вода – зачем нужна модель угроз и т. д. То, на чем нужно здесь заострить внимание это комментарий по поводу вида рассматриваемой информации. По умолчанию в шаблоне представлен наиболее часто встречаемый вариант – персональные данные (ПДн). Но в системе может не быть персональных данных, но может быть другая конфиденциальная информация (КИ), а еще информация может быть не конфиденциальной, но защищаемой (ЗИ) по другим характеристикам – целостность и доступность.

Описание информационной системы

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

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

Пример:

Серверная часть информационной системы «Нипель» представляет собой кластер физических серверов, на которых развернут гипервизор ESXi 6.x. Работа серверной части основных сервисов информационной системы обеспечивается виртуальными серверами (имена серверов) под управлением операционных систем (список ОС). Основным программным обеспечением, реализующим технологические процессы обработки является (название ПО). Прикладное программное обеспечение является клиент-серверным приложением. Клиентская часть работает как толстый клиент на рабочих станциях пользователей под управлением операционных систем (список ОС). Пользователи получают доступ к информационной системе, как из локальной сети, так и через сеть интернет с использованием защищенных каналов связи. В целом информационная система функционирует как показано на схеме.

Прикладывается функциональная (не топологическая!) схема информационной системы.

Вот примерно так оно обычно выглядит. Стиль и другие детали, конечно, могут сильно отличаться, главное – информация, которую можно подчерпнуть из описания.

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

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

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

Модель нарушителя

Здесь можно разделить эту часть на классическую и новую. Классическая это та самая, где описаны потенциальные нарушители 1, 2 и далее категорий. На самом деле эта часть модели нарушителя оставлена в шаблоне только потому, что регуляторам нравится, когда она есть. Практическую же ценность представляет раздел «Нарушители согласно банку данных угроз ФСТЭК России».

Практическую ценность этот раздел представляет потому, что сами угрозы из банка данных угроз ФСТЭК (далее – БДУ) привязаны к нарушителям с низким, средним и высоким потенциалом. Сам раздел представляет из себя копипасту описаний характеристик нарушителей с низким, средним и высоким потенциалами. Далее делается вывод нашим любимым «экспертным» путем — какой нарушитель для нас актуален. То есть, по сути, составитель выбирает нарушителя «на глаз», потому что каких-либо методик выбора нарушителя просто нет.
Не будем здесь приводить эти описания полностью, постараемся коротко сформулировать, чем отличаются потенциалы нарушителей. Кроме разграничения по потенциалу нарушители еще бывают внешние и внутренние.

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

В реалистичных ситуациях потенциал нарушителя либо низкий, либо средний.

«ФСБшные» разделы

Далее идут разделы «Обобщенные возможности источников атак» и «Реализация угроз безопасности информации, определяемых по возможностям источников атак». Эти разделы не нужны, если не используются криптосредства. Если они все же используются, то исходные данные, да и в целом таблицы для этих разделов выдумывать не нужно, они берутся из нормативного документа ФСБ «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432).

У нас правда в шаблоне результат несколько отличается от дефолтного, приведенного в указанном выше, документе ФСБ.

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

Чаще всего применимый класс криптосредств – КС3. Сейчас расскажем почему.

Вообще в документе «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378) класс СКЗИ для рассматриваемой системы устанавливается, во-первых исходя из типа угроз, а во-вторых исходя из возможностей нарушителя.

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

Потому что 378 приказ ФСБ:

• СКЗИ класса КА в случаях, когда для информационной системы актуальны угрозы 1 типа;
• СКЗИ класса КВ и выше в случаях, когда для информационной системы актуальны угрозы 2 типа;
• СКЗИ класса КС1 и выше в случаях, когда для информационной системы актуальны угрозы 3 типа.

Вроде понятно, а в чем проблема? Проблема в том, что СКЗИ классов КА1, КВ1 и КВ2 вы не сможете купить просто так, даже если у вас есть куча денег, которых они стоят.

Проведем небольшое «расследование». Качаем свежий реестр СКЗИ, ищем СКЗИ класса КА1. Поиском первым попался «Аппаратно-программный шифратор М-543К». Идем в гугл, пишем «Аппаратно-программный шифратор М-543К купить» — провал. Пытаемся «купить» следующее криптосредство – опять провал. Вбиваем просто «криптосредство КА1 купить» — провал. Получаем только ссылки на другие криптосредства классов КС1-КС3 или на форумы, где обсуждают криптографию. А дело в том, что, как уже было сказано, просто так купить СКЗИ классов КА и КВ вы не сможете, только через специализированные воинские части. Зачем было эти криптосредства вообще упоминать в документе по персональным данным – до сих пор не ясно. Поэтому в обычной ИСПДн — только третий тип угроз.

С КА и КВ разобрались, но почему именно КС3, а не КС2 и КС1? Тут уже виновато второе условие – нарушитель.

378 приказ ФСБ:

12. СКЗИ класса КС3 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа перечисленных в пунктах 10 и 11 настоящего документа и не менее одной из следующих дополнительных возможностей:

а) физический доступ к СВТ, на которых реализованы СКЗИ и СФ;
б) возможность располагать аппаратными компонентами СКЗИ и СФ, ограниченная мерами, реализованными в информационной системе, в которой используется СКЗИ, и направленными на предотвращение и пресечение несанкционированных действий.

Тут логика такая:

• такие распространенные СКЗИ, как, например ViPNet Client или КриптоПРО CSP реализованы на рабочих станциях пользователей;
• пользователи – потенциальные нарушители;
• потенциальный нарушитель имеет физический доступ к средствам вычислительной техники, на которых реализованы их СКЗИ и среда функционирования.

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

Уязвимости

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

У составителя модели угроз сразу должен появиться вопрос: а что нужно прям список выявленных сканером уязвимостей к документу прикладывать? Вопрос хороший и ответ не однозначный. Знаем мы коллег, которые делают именно так, но мы считаем такой подход неправильным и вот почему.

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

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

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

Выход из этой ситуации простой. Указывать в модели угроз не конкретные уязвимости с указанием идентификатора CVE и рейтинга CVSS, а перечислить возможные классы уязвимостей для конкретной информационной системы. А чтобы придать этому списку солидности, возьмем этот список не из головы, а из ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». Перечень под спойлером. Берем его и убираем лишние, не совместимые со структурно-функциональными характеристиками нашей системы. Раздел готов!

Частная модель угроз безопасности

И вот только здесь мы приступаем непосредственно к определению актуальных угроз.
Методика определения актуальных угроз от ФСТЭК 2008 года слегка попахивает и о ней мы уже писали здесь. Но здесь ничего не поделаешь, как в той же статье отмечено – что есть, с тем и работаем. Давайте же посмотрим, что конкретно нам нужно сделать, чтобы получить список актуальных угроз.

Свежие документы от ФСТЭК предписывают в качестве исходных данных для угроз безопасности информации использовать БДУ. Сейчас там 213 угроз и список может пополняться.

Здесь сразу же хотелось бы рассказать о плюсах и минусах БДУ. Несомненный плюс – это то, что теперь нет необходимости придумывать и формулировать угрозы самостоятельно, хотя дополнить модель угроз своими угрозами тоже ничего не запрещает. Еще один плюс это прописанный потенциал нарушителя и определенные нарушаемые характеристики безопасности информации для каждой угрозы – не нужно ничего выдумывать.

Минусы. Первый минус это до ужаса скудные возможности по сортировке угроз. Когда вы первый раз начинаете делать модель угроз по БДУ, то естественное желание это отсеять угрозы, которые не могут быть актуальны в вашей системе по структурно-функциональным характеристикам. Например, убрать угрозы для виртуальных контейнеров и гипервизоров, потому что в системе не применяется виртуализация или отобрать угрозы для BIOS/UEFI нужно по какой-то причине, а такой возможности нет. Не говоря уже о том, что в БДУ целый ряд достаточно экзотических угроз, связанных, например, с суперкомпьютерами или грид-системами.

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

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

Вернемся определению списка актуальных угроз.

Уровень исходной защищенности

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

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

Список характеристик под спойлером.

Каждому значению соответствует высокий, средний или низкий уровень защищенности. Считаем какой процент у нас получился для показателей с разными значениями. Про высокий уровень исходной защищенности – забудьте, его не бывает. Если «высокий» и «средний» набрали 70% и выше, то определяем средний уровень исходной защищенности (Y1 = 5), если нет, то – низкий (Y1 = 10).

Опасность угроз

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

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

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

По нашей логике негативные последствия не зависят от способа нарушения конфиденциальности, целостности и доступности. Например, если ваши персональные данные утекут в какой-то базе, то вам скорее всего будет неважно каким образом это произошло – с помощью SQL-инъекции или с помощью физического доступа нарушителя к серверу (профессиональный интерес ИБ-шника не в счет!). Поэтому определяем так сказать три «опасности угроз», для нарушения конфиденциальности, целостности и доступности. Часто они могут совпадать, но все равно в модели угроз лучше отдельно проанализировать. К счастью, в БДУ для каждой угрозы нарушаемые характеристики тоже прописаны.

Исключение «лишних» угроз

Далее, чтобы сразу отсечь лишние угрозы делаем табличку со списком исключаемых угроз и обоснование – почему мы их выкидываем.

В шаблоне в качестве примера представлены:

• исключение угроз, связанных с грид-системами, суперкомпьютерами и большими данными;
• исключение угроз, связанных с виртуализацией;
• исключение угроз, связанных с использованием беспроводных сетей связи;
• исключение угроз, связанных с использованием облачных сервисов;
• исключение угроз для АСУ ТП;
• исключение угроз, связанных с использованием мобильных устройств;
• исключение угроз, реализация которых возможна только нарушителем с высоким потенциалом.

По последнему пункту нужно уточнить пару моментов:

• если вы определили нарушителя с низким потенциалом, то здесь исключаются угроз, которые может осуществить нарушители со средним и высоким потенциалом;
• исключаются только оставшиеся угрозы, которые не были исключены в предыдущих пунктах;
• обращайте внимание на то, что в БДУ для некоторых угроз для внутренних и внешних нарушителей может быть определен разный потенциал.

Описание угроз

Далее идет таблица с описанием угроз, которые не были исключены. Да, здесь нужно именно копипастить текст из БДУ, потому что в модели угроз должно быть «описание угроз», отделаться идентификаторами не получится. Давайте посмотрим, что у нас в этой таблице есть.

Номер по порядку и идентификатор угроз из БДУ – тут все понятно. Столбцы «описание угрозы» и «способ реализации угрозы» — текстовый блок из БДУ. В первый столбик вставляем текст до слов «Реализация угрозы возможна…». Во второй – все остальное. Разделение опять же связано с требованием нормативных документов о том, что в модели угроз должны быть описаны «Способы реализации угрозы». При согласовании это поможет избежать лишних вопросов.

Следующие столбцы таблиц это потенциалы внутреннего и внешнего нарушителей. Для того чтобы сделать таблицу боле компактной и дать больше места текстовым блокам мы предварительно сопоставили высокому, среднему и низкому потенциалам соответственно цифры 1, 2 и 3. Если потенциал в БДУ не указан, ставим прочерк.

Столбец «Объекты воздействия» — также берем данные из БДУ.

Столбец «Нарушаемые свойства» — К, Ц и Д, конфиденциальность, целостность и доступность – заменили на буквы с той же целью, что и в случае с нарушителями.

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

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

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

Список актуальных угроз

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

В последней таблице мы умышленно не стали включать некоторые параметры:

• Y1 – этот параметр у нас глобальный, поэтому просто держим его в голове;
• предпосылки – в финальной таблице у нас только угрозы, имеющие предпосылки, поэтому смысла в этом столбце нет.

Коротко пройдемся по столбцам. Номер по порядку и угроза уже только в виде идентификатора – тут все понятно.

«Меры приняты» — «экспертным» путем определяем, приняты ли меры для нейтрализации данной угрозы (кстати, еще один прикол методики — если меры «приняты», то угроза все равно может остаться актуальной). Может быть три варианта: приняты; приняты, но недостаточны; не приняты (+, +-, — соответственно).

Исходя из принятых мер и учитывая, что для угрозы есть предпосылки определяется коэффициент вероятности (Y2), как его определить – выше под спойлером.

Следующий столбец – коэффициент реализуемости угрозы Y. Вычисляется по простой формуле Y = (Y1+Y2)/20.

Возможность реализации – это вербальный аналог коэффициента Y. Определяется в зависимости от числового значения следующим образом:

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

Ну и последнее – актуальность угрозы. Определяется по таблице:

Ура! Наша модель угроз готова.

5.1 Определение источников угроз безопасности информации

Рисунок 5. Внешний нарушитель при реализации угроз безопасности информации

Рисунок 6. Внутренний нарушитель при реализации угроз безопасности информации

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

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

Основными факторами возникновения угроз безопасности информации, связанными с техногенными источниками, могут являться:
а) недостатки качества, надежности программного обеспечения, программно-аппаратных средств, обеспечивающих обработку и хранение информации, их линий связи;
б) недостатки в работе обеспечивающих систем;
в) недоступность сервисов (услуг), предоставляемых сторонними организациями.
Возможность возникновения таких угроз определяется на основе статистики их возникновения за прошлые годы. В случае отсутствия указанной статистики возможно использование экспертной оценки.
Выявление техногенных источников должно осуществляться с учетом требований и правил, установленных уполномоченными федеральными органами исполнительной власти, национальными стандартами(Например, такими стандартами являются: ГОСТ Р 22.0.05-2020 Безопасность в чрезвычайных ситуациях. Техногенные чрезвычайные ситуации. Термины и определения; ГОСТ Р 51901.1-2002 Менеджмент риска. Анализ риска технологических систем (с Поправкой)), и не входит в область действия данной Методики.
5.1.9. По результатам определения источников угроз безопасности информации должны быть определены:
а) виды актуальных нарушителей и возможные цели реализации ими угроз безопасности информации, а также их возможности;
б) категории актуальных нарушителей, которые могут реализовывать угрозы безопасности информации, в том числе непреднамеренные угрозы.
При определении источников угроз безопасности информации необходимо исходить из предположения о наличии повышенной мотивации внешних и внутренних нарушителей, преднамеренно реализующих угрозы безопасности информации. Кроме того, необходимо учитывать, что такие виды нарушителей как специальные службы иностранных государств и террористические, экстремистские группировки могут привлекать (входить в сговор) внутренних нарушителей, в том числе обладающих привилегированными правами доступа. В этом случае уровень возможностей актуальных нарушителей будет определяться совокупностью возможностей нарушителей, входящих в сговор.

5.3.1. В ходе оценки угроз безопасности информации должны быть определены возможные угрозы безопасности информации и оценена их актуальность для систем и сетей – актуальные угрозы безопасности информации.
5.3.2. Исходными данными для оценки актуальности угроз безопасности информации являются:
а) общий перечень угроз безопасности информации, содержащийся в банке данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru), модели угроз безопасности информации, разрабатываемые ФСТЭК России в соответствии с подпунктом 4 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16 августа 2004 г. № 1085, а также отраслевые (ведомственные, корпоративные) модели угроз безопасности информации;
б) описания векторов компьютерных атак, содержащихся в базах данных и иных информационных источниках, опубликованных в сети «Интернет» (CAPEC, ATT&CK, OWASP, STIX, WASC и др.);
в) негативные последствия от реализации (возникновения) угроз безопасности информации, определенные в соответствии с настоящей Методикой; г) объекты воздействия угроз безопасности информации и виды
воздействий на них, определенные в соответствии с настоящей Методикой;
д) виды и категории актуальных нарушителей, которые могут реализовывать угрозы безопасности информации, в том числе непреднамеренные угрозы, и их возможности, определенные в соответствии с настоящей Методикой;
е) актуальные способы реализации (возникновения) угроз безопасности информации.
5.3.3. На основе анализа исходных данных определяются возможные для систем и сетей угрозы безопасности информации, к которым относятся осуществляемые нарушителем воздействия на информационные ресурсы и компоненты систем и сетей (объекты воздействия), в результате которых возможно нарушение безопасности информации и (или) нарушение или прекращение функционирования систем и сетей.
Угроза безопасности информации возможна, если имеются нарушитель или иной источник угрозы, объект, на который осуществляются воздействия, способы реализации угрозы безопасности информации, а реализация угрозы может привести к негативным последствиям:

На этапе эксплуатации систем и сетей для каждой возможной угрозы безопасности информации определяется множество возможных сценариев ее реализации в интересах оценки эффективности принятых технических мер по защите информации (обеспечению безопасности), в том числе средств защиты информации. При этом множество сценариев определяется для каждого актуального нарушителя и уровней его возможностей в соответствии с полученными результатами инвентаризации систем и сетей, анализа уязвимостей и (или) тестирования на проникновение, проведенных с использованием автоматизированных средств (рисунок 8).
5.3.6. На этапе эксплуатации определение сценариев реализации угрозы включает:
а) анализ исходных данных на систему или сеть, предусматривающий в том числе анализ документации, модели угроз безопасности информации, применяемых средств защиты информации, и определение планируемых к применению автоматизированных средств;
б) проведение инвентаризации информационных систем и сетей и определение объектов воздействия и их интерфейсов;
в) определение внешних интерфейсов, которые могут быть задействованы при реализации угроз безопасности информации;
г) определение внутренних интерфейсов, которые могут быть задействованы при реализации угроз безопасности информации;
д) выявление уязвимостей объектов воздействия, а также компонентов систем и сетей, имеющих внешние интерфейсы, с которыми посредством внутренних интерфейсов взаимодействуют объекты воздействия;
е) проведение тестирования на проникновение, подтверждающего возможность использования выявленных уязвимостей или выявления новых сценариев реализации угрозы безопасности информации;
ж) поиск последовательности тактик и техник, применение которых может привести к реализации угрозы безопасности информации, исходя из уровня возможностей актуальных нарушителей, а также результатов инвентаризации, анализа уязвимостей и тестирования на проникновение;
з) составление сценариев реализации угрозы безопасности информации применительно к объектам и видам воздействия, а также способам реализации угроз безопасности информации.

Рисунок 8. Пример сценариев реализации угроз безопасности информации

Введение

В прошлой публикации мы уже говорили о том, что ФСТЭК России последовательно изменяет нормативную базу технической защиты конфиденциальной информации, все больше ориентируя поднадзорные организации на решение практических вопросов безопасности информации. Одним из значимых шагов в этом направлении стало принятие методического документа «Методика оценки угроз безопасности информации».

Какие задачи решает моделирование угроз

Необходимость моделирования угроз установлена основными нормативными документами ФСТЭК России в области безопасности информации для государственных информационных систем, информационных систем персональных данных и значимых объектов критической информационной инфраструктуры (КИИ). Согласно нормативным требованиям, модели угроз необходимы для решения двух задач:

• на стадии создания информационной систем и информационно-телекоммуникационных сетей – для определения предъявляемых к ним требований безопасности информации;
• на стадии их эксплуатации — для выявления новых актуальных угроз и принятия решения о необходимости модернизировать систему защиты информации.

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

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

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

Как эти задачи решаются в мировой практике

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

Наиболее распространенный подход, принятый авторами методических документов (см., например, «A Taxonomy of Operational Cyber Security Risks» или «ENISA Threat Taxonomy») – привести классификацию (taxonomy) угроз и предоставить читателю самостоятельно решить, какие классы угроз актуальны для рассматриваемой ими информационной системы.

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

Более удачный пример классификации разработан Федеральным управлением по информационной безопасности Германии (Bundesamt für Sicherheit in der Informationstechnik, BSI). Авторы разработали всеобъемлющий (более 4700 страниц) каталог типовых объектов ИТ-инфраструктуры, характерных для них угроз и соответствующих им мер защиты («IT Grundschutz Catalogues», ранее известный как «IT Baseline Protection Manual»).

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

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

Еще более детальные сценарии реализации угроз можно построить методами «Cyber Kill chain», описанными в предыдущей статье. Основным источником сведений об угрозах, которые используются при таком моделировании, является база знаний MITRE ATT&CK.

Описанные выше методологии раскрывают информацию о типовых объектах ИТ-инфраструктуры, подверженных атакам нарушителя, и способах воздействия на них, но не описывают процесс моделирования угроз. Основной целью разработки методического документа ФСТЭК России являлось структурирование самого процесса моделирования угроз.

Процесс моделирования угроз в методическом документе ФСТЭК России

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

Согласно документу, моделирование угроз включает в себя решение следующих задач:

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

Рассмотрим эти задачи по отдельности.

Определение негативных последствий

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

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

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

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

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

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

• для крупной организации – единовременное хищение на сумму свыше 10 млн рублей или серия однотипных хищений на общую суммы свыше 500 млн рублей в течение года;
• для промышленного предприятия – вывоз готовой продукции без оформления учетных документов, остановка производственных процессов более, чем на сутки;
• для лечебных учреждений – искажение отчетности о деятельности, связанной яс оборотом наркотических средств, неоказание дежурной больницей профильной для нее медицинской помощи, утечка данных из специальных регистров;
• для органа власти – неспособность в течение длительного времени оказывать государственные услуги в электронном виде, утечка данных из специальных регистров (например, регистра ВИЧ-инфицированных жителей муниципального образования).

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

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

Определение объектов воздействия

Перечень негативных последствий является отправной точкой для моделирования угроз. На втором этапе необходимо определить, воздействие на какие именно объекты может привести к наступлению таких последствий. Методический документ не детализирует, как именно должны определяться объекты воздействия, оставляя это на усмотрение эксперта, проводящего анализ уязвимостей. При этом:

• требуется использовать общий перечень угроз безопасности информации, опубликованный в банке данных угроз безопасности информации ФСТЭК России;
• наряду с ним требуется использовать низкоуровневые описания возможных способов воздействия, описанных в базах знаний CAPEC и Att&CK, а также в базах знаний типовых атак на веб-приложения WASC и OWASP.

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

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

1. Выбираем моделируемое негативное последствие, например – хищение денежных средств с расчетного счета предприятия.
2. Опрашиваем руководителей функциональных подразделений и определяем бизнес-процессы, в рамках которых выполняются платежные операции. К таким бизнес-процессам могут относиться оплата поставщикам, выплата заработной платы, оплата командировочных расходов, прямые финансовые операции и т. п.
3. Для каждого бизнес-процесса определяем какие именно операции могут быть скомпрометированы нарушителем для наступления моделируемого негативного последствия. Например, один из способов хищения денежных средств в бизнес-процессе выплаты заработной платы является добавление несуществующего работника в модуле кадрового администрирования.
4. Для каждой операции, которые могут быть скомпрометированы нарушителем, определяем компоненты информационной системы, которые используются при выполнении таких операций.
5. Для каждого такого компонента определяем, можно ли добиться моделируемого негативного последствия воздействием на такой объект. Так, нарушитель может добавить несуществующего работника, если получит контроль над сервером кадрового администрирования, сервер системы управления базами данных, который используется модулем кадрового администрирования, и т. п.

Пример результата пошаговой детализации бизнес-процессов

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

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

Финальный перечень объектов воздействия должен включать в себя как компоненты информационной системы, так и объекты ИТ-инфраструктуры предприятия.

Определение источников угроз безопасности информации

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

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

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

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

• Нарушитель уровня Н1 не является специалистом, он использует только известные уязвимости и бесплатные инструменты.
• Нарушитель уровня Н2 также использует только свободно распространяемые инструменты, но является специалистом. Он способен находить и использовать уязвимости нулевого дня на атакуемых объектах.
• Нарушитель уровня Н3 дополнительно к этому способен приобретать дорогостоящие инструменты и проводить лабораторные исследования по поиску уязвимостей нулевого дня в оборудовании и программных средствах, аналогичных используемым на атакуемых объектах.
• Нарушитель уровня Н4 способен внедрять программные и аппаратные закладки в серийно изготавливаемое оборудование и программное обеспечение, может использовать побочное электромагнитное излучение, наводки и скрытые каналы, умеет проводить долгосрочные APT-атаки и обладает неограниченными ресурсами.

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

Кроме того, методика подразделяет нарушителей на внешних и внутренних. Нарушитель считается внешним, если он не имеет ни санкционированного физического доступа в контролируемую зону, ни санкционированного удаленного доступа к интерфейсам информационной системы. Подобное разделение является чистой условностью: единственное, что отличает моделирование угроз со стороны внешнего нарушителя, это необходимость рассмотрения в сценариях реализации угроз техник первичного проникновения в ИТ-инфраструктуру атакуемой организации.

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

Оценка способов реализации угроз

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

• формирование подложного поручения на перевод денежных средств путем получения несанкционированного доступа к папке обмена с правами администратора домена, локального администратора или с правами технологической учетной записи модуля платежей;
• формирование в модуле бухгалтерского учета подложной зарплатной ведомости путем получения несанкционированного доступа к СУБД системы управления предприятием и т. п.

Угрозой признается возможной, если определяется нарушитель, целям которого соответствуют негативные последствия реализации угрозы, и возможности которого позволяют выполнить соответствующее воздействие. При этом вопрос «как нарушитель доберется до объекта воздействия» на этом этапе не рассматривается.

Оценка сценариев реализации угроз и актуальности угроз

Если угроза признается возможной, остается оценить может ли выбранный нарушитель практически реализовать угрозу, рассмотрев возможные сценарии реализации угрозы – последовательности тактик и техник действий нарушителя, посредством которой он мог бы из некоторого начального состояния получить возможности, необходимые для реализации угрозы. На практике это означает оценку того, может ли нарушитель из заданных стартовых условий “пройти” по ИТ-инфраструктуре организации и получить практическую возможность реализовать угрозу.

Упрощенный пример сценария реализации угрозы

В соответствии с нормативными документами ФСТЭК России анализ угроз проводится на разных стадиях жизненного цикла информационной системы:

• на стадии создания системы;
• периодически на стадии эксплуатации системы.

На стадии создания системы сценарий реализации угроз не может учитывать меры защиты: на момент анализа угроз меры защиты еще не определены – напротив, именно результаты анализа угроз дают возможность определить, как именно должны быть реализованы базовые и дополнительные меры защиты.

И наоборот, на стадии эксплуатации анализ угроз проводится с учетом реализованных мер защиты, в том числе – с учетом выявленных уязвимостей и результатов тестирования на проникновения. Фактически, на этой стадии анализ угроз заключается в обработке результатов инвентаризации, анализа уязвимостей и тестирования на проникновения с последующей оценкой негативных последствий, которые могли бы наступить, если бы выявленные уязвимости целенаправленно использовал нарушитель.

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

Заключение

Подход к моделированию угроз, выбранный ФСТЭК России имеет свои достоинства и недостатки.

К несомненным достоинствам можно отнести два момента. Прежде всего, при выбранном подходе основой для моделирования угроз являются негативные последствия, необходимость защиты от наступления которых априори определена заинтересованными лицами. Это упрощает проблему убеждения бизнеса в необходимости обеспечения безопасности и снижает требования к кругозору специалиста, проводящему моделирование: ему не требуется досконально знать и свою профессиональную область, и особенности деятельности работодателя. При этом оценивается только возможность реализации угрозы – экспертам не требуется оценивать, с какой вероятностью нарушитель способен реализовать угрозу.

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

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

Сценарное моделирование угроз – один из первых шагов, который может позволить защищающейся стороне сократить отставание от атакующей. И, пожалуй, к главным достоинствам рассматриваемой методики можно отнести подталкивание специалистов по информационной безопасности к необходимости изучать основные информационные ресурсы по теме компьютерных атак и защиты от них, такие как MITRE ATT&CK и OWASP.

Автор:

Дмитрий Кузнецов, директор по методологии и стандартизации Positive Technologies.

Экспертный материал

Алексей Залецкий | специалист по информационной безопасности

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

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

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

Что такое модель угроз и кому необходимо ее разрабатывать

Модель угроз является фундаментом для создания системы защиты информации. При создании любой системы защиты в первую очередь нужно ответить на следующие вопросы:

1. Что защищаем?

2. От чего защищаем?

3. Какой ущерб может быть нанесен?

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

Как результат оценки рисков будет понимание, сколько обосновано компания может потратить на создание системы защиты информации. Так как информационная безопасность —  это почти неосязаемая сфера, пока не случится инцидент, крайне важно руководству иметь какие-то ориентиры для определения объёма финансирования этой составляющей.

Но если смотреть с точки зрения построения системы защиты, даже при отчетливо понятных границах бюджета всё равно остаётся вопрос: «А от чего защищать?». И ответ на этот вопрос предоставляет модель угроз. Она позволяет понять, какие угрозы для компании актуальны, а какие нет, и что даёт возможность построить действительно эффективную систему защиты.

Моделирование угроз является обязательным для компаний, которые создают систему защиты в соответствии с требованиями регуляторов. То есть если у вас  обрабатываются персональные данные или есть государственная информационная система либо даже критическая информационная инфраструктура, то вам это точно нужно. В остальных случаях — не обязательно. Но чем вы будете руководствоваться при выборе мер защиты? Можно, конечно, придерживаться лучших практик, но где гарантия, что созданная вами система будет не избыточно и при этом достаточна.

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

Что нового в моделировании угроз

5 февраля 2021 года вышла новая методика ФСТЭК России по определению актуальных угроз. В этой методике нет ни одной формулы, она вся основывается на экспертном подходе и сочетает в себе определение актуальных угроз с риск ориентированным подходом. Это весьма современный документ, который учитывает в том числе вариант размещения защищаемых систем в облаках.

С 2015 года существует ресурс bdu.fstec.ru, который крайне полезен при моделировании угроз, а для некоторых типов систем даже обязателен.

Чего пока нет, так это новых базовых моделей угроз. Есть базовая модель угроз КСИИ от 2007 года (которая, в дальнейшем заменила документы по КИИ, кроме как раз базовой модели угроз) и базовая модель угроз персональных данных от 2008 года.

Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры (утв. ФСТЭК России 18.05.2007) имеет гриф ДСП (для служебного пользования и не распространяется свободно).

Основные сложности при моделировании угроз

Самое сложное при моделировании угроз по новой методике — это разработка реалистичных сценариев. В методике приводятся только графические примеры таких сценариев. Но что, если актуальных угроз, например, штук 10, и на каждую есть по 10 разных сценариев. Трудоёмкость рисования этих сценариев становится крайне высока.

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

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

Используемые методики, иные документы и ресурсы 

В первую очередь это методика оценки угроз безопасности информации ФСТЭК России от 5 февраля 2021 года.

Базовая модель угроз безопасности персональных данных при обработке в информационной системе персональных данных, утвержденная заместителем директора ФСТЭК России 15.02.2008.

Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры, утвержденная ФСТЭК России 18 мая 2007 г.

Отраслевые базовые модели угроз.

Сайт Банка данных угроз ФСТЭК России.

Основные этапы моделирования угроз

В соответствии с новой методикой определение актуальных угроз проводится в три этапа:

Этап 1. Определение негативных последствий

Это как раз интеграция риск ориентированного подхода в процесс моделирования угроз. Но есть отличия. В риск ориентированном подходе сначала определяются активы, которым может быть нанесён ущерб, а уже потом определяются негативные последствия для этих активов.

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

Этап 2. Определение возможных объектов воздействия угроз безопасности информации

На данном этапе определяются конкретные активы, которым может быть нанесён вред. Начиная с информации, циркулирующей в информационной системе, заканчивая ПО и машинными носителями.

Этап 3. Оценка возможности реализации (возникновения) угроз безопасности информации и определение их актуальности.

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

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

В новой методике определены четыре уровня возможностей нарушителей:

• базовые возможности по реализации угроз безопасности информации (Н1);

• базовые повышенные возможности по реализации угроз безопасности информации (Н2);

• средние возможности по реализации угроз безопасности информации (Н3);

• высокие возможности по реализации угроз безопасности информации (Н4).

Здесь есть отличия от того, как возможности классифицируются в Банке данных угроз (БДУ) ФСТЭК России, которые делятся на:

• нарушитель с низким потенциалом;

• нарушитель со средним потенциалом;

• нарушитель с высоким потенциалом.

Возможно, в БДУ приведут классификацию нарушителей к формату новой методики. Но на данный момент принято считать, что нарушителям с базовыми, повышенными и средними возможностями соответствуют нарушителям со средним потенциалом.

Оценка актуальности угроз безопасности информации

Угроза является актуальной, если от реализации угрозы может быть нанесён ущерб, есть актуальный нарушитель и сценарий реализации угрозы.

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

Самое сложное — это определение сценариев реализации угроз.

В методике приведены примеры таких сценариев, например:

Данный сценарий показывают последовательность атаки на инфраструктуру промышленного предприятия. Для получения доступа к корпоративной сети используется атака отказ в обслуживании и письмо с вредоносным вложением. Что дальше позволяет с компьютеров корпоративной сети изменить настройки межсетевого экрана между корпоративной сетью и производственным сегментом и совершить атаку на сеть АСУ ТП, выводя из строя технологический процесс.

Разработка сценариев реализации угроз

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

Более удобный и предсказуемый в плане трудозатрат вариант — сценарии в табличном виде.

Примеры сценариев

Пример сценариев в табличном виде:

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

Более детально сценарии реализации угроз безопасности, мы рассматривали на вебинаре.

Заключение

Процесс моделирования угроз весьма не прост, но разобраться в нём по силам каждому. Для качественного моделирования угроз лучше обращаться к профессионалам, потому что, как уже упоминалось в статье, для определения реалистичных сценариев угроз нужно привлекать опытных аудиторов и пентестеров. Компания Corpsoft 24 в рамках услуг размещения в облаке информационных систем, обрабатывающих информацию ограниченного доступа, предоставляет услуги по моделированию угроз, так и полного спектра услуг по защите информации.