Ребята из Wiz опубликовали простой, но удобный и наглядный фреймворк SITF (SDLC Infrastructure Threat Framework), разработанный для анализа и защиты от атак, нацеленных на инфраструктуру жизненного цикла разработки программного обеспечения.

Фреймворк SITF позволяет визуализировать этапы атаки на компоненты цикла разработки, идентифицировать риски, сопоставлять с ними меры защиты и позволяет анализировать цепочку атаки.

SITF включает в себя:
🟠Flow Builder — интерактивный инструмент для моделирования и визуализации атак.
🟠Explore Techniques Visually — интерактивная MITRE-подобная база знаний о техниках злоумышленников, содержащая в т.ч. описание рисков и мер защиты в разрезе компонентов SDLC.
🟠Руководство по фреймворку c примерами использования и инструкциями, а также с разбором известных атак (CircleCI, Shai-Hulud-2 и Codecov).

Как и писал в начале, инструменты очень простые в использовании и визуально удобные👍
В репозитории есть ссылки на онлайн-версии, но ссылки там битые🤷 Однако, для локального запуска достаточно скачать два html-файла и открыть их в любом веб-браузере.

#sdlc #framework #technique #risks #controls #modeling

Я тут разбирался с Moltbot (бывший Clawdbot), который мог бы за счет автоматизации существенно поднять мою продуктивность. Изучал разные мнения, в том числе и по его безопасности, которая, как это часто бывает у пет-проектов, оказалась не на высоте. Но дело даже не в этом. Я попробовал представить, как мне защитить Moltbot'а от злоупотреблений и реализации через него угроз против меня? И понял, что это, пипец, какая непростая задача. Большинство современных средств ИБ (например, NGFW или NDR или WAF) исходит из предположения, что ИИ ведет себя как человек или хотя бы как предсказуемая сессия, но ИИ-агенты так не работают.

Чтобы быть полезным, агенту нужны широкие права. Он должен сам решать, куда пойти за данными и какие источники связать между собой. Один запрос, например, "Дай рекомендации по повышению эффективности команды аналитиков SOC" может запустить целую цепочку действий:
➡️ обращение к HR-системе
➡️ загрузку данных по оргструктуре
➡️ обращение к SIEM/SOAR
➡️ запросы к базе зарплат
➡️ объединение с performance-review
➡️ синтез результата.

Решения класса IDM/PAM/JIT проектировались под мониторинг действий людей и понятные сценарии: запрос → одобрение → выполнение → отзыв доступа. У агентов же все иначе:
➡️ Один и тот же запрос сегодня – это 50 записей.
➡️ Тот же запрос завтра – это уже записей 500, включая доступ к чувствительным полям в какой-нибудь СУБД.
➡️ Послезавтра – объединение нескольких наборов данных и экспорт результата.

В таких условиях принцип наименьших привилегий перестает работать как концепция. Сделать списки контроля доступа строгим – агент "ломается" на полпути, а пользователи начинают обходить контроль. Ослабить – вы даете широкие постоянные права и увеличиваете радиус поражения в случае инцидента ИБ. И заранее предсказать путь агента невозможно – он "думает" по ходу выполнения задачи. И тут нет проблемы IAM, NGFW, СЗИ от НСД и других систем ИБ, работающих в детерминистском пространстве и ограниченном пространстве решений. Это фундаментальное отличие и, даже, противоречие автономных систем.

Классические инструменты отвечают на свои привычные вопросы:
➡️ IAM: "Этот сервис-аккаунт успешно аутентифицировался"
➡️ NGFW: "Этот запрос пришел с легитимного IP-адреса"
➡️ PAM/JIT: "Доступ был одобрен"
➡️ CASB/DLP: "Мы видим вызовы и контент".
Но они не видят цепочку исполнения. С точки зрения идентифицированных сущностей все легально, а в реальности агент:
➡️ забрал больше данных, чем требовалось
➡️ связал чувствительные наборы между собой
➡️ выдал результат пользователю, которому эти данные видеть нельзя.
В Интернете дофига кейсов, где ИИ-агенты делают больше запрошенного (я на обучении по ИБ и ИИ для топ-менеджмента тоже привожу такие кейсы), раскрывая конфиденциальную информацию случайным людям или злоумышленникам.

И традиционная ИБ не очень помогает решать эту проблему. Не потому, что она плохая, а потому, что она строилась в другой парадигме. Это примерно как NGFW, которые появились как ответ обычным МСЭ, неспособным видеть, что происходит на прикладном уровне. Так и тут. У ИИ-агентов слишком много прав (и урезать их – не вариант) и мы не видим, как они ими пользуются в рамках всей цепочки запросов и ответов (пользователь → агент → сервис(ы) → MCP-сервер/OpenRouter). На границах между компонентами теряется контекст и мы не понимаем, что происходит на самом деле.

И ИБ нужны будут новые решения. Что-то типа RASP, но для агентов, а не приложений, с добавлением понимания контекста. А я пока думаю, как решать свою задачу, так как давать избыточные права Moltbot'у у меня рука не поворачивается, а без этого он превращается просто в навороченный Shortcuts на macOS.

#ии #модельугроз