ADG Оставить заявку
Блог Регуляторика 5 мин чтения

Методика ФСТЭК по оценке угроз для КИИ: разбираем проект и что он меняет на практике

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

Контекст момента

ФСТЭК публикует проект методики оценки угроз безопасности информации для субъектов КИИ

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

Читали проект вместе с несколькими клиентами. Ниже - что реально важного в документе и где он добавляет работы.

В чём суть изменений

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

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

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

Что изменится в процессе

Методика вводит несколько шагов, которых раньше либо не было, либо они оставались на усмотрение разработчика модели:

  • Анализ архитектуры объекта. Перед оценкой угроз нужно зафиксировать компоненты объекта: что входит в состав, какие интерфейсы есть с другими объектами и с внешними системами, какие данные обрабатываются. Это не описание ради описания - от этого зависит, какие классы угроз вообще применимы.
  • Определение нарушителей по признакам. Документ требует описать не просто «внешний нарушитель» и «внутренний нарушитель», а конкретизировать: кто именно, какие у него возможности, есть ли признаки целенаправленных атак применительно к этой отрасли и этому типу объекта. Для КИИ это принципиально - объекты топливно-энергетической отрасли и объекты банковской инфраструктуры атакуют разные группы с разными целями.
  • Оценка последствий по каждой угрозе. Актуальность угрозы теперь нужно обосновывать через последствия: что произойдёт с объектом и с процессом, который он обеспечивает, если угроза реализуется. Это снова отсылает к категорированию: чем выше категория объекта, тем серьёзнее требования к детализации последствий.

Где добавляется реальная работа

Первое место, где новая методика создаёт работу, - это объекты с третьей и второй категорией, которые компании категорировали «по минимуму». Документы подписаны, категории присвоены, но технической детализации по архитектуре и процессам там нет. Под новую методику такие объекты придётся разбирать заново.

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

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

Связь с актуализацией СОБ

У нескольких клиентов, с которыми мы сейчас работаем по аудиту защищённости КИИ, уже сформированы системы обеспечения безопасности по Приказу №235 ФСТЭК. Вопрос от одного из них был прямой: «Мы делали СОБ под текущую методику - что придётся переделывать?»

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

Статус документа и что делать сейчас

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

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

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

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.