ADG Оставить заявку
Блог АСУ ТП 3 мин чтения

WannaCry добрался до АСУ ТП: аудит DMZ между корпоративной сетью и SCADA

WannaCry поразил SCADA и HMI с Windows XP на производстве. Для промышленных клиентов срочно проводим аудит демилитаризованных зон и документируем разрывы в сегментации.

Контекст момента

WannaCry поразил производственные сети с незащищёнными SCADA/HMI, включая заводы и больницы с Windows XP

Три недели после WannaCry, и картина в промышленности складывается неприятная. Пока корпоративный сегмент худо-бедно залатался - патч MS17-010, отключение SMBv1, разговоры про сегментацию - в технологических сетях всё оказалось сложнее. Несколько производств в разных странах сообщили об остановке линий. Рентгеновские аппараты в больницах отказали прямо во время работы. SCADA на Windows XP, которую «трогать нельзя, она работает», зашифровалась вместе со всем остальным.

Нам это не стало открытием - мы примерно понимали, что там происходит. Но поток запросов от промышленных клиентов после 12 мая заставил сформулировать это явно и поставить аудит DMZ между корпоративкой и АСУ ТП как отдельную задачу.

Почему АСУ ТП оказались под ударом

Коротко: потому что «изолированность» технологической сети часто существует только на бумаге.

Исторически АСУ ТП проектировались как физически изолированные. Никаких соединений с корпоративной сетью, никакого интернета. Но потом появились требования к оперативной отчётности, удалённому мониторингу, интеграции с ERP. Соединения стали прокладывать - иногда через нормально спроектированную DMZ, чаще через временный туннель или напрямую, «только на время пуско-наладки». Временное, как известно, постоянно.

Windows XP в технологическом сегменте - это не артефакт лени. Есть лицензионные SCADA-системы и HMI-приложения, которые не сертифицированы под Windows 7 и выше. Вендор не выпустил обновление, контракт на поддержку закончился, переход требует остановки производства и переаттестации. В итоге XP продолжает крутиться в 2017 году - и MS17-010 для неё появился только после WannaCry, внеплановым патчем, который надо ставить вручную.

SMBv1 в технологических сетях часто нельзя просто выключить. Часть промышленного оборудования - от ПЛК до гистори-серверов типа OSIsoft PI - использует SMBv1 для обмена данными. Выключить его без инвентаризации зависимостей значит остановить линию. А инвентаризацию некому делать: эксплуатация занята производством, ИТ не имеет доступа в технологический контур, ИБ в АСУ ТП вообще нередко отсутствует как функция.

Что мы видим на аудитах

Мы сейчас проходим несколько промышленных объектов подряд - по запросам, которые пришли после WannaCry. Картина повторяется с небольшими вариациями.

DMZ декларирована, но не задокументирована. Файервол между корпоративной сетью и АСУ ТП стоит. Правила в нём - результат многолетних ad hoc изменений, никто не может сказать, зачем открыт конкретный порт и можно ли его закрыть. Документации нет. Актуальной схемы сети нет.

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

Выход в интернет из технологического сегмента присутствует там, где его быть не должно. Не через корпоративный прокси с контролем - напрямую или через NAT на гейтвее. Обновления антивируса, активация Windows, загрузка обновлений от вендоров. Живой интернет из сети с ПЛК.

Патч-менеджмент в технологическом контуре не существует как процесс. Не «медленный» и не «сложный» - его просто нет. Обновление ОС на SCADA-сервере требует согласования с вендором, окна обслуживания, часто остановки производства. В итоге системы не обновляются годами.

Как мы строим аудит

Для промышленных объектов стандартный аудит безопасности требует адаптации - там своя специфика доступа и рисков.

Корпоративная сеть
    |
  [DMZ / файервол]   <-- зона нашего аудита
    |
Уровень диспетчеризации (SCADA, HMI, историки)
    |
Уровень управления (ПЛК, RTU, контроллеры)
    |
Физический процесс

Мы работаем на уровне DMZ и уровня диспетчеризации - туда, где есть ИТ-компоненты с сетевым стеком. В сам ПЛК-контур без согласования с технологами не лезем: там риск последствий от неосторожного сканирования реальный.

Первый шаг - инвентаризация соединений. Собираем актуальные правила файервола, сравниваем с тем, что задекларировано в архитектуре (если она есть). Смотрим NetFlow или логи файервола за последние недели: какие соединения реально используются, какие висят мёртвым грузом.

Второй шаг - классификация трафика. Каждое соединение из корпоративки в технологический сегмент получает статус: обоснованное и необходимое, обоснованное но избыточное (можно сузить), необоснованное (закрыть). Отдельно - соединения из технологического сегмента наружу.

Третий шаг - инвентаризация уязвимостей без активного сканирования. В АСУ ТП активный сканер может вызвать сбой оборудования - это реальная проблема, не параноя. Поэтому работаем пассивно: собираем версии ОС и ПО через агентов там, где можно, через WMI-запросы, через документацию вендоров. Строим матрицу: что запущено, какие CVE актуальны, что нельзя патчить и почему.

Четвёртый шаг - документирование разрывов. На выходе - не список уязвимостей с CVSS-баллами, а карта разрывов: где архитектурный контроль отсутствует, где он есть на бумаге но не в конфиге, где риск принят явно и где он принят молча. Это основа для разговора с производственниками о том, что можно закрыть без остановки процессов, а что требует планового окна.

Где сейчас

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

Отдельный вопрос - что делать с Windows XP, на которую патч MS17-010 теперь есть, но установить его мешает вендор или регламент. Это тема для отдельного поста, там нет простого ответа.

Для 187-ФЗ, кстати, этот разрыв между декларируемой и реальной защитой объектов КИИ - прямая проблема. Законопроект проходит финальные чтения, подзаконные акты готовятся, и одним из требований к защите значимых объектов будет именно сегментация уровней. WannaCry это показал наглядно - и раньше, чем требование стало обязательным.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.