Миссия невыполнима? Как закрыть требования по защите ГИС без раздувания штата

Подробный разбор изменений в защите ГИС (Приказ ФСТЭК № 117). Как перейти от «бумажной» безопасности к реальной, настроить процесс управления уязвимостями и автоматизировать рутину без Excel. Экспертный лонгрид.

В среде специалистов по информационной безопасности (ИБ) принято шутить, что стабильность в России есть только в одном — в постоянном изменении требований регуляторов. Однако принятие ФСТЭК России приказа от 28.05.2019 № 117, вносящего изменения в фундаментальный для отрасли 17-й приказ («Требования о защите информации...»), стало не просто очередной правкой. Это тектонический сдвиг, осознание которого у многих происходит только сейчас, когда приходит время переаттестации или плановой проверки.

Если раньше можно было создать «бумажный щит» — написать гору документации, положить её в сейф и забыть на три года, то теперь эта стратегия стала билетом в один конец (обычно — к административной ответственности, а в худшем случае — к уголовной).

В этой статье мы, как практики, ежедневно работающие с государственными информационными системами (ГИС), разберем приказ № 117 «по косточкам». Мы обсудим не сухие формулировки закона, а реальные боли: управление уязвимостями, контроль обновлений, бесконечную переработку моделей угроз и то, как вообще с этим жить, не раздувая штат до размеров киберармии.

Суть изменений: От «статичного аттестата» к «живой безопасности»

Глобальная идея, которую ФСТЭК заложил в изменения (и которую транслирует через 117-й приказ), звучит так: безопасность — это процесс, а не состояние.

Раньше жизненный цикл ГИС в глазах многих администраторов выглядел так:

1.  Создали систему.

2.  Написали Техпроект и Модель угроз.

3.  Купили СЗИ, настроили.

4.  Аттестовали.

5.  ...Тишина на 3 года...

6.  Повторить.

Приказ № 117 ломает эту порочную практику. Теперь требования по защите информации должны выполняться непрерывно в ходе эксплуатации системы. Регулятор прямым текстом говорит: аттестат соответствия — это не индульгенция. Если вы получили бумажку, но через месяц перестали ставить обновления безопасности — ваша система больше не защищена, и вы нарушаете закон.

Давайте пройдемся по самым болезненным точкам, которые принес нам этот документ.

1. Управление уязвимостями: Гонка на выживание

Пожалуй, самое жесткое требование касается работы с уязвимостями (пункт 17 Требований). Теперь это не факультатив, а обязательная ежедневная рутина.

Как было раньше: Сканирование уязвимостей проводилось перед аттестацией. Найденные дыры закрывались (или писалось обоснование, почему их нельзя закрыть), и система уходила в продакшн.

Как стало теперь:

Оператор ГИС обязан:

• Выявлять уязвимости на регулярной основе (анализ обновлений БДУ ФСТЭК).

• Устанавливать обновления безопасности ПО и СЗИ.

• Если обновление установить нельзя (например, оно ломает функционал ГИС) — применять компенсирующие меры.

В чем здесь «засада»?

Представьте типичную ГИС регионального масштаба. Это сотни серверов, тысячи рабочих станций (АРМ), зоопарк операционных систем (от Windows 7 до Astra Linux) и прикладного ПО.

Ежедневно в Банке данных угроз (БДУ) ФСТЭК появляются новые записи (CVE). Живой человек — администратор или безопасник — физически не способен каждое утро вручную сверять список установленного софта с базой уязвимостей. 

«Вышла уязвимость в Apache Tomcat. А где он у нас стоит? На 15 серверах? А какая версия? А можно ли обновить, или отвалится база данных?»*

Без автоматизации этот процесс превращается в фикцию. А проверка ФСТЭК сейчас часто начинается не с чтения бумаг, а с запуска сканера в вашей сети. Если сканер найдет критическую уязвимость трехмесячной давности, которую вы проигнорировали — разговор будет коротким.

2. Модель угроз: Теперь это не фантастика, а документалистика

Второй ключевой аспект — актуализация Модели угроз (МУ). Приказ № 117 и методические документы ФСТЭК требуют пересматривать МУ при изменении архитектуры, появлении новых угроз или изменении внешних условий (геополитика, новые векторы атак).

Многие привыкли писать Модель угроз методом «copy-paste» из старых шаблонов, включая туда мифических хакеров, перехватывающих ПЭМИН (побочные электромагнитные излучения) с помощью антенн в фургоне под окнами.

Реальность 2026+ года:

ФСТЭК требует реализма. Вы должны учитывать:

• Актуальные тактики и техники атак (матрица MITRE ATT&CK вам в помощь).

• Целевые атаки на госсектор.

• Атаки через цепочку поставок (Supply Chain).

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

Это создает колоссальную нагрузку на аналитиков. Модель нужно не просто написать, её нужно поддерживать. Изменился ландшафт угроз (например, появились новые методы атак на Linux-системы) — будьте добры обновить документ.

3. Контроль состава и целостности ПО: Проблема «Зоопарка»

Приказ вводит жесткие требования к контролю программного обеспечения. Вы должны точно знать:

1.  Какое ПО установлено (инвентаризация).

2.  Откуда оно взялось (легитимность дистрибутива).

3.  Не изменилось ли оно (контроль целостности).

Боль практика:

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

Виноват будет начальник ИБ, который «не обеспечил контроль». 117-й приказ требует внедрения средств автоматизированной инвентаризации и контроля целостности. Вы должны видеть каждый новый .exe файл, появившийся в системе.

4. Централизованное управление и иерархия (для крупных ГИС)

Если ваша система распределенная (например, ГИС здравоохранения области, к которой подключены сотни больниц), 117-й приказ возлагает ответственность за защиту всего сегмента на оператора головной системы.

Раньше можно было сказать: «У нас в министерстве всё защищено, а что там в районной поликлинике — это проблема главврача». Теперь нет. Сегменты ГИС должны иметь единую политику безопасности.

Это рождает проблему управляемости. Как проконтролировать, что в удаленном филиале обновили антивирус? Как убедиться, что там не истекли сертификаты ЭП?

Ответ один: нужны централизованные дашборды и системы мониторинга (SGRC, SIEM), куда стекается информация о состоянии защищенности всех узлов. Попытка управлять этим через переписку по электронной почте и сбор отчетов в Word — это путь к катастрофе.

5. Импортозамещение и доверенные источники

Хотя тема импортозамещения идет отдельным треком, 117-й приказ усиливает требования к установке обновлений только из доверенных источников.

Для западного ПО (которое все еще используется) это стало головной болью. Обновляться напрямую с серверов вендора, который ввел санкции, рискованно (а иногда и невозможно). Скачивать патчи с торрентов — преступно.

Операторам ГИС приходится выстраивать собственные репозитории обновлений, тестировать их в «песочнице» перед накаткой на продуктив. Это полноценный DevOps-процесс, к которому многие госучреждения оказались не готовы ни технически, ни морально.

Как выжить? Стратегия перехода к реальной безопасности

Итак, мы поняли, что «имитация бурной деятельности» больше не работает. Объем задач вырос кратно, а штат сотрудников и бюджеты остались прежними. Что делать?

Единственный выход — автоматизация рутины. Человеческий мозг должен заниматься аналитикой и принятием решений, а не копированием строк из БДУ ФСТЭК в Excel.

Вот пошаговый план, как перестроить работу отдела ИБ под новые требования:

Шаг 1. Тотальная, автоматизированная инвентаризация

Выкиньте бумажные журналы учета ПО и техники. Внедрите систему (класс решений Asset Management), которая сама просканирует сеть и скажет, что у вас реально работает.

Результат: Вы увидите «теневое IT» (неучтенный софт) и получите базу для анализа уязвимостей.

Шаг 2. Автоматизация комплаенса (GRC/SGRC)

Попытка вручную поддерживать актуальность ОРД (организационно-распорядительной документации) — это тупик. Шаблоны приказов, журналов, актов, моделей угроз должны генерироваться автоматически на основе данных инвентаризации и категории системы.

Используйте специализированные платформы, которые:

• Содержат актуальные шаблоны документов.

• Сами напоминают о сроках пересмотра.

• Связывают технику, людей и документы в единую сущность.

Шаг 3. Внедрение процесса Patch Management

Настройте процесс так, чтобы информация о новых CVE автоматически сопоставлялась с вашей инвентаризационной базой. Система должна присылать алерт: «На сервере №5 обнаружена критическая уязвимость, вот ссылка на патч».

Без этого вы всегда будете на шаг позади хакеров (и проверяющих).

Шаг 4. Обучение персонала (Security Awareness)

117-й приказ требует повышения осведомленности. Но не формального подписания журнала «Инструктаж прошел». Внедряйте платформы для тестирования сотрудников, запускайте учебные фишинговые рассылки.

Помните: в 90% случаев ГИС взламывают не через супер-сложный эксплойт нулевого дня, а через бухгалтера, открывшего файл «Зарплата_2026.exe».

Шаг 5. Контроль сроков действия СКЗИ

Просроченный сертификат электронной подписи или лицензия на СЗИ может остановить работу ведомства. Доверять этот контроль календарю в телефоне сисадмина нельзя. Нужна система, которая за месяц начнет бить тревогу: «Срок действия лицензии КриптоПро истекает!».

Почему Excel — главный враг безопасника

Мы часто видим, как коллеги пытаются закрыть требования 117-го приказа с помощью таблиц.

• Таблица «Активы».

• Таблица «Уязвимости».

• Таблица «Сотрудники».

• Таблица «Модель угроз».

Проблема в том, что эти таблицы не связаны. В Excel вы не увидите, что увольнение сотрудника Иванова требует отзыва трех сертификатов и изменения прав доступа на пяти серверах. В Excel вы не увидите, что новая уязвимость касается именно тех серверов, где обрабатываются самые критичные ПДн.

Связанность данных — это то, что дают специализированные IRP и SGRC системы. Они создают «цифровой двойник» вашей системы защиты.

Заключение: Бюрократический шторм можно оседлать

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

Для профессионального сообщества это вызов — трансформироваться. Уйти от роли «писателей бумаг» к роли архитекторов безопасных процессов. И ключевым инструментом в этой трансформации является отказ от ручного труда в пользу специализированных средств автоматизации процессов ИБ.

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