Пентест КИИ я начинаю не со сканера и не с поиска самой эффектной уязвимости. Сначала определяю, какое последствие нельзя допустить. Остановка технологической линии, потеря диспетчерского управления, искажение показаний датчиков, блокировка противоаварийной автоматики или невозможность восстановить производство после инцидента. Затем строю путь, по которому нарушитель может добраться от внешнего периметра до такого последствия.
Российское законодательство не требует ежегодно «взламывать КИИ» по единому сценарию. Для значимых объектов тестирование на проникновение входит в анализ уязвимостей перед вводом в эксплуатацию, а дальнейшую периодичность проверок определяют модель угроз, изменения архитектуры, результаты контроля защищенности и особенности технологического процесса. Трехлетний интервал внутреннего контроля из приказа ФСТЭК № 235 нельзя автоматически превращать в периодичность пентеста.
Материал предназначен для легальной проверки собственной инфраструктуры или систем, на тестирование которых получено письменное разрешение. Работы в OT-сегментах нужно согласовывать с владельцем технологического процесса, службой информационной безопасности и эксплуатационным персоналом. Нельзя применять описанные подходы для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного вмешательства в работу инфраструктуры.
Что требуют 187-ФЗ и приказы ФСТЭК
187-ФЗ регулирует безопасность критической информационной инфраструктуры, категорирование объектов, обязанности субъектов КИИ, создание систем безопасности значимых объектов и взаимодействие с ГосСОПКА. Закон не содержит готовой программы пентеста, списка обязательных инструментов или универсальной периодичности технических проверок.
В 2025 году нормативный контур заметно изменился. В законе появились типовые отраслевые перечни объектов и отраслевые особенности категорирования. Для значимых объектов закрепили требования к российскому программному обеспечению и программно-аппаратным средствам с учетом переходных сроков, которые определяет правительство. Субъекты значимых объектов также должны непрерывно взаимодействовать с ГосСОПКА. Перечисленные изменения усилили требования к управлению защитой, но не превратили пентест в ежегодный формальный ритуал.
Основные технические требования задает приказ № 239. Документ распространяется именно на значимые объекты КИИ. Пункт 12.6 требует перед вводом объекта в эксплуатацию провести анализ уязвимостей всех программных и программно-аппаратных средств, включая средства защиты информации.
Анализ должен охватывать код, конфигурацию и архитектуру. ФСТЭК прямо перечисляет изучение документации, проверку настроек, поиск известных уязвимостей, анализ доступных сетевых служб и тестирование на проникновение в условиях, соответствующих возможностям нарушителей из модели угроз. Способы проверки субъект выбирает с учетом особенностей работы объекта.
Для промышленной инфраструктуры особенно значимо разрешение проводить анализ на макете, в тестовой зоне или на макетах отдельных сегментов. Такая формулировка дает законное основание не доказывать опасный сценарий на действующем контроллере. Если команда уже подтвердила путь до инженерной станции, а технолог на стенде показал возможность изменить логику управления, вмешательство в рабочий ПЛК не добавит полезных доказательств.
После ввода объекта в эксплуатацию приказ № 239 требует отслеживать новые уязвимости, изменения угроз и возможные последствия. Приказ № 235 дополняет требования внутренним контролем состояния безопасности не реже одного раза в три года. Руководитель может назначить проверки чаще. Внешний аудит способен заменить внутренний контроль, но привлеченная организация должна иметь лицензию на работы по технической защите конфиденциальной информации в части контроля защищенности от несанкционированного доступа и модификации.
Трехлетний срок относится к контролю состояния безопасности, а не к любой форме пентеста. После модернизации АСУ ТП, изменения межсетевого взаимодействия, подключения нового подрядчика, переноса сервисов или обнаружения критической уязвимости ждать следующего планового контроля нельзя. Объем повторной проверки определяет изменение, которое могло открыть новый путь атаки.
В сентябре 2025 года ФСТЭК утвердила отдельную методику испытаний систем защиты методами тестирования на проникновение. Методика применяется при аттестации и контроле защищенности информационных систем, прежде всего государственных систем определенных классов. Владельцы других систем могут использовать документ по собственному решению. Называть методику обязательной программой пентеста для любого объекта КИИ было бы ошибкой.
| Требование | Что проверяю на практике | Частая ошибка |
|---|---|---|
| Модель угроз | Точки входа, возможности нарушителя, доверенные связи и достижимые компоненты | Использовать типовую модель без привязки к реальной архитектуре |
| Анализ уязвимостей | Код, настройки, архитектуру, сетевые службы и компенсирующие меры | Приложить выгрузку сканера без проверки применимости находок |
| Тестирование на проникновение | Возможность пройти по цепочке до согласованной контрольной точки | Эксплуатировать каждую CVE ради доказательства |
| Контроль защищенности | Состояние мер защиты, журналирование, обнаружение и реакцию | Считать трехлетний контроль единственной нужной проверкой |
| Устранение недостатков | Разрыв цепочки атаки и повторную проверку | Закрыть один порт и не проверить альтернативные маршруты |
Как я строю разведку OT-сегмента
До начала технических работ я фиксирую границы. В программу входят IP-диапазоны, площадки, допустимые учетные записи, разрешенные способы проверки, временные окна, контакт аварийной остановки, критерии прекращения работ и порядок восстановления. Владельцем риска выступает не пентестер, а руководитель, который отвечает за технологический процесс и письменно принимает условия теста.
Отдельный раздел программы описывает запрещенные действия. На работающем производстве я обычно исключаю изменение логики ПЛК, запись в регистры управления, перезагрузку контроллеров, обновление прошивок, фаззинг промышленных протоколов, широковещательные тесты, подбор паролей, проверку отказа в обслуживании и запуск кода, способного повлиять на доступность.
Разведку начинаю с документов и пассивного наблюдения. Сравниваю проектные схемы с правилами межсетевых экранов, таблицами маршрутизации, журналами VPN, настройками jump-серверов, доменными довериями, системами резервного копирования и реальным сетевым трафиком. Проектная схема почти всегда показывает только предполагаемую архитектуру. Трафик показывает, как инфраструктура работает сейчас.
Зеркальный порт коммутатора или сетевой TAP позволяет собрать базовый профиль без запросов к промышленным устройствам.
tcpdump -i mirror0 -nn -s 0 -w ot-baseline.pcap
tshark -r ot-baseline.pcap -q -z endpoints,ip
tshark -r ot-baseline.pcap
-Y "tcp.flags.syn == 1 and tcp.flags.ack == 0"
-T fields
-e frame.time
-e ip.src
-e ip.dst
-e tcp.dstportПо дампу я определяю активные узлы, инициаторов соединений, направления обмена и неожиданные переходы между зонами. Особое внимание получают подключения к инженерным станциям, HMI, серверам истории, OPC-шлюзам, системам резервного копирования и серверам обновлений. Незашифрованный протокол сам по себе еще не доказывает критический риск. Риск появляется, когда нарушитель может достичь канала, подменить трафик или воспользоваться избыточными полномочиями.
Пассивная разведка не видит выключенные устройства и службы, которые редко обмениваются данными. Результаты нужно сверять с инвентаризацией, конфигурациями коммутаторов, журналами средств защиты и сведениями эксплуатационного персонала. Хороший инвентарь содержит не только IP-адрес и модель устройства, но также версию прошивки, функциональную роль, физическое размещение, владельца, допустимое окно обслуживания и способ восстановления.
Активное сканирование сначала запускаю на стенде или цифровом двойнике. На рабочем сегменте каждый профиль проходит оценку риска. Команда ограничивает скорость запросов, исключает опасные сценарии и заранее проверяет совместимость с оборудованием. Универсального «безопасного режима Nmap для АСУ ТП» не существует. Старый коммуникационный модуль способен зависнуть даже от обычного определения версии сервиса.
Самые интересные маршруты редко начинаются возле контроллера. Я проверяю удаленный доступ подрядчиков, ноутбуки инженеров, общие доменные службы, серверы обновлений, терминальные шлюзы, антивирусные консоли, резервное копирование и файловый обмен между IT и OT. Двухсетевая инженерная станция или временно разрешенный VPN часто опаснее уязвимости в промышленном протоколе.
| Этап | Цель | Безопасное доказательство | Причина остановить тест |
|---|---|---|---|
| Внешняя разведка | Найти публичные точки входа и раскрытые сведения | Метаданные, конфигурация сервиса и согласованная проверка доступа | Обнаружение неизвестного владельцу промышленного узла в интернете |
| Корпоративная сеть | Проверить привилегии и пути администрирования | Доступ к тестовой учетной записи или контрольному ресурсу | Признаки влияния на рабочие станции операторов |
| Граница IT и OT | Проверить DMZ, jump-серверы и доверенные связи | Подтвержденный маршрут без выполнения команд управления | Неожиданное изменение сетевого обмена или задержек |
| OT-сегмент | Определить достижимые инженерные и диспетчерские системы | Чтение журналов, конфигураций или пассивного трафика | Предупреждение оператора, отказ службы или изменение состояния устройства |
| Технологический процесс | Оценить возможность недопустимого последствия | Стенд, эмулятор, цифровой двойник или расчет технолога | Необходимость воздействовать на работающий исполнительный механизм |
Как я превращаю находки в kill chain
Отчет со списком CVE плохо отвечает на вопрос о реальной защищенности. Уязвимость с высоким баллом CVSS на изолированном сервере может создавать меньший риск, чем разрешенный RDP между корпоративной сетью и инженерной станцией. Поэтому каждую существенную находку помещаю в цепочку атаки и связываю с моделью угроз.
Термин kill chain не входит в понятийный аппарат 187-ФЗ. В проекте я использую более точную формулировку «цепочка атаки». MITRE ATT&CK for ICS помогает назвать тактики и техники нарушителя, но сам по себе не подтверждает выполнение российских требований. Нормативной основой остаются модель угроз, требования ФСТЭК, документы системы безопасности и результаты испытаний.
Типовая цепочка начинается с компрометации внешней учетной записи. Нарушитель входит в корпоративный VPN, закрепляется на рабочей станции, получает дополнительные права, находит сервер администрирования, использует доверенное подключение к jump-серверу и достигает инженерной станции. Следующим возможным шагом становится изменение проекта контроллера или параметров технологического процесса.
На действующем производстве последний шаг не выполняю. Достаточным доказательством служит контролируемый доступ к согласованной папке, тестовой учетной записи, копии проекта или другому безопасному маркеру. Возможные последствия подтверждают технологи на стенде, цифровом двойнике или расчетной модели. Пентест должен доказать риск, а не воспроизвести аварию.
Такой подход подтверждают реальные инциденты. В атаке TRITON вредоносная программа добралась до системы противоаварийной защиты Triconex. Ошибка атакующего кода перевела контроллер в безопасное состояние и вызвала автоматическую остановку предприятия. Инцидент показал, что компрометация инженерной станции системы безопасности может оказаться опаснее прямой атаки на обычный ПЛК.
Атака на Colonial Pipeline показала другой сценарий. Вымогатели поразили корпоративные IT-системы, подтвержденного проникновения в OT не обнаружили. Компания отключила часть систем мониторинга и управления из предосторожности и остановила транспортировку топлива. Физическое последствие возникло без доказанного захвата контроллеров. Поэтому цепочка атаки должна учитывать биллинг, связь, диспетчеризацию, управление доступом, резервное копирование и другие IT-зависимости производства.
Каждую цепочку я проверяю не только на возможность проникновения, но и на обнаружение. Команда заранее определяет, какие записи должны появиться в журналах, какое правило SIEM должно сработать, кто получит уведомление и какие действия выполнит дежурная смена. Если пентестер дошел до инженерной станции, а SOC не увидел ни одного этапа, профилактические меры нельзя считать достаточными.
Оценку риска не свожу к CVSS. Учитываю достижимость узла, полномочия компонента, связь с технологическим процессом, наличие резервирования, возможность обнаружения, сложность восстановления и ожидаемое последствие. Ошибка сегментации без номера CVE способна получить высший приоритет. Критическая уязвимость может получить умеренный приоритет, если эксплуатацию надежно блокируют архитектура и компенсирующие меры.
Что должно остаться после проверки
Итоговый отчет я делю на управленческую и техническую части. Руководителю нужны цепочки атак, возможные последствия, нарушенные меры защиты, владельцы рисков и сроки исправления. Инженерам нужны точные узлы, настройки, журналы действий, условия воспроизведения, доказательства и критерии успешного ретеста.
В отчет не следует включать действующие пароли, приватные ключи, полный дамп памяти или готовую инструкцию по остановке производства. Секреты передают по отдельному защищенному каналу, после чего учетные данные меняют. Артефакты теста удаляют, временные разрешения отзывают, а эксплуатационный персонал подтверждает штатное состояние систем.
Рекомендация должна описывать проверяемый результат. Фраза «обновить программное обеспечение» мало помогает владельцу объекта. Полезная формулировка требует установить исправленную версию, удалить устаревшую службу, ограничить маршрут между зонами, включить многофакторную аутентификацию, настроить журналирование и повторить конкретный этап цепочки.
Ретест проверяет не отдельную уязвимость, а разрыв всего маршрута. Закрытый порт не решает проблему, если тот же переход доступен через сервер резервного копирования, ноутбук подрядчика или общую учетную запись администратора. Цепочка считается разорванной только после того, как нарушитель перестает достигать контрольной точки либо защитные средства надежно обнаруживают и останавливают движение.
Моя позиция проста. Пентест КИИ приносит пользу, когда начинается с последствий для технологического процесса и заканчивается доказанным разрывом цепочки атаки. Сканер уязвимостей остается вспомогательным инструментом. Главный результат показывает, сможет ли нарушитель пройти от внешней точки входа к критической функции, заметит ли служба безопасности такое движение и успеет ли остановить атаку до ущерба людям, производству и окружающей среде.
Обязателен ли пентест КИИ по 187-ФЗ?
187-ФЗ не устанавливает единый обязательный пентест для каждого объекта КИИ. Для значимых объектов приказ ФСТЭК № 239 требует анализировать уязвимости перед вводом в эксплуатацию. Анализ может включать тестирование на проникновение с учетом модели угроз и возможностей предполагаемого нарушителя.
Как часто нужно проводить пентест значимого объекта КИИ?
Фиксированного интервала для любого пентеста КИИ нет. Периодичность определяют модель угроз, категория значимости, изменения архитектуры, новые уязвимости и возможные последствия атаки. Внутренний контроль состояния безопасности по приказу ФСТЭК № 235 проводят не реже одного раза в три года, но данный срок нельзя автоматически считать периодичностью пентеста.
Можно ли проводить пентест на работающем производстве?
Ограниченные проверки допустимы после письменного согласования с владельцем технологического процесса и эксплуатационным персоналом. Опасные сценарии лучше переносить на стенд, макет, эмулятор или цифровой двойник. На действующем объекте обычно запрещают изменение логики ПЛК, запись управляющих значений, фаззинг промышленных протоколов, перезагрузку устройств и тестирование отказа в обслуживании.
Чем пентест КИИ отличается от обычного корпоративного пентеста?
В корпоративной сети основной ущерб часто связан с утечкой данных, шифрованием серверов или захватом учетных записей. В КИИ атака может остановить физический процесс, нарушить управление оборудованием или повлиять на безопасность людей. Поэтому доступность и предсказуемость технологических систем имеют приоритет над попыткой полностью эксплуатировать найденную уязвимость.
С чего начинается разведка OT-сегмента?
Разведку начинают с документации, инвентаризации, правил межсетевых экранов, журналов VPN и анализа доверенных связей. Затем применяют пассивный сбор трафика через зеркальный порт или сетевой TAP. Активное сканирование проводят только после оценки риска и проверки профиля на совместимом стенде.
Почему нельзя ограничиться сканером уязвимостей?
Сканер находит версии программ, открытые службы и известные CVE, но не показывает полный путь нарушителя к технологической функции. Критическая уязвимость на изолированном сервере может быть менее опасной, чем ошибочное правило межсетевого экрана или общая административная учетная запись между IT и OT.
Что означает kill chain при проверке КИИ?
Kill chain описывает последовательность действий нарушителя от первоначального доступа до воздействия на критическую функцию. Например, компрометация VPN, захват рабочей станции, повышение привилегий, переход через jump-сервер и доступ к инженерной станции. Термин не закреплен в 187-ФЗ, поэтому в нормативной документации точнее использовать формулировку «цепочка атаки».
Нужно ли реально изменять настройки ПЛК для подтверждения риска?
Нет. Для подтверждения риска обычно достаточно доказать достижимость инженерной станции, наличие необходимых прав и доступ к безопасному контрольному объекту. Возможное влияние на ПЛК подтверждают на стенде, цифровом двойнике или с помощью расчета технологов. Пентест должен показать возможность атаки, а не воспроизвести аварию.
Какие системы чаще всего открывают путь из IT в OT?
Риск часто создают jump-серверы, ноутбуки подрядчиков, двухсетевые инженерные станции, серверы обновлений, системы резервного копирования, терминальные шлюзы, общие доменные службы и временные VPN-подключения. Такие связи нужно проверять раньше, чем промышленные протоколы и контроллеры.
Что должно входить в отчет по пентесту КИИ?
Отчет должен содержать границы работ, модель нарушителя, фактическую архитектуру, найденные цепочки атак, возможные последствия, доказательства, ограничения проверки и план исправления. Для каждой проблемы назначают владельца, срок и критерий успешного ретеста. Действующие пароли, приватные ключи и опасные инструкции в основной отчет не включают.
