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

План защиты значимого объекта КИИ: типовая структура по Приказу №239 и связь с ISO 27001

ФСТЭК разъяснила состав плана защиты значимых объектов КИИ. Разработали типовую структуру документа - оказался объёмнее ожидаемого, но логика совпадает с ISO 27001.

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

ФСТЭК опубликовала разъяснения по составу плана защиты значимых объектов КИИ, осень 2018

ФСТЭК в этом сезоне добавила ясности: опубликовала разъяснения по составу плана защиты значимого объекта КИИ. До этого момента у нас было несколько параллельных проектов, где клиент спрашивал «а что вообще должно быть в этом плане?» - и мы опирались на текст Приказа №239 плюс собственную интерпретацию. Теперь есть более конкретная точка отсчёта, и мы сразу сели делать типовую структуру.

Откуда берётся план защиты

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

Что ФСТЭК уточнила в разъяснениях - так это то, что план должен отражать не просто список мер из самого приказа, а именно реализацию этих мер применительно к конкретному объекту: с учётом его категории, архитектуры, угроз и используемых СЗИ. То есть нельзя просто взять таблицу мер из приложения к №239, поставить галочки и назвать это планом. Нужен живой документ.

Что получилось в типовой структуре

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

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

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

Где ISO 27001 помогает

Неожиданно приятное открытие: если у клиента есть ISO 27001 или он хотя бы работал с этим стандартом, разработка плана защиты идёт быстрее примерно вдвое. Логика почти та же.

В ISO 27001 есть Statement of Applicability - документ, где организация фиксирует применимые меры управления из Приложения A, указывает статус каждой и обоснование исключений. В плане защиты КИИ нужно ровно то же самое, только перечень мер берётся из Приказа №239, а не из ISO 27002. Структура рассуждений, понятие компенсирующих мер, требование документировать обоснования - всё это изоморфно.

Это не значит, что ISO 27001 закрывает КИИ автоматически - не закрывает. Требования к СЗИ в российском регулировании специфичны: нужны сертифицированные средства, есть требования по классам, есть ГосСОПКА. Но организационная дисциплина, которую даёт ISO-опыт, сильно упрощает работу.

Что тормозит больше всего

На практике узкое место не написание самого плана, а сбор исходных данных. Типичная ситуация: клиент провёл категорирование несколько месяцев назад, акт подписали, но с тех пор что-то поменялось в инфраструктуре. Модель угроз формально есть, но сделана внешним подрядчиком и у внутренней команды понимания её нет. Реестр СЗИ не вели.

В итоге добрая половина работы по плану защиты - это приведение в порядок исходных данных, а не сам план как документ. Что стоит учитывать при планировании сроков.

Где мы сейчас

Типовая структура уже в работе на двух проектах - энергетика и транспорт. Клиенты из разных отраслей, разные категории объектов, разный уровень зрелости ИТ. Посмотрим, что придётся адаптировать.

Если вам нужна помощь с разработкой плана защиты или аудитом соответствия по Приказу №239 - пишите, расскажем по своему опыту аудитов.

Контакт

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

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