🔵 Тренажеры AI Red Teaming
1. crucible.dreadnode.io
2. https://huggingface.co/spaces/invariantlabs/ctf-summer-24/tree/main
3. https://promptairlines.com/
4. burp labs: https://portswigger.net/web-security/llm-attacks
5. в обычных ctf тоже появляются куски с ml/llm, например, в http://poll-vault.chal.hackthe.vote/
6. https://myllmdoc.com/
7. https://gandalf.lakera.ai/
8. AI CTF с PHDFest2 2024: https://aictf.phdays.fun/
9. https://aiinsec.ru/

ℹ️ ФСТЭК России представила новый раздел специфических угроз безопасности ИИ, фокусируясь на инфраструктуре разработчика и оператора.
​
💬 Документ четко классифицирует угрозы на две группы — разработка/обучение и эксплуатация — с акцентом на объекты вроде наборов данных, моделей (включая LoRA, RAG) и ПО. Он подчеркивает ключевые риски: утечки, кражу моделей, нарушения функционирования и отказ в обслуживании, ссылаясь на Методику оценки угроз безопасности 2021 года, что облегчает интеграцию с БДУ ФСТЭК России. Учет факторов вроде уровня значимости данных и разделения ответственности делает материал релевантным для российских организаций.
​
🤒 Раздел ограничивается инфраструктурой разработчика (разработка/обучение) и оператора (эксплуатация), игнорируя этап, связанный с данными, как отдельный этап с рисками вроде отравления наборов обучающих данных. При этом, сведения об угрозах, связанных с моделями машинного обучения, которые ранее были в БДУ - утратили свою актуальность, в связи с опубликованием нового подраздела.
​
📈 Для эффективного управления угрозами видится, что этот процесс для ИИ следует производить по этапам (подготовка данных, разработка, обучение/тестирование, функционирование), как в лучших практиках (OWASP, Google SAIF и.т.д).
​
🗒 Таким образом, в РФ всё ещё необходим полноценный фреймворк для эффективного управления угрозами безопасности ИИ, формированию мер защиты и подходов к управлению безопасностью систем ИИ (включая безопасность при аутсорсинге ИИ).
Однако, формирование нового раздела ФСТЭК России это только первый шаг. Надеемся...

Спрашивали – отвечаем ✍️ Откуда пошло цветовое деление у команд ИБ? Истоки концепции – в военных учениях (wargame). Во время Холодной войны, когда армии и аналитические организации моделировали военные конфликты, "красная" сторона (Red) часто символизировала противника (например, СССР), а "синяя" (Blue) – своих или союзников 💪 Например, RAND Corporation во времена Холодной войны проводила такие симуляции, где Red представляла противника, а Blue – США. Со временем этот подход перешел из военного сценарного моделирования в кибербезопасность: "Red Team vs Blue Team" стали использовать для имитации атак и защиты в ИТ-системах ⚔️

Двух цветов со временем стало недостаточно, потому что безопасность – не просто атака vs защита ✏️ С ростом сложности ИТ-инфраструктур понадобились новые роли: разработчики, операторы, люди, внедряющие безопасность на разных этапах. И в 2017 году на конференции Black Hat USA эксперт Эприл Райт (April C. Wright) представила доклад "Orange Is the New Purple", в котором расширила модель, например, добавила "жёлтый" цвет (для разработчиков), фиолетовый (Purple) для описания совместной деятельности Red и Blue для улучшения защиты, и предложила идею, что можно "смешивать" цвета 🎨, получая новые роли. После этого понятием "цветовое колесо" (color wheel) стали называть расширенную систему распределения ролей.

Сегодня деление на цвета выглядит следующим образом: 🎨
🎨 Red Team (красные) – "атакующие" – "белые" хакеры, пентестеры. Они пытаются взломать систему, найти уязвимости, показать, как злоумышленник мог бы проникнуть и нанести вред организации.
🎨 Blue Team (синие) – защитники – отвечают за мониторинг, обнаружение, реагирование на инциденты, защиту систем в режиме реального времени, укрепление безопасности, предотвращение атак.
🎨 Purple Team (фиолетовые) – гибрид / посредник: сочетает подходы Red + Blue. Цель – не просто атака или защита, а совместная работа над усилением безопасности: моментальный разбор обнаруженных уязвимостей, совместная настройка обороны, обмен знаниями.
🎨 Yellow Team (желтые) – разработчики / архитекторы / инженеры: те, кто строят, пишут код, проектируют системы – с учетом безопасности "изнутри". То есть DevSecOps / Secure-by-Design.
🎨 Green Team (зеленые) – инженеры по автоматизации / DevOps-специалисты, кто обеспечивает, чтобы процессы безопасности (патчи, обновления, CI/CD, конфигурации) были автоматизированы, надежны и масштабируемы.
🎨 Orange Team (оранжевые) – команда обучения и трансляции знаний: они "переносят" уроки, которые дает Red Team, внутрь организации, в процессы разработки, операционной безопасности – повышают осведомленность, обучают, помогают закрепить улучшения.
🎨 White Team (белые) – "арбитры" / координаторы: устанавливают правила, рамки, область контроля, наблюдают за процессом, управляют учениями и тестами; гарантируют, что тесты безопасны, организованы, а выводы – адекватно оформлены и переданы командам.

Purple, Green, Orange и другие часто не формальные "отдельные команды", а роли или подходы – особенно в организациях, где нет строго структурированного разделения.

#стратегия

😎 ИИ в кибербезопасности: применение и угрозы 2025

Искусственный интеллект стал не только инструментом защиты, но и грозным оружием в руках злоумышленников.

Алгоритмы машинного обучения анализируют миллионы событий в секунду, выявляя аномалии и атаки нулевого дня, а генеративные модели создают убедительные фишинговые письма и даже вредоносный код.

➡️ В новой статье на сайте разобрали, как ИИ помогает кибербезопасности, какие риски несет его использование и как специалисты учатся держать технологии под контролем.

😎 Здесь о кибербезе