Методичка ФСТЭК по импортозамещению в КИИ: разбираем критерии и приоритеты

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

Что нового в документе

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

Документ вводит несколько осей оценки:

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

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

Как это работает на практике у промышленного заказчика

У нашего клиента - объект второй категории, производственный комплекс с SCADA и несколькими уровнями АСУ ТП. Задача - применить методичку к реальному инвентарю и получить на выходе приоритизированный план с обоснованием для комиссии.

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

Получилась трёхуровневая структура:

Первый уровень - ПО, напрямую управляющее технологическим процессом. SCADA-система, контроллеры, промышленные протоколы. Для нашего клиента это Wonderware (AVEVA) и несколько специфичных HMI-интерфейсов. Замена здесь - отдельная история: российских аналогов с сопоставимой функциональностью и сертификатами единицы, и все они требуют пилотного тестирования перед развёртыванием на действующем производстве.

Второй уровень - инфраструктурное ПО объекта. Операционные системы серверов и рабочих мест технологического сегмента, средства виртуализации, СУБД. Здесь картина лучше: Astra Linux и РЕД ОС уже проходили у нас пилот у другого клиента, для Linux-серверов под СУБД есть PostgreSQL, для виртуализации - zVirt и ряд других решений в реестре. Это более реалистичный горизонт замены.

Третий уровень - вспомогательное ПО. Мониторинг, резервное копирование, средства управления сетью. По методичке ФСТЭК этот слой идёт последним, что логично.

Что реально тормозит

Главная проблема не в том, чтобы найти замену ПО в реестре. Проблема - доказать эквивалентность функциональности и провести тестирование так, чтобы это не остановило производство.

Методичка ФСТЭК пока не описывает детально, как должен выглядеть процесс пилотирования и что считается достаточным доказательством совместимости. Это отдано на откуп субъекту КИИ. На практике это означает, что документировать нужно всё самостоятельно: что тестировали, по каким сценариям, какие проблемы нашли, как устранили или почему приняли риск.

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

Что готовим для комиссии

На текущий момент у заказчика формируется несколько документов:

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

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

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