ГосСОПКА на удалёнке: как субъект КИИ обеспечивает нотификацию инцидентов когда все дома

На прошлой неделе к нам обратился клиент - субъект КИИ из финансового сектора. Вопрос формулировался примерно так: «У нас три месяца народ работает из дома, часть агентов мониторинга стоит на корпоративных ноутбуках, часть - на виртуальных рабочих местах. НКЦКИ требует передачи данных в ГосСОПКА в режиме реального времени. Что именно должно работать и как это проверить?»

Вопрос хороший. Давление со стороны регулятора не ослабло из-за пандемии, зато инфраструктура за последние месяцы у многих сильно изменилась. Разбираем, что именно требует НКЦКИ и где тонко при удалённой работе.

Что говорит регулятор

Базовые требования к субъектам КИИ по взаимодействию с ГосСОПКА установлены в 187-ФЗ и конкретизированы в приказах ФСБ и НКЦКИ. Ключевые обязательства для значимых объектов:

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

Технически это реализуется через подключение к ГосСОПКА: либо к отраслевому центру (если есть), либо напрямую к НКЦКИ через технические средства - агенты, которые передают данные по защищённому каналу.

Где проблема с удалёнкой

Классическая схема мониторинга для субъекта КИИ выглядела так: агенты стоят на серверах и рабочих станциях в корпоративной сети, события собираются в SIEM на площадке, оттуда - в ГосСОПКА. Агенты видят всё, потому что всё в одной сети.

Теперь часть рабочих мест физически вне корпоративной сети. Агент на ноутбуке сотрудника, который работает из дома, оказывается в принципиально другом сетевом окружении. Несколько проблем сразу:

Агент не может достучаться до корпоративного коллектора событий. Если агент настроен слать события на внутренний адрес SIEM-коллектора, а ноутбук вне VPN - события просто не приходят. Пробел в телеметрии накапливается незаметно.

VPN не всегда включён постоянно. Пользователи отключают VPN для видеозвонков, чтобы разгрузить канал, или включают только когда «нужно». В эти промежутки агент молчит.

Split tunneling режет телеметрию. Если VPN настроен с раздельным туннелированием - трафик рабочих приложений идёт через туннель, а остальное - напрямую. Агент может находиться в «остальном» и не попадать в корпоративный коллектор.

Временные метки съезжают. NTP через домашний роутер - это другой источник времени, чем корпоративный NTP. Если агент не синхронизируется через VPN - события могут приходить с расхождением во времени, что ломает корреляцию в SIEM.

Что нужно сделать технически

Работая с клиентом, мы прошлись по нескольким слоям.

Первое - аудит покрытия агентами. Составить список активов, которые попадают в scope мониторинга для ГосСОПКА, и проверить, на каких из них агент реально работает и реально шлёт события. Для ноутбуков удалённых сотрудников это часто сюрприз: агент установлен, но события не приходят уже неделями. Проверяется просто - смотрим в SIEM когда последний раз приходило событие от каждого хоста.

Второе - адресация коллектора. Коллектор событий должен быть доступен для агента вне зависимости от того, включён VPN или нет. Варианта два: либо сделать коллектор доступным через интернет с жёстким ограничением по IP и сертификатам, либо принудительно гнать трафик агента через VPN-туннель даже при split tunneling. Первое проще в реализации, второе - правильнее с точки зрения безопасности.

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

Четвёртое - канал до НКЦКИ. Если организация передаёт данные напрямую в ГосСОПКА, а не через корпоративный SOC, нужно убедиться, что защищённый канал работает. Требования к каналу - использование СКЗИ, сертифицированных ФСБ. VPN типа WireGuard или OpenVPN тут не подходит: нужен КриптоПро или ViPNet. Проверяем, что криптошлюз работает и лицензии актуальны.

Что мы увидели у клиента

У клиента оказалась типичная картина: агенты на серверах работали нормально, события шли. Агенты на ноутбуках сотрудников, перешедших на удалёнку, в трети случаев молчали - и никто не замечал, потому что в SIEM события от серверной части шли нормально, alarm'ов не было.

Коллектор был доступен только изнутри корпоративной сети. Split tunneling был включён «для экономии канала». В итоге - значимые активы в пробеле телеметрии уже несколько недель.

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

По аудиту интеграции с ГосСОПКА мы проходим несколько шагов: инвентаризация активов в scope, проверка покрытия агентами, проверка доставки событий, анализ пробелов. Результат - конкретный список того, что нужно починить, с приоритетами.

Что важно держать в голове

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

Удалёнка сделала этот вопрос острее: инфраструктура разъехалась, а требования никто не отменял. Хорошая новость в том, что технически всё решаемо - вопрос в том, чтобы вообще проверить текущее состояние. Большинство клиентов, которых мы видим сейчас, этой проверки не проводили.