SCADA и корпоративная сеть: аудит изоляции и однонаправленный шлюз для историзации

После публикации Stuxnet все, кто хоть как-то связан с промышленными объектами, в разной степени занервничали. Один из наших клиентов - производственное предприятие с несколькими цехами - решил не ждать, пока к ним придёт проверка, или что-нибудь поинтереснее. Попросили провести аудит защищённости именно в части разделения SCADA-сегмента и корпоративной сети.

Спойлер: разделения как такового не оказалось.

Что нашли на старте

Перед выездом мы запросили схему сети и получили документ, в котором SCADA значилась в «изолированном технологическом сегменте». На месте выяснилось, что изоляция существовала только на схеме.

Реальная картина:

• OPC-серверы (несколько экземпляров, разные цеха) были включены в тот же VLAN, что и корпоративные рабочие станции бухгалтерии и логистики. Никаких дополнительных межсетевых экранов между ними - просто один плоский сегмент.
• Инженерные станции с установленным Siemens Step 7 и WinCC имели выход в корпоративную сеть напрямую. Часть из них - с учётными записями, которые используются также для подключения к корпоративному домену.
• Historian-сервер (OSIsoft PI, принимает данные с OPC) располагался в корпоративном сегменте и тянул данные прямо с OPC-серверов по двусторонней TCP-сессии.
• USB на машинах SCADA не заблокирован. Операторы пользовались флешками для обновления конфигураций - привет MS10-046, которую мы разбирали в феврале.

На вопрос «почему так устроено» главный технолог честно ответил: «Так исторически сложилось, всё работает, и IT сюда особо не лезет». IT-директор был удивлён тем, что вообще видит эти сегменты на одной схеме.

Как обоснование изменений проходило через организацию

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

Пришлось готовить отдельный документ с разбором Stuxnet применительно к их конкретной топологии: вот как червь распространялся через LNK, вот Step 7 у вас стоит, вот корпоративный VLAN прямо рядом с инженерными станциями. После того как технолог и IT-директор увидели на одной схеме свою сеть и описание вектора атаки - разговор стал проще.

Что сделали

Работу разбили на два этапа, чтобы не трогать всё сразу.

Первый - сетевая изоляция. Выделили отдельный VLAN для технологического сегмента: OPC-серверы, инженерные станции, контроллеры. Между корпоративным и технологическим сегментами поставили межсетевой экран (Cisco ASA, уже была в наличии на другом объекте клиента). Правила - строгий whitelist: ни одного разрешения «от корпоративного к технологическому» без явного обоснования. Обратно - вообще ничего по умолчанию.

Корпоративный домен для инженерных станций убрали. Отдельная AD в технологическом сегменте, отдельные учётки. Больно для пользователей, которые привыкли к единому логину, зато граница стала настоящей.

Второй - историзация через data diode. Самый интересный момент. Historian-серверу нужны данные с OPC - это производственная необходимость, аналитика и отчётность. Если просто поставить фаервол, нужно будет открыть порт в сторону корпоративного сегмента - и граница снова стала бы условной.

Решение - однонаправленный шлюз, data diode. Мы взяли готовое изделие (Owl Computing, на тот момент одно из немногих вменяемых решений с нормальной документацией под OPC). Принцип простой: данные физически не могут идти в обратную сторону - это оптоволоконная пара с передатчиком на одном конце и только приёмником на другом. Никаких TCP, никакого подтверждения доставки - данные льются в одну сторону, и всё.

OPC-данные с технологического сегмента идут через программный шлюз diode-а на Historian в корпоративной сети. Historian получает то, что нужно. Обратного канала физически нет. Атака через Historian на OPC-серверы становится невозможной не конфигурационно, а аппаратно.

Настройка потребовала некоторой работы: OPC Classic рассчитан на DCOM, а DCOM и однонаправленный шлюз - вещи мало совместимые в прямом виде. Пришлось перейти на OPC Tunneller со стороны источника, который упаковывает данные в UDP-поток, пригодный для diode. Это добавило несколько дней к проекту, зато решение получилось аккуратным.

Что не успели и что осталось открытым

USB-политику закрыли только частично: заблокировали на корпоративных машинах, до инженерных станций пока не добрались - там конкретные устройства подключаются через USB и надо делать whitelist по hardware ID, а это требует инвентаризации, которой ещё не было.

Патч-менеджмент в технологическом сегменте - отдельный разговор. Машины с WinCC и Step 7 обновляются по рекомендации Siemens, а Siemens рекомендует не торопиться с обновлениями ОС пока не пройдёт их внутренняя квалификация. На практике это означает, что несколько машин до сих пор на Windows XP SP2 без последних патчей. Аргумент «Siemens так рекомендует» технически понятен, но с точки зрения безопасности это дыры, и их надо компенсировать изоляцией - что мы, собственно, и сделали.

Главное наблюдение

На промышленных объектах «изоляция SCADA» очень часто существует только в документах. Реальное состояние сети проверяется только когда кто-то приходит и смотрит руками - не по схемам, а в коммутаторы и таблицы маршрутизации. В нашем случае разрыв между «как записано» и «как есть» оказался тотальным.

Data diode как архитектурный паттерн - дорого и неудобно по сравнению с «просто открыть порт на фаерволе». Зато это единственный способ обеспечить историзацию без обратного канала, который можно доказать не конфигом, а физикой.