Безопасность
AWS заявляет, что инструменты безопасности ИИ должны оцениваться по результатам, а не по количеству оповещений
AWS призывает команды безопасности оценивать системы ИИ по подтвержденным находкам, нагрузке от ложных срабатываний, сэкономленному времени и результатам инцидентов, поскольку агенты переходят к триажу уязвимостей, обзору кода и реагированию.
Автор: Лео У ·
СИЕТЛ. Amazon Web Services призывает руководителей по безопасности оценивать инструменты искусственного интеллекта по подтвержденному снижению рисков и операционным результатам, а не по объему генерируемых ими предупреждений, поскольку команды начинают использовать агенты для триажа уязвимостей, тестирования на проникновение, моделирования угроз, реагирования на инциденты и проверки кода. Предупреждение касается хорошо известного режима сбоев: автоматизация, которая работает быстрее, заставляя защитников тратить больше времени на доказательство того, что её выводы неверны.
Продукты в области безопасности всегда могли создавать показатели активности, которые выглядели впечатляюще. Система ИИ может просканировать больше репозиториев, составить больше выводов и обобщить больше событий, чем команда людей. Ни одно из этого не доказывает, что она обнаружила важные уязвимости или сократила время инцидента. Полезная система оценки должна связывать результаты модели с подтвержденными доказательствами, исправлением и снижением рисков.
Ложные срабатывания — это операционная стоимость
Каждая ложная тревога тратит время на проверку и ослабляет доверие к следующему предупреждению. Стоимость увеличивается, когда агент создает убедительные объяснения, которые делают низкокачественные результаты выглядящими достоверными. Команды должны отслеживать точность по классам уязвимостей, время, необходимое для проверки результата, и долю находок, которые приводят к принятому исправлению. Одна общая цифра точности скрывает, где система небезопасна или неэффективна.
Важно и полнота. Инструмент, который сообщает только о очевидных проблемах, может поддерживать высокую точность, пропуская при этом пути атаки, соединяющие несколько слабых сигналов. Тестирования красной командой и внедренные уязвимости предоставляют известный набор тестов, но оценка в производственной среде также должна сравнивать результаты агента с инцидентами, отчетами по баунти за ошибки и последующими человеческими открытиями. Пропущенная находка часто имеет большее значение, чем шумная.
Агенты создают вторую проблему измерения, потому что они действуют. Система, которая открывает тикеты, изменяет элементы управления или редактирует код, нуждается в аудиторском следе, связывающем каждое действие с доказательствами и разрешениями. Скорость выполнения недостаточна. Команды должны измерять несанкционированные попытки, частоту откатов, обходы политики и время, необходимое для восстановления произошедшего.
AWS описал автономных агентов как сдвиг в области безопасности, сопоставимый с переходом в облако, потому что они аутентифицируют пользователей и выполняют многоступенчатые рабочие процессы. Это сравнение полезно, если организации помнят урок облака: возможности появились раньше, чем многие компании построили консистентную идентификацию, ведение журналов и управление правами. Развертывание агентов не должно повторять эту последовательность.
Производственное равенство изменяет результат
Модель, протестированная на чистом бенчмарке, будет вести себя иначе, когда получает шумные журналы, неполные заявки и враждебный текст из окружающей среды. Внедрение подсказок может произойти через электронную почту, задачу в репозитории или веб-страницу, которую агент читает во время расследования. Оценка должна воспроизводить доступ к инструментам, идентификацию и потоки данных достаточно точно, чтобы те же режимы сбоев были возможны.
Это не значит давать тестовому агенту неограниченные производственные учетные данные. Песочницы, канареечные аккаунты и режимы пробного запуска могут сохранять реалистичный контекст при ограничении воздействия. Важный момент заключается в том, чтобы тестировать всю систему, включая извлечение информации, инструменты, соблюдение политики и одобрение человеком, а не рассматривать языковую модель как продукт.
Лидеры в сфере безопасности также должны разделять помощь и автономию. Модель, которая суммирует инцидент, может быть оценена на точность фактов и сэкономленное время. Агент, который блокирует трафик или меняет учетные данные, требует более высокого порога доказательств, явного отката и более узкой зоны действия. Использование одного показателя доверия для того и другого скрывает различие в последствиях.
Сравнения поставщиков требуют стабильных рабочих нагрузок. Модели и облачные сервисы часто меняются, поэтому результат должен фиксировать версию, подсказки, конфигурацию инструмента и дату. Командам следует воспроизводить репрезентативные случаи перед сменой поставщика или принятием автоматического обновления. В противном случае контроль безопасности может ухудшиться, не зная, какой компонент изменился.
Лучшее развертывание ИИ для обеспечения безопасности может генерировать меньше заметных предупреждений, потому что оно группирует дубли, приоритизирует проверенные пути и автоматизирует сбор доказательств с низким риском. Это может выглядеть менее активно на панели управления, при этом делая команду более эффективной. Оценка должна вознаграждать отсутствие потраченной впустую работы, а не видимость скорости машины.
Темы: AWS, ИИ в области безопасности, ложные срабатывания, реагирование на инциденты, оценка