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