Приказ ФСТЭК №239: заканчиваем комплект документов для значимого объекта КИИ

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

Поводом написать стало то, что вопросы про структуру пакета документов звучат всё чаще - коллеги по рынку, клиенты, которые только входят в тему. Расскажем, как это устроено у нас в конкретном проекте.

Откуда вообще взялась эта история

Приказ №239 действует с 2017 года, но реальная активность по нему сдвинулась примерно на 2019-й: закончились сроки категорирования, ФСТЭК начал плановые проверки, появились первые разъяснения и методички. Сейчас организации, которые прошли категорирование, встают перед следующим шагом - реализовать меры защиты и задокументировать это в понятном для регулятора виде.

Клиент в этом проекте - производственное предприятие. Значимый объект КИИ - АСУ ТП одного из технологических участков. Сеть изолирована, оборудование разнородное (часть - legacy, включая оборудование с заканчивающейся поддержкой вендора). Задача нам досталась не с нуля: акт категорирования есть, список объектов защиты определён, теперь надо строить систему защиты и оформлять документы.

Что входит в пакет

Приказ №239 требует разработать модель угроз и задокументировать меры защиты. Звучит просто, но за этим стоит приличный объём работы. Структура пакета, с которой мы работаем:

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

Самая трудоёмкая часть - не написать, а согласовать. Модель угроз в реальном проекте проходит через техническую службу клиента, службу безопасности, иногда отраслевого куратора. У всех разные ожидания от документа.

Организационные меры - отдельный блок документов:

• политика информационной безопасности (верхнеуровневая)
• регламент управления учётными записями и правами доступа
• инструкция по реагированию на инциденты (с учётом требований к взаимодействию с ГосСОПКА)
• порядок технического обслуживания средств защиты

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

Технические требования к СЗИ - по каждой мере из Приказа №239 нужно либо подтвердить её реализацию существующими средствами, либо сформулировать требования к новым. Для значимых объектов КИИ обязательно использование сертифицированных СЗИ - это сужает выбор заметно.

Конкретно в этом проекте смотрим на:

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

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

Что усложняет

Несколько вещей, с которыми столкнулись в этом проекте и которые не очевидны до начала работы.

Сертифицированные СЗИ для промышленных сред. Выбор не огромный. Часть вендоров сертифицировала свои продукты по нужным классам, но сертификаты бывают на конкретные версии - а версии устаревают. Надо смотреть сроки действия сертификатов и планировать обновления.

Разрыв между ИТ и АСУ ТП командами. Служба ИБ думает категориями ИТ-безопасности, технологи думают категориями непрерывности производства. Требование «обновить прошивку контроллера» для одних очевидно, для других - потенциальная остановка линии. Это приходится согласовывать вместе, а не решать за кабинетным столом.

Взаимодействие с ГосСОПКА. Значимые объекты обязаны уведомлять о компьютерных инцидентах. Технически это реализуется через подключение к ГосСОПКА, но процедурно - через выстраивание внутренних процессов обнаружения и реагирования, которых у многих клиентов просто нет.

Где сейчас

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

Практика первых проверок ФСТЭК по 239-му показывает, что регулятор смотрит прежде всего на полноту комплекта документов и на то, насколько реально реализованы заявленные меры. Красивый документ с мерами, которые не выполняются в жизни, - это хуже, чем честная фиксация текущего состояния с планом устранения.

Про аудит и разработку технической документации для КИИ-объектов - пишите, разберём конкретную ситуацию.