Модель угроз КИИ по 187-ФЗ: собираю с нуля и разбираю три ошибки в категорировании

Первый акт категорирования, который я отправил во ФСТЭК, вернулся через три недели. Пометка: «замечания к определению показателей критериев значимости». Две строки в сопроводительном письме, ноль конкретики — разбирайся сам. Я тогда работал на стороне субъекта КИИ в энергетике и был уверен, что всё заполнил верно. Разбор ошибок занял полтора месяца и три версии документа. Ниже — три конкретные ошибки в категорировании объектов КИИ, которые я допустил при работе по 187-ФЗ, и пошаговая сборка модели угроз безопасности информации для типового объекта, чтобы ты их не повторял.

Что входит в модель угроз безопасности информации для КИИ

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

КИИ (критическая информационная инфраструктура) — информационные системы (ИС), информационно-телекоммуникационные сети (ИТСС) и АСУ ТП (автоматизированные системы управления технологическими процессами; в международной терминологии — ICS/SCADA), от которых зависят ключевые отрасли: энергетика, транспорт, здравоохранение, финансы, связь, оборонная и химическая промышленность. Федеральный закон 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» определяет обязанности организаций — субъектов КИИ — по защите таких объектов.

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

• Описание архитектуры объекта — сетевая топология, компоненты, границы
• Характеристику источников угроз — кто может атаковать (внешние и внутренние нарушители)
• Анализ возможных уязвимостей — слабые места в ПО, конфигурации, сетевой архитектуре
• Способы (сценарии) реализации угроз — как именно атака может развиваться
• Оценку последствий — что произойдёт при успешной атаке

Методическую основу задаёт Методика оценки угроз безопасности информации ФСТЭК 2021 года. По ней определяется, какие угрозы из банка данных угроз ФСТЭК (БДУ — публичная база на bdu.fstec.ru с описаниями угроз и уязвимостей) считаются актуальными для конкретного объекта.

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

Субъект КИИ и категорирование: порядок действий до модели угроз

Субъект КИИ — организация, работающая в одной из отраслей, перечисленных в 187-ФЗ. Требования по категорированию для субъекта КИИ выстроены в чёткую последовательность:

1. Создать комиссию по категорированию — приказом руководителя, с включением специалистов по ИТ, ИБ, технологическим процессам. Обязательно нужен технолог, который знает, какие процессы критичны. Без него ошибки в определении объектов гарантированы — я проверил это на себе.

2. Выявить объекты КИИ — определить, какие ИС, ИТСС и АСУ ТП относятся к критической инфраструктуре. Здесь новички совершают первую типовую ошибку (подробнее ниже).

3. Направить перечень объектов во ФСТЭК — в течение 5 рабочих дней после утверждения.

4. Провести категорирование — оценить каждый объект по показателям критериев значимости КИИ, определённым в Постановлении Правительства №127 (ПП-127 — правила категорирования, устанавливающие показатели по группам критериев значимости).

5. Оформить акт категорирования объекта КИИ и направить его во ФСТЭК в 10-дневный срок.

6. Разработать модель угроз — для значимых объектов (с присвоенной категорией 1, 2 или 3).

7. Построить систему безопасности значимого объекта — подобрать меры защиты информации КИИ на основе модели угроз и базового набора мер из Приложения А Приказа №239.

Если объект получил статус «без категории» (ни один показатель не превышает порогового значения) — формальной обязанности строить модель угроз по Приказу №239 нет. Но анализ угроз всё равно проводится при категорировании по ПП-127, а субъект КИИ независимо от категории обязан уведомлять НКЦКИ (Национальный координационный центр по компьютерным инцидентам — структура ФСБ, оператор ГосСОПКА, государственной системы обнаружения и предупреждения компьютерных атак) об инцидентах в сроки от 3 до 24 часов.

Три ошибки в категорировании объектов КИИ

Ошибка первая: записал в объекты КИИ всё подряд

На первом проекте категорирования в энергетической компании я включил в перечень объектов КИИ корпоративную почту, ERP-систему, систему документооборота и даже СКУД (систему контроля и управления доступом в здание). Рассуждение казалось логичным: организация — субъект КИИ, значит все её ИТ-системы автоматически становятся объектами КИИ.

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

Как не повторить: начинай не с инвентаризации ИТ-систем, а с описания критических процессов. В энергетике это генерация, передача и распределение электроэнергии. Для каждого процесса задай вопрос: «Какая ИС или АСУ ТП непосредственно обеспечивает этот процесс или влияет на его непрерывность?» SCADA-система управления подстанцией — да. Почтовый сервер — нет. Система АСКУЭ (автоматизированная система коммерческого учёта электроэнергии) — да, если от неё зависят расчёты на оптовом рынке электроэнергии.

Признак ошибки: в перечне объектов КИИ больше 10–15 позиций для средней компании с 2–3 площадками. Если насчитал 30–40 систем — туда попало лишнее. ФСТЭК такой перечень может принять, но на этапе категорирования обосновать значимость каждого из 40 объектов будет мучительно.

Ошибка вторая: неправильно оценил показатели критериев значимости КИИ

ПП-127 определяет 14 показателей по 5 группам критериев. Для каждого показателя установлены пороговые значения, определяющие категорию: первая (самая высокая) — катастрофический масштаб последствий, третья — минимальный.

Моя ошибка: при категорировании АСУ ТП распределительной подстанции 110/10 кВ я оценивал показатель «прекращение или нарушение функционирования объектов обеспечения жизнедеятельности населения» (социальная значимость). Взял число прямых потребителей электроэнергии — около 8 000 человек — и решил, что показатель не превышает порога третьей категории.

Проблема: я не учёл каскадные зависимости. Подстанция питала насосную станцию водоканала. При её отключении прекращается водоснабжение уже для 50 000 человек. Совсем другой масштаб последствий и другая категория.

Как не повторить:

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

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

Ошибка третья: модель угроз стала копипастом из банка данных угроз ФСТЭК

БДУ на bdu.fstec.ru содержит более 200 угроз безопасности информации. На первом проекте я открыл базу, выбрал все угрозы, которые хоть как-то относились к АСУ ТП, пометил их как «актуальные» и вставил в документ. Модель вышла на 80 страниц с таблицей, где каждая строка начиналась словами «Угроза является актуальной».

Почему это ошибка: методика ФСТЭК 2021 года требует оценки актуальности каждой угрозы для конкретного объекта с учётом его архитектуры. Нет в АСУ ТП подстанции беспроводных сетей — угрозы атаки на Wi-Fi неактуальны. Объект изолирован от интернета — угрозы эксплуатации публично доступных приложений (в терминологии MITRE ATT&CK — техника T1190 Exploit Public-Facing Application, тактика Initial Access) обоснованно исключаются.

MITRE ATT&CK — открытая база тактик и техник атак, разработанная корпорацией MITRE. Каждая техника имеет идентификатор (T-код, например T1190). При построении модели угроз ATT&CK помогает привязать абстрактные формулировки из БДУ к конкретным действиям атакующего. Грубо говоря, переводит «возможно несанкционированное воздействие» на язык «атакующий отправляет crafted-запрос на порт 443».

Как не повторить:

• Для каждой угрозы из БДУ задай два вопроса: (1) есть ли в архитектуре объекта условие для её реализации? (2) обладает ли актуальный нарушитель возможностями для этого?
• Если хотя бы один ответ «нет» — угроза неактуальна. Задокументируй обоснование.
• Типовой результат для АСУ ТП: 25–40 актуальных угроз из 200+. Если у тебя получилось 180 актуальных — ты не фильтровал, а копировал.

Признак ошибки: модель толще 50 страниц, графа «Обоснование актуальности» содержит одну и ту же формулировку для каждой строки.

Собираю модель угроз по методике ФСТЭК: пошаговая практика

Переходим к сборке. Предпосылки: утверждённый перечень объектов КИИ, проведённое категорирование, объекту присвоена категория значимости. Рабочие инструменты: шаблон модели угроз в Word или Excel, доступ к bdu.fstec.ru, актуальная схема сетевой инфраструктуры объекта.

Шаг 1 — описание архитектуры значимого объекта КИИ

Без описания архитектуры невозможно определить, какие угрозы актуальны. Это фундамент всей модели.

Составь схему объекта. Для типовой АСУ ТП подстанции включи:

• Уровень управления: серверы SCADA, АРМ диспетчеров, серверы баз данных и историана (архива технологических данных)
• Уровень контроллеров: программируемые логические контроллеры (ПЛК/PLC), устройства релейной защиты и автоматики (РЗА)
• Сетевая инфраструктура: коммутаторы промышленной сети, межсетевые экраны, каналы связи с диспетчерским пунктом
• Границы: где заканчивается промышленная сеть, есть ли DMZ (демилитаризованная зона — буферный сегмент между промышленной и корпоративной сетью), существуют ли каналы удалённого доступа
• Протоколы: Modbus TCP/RTU, IEC 60870-5-104, OPC DA/UA — укажи, что и где используется

На выходе: одностраничная сетевая схема плюс таблица «компонент — тип — расположение — сетевой сегмент — ПО и версия». Если объект построен по модели Purdue (иерархическая модель сегментации ICS-сети на уровни от 0 — физический процесс до 5 — корпоративная сеть) — отрази это в схеме. Большинство энергетических АСУ ТП в России хотя бы номинально следуют этой модели, даже если так её не называют.

По подходу это совпадает с фазой «Know» в методологии построения стратегии защиты ICS/OT (по терминологии Sygnia): пока не знаешь инфраструктуру до уровня конкретных контроллеров и их связей — любой анализ актуальных угроз безопасности информации останется абстракцией.

Шаг 2 — определение нарушителя в модели угроз

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

Методика ФСТЭК 2021 года разделяет нарушителей на два класса:

• Внешние: иностранные спецслужбы, террористические организации, хакерские группировки, конкуренты, одиночные хакеры
• Внутренние: действующие и бывшие сотрудники, подрядчики и сервисные инженеры, поставщики оборудования и ПО

Для каждого типа оцени три параметра:

В терминах MITRE ATT&CK: внутренний нарушитель с легитимной учёткой реализует технику T1078 (Valid Accounts — использование легитимных учётных записей; тактики Initial Access, Persistence, Privilege Escalation и Defense Evasion). Внешний нарушитель чаще начинает с T1190 (Exploit Public-Facing Application) или T1059 (Command and Scripting Interpreter — выполнение команд через интерпретаторы, тактика Execution). Для латерального перемещения внутри промышленной сети — T1210 (Exploitation of Remote Services, тактика Lateral Movement).

На выходе: таблица «Тип нарушителя — Мотивация — Потенциал — Актуальность для объекта (да/нет) — Обоснование». Для типовой АСУ ТП энергетики актуальными обычно оказываются 3–5 типов нарушителей. Остальные исключаются с обоснованием — например: «Конкурент — неактуален, т.к. объект не участвует в конкурентном рынке».

Шаг 3 — отбор актуальных угроз из банка данных угроз ФСТЭК

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

Открой bdu.fstec.ru, раздел «Угрозы безопасности информации». Каждая запись содержит: идентификатор, описание, источник угрозы (внешний/внутренний нарушитель), объект воздействия и последствия (нарушение конфиденциальности, целостности или доступности).

Первый проход: выгрузи список угроз из БДУ. Отфильтруй по типу объекта воздействия — оставь те, что направлены на компоненты из твоей схемы архитектуры (Шаг 1). Нет виртуализации — угрозы к виртуальным средам исключай сразу. Нет беспроводных сетей — угрозы к Wi-Fi тоже. Ожидаемый результат: из 200+ угроз останется 60–80 кандидатов.

Второй проход: для каждого кандидата проведи оценку актуальности:

Заполняй таблицу построчно. Для каждой исключённой угрозы пиши обоснование в 1–2 предложения. Это критично: ФСТЭК может запросить обоснования при проверке.

Третий проход: для каждой актуальной угрозы определи сценарий реализации. Привязка к технике MITRE ATT&CK не является формальным требованием ФСТЭК, но помогает структурировать сценарии и в дальнейшем подбирать меры защиты:

• Угроза «несанкционированное шифрование данных» → T1486 (Data Encrypted for Impact, тактика Impact) — атакующий шифрует данные на серверах SCADA, блокируя управление процессом
• Угроза «принудительная остановка управляющих сервисов» → T1489 (Service Stop, тактика Impact) — остановка служб АСУ ТП
• Угроза «отказ в обслуживании каналов связи» → T1498 (Network Denial of Service, тактика Impact) — перегрузка канала между подстанцией и диспетчерским пунктом
• Угроза «сбор информации о конфигурации системы» → T1082 (System Information Discovery, тактика Discovery) — разведка архитектуры перед основной атакой

На выходе: итоговая таблица модели угроз: «Угроза — Источник — Объект воздействия — Техника ATT&CK — Последствия — Актуальность — Обоснование». Для типовой АСУ ТП подстанции обычно получается 25–40 актуальных угроз. Меньше 15 или больше 60 — перепроверь: скорее всего, ошибка в фильтрации.

Дальше на основании актуальных угроз подбираются меры защиты из Приложения А Приказа ФСТЭК №239 — но это уже следующий этап, за рамками модели угроз.

Акт категорирования объекта КИИ: типичные точки возврата от ФСТЭК

Акт категорирования — итоговый документ всей работы. ФСТЭК проверяет его в течение 30 дней и может вернуть с замечаниями. По моему опыту трёх проектов, основные причины возврата:

Неполные сведения об объекте. В акте должны быть: наименование объекта КИИ, сфера деятельности субъекта, перечень процессов, которые объект обеспечивает, состав программных и аппаратных компонентов. Пропустил описание процессов или указал их размыто («обеспечение работы предприятия» вместо «управление режимом 110/10 кВ на ПС «Северная»») — вернут.

Необоснованные значения показателей. Для каждого из 14 показателей критериев значимости КИИ нужно указать конкретное числовое значение и источник данных. «Прекращение электроснабжения 50 000 потребителей, основание — схема электроснабжения района, утверждённая приказом №… от…» — это обоснование. «Значительный ущерб» или «возможны негативные последствия» — нет.

Несоответствие масштаба последствий и категории. Если описание содержит последствия регионального масштаба, а присвоена третья категория — ФСТЭК заметит нестыковку. Показатели и категория должны быть согласованы с пороговыми значениями из ПП-127.

Отсутствие учёта взаимосвязей. ПП-127 требует учитывать взаимосвязи между объектами КИИ. Если отключение одного объекта каскадно влияет на другой (подстанция → водоканал → больница) — это нужно отразить в акте.

Практический приём: веди Excel-таблицу, где в строках — объекты КИИ, в столбцах — все 14 показателей. Для каждой ячейки — числовое значение и ссылка на документ-источник (технический паспорт, акт обследования, схема электроснабжения). Когда ФСТЭК вернёт акт без указания конкретного показателя — у тебя будет матрица, по которой можно быстро проверить каждое значение, а не обследовать объект заново.

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

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

Три возврата от ФСТЭК научили меня одному: документ пишется не для регулятора, а для себя. Если модель угроз не помогает выбрать конкретные меры защиты информации КИИ — она не работает, какой бы толстой ни была. Если только входишь в тему — на IB Basics показывают не теорию, а как джуны реально решают рабочие задачи, включая работу с нормативкой.