«Моделирование угроз — это перевод хаоса возможных атак в структурированную схему. Это не отчёт для галочки, а инструмент, который показывает, какие именно барьеры остановят реального нарушителя, а не абстрактного «хакера». В российских реалиях этот процесс из рекомендации превращается в обязательный язык общения с регулятором — без него не обосновать ни одну меру защиты для систем, попадающих под 152-ФЗ или требования к КИИ.»
Что такое моделирование угроз?
Моделирование угроз — систематический разбор архитектуры на предмет слабых мест, который переводит абстрактные опасения в конкретные сценарии компрометации. Его задача — выяснить, как именно можно похитить данные, нарушить работу сервиса или получить несанкционированные права. Результатом становится формализованная модель, связывающая ценные активы, профили нарушителей, уязвимости системы и меры защиты в единую картину рисков.
Зачем это нужно?
Формальный повод — требование закона. 152-ФЗ прямо обязывает проводить оценку рисков и обосновывать применяемые меры защиты. Однако практическая ценность в ином: моделирование останавливает бессмысленные траты бюджета. Без него решения о защите часто принимаются по принципу «так делают все» или «чем больше технологий, тем лучше», что ведёт к раздутым затратам и иллюзии безопасности. Модель даёт чёткие ответы: что именно защищаем, от кого и какие контрмеры будут эффективны против конкретных путей атаки.
Основные этапы
Процесс превращает неопределённость в последовательный план действий.
- Определение границ анализа. Необходимо точно очертить объект изучения: отдельное веб-приложение, группа сервисов или сегмент сети. Ключевая ошибка — попытка охватить всё сразу. Эффективнее работать с логически завершённым компонентом, у которого понятны точки входа и выхода.
- Выявление активов. Актив — это то, что представляет ценность и утрата чего нанесёт ущерб. Часто это не оборудование, а данные: персональные данные категории «К», финансовые реестры, ключи шифрования, критичные конфигурации.
- Профилирование нарушителей. Создание портретов возможных атакующих: внешний злоумышленник, инсайдер, партнёр с легальным доступом. Для каждого определяется мотивация, исходный уровень доступа и доступные ресурсы (время, деньги, экспертиза).
- Выявление угроз и уязвимостей. Используя выбранную методологию, аналитик изучает, как каждый тип нарушителя может достичь цели, эксплуатируя слабые места в архитектуре, коде или процессах.
- Оценка и ранжирование рисков. Угрозы оцениваются по двум ключевым параметрам: потенциальный ущерб и вероятность реализации. В российском контексте к ущербу часто добавляются регуляторные последствия — крупные штрафы или приостановка эксплуатации системы.
- Определение и обоснование контрмер. Для каждого значимого риска подбираются конкретные меры защиты. Их адекватность проверяется на той же модели: действительно ли выбранный контроль перекрывает выявленный вектор атаки.
- Документирование и интеграция в процессы. Модель угроз должна стать рабочим инструментом, а не отчётом, который пылится на полке. Её необходимо привязать к процессам изменения конфигураций, управления инцидентами и регулярной переоценки рисков в рамках системы управления информационной безопасностью.
Методологии моделирования угроз
Разные подходы позволяют взглянуть на систему под разными углами. Универсального решения нет, часто используется комбинация методов.
STRIDE
Фреймворк, классифицирующий угрозы по шести категориям: Spoofing (подмена), Tampering (модификация), Repudiation (отказ от действий), Information Disclosure (раскрытие информации), Denial of Service (отказ в обслуживании), Elevation of Privilege (повышение привилегий). Его сила — в чёткой привязке к элементам диаграмм потоков данных. Процесс итеративен: строится DFD, и для каждого элемента (процесс, хранилище, поток) проверяется список STRIDE. Подходит для детального анализа приложений на этапе проектирования.
PASTA
Process for Attack Simulation and Threat Analysis — семиэтапный процесс, сфокусированный на бизнес-рисках. Его отличие — старт с анализа бизнес-целей. PASTA сначала определяет, какие процессы наиболее критичны для компании, а затем моделирует атаки именно на них. Этапы включают анализ тактик и техник злоумышленников, оценку уязвимостей и симуляцию атак для проверки реалистичности угроз. Подходит для комплексных систем с высокими регуляторными требованиями.
OCTAVE
Operationally Critical Threat, Asset, and Vulnerability Evaluation — методология, сконцентрированная на организационных рисках и критических активах. Её часто выбирают для построения СУИБ в целом. Анализ проводится рабочей группой из сотрудников разных отделов, что позволяет выявить угрозы, незаметные чисто техническим специалистам — например, связанные с регламентами или человеческим фактором.
Деревья атак (Attack Trees)
Это инструмент визуализации и декомпозиции, а не полноценная методология. В корне дерева — цель атакующего. Цель разбивается на подзадачи, которые, в свою очередь, дробятся на элементарные шаги. Дерево атак наглядно показывает все возможные пути достижения цели и помогает найти точку, блокировка которой наиболее эффективно ломает весь сценарий.
Особенность для российской практики
При работе в рамках требований ФСТЭК, особенно для систем категории «К», недостаточно механически применить западный фреймворк. Необходимо явно учитывать классы нарушителей из руководящих документов регулятора. Также в модель должны включаться сценарии, связанные с действиями организованных групп и спецслужб, обладающих значительными ресурсами, что редко явно прописано в популярных методологиях.
Практическое применение в регуляторной практике
Для регулятора модель угроз — обязательный артефакт, подтверждающий адекватность системы защиты. При экспертизе документов проверяется не сам факт наличия модели, а её связность и обоснованность.
| Критерий | Что проверяется | Типичные ошибки |
|---|---|---|
| Связь угроз с активами | Чётко ли показано, какая угроза направлена на какой конкретный актив (файл с ПДн, сервис аутентификации). | Общие формулировки вроде «угроза конфиденциальности данных» без указания, каких именно. |
| Обоснование вероятности | Аргументация, основанная на актуальности уязвимости, сложности эксплуатации, мотивации нарушителя. | Использование шаблонных оценок («высокая», «средняя») без привязки к контексту системы. |
| Трассировка контрмер | Каждая заявленная мера защиты должна быть привязана к одной или нескольким угрозам из модели. | Наличие в документации мер, не связанных ни с одной из выявленных угроз. |
| Актуальность | Модель должна отражать текущее состояние системы и актуальный ландшафт угроз. | Предоставление модели, созданной несколько лет назад для устаревшей версии архитектуры. |
Особенности реализации для информационных систем категории «К»
Требования здесь строже. Моделирование становится частью пакета документов для обязательной экспертизы.
- Обязательное использование аттестованных СЗИ. В модели необходимо показать, как конкретное средство защиты информации из реестра ФСТЭК перекрывает выявленные угрозы. Попытка использовать неаттестованный аналог потребует отдельного, сложного обоснования.
- Учёт угроз со стороны ресурсоёмких нарушителей. В модели для систем «К» класса необходимо явно рассматривать нарушителя с ресурсами уровня государственной спецслужбы или крупной APT-группы. Это меняет расчёт вероятности и требует закладки глубокоэшелонированной защиты с акцентом на обнаружение и реагирование.
- Интеграция с планами восстановления. Для критически важных объектов недостаточно только предотвратить атаку. Модель должна включать сценарии, где защита была преодолена, и показывать, как меры обнаружения и восстановления минимизируют ущерб.
- Верификация независимой организацией. Регулятор часто рекомендует или требует, чтобы модель угроз была проверена организацией, имеющей соответствующую лицензию. Это создаёт дополнительный уровень проверки её адекватности.
Интеграция с системой управления информационной безопасностью
Изолированная модель угроз бесполезна. Её ценность раскрывается только при встраивании в цикл управления безопасностью.
- Связь с реестром инцидентов. Каждый реальный инцидент должен проверяться на соответствие смоделированным сценариям. Если инцидент не был предусмотрен — модель требует немедленной доработки. Это главная обратная связь, повышающая точность модели.
- Основа для тестирования на проникновение. Задачи для регулярных пентестов должны формулироваться на основе наиболее вероятных и опасных сценариев из модели. Так проверяется не «вообще всё», а реальная эффективность защиты против ключевых угроз.
- Инструмент для диалога с бизнесом. Модель, выраженная в терминах бизнес-рисков (остановка производства, штраф регулятора, репутационные потери), становится понятным языком для обоснования бюджета на ИБ перед руководством.
- Триггер для пересмотра. Любое значимое изменение в инфраструктуре, появление новой значимой уязвимости или смена законодательства должны автоматически запускать процесс актуализации модели. Это должно быть прописано в регламентах СУИБ.
Распространённые ошибки
- Формальный подход. Составление модели «для галочки», где угрозы копируются из шаблона, а контрмеры — из каталога вендора. Такая модель не выдерживает даже поверхностной проверки экспертом.
- Забывают про внутреннюю угрозу. Фокус на внешних хакерах, тогда как значительная часть инцидентов связана с действиями или ошибками сотрудников.
- Игнорирование физического и организационного уровня. Угроза — это не только уязвимость в коде. Это и уборщик, подключающий флешку к серверу, и отсутствие регламента уничтожения бумажных носителей с ПДн.
- Отсутствие приоритизации. Попытка бороться со всеми угрозами сразу приводит к распылению ресурсов. Модель должна явно выделять неприемлемые риски, которые нужно закрыть в первую очередь.
Моделирование угроз — это мышление атакующего, оформленное в методичный процесс. В условиях российского регулирования это не просто лучшая практика, а необходимое условие для легитимной эксплуатации многих информационных систем. Грамотно построенная модель превращает информационную безопасность из статьи затрат в управляемый процесс, где каждая вложенная копейка имеет понятное обоснование и направлена на нейтрализацию конкретного, оценённого риска.