Завод нельзя защищать по схеме, которая устарела вчера

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

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

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

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

Нельзя защищать контур, которого не видно

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

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

Для офисной ИТ-инфраструктуры такие расхождения тоже опасны. Для АСУ ТП они критичнее, потому что за сетевым взаимодействием стоит физический процесс. Контроллер управляет оборудованием, SCADA передает команды и получает данные, инженерная станция может изменить программу ПЛК, а сбой связи или некорректная команда способны повлиять на производство.

«Первый вопрос к защите АСУ ТП - не какие продукты установлены, а что предприятие фактически видит в технологическом контуре. Если перечень устройств, связей, версий ПО и конфигураций собирается вручную только перед проверкой или после сбоя, это не контроль, а восстановление картины задним числом», - говорит Иван Бурмистров, пресейл-инженер UDV Group.

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

Документация не успевает за эксплуатацией

В промышленной инфраструктуре изменения часто появляются легально. Подрядчик выполняет работы. Инженер корректирует настройки. Площадка модернизирует участок. Сетевая команда добавляет связь. Автоматчики временно подключают устройство для диагностики. После ремонта меняется оборудование или версия ПО.

Каждое изменение по отдельности может быть нормальным. Но если оно не фиксируется в единой картине, контур постепенно уходит от документации. Через несколько месяцев предприятие уже не может быстро объяснить, почему конкретный узел общается с корпоративной сетью, когда появилась новая версия ПО, кто изменил настройку оборудования и почему проект ПЛК отличается от сохраненного архива.

Особенно опасны изменения, которые не приводят к немедленному сбою. Новое соединение может не мешать производству. Уязвимая версия ПО может работать годами. Измененная конфигурация может проявиться только при аварийном режиме. Аномальное поведение контроллера может выглядеть как штатный обмен по разрешенному протоколу.

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

Проверка должна отвечать на вопросы, а не создавать отчеты

Руководителю не нужно разбираться во всех промышленных протоколах, чтобы понять, есть ли в АСУ ТП слепые зоны. Достаточно попросить команды показать актуальные данные.

Есть ли полный перечень устройств в технологической сети. Какие версии ПО установлены на объектах автоматизации. Как служба ИБ узнает о новом устройстве. Какие уязвимости известны для текущих версий ПО и что уже устранено. Какие данные останутся после работ подрядчика. Можно ли показать фактические соединения между технологическими сегментами и корпоративной сетью. Как фиксируются изменения настроек оборудования. Какие сведения будут доступны через месяц после инцидента.

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

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

В АСУ ТП время почти всегда связано с производственными потерями.

Сеть нужно видеть без вмешательства в процесс

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

Но промышленный мониторинг нельзя строить так же, как в офисной ИТ-среде. Активное сканирование, агрессивные запросы или неосторожные проверки могут повлиять на старое оборудование, промышленные контроллеры и технологический процесс. Поэтому для действующего производства важен неинвазивный подход: анализ копии трафика, пассивное наблюдение, безопасные read-only-команды там, где они допустимы, и согласование любых проверок с эксплуатацией.

Даже канал передачи копии трафика должен быть защищен. Если SPAN-порт или сенсор мониторинга подключены неаккуратно, сам контур наблюдения может стать новой точкой риска. Мониторинг не должен создавать путь для несанкционированного доступа или подмены данных.

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

Конфигурации опасны тем, что меняются незаметно

Многие риски АСУ ТП не выглядят как атака. Изменились настройки оборудования. Обновилась версия ПО. Появилась уязвимость в используемом компоненте. Подрядчик внес правку. Инженер поменял параметр. Старое устройство осталось в сети после модернизации. Ни одно из этих событий не обязательно приводит к немедленной остановке.

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

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

Там, где активное сканирование опасно, нужны безопасные методы. Например, пассивный fingerprinting по признакам сетевого обмена или read-only-команды, которые не изменяют состояние устройства. В промышленной среде способ получения данных так же важен, как сами данные.

Аномалия может быть важнее сигнатуры

Классическая защита часто ищет известные признаки атаки. Это нужно, но для АСУ ТП недостаточно. Контроллер может продолжать использовать штатный протокол, но изменить характер взаимодействий с другими компонентами. Устройство может начать общаться с новым узлом. Частота запросов может стать необычной. Время, направление или состав обмена могут отличаться от привычной модели.

Такое поведение не всегда совпадает с известной сигнатурой. Но для технологического контура оно может быть важным сигналом. Особенно если речь идет о ПЛК, который раньше работал предсказуемо, а теперь меняет сетевой профиль или начинает участвовать в связях, которых раньше не было.

Поведенческий анализ в АСУ ТП ценен именно потому, что промышленные системы обычно более стабильны, чем офисная ИТ-среда. Набор узлов, маршрутов, команд и протоколов ограничен. Если эта стабильная картина меняется, изменение нужно объяснить.

«Для промышленного контура важно выявлять не только известные атаки, но и отклонения от нормального поведения. ПЛК может продолжать работать по штатному протоколу, но изменить характер обмена, частоту обращений или связи с другими узлами. В АСУ ТП такая аномалия может быть ранним признаком инцидента, даже если классическая сигнатура еще не сработала», - отмечает Иван Бурмистров, пресейл-инженер UDV Group.

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

Проекты ПЛК должны быть под управлением версий

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

На практике с этим часто возникают проблемы. Проекты лежат на инженерных станциях, у подрядчиков, в сетевых папках и локальных архивах. Файлы называются final, last, new или backup, но их статус не подтвержден. В контроллере может выполняться версия, которая отличается от сохраненного проекта. А при сбое становится непонятно, к какому состоянию можно безопасно вернуться.

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

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

Инцидент состоит из цепочки, а не из одного события

В АСУ ТП редко бывает один сигнал, который сразу объясняет все. Изменение конфигурации, новое сетевое соединение, появление уязвимого ПО, аномальный обмен ПЛК и срабатывание средства защиты могут быть частями одного инцидента. Причем эти события могут происходить в разное время и попадать в разные системы.

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

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

Эта ретроспектива особенно важна через месяц после инцидента. В момент события команда может работать в авральном режиме и фиксировать не все. Если данные не сохраняются, расследование быстро теряет опору. Через несколько недель остаются только воспоминания, переписка и неполные журналы.

Несколько площадок нельзя контролировать как отдельные миры

У крупных промышленных предприятий АСУ ТП часто распределена по нескольким площадкам. Локальные команды знают свои объекты, свое оборудование, свои особенности и свои проблемы. Но на корпоративном уровне нужна сводная картина: какие активы есть, где появились критичные отклонения, какие уязвимости не устранены, какие версии ПО используются, какие события повторяются на разных площадках и где нарушаются единые требования.

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

Для объектов КИИ этот вопрос становится еще чувствительнее. Там важны не только техническая видимость и скорость реакции, но и подтверждение выполнения требований. Если для каждой проверки данные приходится заново собирать у нескольких подразделений, это означает, что актуальной картины нет.

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

Разовая диагностика быстро устаревает

Даже качественное обследование АСУ ТП имеет срок годности. Сегодня предприятие получило фактическую картину, сравнило ее с проектной документацией, нашло неизвестные устройства, лишние связи и уязвимые версии ПО. Завтра подрядчик подключил оборудование. Через неделю прошел ремонт. Через месяц обновили конфигурацию. Через квартал модернизировали участок.

Если после этого контроль не продолжается, предприятие снова возвращается к устаревшей картине. Поэтому разовая диагностика должна быть только первым этапом.

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

«Разовая диагностика АСУ ТП быстро устаревает. Уже после первого ремонта, модернизации или подключения подрядчика фактическая картина может измениться. Поэтому защита должна строиться как постоянный контроль: с эталонными значениями, автоматическим выявлением отклонений, сопоставлением событий из разных источников и хранением данных для расследования», - подчеркивает Иван Бурмистров, пресейл-инженер UDV Group.

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

Своих сил может не хватить, и это нормально

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

В реальности такие знания часто распределены между разными подразделениями. Автоматчики понимают технологический процесс, но не всегда видят ИБ-риски. Сетевая команда знает маршруты и оборудование, но не всегда понимает логику ПЛК. ИБ умеет работать с инцидентами и требованиями, но может зависеть от службы автоматизации в вопросах фактического состояния контура.

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

Но подрядчик не должен становиться новым черным ящиком. Предприятие все равно должно понимать, какие данные собираются, какие отклонения считаются критичными, кто принимает решения и как контроль будет сопровождаться после внедрения.

Защита АСУ ТП - это контроль изменений

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

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

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

Если ответ есть, предприятие управляет риском. Если ответа нет, оно узнает о проблеме в тот момент, когда оборудование уже остановилось.