От данных к действиям: сокращает ли ИИ путь атаки на промышленный процесс?

Статья подготовлена на основе двух научных публикаций и аналитического материала:

Adversarial Machine Learning in Industrial IoT: A Systematic Review of Attack Realism, Defense Trade-Offs, and Deployment Gaps — обзор атак на промышленное машинное обучение и методов защиты.

AAIGF-E: An AI and Agentic Intelligence Governance Framework for Electric-Sector Smart-City Infrastructure — система мер контроля для ИИ в электроэнергетике и её сценарная оценка.

Taiwan Should Set the Standard for Industrial AI Security — предложения по сертификации и безопасному внедрению промышленных ИИ-агентов.

Доступ выдали агенту. Полезно ли это атакующему?

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

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

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

Поэтому хочется копнуть глубже: Может ли ИИ сократить путь от воздействия на данные до воздействия на оборудование, если ему делегированы полномочия без достаточных независимых ограничений?

При этом промышленность и до ИИ не управлялась исключительно человеком с рукой на кнопке. Контроллеры, SCADA и распределённые системы управления давно выполняют автоматические операции. Подмена измерений, изменение логики контроллера и передача оператору ложной информации тоже не появились вместе с языковыми моделями. Эти классы угроз давно описаны, например, в NIST SP 800-82r3.

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

Выбранные материалы позволяют пройти этот путь последовательно. Adversarial Machine Learning in Industrial IoT рассматривает атаки на промышленное машинное обучение и ограничения исследований. AAIGF-E предлагает архитектуру контроля и проверяет её на сценариях отказов. Публикация Taiwan Should Set the Standard for Industrial AI Security обсуждает, как связать безопасность промышленных агентов с сертификацией, закупками и допуском к эксплуатации.

Adversarial Machine Learning in Industrial IoT: как сбить промышленную модель с толку

В статье разобраны 50 исследований за период 2019–2026 годов. Область рассмотрения достаточно широкая:

• обнаружение вторжений;
• диагностика оборудования;
• контроль технологических процессов;
• оценка состояния энергосистем;
• распределённое обучение.

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

Семь категорий атак и несколько разных предпосылок

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

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

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

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

Красивое падение точности ещё нужно доставить до объекта

Авторы пишут, что из 28 исследований атак половина использует исключительно условия white-box, где атакующему доступны внутренние сведения о модели, необходимые для построения воздействия. Это полезный способ проверить устойчивость, но в реальной системе такой доступ ещё нужно получить или обоснованно предположить. Также не стоит забывать, что для black-box могут понадобиться многочисленные запросы, наблюдение за ответами, подходящие данные или возможность повторять воздействия в экспериментальной среде.

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

Adversarial Machine Learning in Industrial IoT полезна именно вниманием к этому разрыву. SWaT и WADI дают материал о физических процессах и связях датчиков с исполнительными устройствами. NSL-KDD и UNSW-NB15 в первую очередь служат задачам обнаружения сетевых вторжений и не воспроизводят весь контекст управления производством. Хороший результат на одном типе данных нельзя без проверки переносить на другой.

При этом в статье есть и работы с реальными контроллерами и полунатурными стендами. Например, в исследовании [66] из библиографии используется реальный ПЛК Siemens, управляющий моделируемым процессом с четырьмя резервуарами. При подготовке атакующих данных учитываются допустимость промышленного протокола и сохранение исходного вредоносного воздействия. Однако проблема в том, что условия исследований, модели угроз и метрики слишком различаются для универсального вывода об эффективности атак.

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

Защита тоже должна помещаться в технологический процесс

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

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

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

Из Adversarial Machine Learning in Industrial IoT следует важное ограничение - техническая уязвимость моделей показана в разных условиях, но её вклад в риск конкретного объекта определяется доступом атакующего, физикой процесса и местом модели в системе.

Где заканчивается ответ модели и начинается действие

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

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

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

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

Действительно ли атакующему становится проще?

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

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

С компетенциями похожая история. Для попытки текстовой манипуляции агентом может потребоваться меньше специальных знаний, чем для разработки воздействия на промышленную ML-модель. Однако вызвать странный ответ, добиться исполнения команды и воспроизводимо получить определённое физическое последствие — задачи разной сложности. Для последней могут понадобиться знания процесса, защит и текущего режима работы.

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

Где должна прерваться цепочка

В AAIGF-E: An AI and Agentic Intelligence Governance Framework for Electric-Sector Smart-City Infrastructure предложен AAIGF-E — фреймворк управления ИИ и агентными системами в электроэнергетике. Он содержит 111 мер контроля в 11 предметных областях и охватывает семь этапов жизненного цикла:

управление → проектирование → внедрение → проверка и допуск → наблюдение → реагирование → восстановление.

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

Полезная особенность AAIGF-E — двойное описание каждой меры. Одно объясняет её смысл с точки зрения управления рисками ИИ, другое переводит этот смысл на язык электрических сетей, диспетчеризации и OT. Требование «контролировать входные данные» превращается в проверку конкретной телеметрии, её времени, допустимых значений и согласованности.

Авторы сопоставляют меры с NIST AI RMF, ISO/IEC 42001, NERC CIP, ISA/IEC 62443 и MITRE ATLAS. При этом сами подчёркивают, что наличие соответствия в таблице не доказывает выполнение стандарта, получение сертификата или эффективность защиты. Эти источники имеют разные назначения и нормативный статус.

Архитектура ориентирована на электроэнергетику Северной Америки. Для другого сектора или юрисдикции потребуются собственные инженерные ограничения и проверка применимости требований.

Что именно проверяли

В работе рассмотрены три сценария:

• манипуляция входными данными
• несанкционированные действия агента
• незаметный дрейф модели.

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

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

Сценарий A: данные подменили, управление поверило

ИИ управляет распределёнными энергоресурсами — например, распределённой генерацией и накопителями. На вход поступает подменённая телеметрия. Система формирует команды, которые выводят параметры напряжения за допустимые пределы, а аномалия обнаруживается с задержкой.

В AAIGF-E предусмотрены несколько точек защиты. Источники данных должны быть согласованы заранее. На входе проверяются формат, диапазоны значений, временные метки, полнота и согласованность. Модель должна проходить проверку устойчивости к манипуляциям и нетипичным режимам. Во время эксплуатации необходимо отслеживать изменения входов/выходов и отклонения результатов. При инциденте — иметь возможность изолировать влияние ИИ и вернуться к проверенному варианту работы.

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

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

Сценарий B: поручили разобраться, агент пошёл исправлять

Агенту поручают исследовать аномалию. Он самостоятельно выполняет изменения в OT-сегментах без необходимого согласования. Изменения приводят к срабатыванию защит и незапланированному отделению части сети.

Ключевая мера здесь “OP-009” — проверка и разрешение команд на границе между ИИ и OT. Запрос должен пройти контроль полномочий, области действия, инженерных ограничений, защитных блокировок и необходимых согласований. Этот механизм дополняют ограничение привилегий, сегментация, возможность вмешательства оператора и совместное реагирование кибербезопасности и эксплуатационных служб.

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

Человеческое подтверждение тоже должно быть реальным контрольным действием. Нужны понятное обоснование, сведения о последствиях и возможность проверить исходные данные. Кнопка «Согласовать», под которой написано только «ИИ рекомендует», выглядит довольно слабым инженерным барьером.

Именно в этом сценарии авторы рассматривают незакрытый путь атаки через содержимое данных. Мера “DI-006” проверяет технические свойства входа: схему, значения, время, полноту и согласованность. Но текст, который проходит эти проверки, всё ещё может искажать понимание задачи агентом или создавать ложное впечатление о выданном разрешении.

“OP-009” ограничивает исполнение команды, однако сам по себе не гарантирует достоверности обоснования, которое привело к этой команде. Более того, искажённое обоснование может прочитать человек, от которого требуется согласование. В такой ситуации человек становится ещё одним участником цепочки воздействия.

Авторы прямо признают этот остаточный риск в версии AAIGF-E v1.0. Проверка происхождения и правдоподобия содержимого до его влияния на задачу и контекст разрешений предложена как направление дальнейшей работы.

Сценарий C: никто не атаковал, а доверять уже нельзя

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

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

AAIGF-E требует заранее определить критерии приемлемости, проверять редкие и пограничные режимы, документировать ограничения модели и наблюдать за дрейфом. Выход за установленные границы должен запускать предусмотренные действия: дополнительную проверку, ограничение использования, повторную оценку или приостановку влияния ИИ.

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

Что добавляет AAIGF-E

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

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

Однако возникает вопрос: как понять, что система соответствует применимым требованиям? Кто отвечает за этот праздник автоматизированной жизни и, самое главное, готов подтвердить, что всё ок?

Как сделать ограничения условием допуска

В Taiwan Should Set the Standard for Industrial AI Security авторы предлагают использовать существующую основу сертификации полупроводникового оборудования для проверки промышленных ИИ-агентов.

Отправная точка — SEMI E187 и связанная с ним тайваньская схема сертификации. По описанию авторов, она уже связывает требования к кибербезопасности оборудования, независимые испытания и закупочные условия. Авторы предлагают дополнить её отдельным профилем безопасности агентов; в материале этот профиль рассматривается как предложение к разработке. Однако материал посвящён прежде всего Тайваню и полупроводниковой отрасли, то есть перенос предложений на другие производства потребует адаптации.

Проверять конкретную конфигурацию

Авторы предлагают оценивать модель вместе со средой исполнения, политиками, подключёнными навыками, инструментами, учётными данными и областью полномочий. Такое сочетание определяет, на что агент действительно способен.

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

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

Отдельно разрешать применение на объекте

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

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

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

Контролировать изменения и поведение после внедрения

Третий элемент предложения — постоянная оценка после допуска:

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

При выходе за проверенные условия предлагается автоматически приостанавливать и изолировать агента.

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

Проверять, как агент будет отказывать

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

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

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

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

Ценность предложения авторов — в связи между техническими ограничениями и условиями внедрения. Требования можно проверять при закупке, при подключении к объекту и после изменения возможностей. Но результативность именно предложенного профиля ещё предстоит установить, так как сам аналитический материал такой проверки не содержит.

Так становится ли путь атаки короче?

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

Однако ни один из трёх материалов не устанавливает, насколько в среднем внедрение ИИ упрощает атаку на промышленный объект. Adversarial Machine Learning in Industrial IoT обобщает разнородные эксперименты, AAIGF-E проверяет архитектуру на сценариях, статья Taiwan Should Set the Standard for Industrial AI Security предлагает механизм сертификации. Сравнительного измерения трудоёмкости одинаковой атаки на один объект до и после внедрения ИИ нет.

Поэтому оценивать сложность атаки нужно на конкретной системе, прослеживая всю цепочку:

источник под влиянием атакующего → вход ИИ → изменение решения → использование полномочий → проверка исполнения → воздействие на процесс

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

Практический вопрос перед внедрением получается вполне конкретным: А что сможет произойти с оборудованием, если ИИ получит ложные данные, ошибётся или неверно поймёт поручение?

В ответе нужны допустимые действия, независимые ограничения, время реакции и проверенный порядок работы без ИИ.

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