Достижения в области передового ИИ создали мир, где эксплуатация опережает защиту. Среднему предприятию требуется от 32 до 43 дней на установку исправлений, но среднее время эксплуатации уязвимости составляет 10 часов. Эта асимметрия порождает вопросы о том, как предприятия могут доверять автономному ИИ, работающему повсеместно в их средах. Как я упомянул на сцене TechCrunch Disrupt на прошлой неделе, безопасность на скорости машины означает, что ИИ ускоряет исправление так же быстро, как и обнаружение. Ниже представлено расширенное изложение этого обсуждения.
Асимметрия между обнаружением и исправлением
Асимметрия между атакующими и защитниками усугубляет проблему исправлений. Традиционные модели безопасности сортируют по степени серьезности с помощью ручных процессов, что создает недельные и месячные очереди. Но продвинутые модели позволяют атакующим объединять уязвимости низкой и средней степени серьезности — которые по замыслу остаются незамеченными — для создания проблемы высокой степени серьезности. Например, уязвимость межсайтового скриптинга, перехват сессионного cookie и утечка базы данных по отдельности регистрируются как инциденты средней степени серьезности. В виде цепного эксплойта межсайтовый скрипт дает атакующему точку входа в браузер, который они используют для перехвата сессионного cookie, что позволяет аутентифицироваться как пользователь, что дает им доступ к базе данных с полным чтением производственных данных.
Проблема подсказок
Напряжение в безопасности на скорости машины заключается в том, что обнаружение чрезвычайно точно, но исправление все еще отстает. Тесты, которые мы провели на CyberGym, показали 95-процентную точность обнаружения сложных ошибок, связанных с последовательностью событий. Механизм обнаружения работает. Но более чем в 98% случаев передовые модели отказываются выполнять подсказки по исправлению, потому что их встроенные защитные ограждения неправильно классифицируют 76-99% прямых подсказок кода, связанных с уязвимостями, как ложные срабатывания. Когда они все же пытаются исправить, 55% исправляют основную проблему, но упускают второстепенную, и 40% исправлений нарушают производственный код. Одних подсказок недостаточно, чтобы исправить асимметрию, потому что показатели обнаружения высоки, но точность исправления низка.
Устранение инженерного разрыва
Одних подсказок с помощью продвинутых моделей недостаточно. Ответом является интегрированная система, которая объединяет многоагентную оркестрацию, внедрение контекста, валидацию в песочнице и итеративное исправление. Точность этой системы обеспечивается информацией из графа контекста, инфраструктуры песочницы, конвейера валидации и опыта реализации примитивов безопасности.
Три достижения для преодоления пропасти
Инженерный прогресс требует, чтобы технология вышла за рамки трех ограничений. Система должна перейти от участия человека в цикле к автономной и непрерывной работе. Она не может просто объяснять сортировку на простом английском – она должна создавать долговечные проблемы с решениями, подкрепленными доказательствами. Она не может быть системой «Волшебника страны Оз», работающей на передовой модели.
Путь вперед — это многоагентная система с управлением идентификацией и доступом для каждого действия и сеанса и применением Cedar для детализированных политик доступа. Система сжимает сигналы в действия, управляемые IAM и Cedar, а не просто в вызовы моделей.
5 ингредиентов для надежной многоагентной системы
Пять проектных решений создают надежную многоагентную систему
- Кибер-ориентированные модели. Первый компонент — использование нескольких кибер-ориентированных моделей, оптимизированных для обнаружения уязвимостей.
- 5-этапная система. Затем создайте 5-этапную систему, включающую разведку, моделирование угроз, охотника, валидацию и исправление.
- Песочница с нулевым исходящим трафиком. В-третьих, убедитесь, что песочница представляет собой microVM с нулевым исходящим трафиком, без доступа в интернет, без роли IAM и с вызовом с чистого листа.
- 2-уровневая валидация. Проверяйте, запуская статический анализ L1 и динамическое тестирование безопасности L2 внутри песочницы. Требуйте подтверждения срабатывания перед закрытием.
- Богатый контекст. Наконец, множитель точности достигается за счет подачи в систему контекста инфраструктуры, приложения и бизнеса.
Эта система создает непрерывный цикл, который обнаруживает, расставляет приоритеты, проверяет и исправляет таким образом, что каждый раз дает один и тот же ответ доказуемым образом, масштабируясь до тысяч репозиториев.
3 агента, смоделированных по образцу ролей в области безопасности
Агент приоритизации мыслит как аналитик threat intel. Он прочесывает граф контекста, оценивает близость к вашим ключевым активам, выполняет классификации и смотрит на влияние на бизнес.
Агент валидации мыслит как оператор red team. Он отображает пути атак, оценивает радиус поражения, проверяет компенсирующие меры контроля, чтобы дать трехзначный ответ: эксплуатируемо, неопределенно или не эксплуатируемо.
Агент исправления мыслит как инженер по безопасности. Он исправляет на основе подтвержденного эксплойта. Он исправляет шаблон, а не одну строку кода. Он затрагивает каждую точку. Он предоставляет набор тестов в песочнице вместе с pull request.
Эти агенты работают вместе в общем состоянии, используя долговечные записи. Каждый выполняет свою ограниченную роль и записывает обратно.
Контекстный ров для повышения точности системы
Согласно тестам CyberGym, контекст повысил точность LLM. Точность универсальной LLM составляла около 65 процентов. Контекст инфраструктуры повысил ее до 90 процентов. Добавление бизнес-контекста повысило точность до 95 процентов. Система безопасности на скорости машины требует сильного контекста, основанного на безопасности на уровне инфраструктуры. Это существует в пяти столпах:
- Формально проверять каждый путь для определения сетевой достижимости.
- Использовать автоматизированное рассуждение над политиками IAM, которое математически доказывает, предоставляет ли политика непреднамеренный доступ.
- По умолчанию блокировать публичный доступ к вашему облаку.
- Непрерывная инвентаризация в реальном времени каждого ресурса и изменения конфигурации.
- Математически доказывать корректность безопасности, развернутой в масштабе.
Итак, как доверять этой автономной системе?
Каждый вызов проходит через четырехшлюзовую цепочку авторизации. Первый шлюз — это движок политик с двумя уровнями: область IAM для защиты от выхода за установленные границы и Cedar для обеспечения детализированного доступа к инструментам в отношении того, какие действия агентам разрешено выполнять над какими ресурсами и при каких условиях. Это накладывает детерминированные ограничения на действия агентов без привлечения LLM для этих решений об авторизации. Второй шлюз — это валидация ввода, осуществляемая с помощью проверок схемы и привязки учетной записи. Третий шлюз — это аудит с закрытием при сбое, где каждое действие регистрируется до выполнения, и ничего не отправляется, если аудит не пройден. Четвертый шлюз — это брокер учетных данных, ограниченный одним действием, одним ресурсом с временем жизни (TTL) 15 минут.
Как упоминалось ранее, песочница имеет нулевой исходящий трафик, без подключения к интернету или конечных точек сервисов. Память уничтожается после каждой задачи. Если что-то идет не так внутри песочницы, проблема остается изолированной там.
Мы добавляем постепенную автономию для обработки спектра рисков. Допуск ограничений может выглядеть так:
- 80% автономии для удаления неиспользуемых разрешений
- 60% автономии для ужесточения групп безопасности
- 20% автономии для изменения ролей IAM
- Нулевая автономия для удаления ресурсов – только люди могут выполнять это действие
Наконец, добавьте прозрачность трехзначного вывода. Каждое решение ссылается на доказательства с оценкой уверенности. Суждение LLM отделено от детерминированной математики. Полная трассировка W3C с хранением в течение 90 дней.
Эти элементы создают управляемую систему для LLM с долговечными записями вместо чатов и явным состоянием вместо подсказок.
Обеспечение безопасности на скорости машины
Любой может обернуть модель в систему и построить пользовательский интерфейс. Но это стандартное решение, обреченное на более высокие показатели неточностей и неполных исправлений. Надежная система требует контекста инфраструктуры из мест, где работают ваши нагрузки, формальной верификации, дающей отслеживаемые результаты, и управляемой плоскости управления.
Обнаружение решено. Каждый коммерческий инструмент сканирования может находить события безопасности. Сложная часть — создание надежной автономной системы, которая понимает, что означает проблема в вашей среде, а затем помогает организации двигаться к правильному ответу.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Rudra Mitra
