Настройка Nessus под требования 187-ФЗ: обязательные плагины для скана значимого объекта КИИ

На аудите энергетического предприятия мы полгода получали «чистые» отчёты Nessus — 12 находок на хост, в основном просроченные SSL-сертификаты и раскрытие баннеров. Формально мера АНЗ.1 выполнена, все довольны. Потом настроили аутентифицированное сканирование через выделенную доменную учётку — и первый же скан вернул 87 находок на хост. 14 критических на 60% серверов. Почти все — пропущенные патчи Windows, которые числились установленными в WSUS, но фактически не развернулись из-за ошибки конфигурации клиента. WSUS показывал «Success», а патчей на хостах не было. Для значимого объекта КИИ это прямое нарушение требований ФСТЭК, и при проверке такой разрыв между отчётом и реальностью объяснять будет нечем. Ниже — пошаговая настройка Nessus под 187-ФЗ с конкретными параметрами политики, разбором обязательных плагинов и маппингом результатов на меры Приказа №239.

Зачем 187-ФЗ требует сканирование уязвимостей значимого объекта КИИ

187-ФЗ (Федеральный закон «О безопасности критической информационной инфраструктуры РФ» от 26.07.2017) задаёт рамку: субъект КИИ — организация, владеющая объектом критической инфраструктуры (информационной системой, сетью связи или АСУ ТП) — обязан обеспечить безопасность значимых объектов. А вот конкретные технические меры определяет уже ФСТЭК.

Базовый документ для практики — Приказ ФСТЭК №239 от 25.12.2017 (с изменениями). В приложении к нему есть группа мер АНЗ (Анализ уязвимостей), которая прямо обязывает субъекта КИИ:

• АНЗ.1 — выявлять и анализировать уязвимости значимого объекта, в том числе с использованием средств анализа защищённости
• АНЗ.2 — контролировать установку обновлений ПО, включая обновления средств защиты информации
• АНЗ.3 — контролировать работоспособность и параметры настройки средств защиты

Для ЗОКИИ (значимый объект КИИ — объект, которому присвоена 1-я, 2-я или 3-я категория значимости) всех категорий базовый набор мер включает АНЗ.1. Проще говоря: если у вас есть ЗОКИИ — вам нужен сканер уязвимостей, настроенный под требования регулятора, а не запущенный «по дефолту».

Nessus Professional или Tenable.sc — один из инструментов, закрывающих эту задачу. Но «из коробки» он заточен под западные комплаенс-стандарты: CIS, PCI DSS, HIPAA, DISA STIG. Под ФСТЭК его нужно настраивать руками — выбирать нужные семейства плагинов, отключать агрессивные проверки для АСУ ТП (автоматизированных систем управления технологическими процессами) и выстраивать отчётность, которую примет регулятор.

Контекст, который часто упускают: ФСТЭК при проверках опирается на банк данных угроз (bdu.fstec.ru). Обнаруженные Nessus уязвимости с идентификаторами CVE нужно сверять с BDU — если уязвимость есть в банке данных для ПО, используемого в ЗОКИИ, приоритет её устранения повышается. При плановой или внеплановой проверке (ст. 14 187-ФЗ, Постановление Правительства №162) наличие незакрытой уязвимости из BDU — это конкретный предмет разговора с регулятором.

Создаём политику сканирования Nessus под ФСТЭК

Политика сканирования (scan policy) — набор параметров, определяющий что и как Nessus проверяет. Для КИИ нельзя использовать дефолтный шаблон Basic Network Scan: он включает агрессивные проверки, способные нарушить работу промышленных контроллеров и SCADA-серверов.

Перед стартом убедитесь, что Nessus Professional с актуальной лицензией установлен, база плагинов полностью синхронизирована. Без полной синхронизации результаты будут неполными — сканер просто не знает о части уязвимостей.

Делай раз: создаём кастомную политику. В веб-интерфейсе Nessus: Policies → New Policy → Advanced Scan. Этот шаблон открывает доступ ко всем параметрам. Если выбрать шаблон попроще (Basic или Host Discovery), часть настроек будет скрыта — для КИИ это неприемлемо, потому что вы потеряете контроль над тем, какие именно проверки запускаются.

Делай два: задаём базовые параметры безопасного сканирования.

Вкладка Settings → General: имя задавайте в формате KII-FSTEC-239-[категория]-[дата] (например KII-FSTEC-239-K1-2026Q3). В описании укажите привязку к нормативке — при аудите это сэкономит время: «Политика анализа уязвимостей ЗОКИИ категории 1 по мерам АНЗ.1–АНЗ.3 Приказа ФСТЭК №239».

Вкладка Settings → Discovery → Port Scanning: для IT-сегмента используйте default (Top 4790 портов). Для сегмента АСУ ТП ограничьте диапазон реально используемыми портами промышленных протоколов — Modbus TCP (502), OPC UA (4840), EtherNet/IP (44818), HTTP/HTTPS (80/443) для HMI-панелей. Расширенное сканирование портов на промышленном оборудовании генерирует лишний трафик и может вызвать нештатное поведение ПЛК. Я видел, как широкий скан портов на Siemens S7 приводил к зависанию HMI — технолог потом полчаса перезагружал панель.

Вкладка Settings → Assessment → General: параметр Safe checks — включить обязательно. Nessus не будет запускать эксплойты и DoS-проверки. Для АСУ ТП это критично: без Safe checks плагин проверки Modbus способен вызвать перезагрузку контроллера на работающем оборудовании.

Делай три: выставляем ограничения производительности. Вкладка Settings → Performance: Max simultaneous hosts — для IT-сети 20–30 хостов, для сегмента АСУ ТП не более 5. Max simultaneous checks per host — для промышленных систем 2–3 вместо дефолтных 5. Network receive timeout — 15 секунд для медленных промышленных сетей. Как проверить, что параметры подобраны верно: запустите тестовый скан на 3–5 хостах сегмента АСУ ТП в согласованное с технологическим персоналом окно обслуживания. Скан завершился без ошибок таймаута и без нештатных событий на оборудовании — всё в порядке. Появились таймауты или контроллер «моргнул» — снижайте параллелизм.

Обязательные плагины Nessus для аудита уязвимостей КИИ

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

Плагины для IT-сегмента ЗОКИИ

Вкладка Plugins в политике сканирования. Включите следующие семейства:

Отдельно про Policy Compliance: Nessus умеет одновременно сканировать уязвимости и проверять конфигурации. Для ЗОКИИ это критично — отсутствие уязвимостей не означает, что сервер настроен правильно. Compliance-аудит по CIS-бенчмаркам закрывает меру АНЗ.3 и даёт регулятору картину соответствия базовым конфигурациям. Без этого семейства вы закрываете только половину задачи.

Плагины для сегмента АСУ ТП

Семейство SCADA содержит проверки для промышленных протоколов и контроллеров. Для анализа уязвимостей АСУ ТП это основное семейство, но работать с ним нужно аккуратно.

SCADA-плагины отправляют запросы на промышленные контроллеры. Запускайте их исключительно в согласованное с технологическим персоналом окно планового останова. На одном из объектов энергетики плагин проверки Modbus вызвал перезагрузку контроллера подстанции — после этого инцидента мы перешли на сканирование ПЛК только в период ТО. Урок был дорогим.

Какие плагины отключить

Три семейства создают прямой риск для непрерывности работы ЗОКИИ:

• Denial of Service — проверки, имитирующие атаки на отказ в обслуживании. На промышленном оборудовании это может привести к реальному останову технологического процесса
• Brute Force — перебор паролей блокирует учётные записи операторов АСУ ТП, у которых часто ограниченное число УЗ. Заблокировали оператора — и некому реагировать на аварийный сигнал
• Default Unix Accounts — агрессивные проверки стандартных учёток

Для отключения: в разделе Plugins политики снимите галочку напротив названия семейства. После сохранения политики проверьте, что отключённые семейства не вернулись — иногда обновление плагинов сбрасывает настройки. Я на это натыкался дважды: обновили базу плагинов, а DoS-семейство снова включилось.

Аутентифицированное сканирование значимого объекта КИИ

Без аутентификации Nessus видит только то, что доступно по сети: открытые порты, баннеры сервисов, SSL-сертификаты. По сути — выполняет разведку, аналогичную технике Vulnerability Scanning (T1595.002 в MITRE ATT&CK). MITRE ATT&CK — открытая база тактик и техник, которыми пользуются атакующие; T-коды вроде T1595.002 — её идентификаторы. Эта конкретная техника относится к тактике Reconnaissance — действиям до получения доступа.

Но атакующий, получивший начальный доступ через уязвимость публичного приложения (T1190, Exploit Public-Facing Application), видит гораздо больше: установленное ПО (T1518), конфигурацию сети (T1016), системную информацию (T1082). Аутентифицированное сканирование имитирует эту видимость и показывает реальную картину уязвимостей. В кейсе из начала статьи — рост с 12 до 87 находок на хост. Для ЗОКИИ разница между «15 находок, всё хорошо» и «87 находок, 14 критических» — это разница между формальным соответствием и реальной защитой.

Настройка сервисной учётной записи

Для Windows-хостов:

Создайте выделенную сервисную учётную запись в Active Directory (например, svc-nessus-scan). Не используйте учётку администратора домена — при компрометации сканера злоумышленник получит ключи от всей инфраструктуры. Пароль — не менее 25 символов, хранение в корпоративном менеджере паролей. Ротация — ежегодно или при смене персонала с доступом.

Предоставьте учётной записи права локального администратора через GPO (Group Policy Object — механизм централизованного управления настройками Windows в домене Active Directory). Путь: Computer Configuration → Policies → Windows Settings → Security Settings → Restricted Groups → добавьте svc-nessus-scan в группу Administrators.

Следующий шаг, без которого аутентификация не заработает: примените ключ реестра LocalAccountTokenFilterPolicy со значением 1 на все сканируемые хосты через GPO. Без него UAC (User Account Control — контроль учётных записей Windows, механизм, ограничивающий привилегии при удалённом доступе) блокирует удалённый доступ даже для учётки с правами администратора. Путь в реестре: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy, тип DWORD, значение 1.

На файрволе целевых хостов откройте порты WMI и SMB (TCP 135, 139, 445) для IP-адреса сканера Nessus.

Для Linux-хостов:

Создайте выделенную учётку (например, nessus-scan), настройте SSH-доступ по ключу (не по паролю) и предоставьте sudo-права для команд чтения конфигураций и проверки пакетов.

В политике Nessus: вкладка Credentials → Windows → укажите домен, логин и пароль сервисной учётки. Для Linux: Credentials → SSH → загрузите приватный ключ.

Как проверить успешность аутентификации

После первого скана с учётными данными откройте результаты и найдите два плагина:

• Plugin ID 21745 — сообщает о неудачной аутентификации. Если появился на более чем 10% хостов — есть системная проблема: WMI не включён, SMB заблокирован файрволом или LocalAccountTokenFilterPolicy не применился
• Plugin ID 12634 — подтверждает успешную аутентификацию

Отфильтруйте результаты по Plugin ID 21745 и посмотрите текст вывода — там указана конкретная причина отказа. Исправьте самую частую причину (она затронет наибольшее число хостов) и перезапустите скан на проблемной группе.

Правило для КИИ: не включайте результаты скана в отчёт для ФСТЭК, пока доля успешной аутентификации не превысит 90%. Отчёт с заниженным количеством уязвимостей — прямой путь к претензиям регулятора при проверке. По документам всё чисто, а при проверке выясняется, что сканер просто не смог залогиниться на половину хостов.

Маппинг результатов Nessus на требования ФСТЭК к сканированию

ФСТЭК при проверке ЗОКИИ оценивает не абсолютное количество найденных уязвимостей, а выполнение мер Приказа №239. Регулятору нужна связь между находками сканера и конкретными мерами.

Экспортируйте результаты Nessus в CSV — этот формат удобен для маппинга на меры №239. Для каждой критической и высокой уязвимости зафиксируйте: CVE-идентификатор, CVSS-оценку (Nessus поддерживает CVSS v3 и v2), затронутые хосты и конкретный срок устранения.

Для внутренней приоритизации CVSS — не лучший ориентир. CVSS показывает теоретическую опасность, а вам нужно понять, что закрывать первым. Тут полезнее EPSS — оценка вероятности от 0 до 1, что уязвимость начнут эксплуатировать в ближайшие 30 дней. Или VPR (Vulnerability Priority Rating) — собственная оценка Tenable на основе данных об активной эксплуатации. Для регулятора CVSS остаётся основным языком, но внутри организации приоритизация по EPSS позволяет закрывать первыми то, что реально атакуют, а не то, что страшнее выглядит на бумаге.

Если организация использует GRC-систему (RVision, Security Vision или аналог) — импортируйте результаты скана через API и привяжите к требованиям №239 автоматически. Это экономит десятки часов ручного маппинга при каждом цикле сканирования.

Периодичность сканирования КИИ и отчётность для ГосСОПКА

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

Привяжите расписание Nessus к циклу патч-менеджмента: запускайте скан до и после каждого окна обновлений. Предпатчевый скан фиксирует базовый уровень уязвимостей, послепатчевый подтверждает реальную установку. Если послепатчевый скан показывает те же Critical-уязвимости — патч не встал, несмотря на статус «Success» в системе развёртывания. Именно так мы обнаружили проблему с WSUS из начала статьи. Nessus позволяет сравнивать результаты двух сканов через scan history comparison: категории Added (новые), Removed (исправленные) и Unchanged (оставшиеся) показывают динамику устранения.

Взаимодействие с ГосСОПКА

ГосСОПКА (государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак; координатор — НКЦКИ при ФСБ) требует от субъектов КИИ уведомления о компьютерных инцидентах в сроки от 3 до 24 часов в зависимости от категории объекта (ст. 5 187-ФЗ, Постановление Правительства №43).

Результаты Nessus сами по себе не инцидент. Но обнаруженная критическая уязвимость с активной эксплуатацией в реальных атаках — это уже эскалация. Ориентир: каталог CISA KEV (Known Exploited Vulnerabilities — перечень уязвимостей, которые уже используются злоумышленниками в реальных атаках). Если Nessus находит CVE из KEV на значимом объекте — это не обычный тикет в очереди на патчинг, а основание для экстренных мер и потенциального уведомления. Заведите под это отдельную процедуру.

Российский контекст: Nessus — иностранный продукт, и в условиях импортозамещения ряд субъектов КИИ переходит на отечественные сканеры (MaxPatrol VM, RedCheck). Методология, описанная здесь — создание кастомной политики, выбор семейств плагинов, маппинг на меры №239 — применима к любому сканеру уязвимостей. Принцип один: не сканировать «по дефолту», а выстраивать проверки под конкретные требования регулятора и особенности инфраструктуры.

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

Я вижу повторяющуюся ошибку у субъектов КИИ, которые только начинают выстраивать процесс анализа защищённости: запускают неаутентифицированный скан с дефолтной политикой, получают «чистый» отчёт и успокаиваются. По документам мера АНЗ.1 выполнена. На практике — 80% реальных уязвимостей остались невидимыми. Первый аутентифицированный скан с правильно настроенной политикой вскрывает картину, которая заставляет пересматривать весь подход к патч-менеджменту. Да, это неприятно: вместо 12 находок появляется 87, и каждую нужно отработать. Но именно это отличает реальную защиту от имитации. В КИИ цена имитации — не штраф от регулятора, а инцидент на объекте, последствия которого выходят далеко за периметр IT. На codeby.school/ib-basics эту базу — от категорирования до первых результатов аудита — закрывают за пару модулей с лабами, если нужна структура после перехода из IT в ИБ.