Модель угроз безопасности информации — документ, в котором для конкретной системы перечислено, что именно с ней может произойти, кто это может сделать и каким способом. Она нужна не сама по себе: без неё нельзя обосновать набор мер защиты, нельзя пройти аттестацию объекта информатизации, нельзя закрыть требования ФСТЭК к значимым объектам КИИ и государственным информационным системам, нельзя внятно ответить проверяющему на вопрос «почему у вас именно такой состав средств защиты».
На практике модель угроз чаще всего требуют в трёх ситуациях: при вводе системы в эксплуатацию, при аттестации и при проверке регулятора. И почти всегда выясняется, что документ либо не разрабатывался вовсе, либо скачан как шаблон и не имеет отношения к реальной архитектуре. Второй вариант хуже первого: формально документ есть, фактически он не защищает ни систему, ни руководителя.
Что вы получаете:
- разработку модели угроз по действующей методике ФСТЭК России под вашу конкретную систему;
- описание архитектуры, границ системы и объектов воздействия — той части, которую чаще всего пропускают;
- обоснованный перечень актуальных угроз со ссылками на банк данных угроз ФСТЭК;
- сценарии реализации угроз, а не абстрактный список из справочника;
- увязку модели угроз с требуемым набором мер защиты, чтобы документ работал, а не лежал;
- сопровождение при согласовании и при проверке, если модель угроз оспаривает регулятор.
Кому это нужно
- субъектам КИИ — модель угроз входит в исходные данные для категорирования и в обоснование мер защиты значимых объектов;
- операторам государственных информационных систем — без модели угроз аттестация не проводится;
- операторам персональных данных — определение актуальных угроз безопасности персональных данных прямо предусмотрено законом об их защите;
- компаниям, проходящим аттестацию объекта информатизации — модель угроз входит в комплект аттестационной документации;
- руководителям и ИТ-директорам, чья персональная ответственность наступает за необеспечение защиты, а не за отсутствие бумаги.
Нормативная рамка
- Методический документ ФСТЭК России «Методика оценки угроз безопасности информации» (утверждён 5 февраля 2021 года) — основной документ, по которому сегодня разрабатывается модель угроз для систем, не обрабатывающих сведения, составляющие государственную тайну;
- банк данных угроз безопасности информации ФСТЭК России (БДУ) — источник перечня угроз и уязвимостей, на который методика прямо опирается;
- Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» — угрозы безопасности информации и данные о компьютерных инцидентах входят в исходные данные для категорирования;
- приказ ФСТЭК России № 239 — требования по обеспечению безопасности значимых объектов КИИ;
- приказ ФСТЭК России № 17 — требования о защите информации в государственных информационных системах;
- приказ ФСТЭК России № 21 — состав и содержание мер по обеспечению безопасности персональных данных в информационных системах персональных данных;
- Федеральный закон от 27.07.2006 № 152-ФЗ — обязанность оператора определять актуальные угрозы безопасности персональных данных при их обработке.
Отдельно про криптографию: если в системе применяются сертифицированные средства криптографической защиты, часть угроз оценивается по документам ФСБ России, и здесь модель угроз ФСТЭК не заменяет модель нарушителя для СКЗИ — это два разных документа с разной логикой.
Кто разрабатывает модель угроз
Обладатель информации или оператор системы. Ответственность за наличие документа лежит на организации, а не на подрядчике. Это принципиальный момент: заказать разработку можно у кого угодно, но отвечать перед регулятором будет оператор.
Собственными силами. Допустимо, если в штате есть подразделение по защите информации, способное описать архитектуру и обосновать выводы. Требования лицензии ФСТЭК к собственной модели угроз для своих систем закон не предъявляет.
С привлечением лицензиата ФСТЭК. Обязательно там, где работы по защите информации выполняются сторонней организацией: техническая защита конфиденциальной информации — лицензируемый вид деятельности. Если внешний подрядчик разрабатывает вам модель угроз в составе работ по защите информации, лицензия у него должна быть, и её реквизиты стоит проверить до подписания договора, а не после отказа в аттестации.
Совместно. Рабочий вариант для крупных систем: архитектуру и негативные последствия описывает заказчик, оценку угроз и сценарии формализует лицензиат. Разработка модели угроз в одиночку силами внешнего подрядчика без доступа к реальным процессам обычно и даёт тот самый шаблон, который потом не проходит проверку.
Что входит в модель угроз по методике ФСТЭК
Методика задаёт последовательность, и именно её нарушение — самая частая претензия. Порядок такой.
1. Область применения и границы оценки. Что за система, какие сегменты входят в оценку, где проходят границы с внешними сетями и смежными системами, кто участники процесса (обладатель информации, оператор, поставщики услуг).
2. Негативные последствия. С них методика начинает, и это ключевое отличие от старого подхода. Сначала определяется, что недопустимо для организации, — ущерб физическим лицам, ущерб самой организации, ущерб государству. Только потом рассматривается техника.
3. Объекты воздействия. Компоненты системы, воздействие на которые приводит к этим последствиям: информационные ресурсы, программное обеспечение, машинные носители, сетевое оборудование, каналы связи, машинные помещения, персонал.
4. Источники угроз и уровни возможностей нарушителей. Определяются виды нарушителей — внешние и внутренние — и их возможности. Методика различает нарушителей по уровню возможностей: от нарушителя с базовыми возможностями до нарушителя, обладающего специальными техническими средствами и способного проводить целенаправленные кампании. Уровень возможностей выбирается не по желанию, а исходя из значимости системы и мотивации нарушителя.
5. Способы реализации угроз. Какие интерфейсы и каналы доступны нарушителю с учётом реальной архитектуры: интернет, каналы удалённого доступа, съёмные носители, подрядчики с привилегированным доступом, цепочка поставок программного обеспечения.
6. Актуальные угрозы. Угроза признаётся актуальной, если для неё есть источник, есть доступный способ реализации и её реализация приводит к определённым ранее негативным последствиям. Каждая актуальная угроза увязывается с БДУ ФСТЭК либо описывается самостоятельно, если в банке данных её нет.
7. Сценарии реализации. Пошаговое описание того, как нарушитель проходит от точки входа до объекта воздействия. Именно этот раздел отличает рабочую модель угроз от компиляции и именно его чаще всего нет в скачанных шаблонах.
Как модель угроз связана с мерами защиты
Ошибка, которая обесценивает документ: модель угроз разрабатывается отдельно, а состав средств защиты выбирается отдельно — по бюджету или по привычке подрядчика. Регулятор смотрит ровно на связку.
Правильная логика такая: актуальная угроза → мера защиты, её нейтрализующая → техническое или организационное решение, реализующее меру → подтверждение того, что решение работает. Если в модели угроз есть угроза несанкционированного доступа со стороны привилегированного пользователя, а в системе нет ни контроля действий администратора, ни разграничения доступа, — это несоответствие видно сразу и в акте проверки, и в заключении по результатам аттестационных испытаний.
Обратная ситуация встречается не реже: угрозы исключены из перечня как неактуальные без обоснования, чтобы сократить состав мер. Формально документ становится короче, фактически появляется риск, что при инциденте именно эта запись станет доказательством того, что риск был известен и сознательно проигнорирован.
Требования к самому набору мер берутся из профильных приказов: для значимых объектов КИИ — защита значимых объектов КИИ по приказу ФСТЭК № 239, состав организационно-распорядительных документов — разработка ОРД по защите КИИ и документы по защите информации под ключ. Для систем персональных данных та же связка разбирается в материале защита персональных данных по 152-ФЗ, а проверка достаточности мер на практике завершается процедурой аттестации систем защиты информации по требованиям ФСТЭК.
Когда модель угроз нужно пересматривать
Документ не разовый. Пересмотр требуется:
- при изменении архитектуры системы — новые сегменты, миграция в облако, подключение внешних сервисов;
- при изменении состава обрабатываемой информации или категории данных;
- при изменении категории значимости объекта КИИ или уровня защищённости системы персональных данных;
- при появлении новых угроз и уязвимостей в БДУ ФСТЭК, значимых для вашей архитектуры;
- после компьютерного инцидента — реализовавшийся сценарий по определению актуален;
Практическое правило: модель угроз пересматривается вместе с системой, а не по календарю. Периодичность пересмотра при этом стоит закрепить во внутреннем документе — иначе доказать, что процесс существует, будет нечем.
Что входит в работу
- Обследование системы: сбор исходных данных, интервью с владельцами процессов, описание архитектуры и границ оценки.
- Определение негативных последствий совместно с бизнесом — этот блок нельзя написать за заказчика в одиночку.
- Разработка модели угроз по методике ФСТЭК с обоснованием актуальности каждой угрозы и со сценариями реализации.
- Модель нарушителя — как самостоятельный раздел или отдельный документ, в зависимости от требований к системе.
- Увязка с мерами защиты: таблица соответствия «угроза — мера — реализация», пригодная для предъявления проверяющему.
- Комплект сопутствующих документов: приказ об утверждении, акт классификации или категорирования, при необходимости — техническое задание на систему защиты.
- Сопровождение аттестации в части модели угроз и защита выводов документа перед органом по аттестации.
- Актуализация при изменении системы и после инцидентов.
Сроки и стоимость
Срок зависит от размера системы и от того, есть ли актуальное описание архитектуры. Для одной изолированной системы со сложившимся ландшафтом разработка занимает несколько недель, из которых существенная часть — обследование, а не написание текста. Для распределённой системы с несколькими площадками, внешними интеграциями и подрядчиками срок кратно больше, и узкое место обычно не на нашей стороне, а на стороне сбора исходных данных.
Стоимость определяется объёмом обследования: количеством сегментов, числом типов обрабатываемой информации, наличием СКЗИ и промышленного сегмента. Разработка модели угроз для небольшой системы персональных данных и для значимого объекта КИИ первой категории — работы разного порядка. Цены не являются публичной офертой; смета формируется после короткого обследования, чтобы не продавать вам объём, которого нет.
Вопросы и ответы
Можно ли взять готовый шаблон модели угроз?
Как основу для структуры — да. Как готовый документ — нет. Методика построена от негативных последствий и архитектуры конкретной системы; в шаблоне ни того, ни другого нет. Проверяющий видит шаблон по первым же страницам: границы оценки не совпадают с реальной схемой сети, а в перечне актуальных угроз есть те, которые в вашей архитектуре неосуществимы.
Обязательна ли лицензия ФСТЭК для разработки модели угроз?
Для разработки модели угроз для собственных систем силами штатных сотрудников — нет. Если работы по технической защите информации выполняет сторонняя организация, деятельность лицензируется, и лицензия у подрядчика должна быть. Проверяйте реквизиты лицензии до заключения договора: переделывать документ после отказа в аттестации дороже.
Модель угроз и модель нарушителя — это одно и то же?
Нет. Модель нарушителя — часть общей картины: кто может действовать против системы и какими возможностями обладает. Модель угроз включает её как раздел, но добавляет объекты воздействия, способы реализации и сценарии. Отдельно модель нарушителя для СКЗИ строится по документам ФСБ России и живёт по своим правилам.
Как часто нужно обновлять модель угроз?
Жёсткой периодичности методика не устанавливает. Обновление привязывается к событиям: изменение архитектуры, изменение состава данных, изменение категории объекта, появление новых угроз в банке данных ФСТЭК, произошедший инцидент. Порядок и основания пересмотра лучше закрепить приказом — тогда вопрос «почему не обновляли три года» имеет письменный ответ.
Что будет, если модели угроз нет?
Отсутствие документа само по себе фиксируется как нарушение требований о защите информации в проверках ФСТЭК и Роскомнадзора. Гораздо тяжелее второй эффект: без модели угроз невозможно обосновать достаточность принятых мер, а именно этим обоснованием защищаются и организация, и её руководитель, когда инцидент уже произошёл.
Получить консультацию
Пришлите схему системы и перечень обрабатываемой информации — скажем, какая модель угроз вам нужна по действующим требованиям, что можно закрыть силами вашей команды и какой объём работ придётся отдать лицензиату. Если модель угроз уже есть, посмотрим её на предмет типовых претензий регулятора: границы оценки, обоснование неактуальности и связь с мерами защиты.
Почта: law@vfs.consulting. Телефон: +7 916 419-16-66.