Защита SCADA-систем: угрозы, безопасная оценка защищенности и выбор подрядчика

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

Дальше события развиваются так, как в офисной сети почти не бывает. Коммуникационный модуль перестает отвечать на опрос, значения давления на операторском HMI «замирают», и дежурная смена уже не понимает, отражает ли экран реальное состояние процесса. Операторы переходят на ручное управление. Главный инженер требует остановить работы, но в договоре не записано, кто имеет право сказать «стоп» и как об этом уведомить исполнителя. Восстановление занимает часы: актуальной резервной копии конфигурации модуля нет, а поставщик оборудования доступен только по заявке.

Этот пример показывает, почему квалификация исполнителя должна включать понимание технологического процесса и его ограничений. Ошибки подготовки могут нарушить доступность и при обычном ИТ-пентесте. В SCADA/OT последствия дополнительно затрагивают физический процесс, безопасность людей и целостность данных, на основании которых принимаются операционные решения. Поэтому оценка защищенности АСУ ТП начинается не с выбора сканера, а с инвентаризации процесса, границ доверия, правил проведения работ, полномочий на остановку и готовности к восстановлению.

Ниже — практическая схема для CISO, CTO и руководителей эксплуатации: что считается OT, как строятся пути угроз от корпоративной сети и удаленного доступа к технологическим зонам, какие уровни оценки безопасны, как фиксировать доказательства и что спрашивать у поставщиков и подрядчиков.

Что относится к OT и почему NIST SP 800-82 Rev.3 — отправная точка

Финальная редакция NIST SP 800-82 Rev.3 опубликована в сентябре 2023 года. Документ посвящен безопасности операционных технологий с учетом их особых требований к производительности, надежности и безопасности (safety). Понятие OT в нем широкое: это программируемые системы и устройства, которые взаимодействуют с физической средой или управляют такими устройствами. Сюда входят промышленные системы управления, SCADA, системы автоматизации зданий, транспортные системы и системы физического контроля доступа.

Для практики это означает две вещи. Во-первых, граница оценки редко совпадает с границей «серверной SCADA». В нее попадают операторские HMI, серверы SCADA, инженерные станции, исторические базы данных, шлюзы удаленного доступа, а иногда и системы управления зданием или проходными, если они связаны с той же инфраструктурой. Во-вторых, привычные ИТ-приоритеты меняются местами: доступность и предсказуемость работы управляющих систем часто важнее конфиденциальности, а любое вмешательство оценивается через последствия для процесса.

Руководство, а не сертификат

NIST SP 800-82 — это руководство, а не универсальная схема сертификации и не обязательство проходить аудит с фиксированной периодичностью. Ссылка на него в договоре или внутренней политике полезна как общий словарь и ориентир, но сама по себе не означает соответствия чему-либо. По состоянию на 21 сентября 2026 года следующая редакция, Rev.4, существовала только как первоначальный публичный проект, поэтому опираться на нее как на окончательную замену Rev.3 нельзя.

Рядом с SP 800-82 стоит держать технологически нейтральные рамки. NIST Cybersecurity Framework 2.0 помогает организациям понимать и улучшать управление рисками кибербезопасности. Для технологического сегмента удобно описать текущий и целевой профиль и сопоставить разрывы с информативными ссылками NIST. Отраслевые серии стандартов, например IEC 62443, стоит изучать отдельно и с учетом требований конкретной отрасли. Если организация относится к объектам критической информационной инфраструктуры, полезно заранее понять, какие доказательства ожидаются при проверке: этому посвящен наш материал о методологии аудита КИИ.

Инвентаризация активов и технологического процесса

Без инвентаризации нельзя ни оценить риск, ни безопасно спланировать проверку. Но в OT недостаточно списка IP-адресов и моделей оборудования. Нужно понимать, какую функцию процесса выполняет каждый узел, что произойдет при его недоступности и кто отвечает за его эксплуатацию.

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

Что фиксировать помимо списка устройств

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

Такая инвентаризация служит основой для всех следующих шагов. От нее зависят границы доверия, список исключений в правилах проведения работ и план восстановления.

Границы доверия и удаленный доступ в SCADA

Граница доверия — это место, где данные или управление переходят между зонами с разным уровнем риска: из корпоративной сети в технологическую, из интернета к порталу поставщика, с инженерного ноутбука подрядчика к контроллеру. Для каждой такой границы нужно ответить на несколько вопросов. Что именно разрешено пересекать? Кто это контролирует? Как это журналируется? Как быстро доступ можно отозвать?

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

Вендорский и подрядный доступ

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

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

Угрозы для SCADA удобнее моделировать не списком уязвимостей, а путями: откуда может начаться злоупотребление и через какие границы оно способно дойти до функций управления. На практике рассматривают как минимум три исходные зоны. Первая — корпоративная сеть: скомпрометированная рабочая станция, общий сервер, учетная запись с избыточными правами. Вторая — удаленный доступ: VPN, шлюзы, облачные порталы. Третья — вендорская зона: сервисные подключения, каналы обновлений, инженерные инструменты подрядчика.

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

Веб-компоненты HMI и порталов

Если операторы работают через браузерный HMI, панели мониторинга, порталы исторических данных, REST API или портал удаленного доступа поставщика, часть поверхности атаки проходит через HTTP. Здесь стандарты веб-безопасности применяются напрямую. HTTP не хранит состояние между запросами, поэтому сессии держатся на cookies и механизмах аутентификации. В HTTP/1.1 есть механизм Upgrade, через который соединение переводится на WebSocket, а именно так часто устроено обновление данных в реальном времени. При приемке таких компонентов стоит проверять Content Security Policy, которая помогает обнаруживать и смягчать часть атак, включая XSS и внедрение данных, а также настройки CORS, CORP и Permissions Policy, обработку сессионных cookies и аутентификацию.

Для требований и процедур удобна связка проектов OWASP: Top 10 как документ осведомленности о критичных рисках веб-приложений, ASVS как основа для проверки технических мер и требований к разработке, WSTG как набор процедур тестирования. ASVS рекомендует ссылаться на требования с указанием версии, например v5.0.0-1.2.5, поскольку идентификаторы могут меняться между версиями. Веб-проверки при этом тоже подчиняются правилам OT: тестовая копия портала предпочтительнее работающего узла, который опрашивает контроллеры.

Классы первопричин вместо погони за CVE

Список MITRE CWE Top 25 выделяет наиболее опасные и распространенные классы слабостей ПО, а MITRE отмечает, что анализ первопричин помогает исключать целые классы дефектов, например в области безопасности памяти и внедрения. Серия оповещений CISA Secure by Design посвящена устранению внедрения команд ОС, межсайтового скриптинга, обхода каталогов и переполнения буфера; по последнему классу CISA выпускала предупреждение совместно с FBI. Для SCADA-программ это дает общий язык с поставщиками. Продуктивнее спрашивать, какие классы дефектов устранены на уровне архитектуры, чем обсуждать отдельные идентификаторы уязвимостей, для которых в работающей среде может не найтись безопасного окна обновления.

Безопасные уровни оценки защищенности SCADA

Главное различие между методами оценки в OT — степень взаимодействия с работающими устройствами. Активное сканирование добавляет трафик в сеть и напрямую взаимодействует с устройствами в контуре. Оно может дестабилизировать устройства или повлиять на состояние процесса, а значит, потенциально затронуть безопасность и целостность. Пассивное обнаружение позволяет узнать подключенное оборудование с меньшим взаимодействием.

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

Почему активное сканирование — отдельное решение

Активную проверку нельзя считать режимом по умолчанию, который просто включают аккуратнее. Активные сканирования стоит по возможности проводить в плановые технологические остановы. Рекомендации CISA и ICS-CERT по оценке систем управления советуют избегать активных сканирований производственных систем управления, поскольку они способны вызвать эксплуатационные проблемы или отказ в обслуживании, и отмечают, что пассивной активности может быть достаточно. Если же производственные системы все-таки проверяются активно, тесты должен выполнять местный персонал по указаниям команды оценки. Также стоит рассмотреть достоверную замещающую или тестовую систему.

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

Правила проведения работ и полномочия на остановку

Письменные правила проведения работ (rules of engagement, ROE) — центральный документ любой оценки SCADA/OT. Согласно рекомендациям CISA и ICS-CERT, они определяют разрешенные действия, системы, операторов, условия остановки и протоколы уведомления. Для OT к этому важно добавить конкретных людей: названных владельцев со стороны эксплуатации и технологической безопасности, контакты для экстренной связи и явное одобрение каждой активной техники по отдельности, а не «активного тестирования» в целом.

1. Пассивная основаДокументация, архитектура и пассивное обнаружение дают картину активов и связей без воздействия на процесс.
2. Офлайн и стендКонфигурации, резервные копии и логика анализируются офлайн; рискованные техники отрабатываются на тестовой системе или цифровом двойнике.
3. Готовность к восстановлениюДо любого активного шага подтверждены актуальные резервные копии, шаги восстановления и доступность поставщика.
4. Решение по каждой техникеВладельцы эксплуатации и safety письменно одобряют конкретную технику, систему, окно и условия остановки.
5. Плановое окно и местный персоналАктивные действия по возможности идут в плановый останов; на производстве их выполняет местный персонал по указаниям команды.

Минимальный состав правил проведения работ

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

Простое правило: если в ROE нельзя за минуту найти, кто останавливает работы и как об этом сообщить, документ не готов. В гипотетическом сценарии из начала статьи не хватало именно этого пункта.

Готовность к восстановлению до начала проверки

Восстанавливаемость в OT — это ограничение контура, а не пункт «на потом». Прежде чем планировать даже пассивные работы на работающей системе, полезно ответить на несколько вопросов. Есть ли актуальные резервные копии конфигураций, логики контроллеров и образов станций? Проверялось ли восстановление из них и сколько оно занимает? Кто из поставщиков нужен для восстановления и в какие сроки он доступен? Какие узлы нельзя перезагружать без остановки процесса?

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

Доказательства, отчет и устранение находок

Ценность оценки SCADA определяется качеством доказательств, а не количеством найденных проблем. Каждая находка должна показывать, где она обнаружена и каким методом, на каком уровне взаимодействия получено доказательство, к какому пути угрозы она относится, какие последствия для процесса возможны и что предлагается сделать с учетом ограничений эксплуатации. Находки полезно привязывать к классам CWE, к требованиям ASVS с указанием версии там, где речь идет о веб-компонентах, и к целевому профилю CSF, который организация для себя определила.

Методологически здесь помогает NIST SP 800-115, опубликованный в сентябре 2008 года. Он описывает планирование и проведение технических проверок, анализ находок и разработку стратегий устранения, но прямо оговаривает, что не является полной программой тестирования. Его процессная часть остается полезной, а конкретные техники для OT нужно соотносить с SP 800-82 и ограничениями среды.

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

Оценка — не сертификация

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

Закупки и вопросы к поставщикам OT

Безопасность SCADA во многом закладывается при закупке. В рамках Secure by Design CISA исходит из того, что безопасность клиента должна быть ключевым бизнес-требованием, а не технической опцией. Продукт должен быть безопасным «из коробки», а многофакторная аутентификация, журналирование и единый вход должны предоставляться без доплаты. Для владельцев и операторов OT CISA выпустила руководство «Secure by Demand: приоритетные соображения для владельцев и операторов OT при выборе цифровых продуктов». Есть также общее руководство Secure by Demand для разговоров с реселлерами и поставщиками услуг, рекомендации по безопасному развертыванию обновлений и совместное с австралийским ACSC руководство по выбору безопасных и проверяемых технологий.

Обязательство Secure by Design Pledge, которое подписывают производители ПО, — это добросовестное обязательство двигаться к семи ключевым целям с публикацией отчетов о прогрессе, а не сертификация. Его разумно учитывать как сигнал и подкреплять договорными требованиями. MITRE отмечает, что меньшее число уязвимостей на этапе разработки означает меньше проблем после внедрения. Поэтому требования при закупке обычно рациональнее дорогой доработки уже установленной системы.

Матрица ниже подходит и для закупки продукта, и для выбора исполнителя оценки.

Как выбрать исполнителя оценки SCADA/OT

Хороший исполнитель начинает с вопросов о процессе, а не со списка инструментов. Он спрашивает, какие функции критичны, какие узлы нельзя трогать, есть ли тестовая система, кто владеет эксплуатацией и safety, как устроено восстановление. Его методология прослеживается до этапов планирования, проведения, анализа и стратегии устранения, а план работ явно разделяет пассивные, офлайн, стендовые и активные действия.

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

Перед стартом попросите обезличенный образец отчета и план работ для OT-среды, уточните, какие работы выполняются только на стенде и кто со стороны заказчика согласует каждую активную технику. Если нужно собрать контур проверки с учетом этих ограничений — систем, исключений, окон и ожидаемых доказательств, — начните с подготовки контура пентеста на Pentest.red. Это помогает заранее отделить то, что можно проверить безопасно, от того, что требует отдельного решения владельцев.

Итог: защита SCADA-систем как управляемый цикл

Защита SCADA-систем строится не вокруг одного продукта или одной проверки, а вокруг цикла. В него входят инвентаризация процесса, границы доверия, пути угроз, безопасные уровни оценки, правила работ с ясными полномочиями на остановку, готовность к восстановлению, доказательная отчетность и контроль устранения, а затем требования к закупкам, которые уменьшают классы дефектов в новых системах. NIST SP 800-82 Rev.3 задает общий ориентир для OT, CSF 2.0 помогает связать находки с целевыми результатами, а рекомендации CISA показывают, как не превратить оценку в инцидент.

Главный принцип прост: безопасность процесса, его целостность, доступность, ограничения поставщиков и восстанавливаемость — такие же условия контура, как список IP-адресов. Наименее инвазивное достаточное доказательство часто оказывается лучшим.