Почему десятилетиями известные кибератаки всё ещё эффективны против современных AI-систем

Несмотря на активное обсуждение продвинутых угроз и атак, управляемых искусственным интеллектом (ИИ), множество успешных киберинцидентов по-прежнему происходят из-за методов, существующих уже десятилетия.

Так, уязвимости, связанные с SQL-инъекциями (внедрением вредоносного SQL-кода), известны более 20 лет. Однако, по данным вице-президента по продуктам компании Wallarm, при первичной оценке более 20% организаций по-прежнему оказываются уязвимыми к ним, и этот метод продолжает составлять значительную долю современных киберугроз.

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

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

Наслоение технологий и устаревший код

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

Компании активно разрабатывают программные интерфейсы (API), внедряют микросервисы и интегрируют ИИ-инструменты в свои системы. Эти изменения способствуют росту и улучшению функциональности, но одновременно увеличивают потенциальную поверхность для атак.

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

Пробелы в ответственности создают реальные риски

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

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

В результате некоторые API никогда не подвергаются полной оценке или постоянному мониторингу, и известные классы уязвимостей сохраняются в них долгое время после того, как индустрия считает их «решёнными».

Поверхность атаки систем ИИ: старые проблемы в новой упаковке

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

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

Каждый из этих компонентов построен на архитектурных паттернах, существовавших за годы или даже десятилетия до появления генеративного ИИ. Это означает, что поверхность атаки ИИ-систем подвержена тем же классам уязвимостей, с которыми специалисты боролись всегда. Конечные точки вывода (inference endpoints) являются API-интерфейсами и наследуют те же проблемы аутентификации, авторизации, ограничения скорости и валидации ввода, что и вся экосистема API.

Конвейеры генерации с дополнением извлекают данные из баз, что подразумевает актуальность SQL-инъекций и проблем с контролем доступа. Инструменты агентов выполняют запросы к внутренним и внешним системам, что вновь актуализирует подделку запросов на стороне сервера (server-side request forgery) и внедрение команд (command injection) в новых контекстах.

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

Команды, сосредоточенные исключительно на новых ИИ-специфичных угрозах, оставляют более обширную и привычную поверхность атаки незащищённой. Злоумышленнику не обязательно разрабатывать хитрую инъекцию запроса, если API вывода имеет сломанную авторизацию на уровне объектов или некорректно настроенную политику CORS (Cross-Origin Resource Sharing). Путь наименьшего сопротивления по-прежнему лежит через основы.

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

Безопасность как бизнес-решение

Определение приоритетов в области безопасности требует перевода технических уязвимостей в плоскость их влияния на бизнес. Уязвимость класса SQL-инъекций общеизвестна, но её значимость зависит от того, какие данные она раскрывает и насколько легко до них добраться. Без такого контекста приоритеты устанавливаются по принципу «что громче», то есть обычно «что новее».

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

Старые риски не исчезают

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

Наиболее важны три действия:

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

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

Твитнуть