“Когда ИИ обретает тело, появляется поверхность для атак”

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

До написания книги я готовил облачную инфраструктуру, работающую в Китае и США, к аудитам соответствия кибербезопасности и к Multi-Level Protection Scheme — обязательному режиму оценки безопасности в Китае, который определяет, разрешена ли работа системы. Эта работа научила меня уроку, который я применяю в каждом разговоре об ИИ. Нельзя защитить то, что не видишь, а покупатель редко видит внутренности. Демонстрация делает хуже. Она показывает одну задачу, выполненную один раз, в условиях, выбранных поставщиком. Ничего из того, что должна оценить команда безопасности, на экране нет.

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

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

Оценивайте эти системы по пяти вопросам: происхождение, доступ, целостность, доказательства и подотчетность. Вот что означает каждый.

Вопрос оценки №1: Происхождение

Что внутри и кто это контролирует? Гуманоид — это сборка приводов, лидаров, аккумуляторных блоков, модулей сочленений и контроллеров, большинство из которых поступает из цепочки поставок, которую покупатель никогда не проверял, и каждый работает на прошивке, которую покупатель не может прочитать. Команды разработчиков ПО уже прошли через эту борьбу, поэтому software bill of materials стала стандартной практикой. Отсутствие прозрачности создает системный риск. Воплощенные системы повышают ставки, потому что прошивка теперь живет в десятках движущихся частей. Риск не зависит от того, китайский, американский, немецкий или японский робот. Он зависит от того, какую часть системы покупатель может видеть: аппаратное обеспечение, прошивку, пути удаленного доступа и отношения по обслуживанию, стоящие за ними. Китай устанавливает больше промышленных роботов, чем любая другая страна, и находится в центре цепочки поставок аккумуляторов, а также части базы поставок лидаров и машинного зрения, на которые опираются эти системы. Лидар (Light Detection and Ranging) использует импульсные лазерные лучи для трехмерного картирования окружающей среды; машинное зрение отвечает за оптический контроль и наведение. Большая часть этой родословной восходит к поставщикам, с которыми у вашей команды нет отношений. Это аппаратная и прошивочная версия руководства NIST по цепочке поставок, написанного для управления рисками третьих сторон, за исключением того, что компонент имеет двигатели. Требуйте спецификацию аппаратного обеспечения и прошивки (hardware and firmware bill of materials), а затем используйте ее. Отмечайте неподписанную прошивку. Определите, какой поставщик имеет право на обновление каждой части. Требуйте способ проверки целостности и рассматривайте любой компонент, который вы не можете идентифицировать, как неуправляемый.

Вопрос оценки №2: Доступ

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

Вопрос оценки №3: Целостность

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

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

Вопрос оценки №4: Доказательства

Правдивы ли заявления? Вы не нашли независимого аудита полевой производительности воплощенного ИИ, поэтому показатели времени безотказной работы и надежности поступают от поставщика. Вы покупаете заявление, а не послужной список. Требуйте независимо подтвержденное время безотказной работы, частоту вмешательств и историю инцидентов от названного развертывания, которому вы можете позвонить. «Передовой» — это не контроль.

Вопрос оценки №5: Подотчетность

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

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

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

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

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

Эта статья опубликована в рамках сети экспертных участников Foundry.
Хотите присоединиться?