Модель нарушителя КИИ: как адаптировать шаблоны ФСТЭК под реальный объект

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

Что такое модель нарушителя и зачем она нужна субъекту КИИ

Модель нарушителя — часть модели угроз безопасности КИИ. Она отвечает на три вопроса: кто может атаковать объект, какими возможностями располагает и что конкретно способен сделать. Без ответов определить актуальные угрозы объекта КИИ невозможно — непонятно, от кого защищаться и какие меры нужны в первую очередь.

Несколько определений для навигации по теме:

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

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

Почему модель нарушителя ФСТЭК не подошла без адаптации

Категории нарушителей безопасности информации: шаблон и реальность

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

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

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

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

Потенциал нарушителя: формальная оценка и методика оценки угроз

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

Связь между категорией и потенциалом в методике жёсткая. Внутренний пользователь — базовый. Организованная группа — повышенный. Спецслужба — высокий. На реальном объекте границы размыты.

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

Специалисты Sygnia подчёркивают: при разработке стратегии детектирования в промышленных средах нужно определить конкретные типы релевантных нарушителей. APT-группировка, нацеленная на шпионаж или диверсию, криминальная группа с ransomware, инсайдер с глубоким знанием систем — каждый тип демонстрирует разное поведение и требует отдельного подхода к обнаружению. Шаблонная модель эту дифференциацию стирает.

Адаптация методики ФСТЭК под объект: делай раз, делай два, делай три

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

Шаг 1 — декомпозиция значимого объекта КИИ

Зачем: модель нарушителя без чёткого описания объекта — список абстрактных угроз, не привязанный к реальности. Нарушитель не атакует «КИИ вообще». Он атакует конкретный интерфейс, протокол, рабочее место.

Что делать:

Возьмите акт категорирования объектов КИИ — в нём указаны границы объекта и присвоенная категория значимости. Это стартовая точка. Проведите декомпозицию по уровням: корпоративная сеть → демилитаризованная зона (ДМЗ — буферный сегмент между внешней и внутренней сетью) → технологическая сеть → SCADA / DCS → ПЛК и полевые устройства. На каждом уровне зафиксируйте, какие системы работают, какие протоколы используются, кто и каким способом подключается.

Отдельно зафиксируйте все точки сопряжения — места, где корпоративная (IT) сеть соединяется с технологической (OT) сетью. По данным Group-IB, атакующие редко получают прямой доступ к OT-среде. Типичная прогрессия: закрепление в IT → расширение доступа через гибридные сети → целенаправленная разведка систем управления → воздействие на технологический процесс. Понимание этой цепочки определяет, на каких уровнях какие нарушители реалистичны.

Ещё один фактор, который часто недооценивают: OT-системы нередко работают 15–20 лет на устаревших платформах. Протоколы вроде Modbus и DNP3 приоритизируют надёжность, а не безопасность — в них нет встроенной аутентификации или шифрования. Это напрямую влияет на потенциал даже «слабого» нарушителя: ему не нужен эксплойт, если протокол вообще не спрашивает пароль.

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

Шаг 2 — пересмотр категорий внутренних и внешних нарушителей

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

Что делать:

Проведите интервью с IT- и OT-специалистами заказчика. Вопросы — конкретные: кто имеет удалённый доступ к промышленной сети? Какие подрядчики подключаются и по какому каналу? Есть ли у вендоров постоянный VPN? Используются ли общие учётные записи на SCADA-серверах? По результатам составьте реальный список лиц с доступом к объекту. Каждому сопоставьте: уровень доступа (физический, сетевой, к конкретной системе), знание архитектуры, возможную мотивацию.

На моём проекте этот шаг выявил категорию, которой в шаблоне не было: «сервисный инженер вендора АСУ ТП с привилегированным удалённым доступом». По шаблону это «представитель обслуживающей организации» с базовым потенциалом. Я повысил потенциал до базового повышенного с обоснованием: знание архитектуры ПЛК и прошивок, легитимный VPN-канал, возможность вносить изменения в логику контроллеров. Заказчик подтвердил — этот вендор фактически имел привилегии уровня «полный контроль» над контроллерами.

По данным Group-IB, валидные учётные данные позволяют нарушителю действовать без развёртывания вредоносного ПО. В средах без поведенческого мониторинга атакующий с украденными инженерными учётными данными может изменить логику управления или извлечь данные, не вызвав ни одного алерта. Повторное использование корпоративных учётных записей Active Directory на промежуточных серверах OT (jump servers) усиливает этот риск многократно.

Ожидаемый результат: таблица нарушителей с «персонажами», привязанными к конкретной инфраструктуре. Каждая исключённая категория — с обоснованием. Каждый скорректированный потенциал — тоже. Документ в 8–15 страниц, а не в 50.

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

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

Что делать:

Откройте раздел «Угрозы» в БДУ ФСТЭК. Каждая угроза (идентификатор УБИ.XXX) содержит описание, источники (типы нарушителей), объект воздействия и последствия. Отфильтруйте угрозы по категориям нарушителей и объектам воздействия из вашей модели. Нет виртуализации в инфраструктуре — угрозы, связанные с гипервизорами, неактуальны. Нет беспроводной сети в технологическом сегменте — угрозы через Wi-Fi тоже.

Для каждой оставшейся угрозы постройте вектор атаки — маршрут от точки входа до цели. Вектор атаки на АСУ ТП обычно проходит через несколько уровней: корпоративная сеть → точка сопряжения → инженерная рабочая станция → ПЛК.

Ключевой момент: не переносите угрозы из БДУ механически. Адаптируйте формулировки под конкретный объект. Угроза «несанкционированный доступ к технологической информации» на уровне SCADA в вашем случае может означать «чтение архива тегов через OPC-сервер с незащищённого сегмента корпоративной сети». Такая конкретика позволяет проектировать меры защиты, а не закрывать абстрактные пункты.

Ожидаемый результат: перечень актуальных угроз с векторами и обоснованием актуальности. Это основа для выбора мер защиты по Приказу ФСТЭК №239.

Модель угроз и нарушителя: пример дополнения через MITRE ATT&CK for ICS

Банк данных угроз ФСТЭК — обязательная основа с точки зрения регулятора. Для технической полноты я дополняю его матрицей MITRE ATT&CK for ICS.

MITRE ATT&CK — открытая база тактик и техник атак, собранная на основе реальных инцидентов. T-коды (например, из серии T0800+ для ICS) — её идентификаторы. Матрица ATT&CK for ICS описывает не абстрактные угрозы, а конкретные действия атакующего на каждом этапе: от первоначального доступа (Initial Access) до воздействия на физический процесс (Impact).

Разница с БДУ принципиальная. Банк данных описывает что может произойти. ATT&CK for ICS описывает как это происходит — конкретные техники, наблюдавшиеся в реальных инцидентах на промышленных объектах. Сопоставление двух источников даёт модель, которая удовлетворяет регулятора и содержит техническую детализацию для построения реальной защиты.

Интеграция на практике: возьмите каждый вектор атаки из предыдущего шага. Для каждого этапа вектора найдите соответствующие тактики и техники в ATT&CK for ICS. Зафиксируйте маппинг: УБИ.XXX (БДУ) → тактика → техника (ATT&CK for ICS). С позиции регулятора это необязательное дополнение, но именно оно превращает формальный документ в инструмент проектирования мониторинга.

Специалисты Sygnia описывают четырёхфазный подход к построению детектирования в ICS/OT: Know (понять среду и активы) → Assess (оценить текущие возможности) → Plan (спланировать покрытие) → Optimize (настроить мониторинг). Модель нарушителя — фундамент первой фазы. Без неё остальные три не имеют отправной точки.

Показательный пример — инцидент Colonial Pipeline: атака на IT-сеть привела к остановке OT-среды, хотя подтверждённого проникновения в контур управления не зафиксировали. Решение об остановке приняли, потому что не смогли определить, достиг ли нарушитель промышленного сегмента. Качественная модель нарушителя с разграничением IT- и OT-векторов позволяет принимать такие решения на основе данных, а не паники.

Типичные ошибки при построении модели нарушителя КИИ

Несколько ошибок, которые встречались на каждом втором проекте.

Копирование без обоснования. Берут типовую модель из методических рекомендаций, меняют название организации в шапке, отправляют на согласование. ФСТЭК осуществляет надзор за выполнением требований по обеспечению безопасности ЗОКИИ (187-ФЗ, ст. 14) — и при проверках всё чаще запрашивает не факт наличия документа, а логику определения актуальности угроз. Шаблонная копия этот вопрос не закрывает.

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

Игнорирование OT-специфики. Модель строит IT-специалист без участия инженеров АСУ ТП. Результат предсказуем: не учтены общие сервисные учётные записи на ПЛК, отсутствие аутентификации в промышленных протоколах, физический доступ к контроллерам через незапертые шкафы в цехах.

Отсутствие пересмотра. Модель пишется один раз и забывается. Между тем инфраструктура меняется: появляются новые подрядчики, открываются VPN-каналы, вводятся новые подсистемы. Модель нарушителя — живой документ, который пересматривается при каждом значимом изменении архитектуры, а не по формальному календарю.

Большинство моделей нарушителя, которые мне попадались у заказчиков, — документы «для проверяющего»: 40–60 страниц текста из методики, где актуально всё и ничего одновременно. Формально такие документы проверку проходят, но защиту объекта не обеспечивают. Я видел объект, где модель включала «иностранные спецслужбы» с высоким потенциалом — при том что технологическая сеть соединялась с корпоративной через нефильтруемый VLAN, а пароль от SCADA-сервера не менялся три года. По документам все угрозы учтены. Реальный нарушитель (уволенный сотрудник с запомненным паролем) описан одной строкой как «базовый потенциал, низкая мотивация».

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

Модель нарушителя — не бюрократическая формальность, а фундамент, на котором стоит весь периметр защиты. Если она врёт — врёт всё, что на ней построено. Если ищешь джуниор-роль в этой области — IB Basics плюс пара разобранных кейсов вроде этого дают что показать на собеседовании.