OT/IT-сегментация: что спрашивают клиенты после Colonial Pipeline

С момента публикации про Colonial Pipeline прошло меньше двух недель, а нам уже позвонили четыре клиента с промышленными сетями. Не с новыми задачами - с одним и тем же вопросом: «У нас что, тоже может быть такое?»

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

Почему вопрос стал острым именно сейчас

Colonial Pipeline остановили не потому, что атакующие взломали SCADA или PLC. Судя по тому, что сейчас известно, ransomware DarkSide затронул преимущественно IT-инфраструктуру - биллинг, корпоративные данные. Трубопровод остановила сама компания: превентивно, не зная, добрались ли атакующие до операционного сегмента.

Это ключевой момент, который многие пропустили. Не взломали АСУ - но и уверенности в её целостности тоже не было. А когда нет уверенности - останавливают. Если бы OT был надёжно изолирован, такой дилеммы могло не возникнуть вообще.

Именно это и объясняет характер звонков. Клиенты не паникуют из-за конкретной уязвимости - они беспокоятся о том, что не знают, что будет, если что-то пойдёт не так у них.

Базовая архитектура, которую мы рекомендуем

На бумаге правильная модель описывается просто. На практике от неё отступают по самым разным причинам - историческим, бюджетным, потому что «вендор сказал так настроить». Поэтому фиксируем её явно.

Три зоны, не две. Корпоративная сеть и технологическая сеть не должны быть соединены напрямую - между ними нужна DMZ. В DMZ живут сервисы, которые должны обмениваться данными между сегментами: историки данных, OPC-шлюзы, серверы обновлений для OT-оборудования. Ничто из корпоративного сегмента не имеет прямой маршрутизации в технологический.

Трафик - только туда, куда нужно. Из OT в DMZ - данные телеметрии и состояния. Из корпоративного в DMZ - запросы к историку, мониторинг. Прямой доступ из корпоративной сети в OT - запрещён. Это не «закрыть порты на всякий случай», это принцип: каждое разрешённое соединение должно быть обосновано задачей.

Никакого RDP напрямую в технологическую сеть. Это отдельный пункт, потому что встречается регулярно. Администратор настроил прямой RDP на рабочие станции в OT-сегменте «для удобства», и это соединение живёт годами. RDP - один из самых популярных векторов горизонтального движения внутри сети. Если нужен удалённый доступ к OT - только через jump host в DMZ, с логированием сессий и желательно с записью.

Однонаправленные шлюзы там, где это возможно. Для потоков данных из OT в корпоративный сегмент (телеметрия, историк) можно использовать аппаратные data diode - устройства, которые физически могут передавать данные только в одну сторону. Это дороже, чем файрволл с ACL, но надёжнее: никакое программное обеспечение не сможет открыть соединение в обратную сторону. Для некоторых объектов КИИ это уже не рекомендация, а требование.

Что мы видим на практике

Типичная картина у клиентов с промышленными сетями, которых мы смотрели в последние месяцы:

• Есть VLAN, иногда даже несколько. Но между ними есть маршрутизация, и ACL либо нет, либо устаревшие.
• Есть файрволл между OT и IT. Правила на нём выглядят логично - до первого детального разбора. Потом обнаруживается правило «permit any any», оставшееся после «временного» доступа вендора три года назад.
• Удалённый доступ для технического обслуживания - отдельная история. Вендор АСУ требует возможность подключиться для диагностики. Как именно организован этот доступ - часто не задокументировано и не мониторится.
• Патч-менеджмент для OT-оборудования - либо не делается совсем («производитель не сертифицировал, не трогаем»), либо делается руками через те же открытые каналы.

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

Что делать в первую очередь

Если клиент звонит с вопросом «с чего начать» - мы обычно предлагаем следующий порядок.

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

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

Разобраться с удалённым доступом. Как именно вендор или службы техобслуживания заходят в OT? Если это VPN с широким доступом или прямой RDP - это нужно переделать через управляемый jump host с ограниченным временем сессии.

Дальше - DMZ. Перепроектирование топологии с выделением DMZ - это уже проект, требует планирования и технического окна. Но его реалистично сделать поэтапно, не останавливая производство.

Аудит в данном случае - не про соответствие стандартам, а про понимание реальной картины. Пока её нет - непонятно, что именно менять и в каком порядке.

Где мы сейчас

У двух клиентов из четырёх уже идёт инвентаризация - делаем схему реальной топологии и смотрим правила файрволлов. Ещё двое пока на уровне разговора. Результаты покажут, что именно менять.

Скорее всего, у обоих будет один и тот же вывод: сделано неплохо для своего времени, но за несколько лет накопились отступления от первоначального замысла, которые никто не фиксировал. Это нормальная история. Ненормально - не знать об этом.