Привет, Хабр! Меня зовут Антон Кутепов, я руковожу центром промышленной экспертизы Positive Technologies. Мы исследуем угрозы для технологических сетей, промышленные протоколы и оборудование, разрабатываем правила обнаружения атак и закладываем эту экспертизу в PT ISIM.
Подробные разборы инцидентов на действующих предприятиях появляются редко. Публикация такой истории может раскрыть архитектуру и конфигурацию систем, которые в промышленности живут годами. Поэтому сегодня разберем учебный сценарий, воспроизведенный на Standoff – онлайн-полигоне с реальными компонентами АСУ ТП. Это не цифровая копия действующего производства со всей его эксплуатационной историей, блокировками и последствиями, но логика перемещения атакующего и работа источников телеметрии вполне характерны для промышленной инфраструктуры.
Начнем с конца
В 14:23 SCADA-сервер установки гидрокрекинга записал новое значение технологического сигнала в ПЛК. Событие произошло вне технологического окна и вызвало вопросы службы ИБ, но прежде чем делать выводы необходимо понять контекст. Источник команды — сервер АСУ ТП, получатель — контроллер, которым он и должен управлять. Соединение не похоже на эксплуатацию уязвимости, протокол стандартный, а сама операция записи предусмотрена логикой работы системы.
Что это было: инженер изменил параметр или злоумышленник начал воздействовать на технологический процесс?
По одному событию ответить невозможно. Но если отмотать расследование назад, перед этой командой обнаружится цепочка, начавшаяся далеко от контроллера — с компрометации сервера в DMZ.
Сам факт записи со SCADA-сервера в ПЛК еще не доказывает атаку: передавать контроллерам управляющие значения — штатная работа SCADA. Если смотреть только на сетевой поток, перед нами знакомая пара узлов и допустимое направление взаимодействия. Подозрение вызывает, тот факт, что такой записи ранее не было.
Даже название сигнала HR 32768.0 мало что объясняет без привязки к проекту АСУ ТП. Нужно знать, какому параметру он соответствует, допускается ли запись с этого узла, какое значение было до изменения и к чему новое значение может привести в физическом процессе.
Для понимания контекста необходимо ответить на вопрос: что происходило на SCADA-сервере и вокруг него до этой записи?
Отмотаем цепочку назад
Незадолго до обращения к ПЛК на SCADA-сервере отключили Windows Defender — в сценарии это потребовалось для получения учетных данных из памяти. Отключение антивируса само по себе не доказывает воздействие на техпроцесс, но меняет контекст следующего события: запись в контроллер теперь выполняет узел, на котором только что ослабили защиту и работали с учетными данными. Увидеть это позволяет контроль конечных устройств: он фиксирует локальные действия, которые невозможно восстановить только по копии сетевого трафика, и одновременно может остановить вредоносную активность там, где блокировка безопасна для технологического процесса.
На SCADA атакующий попал по RDP. Протокол штатный, запрещать его бессмысленно и даже вредно. Но подключение пришло не по привычному маршруту и породило активность на уже скомпрометированном узле. Сетевой профиль показывает отклонение, журналы — факт аутентификации, телеметрия с конечной точки — действия внутри сеанса. Порознь это три допустимых события, вместе — один этап атаки.
Перед этим атакующий получил доступ к инженерной рабочей станции, провел локальную разведку и добыл учетные данные. Роли двух узлов тут лучше не путать: инженерная станция обслуживает компоненты АСУ ТП, SCADA-сервер ведет диспетчерское управление. Компрометация первого дала удобную точку продвижения, но само воздействие выполнялось со второго.
На инженерную станцию атакующий пришел через административный хост в корпоративной сети. К этому моменту он уже закрепился в домене, повысил привилегии и получил возможность использовать доверенные механизмы аутентификации. В полной демонстрации эта часть включает Kerberoasting, получение учетных данных, злоупотребление службой сертификатов Active Directory и туннелирование трафика. Тут важен результат: у атакующего появились актуальные учетные данные и контроль над узлом, которому разрешалось взаимодействовать с технологическим сегментом.
А началась история с уязвимой системы на периметре. После первоначального доступа атакующий организовал обратный SSH-канал, повысил привилегии и провел разведку в DMZ: искал внутренние сервисы, DNS-сервер и неучтенные узлы, через которые можно двигаться дальше. Затем последовали попытки массовых SMB-подключений, перенос вредоносного файла и закрепление в корпоративной сети. Анализ сетевого трафика выявил направление движения, журналы аутентификации добавили дополнительных деталей, вплоть до имени хоста атакующего, а анализ файла в песочнице подтвердил, что активность свидетельствует о развитии кибератаки.
Если смотреть на финал отдельно, мы видим обычную операцию АСУ ТП. Если собрать предысторию, получается последовательность: компрометация периметра, продвижение по корпоративной сети, захват административного узла, переход в технологическую сеть, доступ к инженерной станции и SCADA, ослабление защиты, получение учетных данных и, наконец, запись технологического сигнала.
Реализация недопустимого события может быть разрешенным действием
В этой цепочке особенно показателен переход из корпоративной сети в технологическую. Атакующий не обязательно пробивает межсетевой экран или использует неизвестную уязвимость на границе. Гораздо чаще он ищет уже существующий путь: административный сервер, систему обновлений, терминальный доступ, рабочее место подрядчика или временное правило, которое уже не актуально.
В нашем сценарии таким мостом стал административный хост, который сам по себе мог иметь понятное эксплуатационное обоснование. Проблема возникла из-за того, что доверие к узлу фактически превратилось в доверие ко всему, что выполняется от его имени. После компрометации домена атакующий использовал разрешенную достижимость и легитимные средства удаленного управления.
Для межсетевого экрана соединение при этом может выглядеть корректно: разрешенный источник, разрешенное назначение, разрешенный сервис. Поэтому одна только сегментация не отвечает на вопрос, кто и зачем воспользовался разрешением. Нужны контроль фактических взаимодействий, сопоставление с профилем узла и возможность связать переход через границу с предыдущими событиями в корпоративной сети.
Это важный сдвиг в модели угроз. Защищать нужно не только границу между IT и OT, но и легитимные маршруты, пересекающие ее, — те самые, которыми пользуются эксплуатация, подрядчики и средства администрирования.
Так все-таки хакер или инженер?
Учитывать технологическое окно полезно, но одного времени недостаточно. Инженер может выполнить аварийную работу вне графика, а злоумышленник — дождаться согласованного окна. Вывод складывается из нескольких контекстов одновременно:
Источник действия. Команда пришла со штатного SCADA-сервера, но перед этим к нему подключился узел, который не входил в обычный профиль взаимодействий.
Идентичность и канал доступа. Важно, под какой учетной записью прошла сессия, откуда она началась и была ли эта цепочка удаленного доступа предусмотрена регламентом.
Предшествующие действия. Отключение защитного средства, работа с учетными данными, туннелирование и продвижение между узлами превращают обычную RDP-сессию в этап атаки.
Технологический смысл. Нужно понимать не только факт обмена, но и тип операции, затронутый сигнал, допустимые источники записи и возможное влияние на процесс.
Контекст изменений. Согласованные работы, заявка, технологическое окно и подтверждение от эксплуатации помогают интерпретации, но не заменяют технических доказательств.
Поэтому отличить инженера от атакующего позволяет не подозрительная команда сама по себе, а связная история: откуда возникла активность, как менялись права и маршруты, какие узлы были затронуты и что непосредственно предшествовало воздействию.
Почему одного источника данных недостаточно
Начнем с копии сетевого трафика. Она позволяет увидеть сканирование, SMB- и RDP-сессии, переходы между сегментами, обращения к контроллеру и саму операцию записи. Глубокий разбор промышленного протокола показывает, что перед нами не просто пакет между двумя IP-адресами, а конкретное действие с технологическим сигналом. При этом пассивный анализ не вмешивается в процесс.
Но трафик не расскажет, что на SCADA отключили Defender, какой процесс работал с памятью и что происходило локально внутри зашифрованной RDP-сессии, потому что это область телеметрии с конечного узла. На SCADA-серверах, операторских и инженерных станциях агент зачастую установить можно, но только после проверки совместимости и согласования с эксплуатацией. На части сетевого и промышленного оборудования такой подход неприменим в принципе.
Там, где агента нет, помогают журналы операционной системы, сетевого оборудования и прикладных систем — если источник действительно ведет нужный аудит и позволяет его безопасно забрать. Тут есть обратная ловушка: не каждое устройство имеет полноценный журнал, не каждое действие журналируется, а сам факт доставки записи еще не делает ее понятным событием ИБ.
Наконец, всем этим данным нужен контекст активов. Чтобы оценить отклонение, необходимо знать, что один адрес принадлежит административному серверу, другой — инженерной станции, третий — SCADA, а четвертый — контроллеру установки, а также какие связи между ними нормальны, какое ПО и версии используются, кто отвечает за узел и какие изменения были согласованы.
Такая инвентаризация не строится одним способом. Пассивный анализ видит только те устройства, которые обмениваются трафиком через контролируемые точки, и молчащий резервный ПЛК, локальный узел или обмен внутри непросматриваемого сегмента могут остаться за кадром. Поэтому данные из трафика дополняются безопасным активным опросом, сведениями с агентов и эксплуатационной документацией. Чем лучше сведены эти источники, тем меньше расхождение между схемой на бумаге и реальной инфраструктурой.
И все равно абсолютной наблюдаемости не существует. Действие может пройти вне точки съема, остаться локальным, использовать неподдерживаемый или зашифрованный протокол либо не журналироваться источником. Но большинство действий оставляет признаки на одном или нескольких уровнях, и задача системы защиты — собрать максимально полную картину, понимая границы покрытия.
Единое решение ускоряет расследование
Смысл комплексного подхода в том, чтобы все источники данных работали на одно расследование и единый контекст. Тогда данные дополняют друг друга и специалисту не приходится сопоставлять разрозненные факты из разных интерфейсов, как в случае с несколькими отдельными продуктами. В нашем сценарии разведку в DMZ, переходы между узлами и команду по промышленному протоколу видно в трафике. Туннелирование, отключение защиты и работу с учетками — в событиях и корреляциях с конечных устройств. Дальше на это ложатся журналы аутентификации, нетипичный маршрут из модели активов и уязвимость на периметре, с которой все началось.
Но простого сбора данных тоже недостаточно. События необходимо нормализовать, сопоставить по времени, узлам, пользователям и сетевым сессиям, а затем связать с ролью оборудования и возможным влиянием на технологический процесс. Когда эта работа выполняется в едином OT-контексте, вместо россыпи срабатываний появляется понятный вектор атаки.
Управление уязвимостями здесь тоже важно, поскольку исходной точкой сценария стала как раз эксплуатация недостатка на периметре. До инцидента сведения об уязвимостях помогают закрывать вероятные пути проникновения и расставлять приоритеты с учетом роли актива, а во время расследования — понять, как атакующий мог получить первоначальный доступ.
Увидеть атаку мало — нужно безопасно отреагировать
В офисной сети зараженный компьютер часто можно быстро изолировать. В АСУ ТП автоматическое отключение SCADA-сервера или блокировка его связи с контроллером способны нарушить управление процессом и оказаться опаснее самого инцидента.
Поэтому реакция начинается с оценки технологического состояния и согласования с эксплуатацией. В одном случае безопаснее сначала отозвать скомпрометированные учетки и сертификаты, закрыть путь со стороны корпоративной сети и изолировать промежуточный узел. В другом потребуется перевод процесса в безопасный режим и только затем изоляция SCADA. Поэтому важно иметь заранее согласованные сценарии реагирования, учитывающие назначение активов, резервирование и возможные последствия каждого действия.
В технологической среде хороша только та мера защиты, риск от которой ниже устраняемого риска.
Это не аргумент против автоматизации. Автоматизировать можно сбор доказательств, объединение событий, приоритизацию и подготовку рекомендаций. Но исполнение действий, способных повлиять на физический процесс, должно учитывать технологический контекст и границы, согласованные с владельцем процесса.
Защита — это процесс
Сценарий начался с уязвимости на периметре, в нем использовались доверенные механизмы корпоративного домена, он прошел через разрешенный канал в ОТ и закончился легитимной операцией промышленного протокола. Это хорошо показывает, почему промышленную безопасность нельзя свести только к мониторингу трафика или только к защите конечных устройств.
Инфраструктура постоянно меняется: появляются новые рабочие станции, подключаются подрядчики, обновляются версии ПО, временно открываются каналы доступа, меняются конфигурации и схемы взаимодействия. Вместе с ними меняется и нормальный профиль сети. Если инвентаризация, модель связей и правила обнаружения не обновляются, вчерашняя карта быстро превращается в еще одну слепую зону.
Поэтому защита строится как цикл. Сначала нужно понимать активы, связи и допустимые взаимодействия, затем — находить уязвимости и слабости конфигурации, оценивать их с учетом достижимости и роли узла, и после этого — наблюдать сеть, конечные точки и события, расследовать отклонения, выбирать безопасную реакцию и проверять, действительно ли закрыт путь атаки. А затем проходить цикл снова, потому что к этому моменту инфраструктура уже могла измениться.
Когда весь цикл собран в одном продукте
До этого места мы описывали не конкретный программный продукт, а набор возможностей, без которых сквозная защита промышленного объекта не складывается. Именно такой набор модулей предоставляет шестое поколение PT ISIM. Управление активами формирует единый OT-контекст, а управление уязвимостями оценивает слабые места с учетом достижимости и критичности оборудования. Сетевые взаимодействия и промышленные протоколы разбирает Industrial NTA, локальную активность на поддерживаемых узлах — Industrial EPP. SIEM-возможности закрывают оставшиеся слепые зоны. Все это работает в одной консоли и на одну задачу — восстановить путь атакующего и помочь выбрать безопасную реакцию.
При этом наличие всех компонентов само по себе еще не гарантирует результат. Нужны корректные точки съема трафика, подключенные источники, актуальная модель активов, настроенные правила, согласованные сценарии реагирования и специалисты, понимающие одновременно кибератаку и технологический процесс.
Следующий шаг — автоматическое расследование
Даже если все данные собраны в одной системе, значительная часть аналитической работы все еще остается за человеком: отделить связанное от случайного, восстановить последовательность, определить затронутые активы, оценить технологический риск и выбрать дальнейшие действия.
Поэтому дальше защита промышленных сетей развивается не в сторону большего числа событий и правил. Точка роста — помощники оператора, которые предложат гипотезу, соберут хронологию, объяснят, почему события связаны, и подсветят пробелы в данных. Следующий логичный этап — автоматический расследователь, который строит доказательную цепочку, а человеку оставляет решения, особенно там, где реакция может затронуть физический процесс.
Возвращаясь к событию, произошедшему в 14:23: запись со SCADA в ПЛК могла выглядеть штатно, только пока мы смотрели на нее изолированно. Атака проявилась не в одном пакете, процессе или журнале — она проявилась в связях между ними. Восстановить эти связи и значит перейти от наблюдения за технологической сетью к реальному контролю ее защищенности. А как вы отличаете незапланированные работы от инцидентов и объединяете данные из нескольких классов решений? Делитесь в комментариях.