Forwarded from Порвали два трояна
Cloudflare опубликовали монструозный обзор (
Основная новость в статье — более половины трафика живых людей, который проходит через Cloudflare, защищено постквантовыми алгоритмами согласования ключа. Среди серверов на топ-100k доменов, уже 39% поддерживают ПКШ, хотя всего полгода назад было 28%.
А заканчивается обзор достаточно простой рекомендацией — постквантовое согласование ключей в инфраструктуре надо внедрять уже сейчас, а вот сертификаты на базе ПКШ пока к внедрению не готовы из-за зоопарка стандартов и высоких вычислительных расходов. Тем не менее, нужно готовить инфраструктуру к их внедрению, используя актуальные версии ПО, автоматизируя управление сертификатами и поддерживая конфигурации серверов, которые способны работать одновременно как с доквантовыми, так и постквантовыми сертификатами в зависимости от поддержки на стороне клиента.
#CISO @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
Таксономия атак и рекомендации по использованию пошаговых агентов выглядят полезными.
Forwarded from PWN AI (Artyom Semenov)
Безопасность AI-агентов до сих пор оценивают по метрикам, которые являются, на мой взгляд, недостаточными: фильтрация токсичного контента 😡 или эффективность в решении заранее заданных формальных задач (например, pass@k для кода).
Из тех публичных бенчмарков что я знаю - никто пока не проверяет выдержит ли модель, работающая в ядре AI-агента целевую атаку, когда злоумышленник сможет превратить сам агент, его компоненты или даже весь его функционал в оружие против системы, в которой он работает.😊
Именно этот вопрос был учтён при реализации Backbone Breaker Benchmark (b3) - совместного проекта Lakera и UK AI Security Institute.🤨
Он предлагает иной подход к тестированию атак на AI-агенты: вместо абстрактных метрик «умения»😊 или фильтрации контента бенчмарк целенаправленно атакует ядро системы — ту самую «основу» (backbone) 😊 , на которой держится весь AI-агент. Это сама LLM — ядро агента, где формируются решения при каждом взаимодействии.
Несмотря на то, что данных пока - нет информации о том, что из себя представляет бенчмарк уже достаточно..😳 (Код и данные опубликуют позже на GitHub)
Зачем это нужно?🤔
AI-агенты превратили LLM в основную точку взаимодействия с угрозами извне: они читают письма, генерируют код, взаимодействуют с базами данных. Но то, что LLM не умеют отличать данные от инструкций, делает их уязвимыми.
🐈 🐈 🐈
Именно в этом случае появляются разнообразные и гибридные атаки - например: через веб-страницу, файл или сообщение в чате атакующий может заставить модель украсть данные, выполнить вредоносный код или изменить логику работы.
Как устроен b3?🫣
Он использует «снимки угроз» (threat snapshots).
То есть задача — оценить конкретный момент атаки😳 : контекст, вектор воздействия и чёткий критерий провала. Например, удастся ли внедрить фишинговую ссылку в расписание для туриста или украсть информацию из юридически защищённого документа. Каждый тест показывает, где именно и почему модель теряет контроль.
Бенчмарк содержит 194 000 успешных попыток реализации атак, собранных в игре Gandalf: Agent Breaker. Участники, придумывали изощрённые способы атак на AI-агентов, из них почти 40% являются промпт-инъекциями при взаимодействии с внешними API, а 25% - джейлбрейки.🫤
Исследователи отобрали лишь 0,1 % от общего числа запросов, которые были реализованы в рамках соревнования — только те, что могут обойти защиту даже у топовых моделей (Claude 3.7, GPT-5).🗿
Что стало открытием при реализации бенчмарка?
Во-первых, агенты с многошаговым планированием (например, на базе ReAct или Tree-of-Thought prompting) оказались на 15% устойчивее к инъекциям по сравнению с классическими single-shot AI-агентами.😞
Во-вторых, размер модели — не гарант защиты. Выяснилось, что некоторые LLM среднего размера уверенно обыгрывают гигантов. Например, среди опенсурсных моделей Llama-3-70B выдерживала больше атак, чем GPT-4o в ряде категорий.🕺
А в-третьих, open-source модели в целом сокращают разрыв с коммерческими гигантами по защитной составляющей.🔥
Важно и то, что модель, выступающая ядром AI-агента, может идеально фильтровать токсичный контент (safety), но при этом безотказно выполнять команды из вредоносного запроса (security). Как дверной замок, который идеально определяет вежливых гостей, но не замечает взломщика с отмычкой.
Ещё из полезного исследователи реализовали таксономию атак, на AI-агентов, которую я приложил в картинке к посту.⚡️ ⚡️ ⚡️
Из тех публичных бенчмарков что я знаю - никто пока не проверяет выдержит ли модель, работающая в ядре AI-агента целевую атаку, когда злоумышленник сможет превратить сам агент, его компоненты или даже весь его функционал в оружие против системы, в которой он работает.
Именно этот вопрос был учтён при реализации Backbone Breaker Benchmark (b3) - совместного проекта Lakera и UK AI Security Institute.
Он предлагает иной подход к тестированию атак на AI-агенты: вместо абстрактных метрик «умения»
Несмотря на то, что данных пока - нет информации о том, что из себя представляет бенчмарк уже достаточно..
Зачем это нужно?
AI-агенты превратили LLM в основную точку взаимодействия с угрозами извне: они читают письма, генерируют код, взаимодействуют с базами данных. Но то, что LLM не умеют отличать данные от инструкций, делает их уязвимыми.
Именно в этом случае появляются разнообразные и гибридные атаки - например: через веб-страницу, файл или сообщение в чате атакующий может заставить модель украсть данные, выполнить вредоносный код или изменить логику работы.
Как устроен b3?
Он использует «снимки угроз» (threat snapshots).
То есть задача — оценить конкретный момент атаки
Бенчмарк содержит 194 000 успешных попыток реализации атак, собранных в игре Gandalf: Agent Breaker. Участники, придумывали изощрённые способы атак на AI-агентов, из них почти 40% являются промпт-инъекциями при взаимодействии с внешними API, а 25% - джейлбрейки.
Исследователи отобрали лишь 0,1 % от общего числа запросов, которые были реализованы в рамках соревнования — только те, что могут обойти защиту даже у топовых моделей (Claude 3.7, GPT-5).
Что стало открытием при реализации бенчмарка?
Во-первых, агенты с многошаговым планированием (например, на базе ReAct или Tree-of-Thought prompting) оказались на 15% устойчивее к инъекциям по сравнению с классическими single-shot AI-агентами.
Во-вторых, размер модели — не гарант защиты. Выяснилось, что некоторые LLM среднего размера уверенно обыгрывают гигантов. Например, среди опенсурсных моделей Llama-3-70B выдерживала больше атак, чем GPT-4o в ряде категорий.
А в-третьих, open-source модели в целом сокращают разрыв с коммерческими гигантами по защитной составляющей.
Важно и то, что модель, выступающая ядром AI-агента, может идеально фильтровать токсичный контент (safety), но при этом безотказно выполнять команды из вредоносного запроса (security). Как дверной замок, который идеально определяет вежливых гостей, но не замечает взломщика с отмычкой.
Ещё из полезного исследователи реализовали таксономию атак, на AI-агентов, которую я приложил в картинке к посту.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Несмотря на то, что ссылка крайне ограничено описывает проведенный тест, она поднимает не простой вопрос доверия. Доверия и необходимости запуска процесса аудита безопасности новых классов товаров. Таких классов как автобусы, портовые краны, автомобили и любой другой техники которая только может (даже если не декларирует) иметь функции удаленнного управления.
https://www.aftenposten.no/oslo/i/PpWLwJ/ruter-har-testet-egne-elbusser-de-kinesiske-kan-stoppes
https://www.aftenposten.no/oslo/i/PpWLwJ/ruter-har-testet-egne-elbusser-de-kinesiske-kan-stoppes
www.aftenposten.no
Ruter har testet egne elbusser: De kinesiske bussene kan stoppes
Ruter har testet om egne Kina-busser utgjør en sikkerhetsrisiko. Nå har de varslet Samferdselsdepartementet om funnene.
https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html
В новом релизе хрома добавились функции блокировки локальных сетевых атак, принудительное отключение расширений которые нарушают политики магазина приложений, использование ИИ для обнаружения и блокировки всплывающих окон.
В новом релизе хрома добавились функции блокировки локальных сетевых атак, принудительное отключение расширений которые нарушают политики магазина приложений, использование ИИ для обнаружения и блокировки всплывающих окон.
Chrome Releases
Stable Channel Update for Desktop
The Chrome team is delighted to announce the promotion of Chrome 142 to the stable channel for Windows, Mac and Linux. This will roll out ov...
ИИ агент от создателей Chat GPT который может заметно изменить процесс SSDLC в большинстве компаний https://openai.com/index/introducing-aardvark/
Openai
Introducing Aardvark: OpenAI’s agentic security researcher
Now in private beta: an AI agent that thinks like a security researcher and scales to meet the demands of modern software.
Вышел новый state of devops 2025 https://devopsrussia.ru/ . В этот раз с интересным разделом по ИБ.
State of DevOps Russia 2025
Результаты масштабного исследования состояния DevOps в России. Полная версия отчета!
👍1
Forwarded from OWASP RU
Русский перевод и адаптация OWASP Application Security Verification Standard
Стандарт верификации требований к безопасности приложений — это перечень требований к безопасности приложений (тестов), которыми могут пользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, разработчики инструментов и конечные пользователи для проектирования, разработки, тестирования и контроля безопасных приложений.
Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.
После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.
ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.
Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.
Не существует такого понятия, как «область действия» для злоумышленника. Поэтому требования ASVS должны оцениваться в совокупности с рекомендациями по другим аспектам жизненного цикла приложения, включая процессы CI/CD, хостинг и операционную деятельность.
Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.
Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.
В свою очередь, ASVS не включает требования, не относящиеся к приложению напрямую или находящиеся за пределами его зоны ответственности. Так, например, проблемы DNS обычно относятся в ведении отдельной команды или функции.
Аналогично, хотя в зону ответственности приложения входит обработка входящих данных и генерация исходящих данных, если внешний процесс взаимодействует с приложением или его данными, это считается выходящим за рамки ASVS. Например, резервное копирование приложения или его данных обычно выполняется внешними процессами и не контролируется самим приложением или его разработчиками.
Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.
Все прочие аспекты, такие как функциональные характеристики, стиль кода или требования политик, выходят за рамки стандарта.
Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».
Стандарт
ASVS представляет собой набор требований безопасности, которые необходимо реализовать для соответствия стандарту. Это означает, что требования ограничиваются определением целевого показателя безопасности, которого необходимо достичь. Прочая сопутствующая информация может быть надстроена на основе ASVS или связана с ним через сопоставления.
PDF RU
Стандарт верификации требований к безопасности приложений — это перечень требований к безопасности приложений (тестов), которыми могут пользоваться архитекторы, разработчики, тестировщики, специалисты по безопасности, разработчики инструментов и конечные пользователи для проектирования, разработки, тестирования и контроля безопасных приложений.
Пятая версия стандарта верификации требований к безопасности приложений опирается на предыдущие версии ASVS, начиная с первой, вышедшей в 2008 году, и до четвертой, в 2019 году.
После выхода версии ASVS 4.0 в 2019 году и ее незначительного обновления (v4.0.3) в 2021 году, версия 5.0 является значительным шагом вперед — она была модернизирована, чтобы учесть последние достижения в области безопасности программного обеспечения.
ASVS 5.0 стал результатом масштабного вклада руководителей проекта, членов рабочей группы и широкого сообщества OWASP, направленного на обновление и совершенствование этого важного стандарта.
Область действия ASVS
Область действия ASVS определяется его названием: Приложение (Application), Безопасность (Security), Верификация (Verification) и Стандарт (Standard). Он устанавливает, какие требования включены в стандарт, а какие — исключены из него, с глобальной целью определения основополагающих принципов безопасности, которые должны быть достигнуты. Область действия также учитывает требования к документации, которые служат основой для требований к реализации.
Не существует такого понятия, как «область действия» для злоумышленника. Поэтому требования ASVS должны оцениваться в совокупности с рекомендациями по другим аспектам жизненного цикла приложения, включая процессы CI/CD, хостинг и операционную деятельность.
Приложение
ASVS определяет «Приложение» как разрабатываемый программный продукт, в который должны быть интегрированы механизмы безопасности. ASVS не регламентирует процессы жизненного цикла разработки и не указывает на методы сборки приложения в CI/CD. Его задача — описать требуемый уровень защищённости, который должен быть достигнут в конечном продукте.
Компоненты для обработки HTTP-трафика (WAF, балансировщики нагрузки, прокси) могут считаться частью приложения в контексте безопасности, поскольку некоторые механизмы безопасности напрямую зависят от них или могут быть реализованы с их помощью. Это касается требований по кешированию, rate limiting, а также фильтрации входящих/исходящих подключений по источнику и получателю.
В свою очередь, ASVS не включает требования, не относящиеся к приложению напрямую или находящиеся за пределами его зоны ответственности. Так, например, проблемы DNS обычно относятся в ведении отдельной команды или функции.
Аналогично, хотя в зону ответственности приложения входит обработка входящих данных и генерация исходящих данных, если внешний процесс взаимодействует с приложением или его данными, это считается выходящим за рамки ASVS. Например, резервное копирование приложения или его данных обычно выполняется внешними процессами и не контролируется самим приложением или его разработчиками.
Безопасность
Каждое требование должно иметь очевидное влияние на безопасность. Отсутствие требования должно привести к снижению уровня защищённости приложения, а реализация требования должна либо уменьшить вероятность возникновения риска безопасности, либо смягчить последствия.
Все прочие аспекты, такие как функциональные характеристики, стиль кода или требования политик, выходят за рамки стандарта.
Верификация
Требование должно быть верифицируемым, а его проверка должна приводить к однозначному решению: «не выполнено» или «выполнено».
Стандарт
ASVS представляет собой набор требований безопасности, которые необходимо реализовать для соответствия стандарту. Это означает, что требования ограничиваются определением целевого показателя безопасности, которого необходимо достичь. Прочая сопутствующая информация может быть надстроена на основе ASVS или связана с ним через сопоставления.
PDF RU
Forwarded from Порвали два трояна
Можно бесконечно смотреть на то, как горит огонь, течёт вода и атакующие эксплуатируют ошибки конфигурации Exchange. Но даже если положить конец этому безобразию невозможно, уменьшить его масштабы очень желательно.
Ощутимый вклад в это благое дело на днях внесли ИБ-регуляторы англоязычных стран, опубликовав пятнадцатистраничное руководство Microsoft Exchange Server Security Best Practices.
Документ разделён на два больших раздела — Prevention posture и Harden authentication and encryption.
В первом даны рекомендации по минимальному набору безопасных настроек со ссылками на ещё более подробные security baselines от CIS, DISA и Microsoft, адаптированные для конкретных версий Exchange. Также перечислены встроенные инструменты защиты и механизмы оперативного обновления, которые авторы рекомендуют активировать.
В разделе про харденинг, которому уделено две трети документа, рекомендованы более сложные настройки и изменения, значительно повышающие стойкость сервера к современным атакам:
Тем, кто продолжает пользоваться Exchange, стоит взять этот чеклист на вооружение.
#советы #Microsoft @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
https://owasp.org/Top10/2025/0x00_2025-Introduction/
Релиз кандидат Owasp top ten web.
На первом месте остается Broken access control.
На второе место вышли с пятого security misconfiguration.
Software supply chain был объединен с vulnerable and outdated components.
На 10 месте расположилась новая категория по некорректной обработке ошибок.
Итого проект топ 2025 выглядит так:
A01:2025 - Broken Access Control
A02:2025 - Security Misconfiguration
A03:2025 - Software Supply Chain Failures
A04:2025 - Cryptographic Failures
A05:2025 - Injection
A06:2025 - Insecure Design
A07:2025 - Authentication Failures
A08:2025 - Software or Data Integrity Failures
A09:2025 - Logging & Alerting Failures
A10:2025 - Mishandling of Exceptional Conditions
Не могу не отметить, что в выборке github топ уязвимостей в этом анализе
https://habr.com/ru/articles/963774/ топ немного другой:
1. Broken acces control.
2-3 место insecure design, injection
4,5,6 Security misconfigration, Security logging and monitoring failrues, Cryptographic failrues.
7. Software and data integrity failrues
8. Identification and authentication failrues
9. server side request forgery SSRF.
Релиз кандидат Owasp top ten web.
На первом месте остается Broken access control.
На второе место вышли с пятого security misconfiguration.
Software supply chain был объединен с vulnerable and outdated components.
На 10 месте расположилась новая категория по некорректной обработке ошибок.
Итого проект топ 2025 выглядит так:
A01:2025 - Broken Access Control
A02:2025 - Security Misconfiguration
A03:2025 - Software Supply Chain Failures
A04:2025 - Cryptographic Failures
A05:2025 - Injection
A06:2025 - Insecure Design
A07:2025 - Authentication Failures
A08:2025 - Software or Data Integrity Failures
A09:2025 - Logging & Alerting Failures
A10:2025 - Mishandling of Exceptional Conditions
Не могу не отметить, что в выборке github топ уязвимостей в этом анализе
https://habr.com/ru/articles/963774/ топ немного другой:
1. Broken acces control.
2-3 место insecure design, injection
4,5,6 Security misconfigration, Security logging and monitoring failrues, Cryptographic failrues.
7. Software and data integrity failrues
8. Identification and authentication failrues
9. server side request forgery SSRF.
Хабр
Взгляд безопасника на ежегодный отчет Github Octoverse 2025
Всем привет! Сделал для вас анализ ключевых положений нового крутого отчета Github с точки зрения безопасности. Меня зовут Василий Пластунов и я люблю делать анализ тенденций которые повлияют на...
Forwarded from Порвали два трояна
Аккурат к новому циклу бюджетирования IANS подвёз исследование о тратах на ИБ, составленное по опросу почти 600 CISO из разных стран и вертикалей бизнеса. Хотя выводы делались для западных компаний, большинство наблюдений актуальны и для наших широт.
Авторы отчёта советуют CISO внимательно смотреть на нужды бизнеса, расставлять приоритеты и соразмерять аппетиты:
#CISO @П2Т
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Сильный голос Google за - использовать memory safe Rust для снижения расходов на поиск, устранение и компенсирующие меры для уязвимостей. Приятный плюс - уменьшение до 4 раз количество откатов новых сборок.
Google Online Security Blog
Rust in Android: move fast and fix things
Posted by Jeff Vander Stoep, Android Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in ...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/native-sysmon-functionality-coming-to-windows/4468112
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
В следующие релизы Win 11 и Server 2025 будет добавлен Symon, полезный инструмент для расширенного сбора логов.
TECHCOMMUNITY.MICROSOFT.COM
Native Sysmon functionality coming to Windows | Microsoft Community Hub
Learn how to eliminate manual deployment and reduce operational risk with Sysmon functionality in Windows.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1308.2pd.pdf вторая версия проекта рекомендаций быстрого внедрения треьований безопасности по фреймворку NIST CSF 2.0.