https://www.coveware.com/blog/2025/10/24/insider-threats-loom-while-ransom-payment-rates-plummet
По оценке Coverware процент выплат выкупов в ходе действий шифровальщиков упал в Q3 до 25 процентов от всех успешных атак, это рекорд за всю историю наблюдений.
По оценке Coverware процент выплат выкупов в ходе действий шифровальщиков упал в Q3 до 25 процентов от всех успешных атак, это рекорд за всю историю наблюдений.
Coveware: Ransomware Recovery First Responders
Insider Threats Loom while Ransom Payment Rates Plummet
The percentage of companies choosing to pay ransoms dropped significantly, while threat actors shift their tactics in response to decreasing profits.
Forwarded from DevSecOps Talks
Supply Chain: ретроспектива за 2024/2025 года
Всем привет!
По ссылке можно найти агрегированную информацию о нашумевших атаках на цепочку поставки ПО, реализованных за 2024/2025 года.
В выборку попали: XZ Utils. Shai-Hulud, MavenGate, Ultralytics и многие другие. Для каждой их них Автор приводит ссылку для более детального изучения.
Помимо этого, Автор описывает наиболее «популярные» векторы:
🍭 Phishing
🍭 Control Handoff
🍭
🍭 Long-lived Credentials Exfiltration и не только
Для каждого из них в статье можно найти рекомендации по противодействию.
Очень хороший обзорный материал, который мы рекомендуем к ознакомлению!
Всем привет!
По ссылке можно найти агрегированную информацию о нашумевших атаках на цепочку поставки ПО, реализованных за 2024/2025 года.
В выборку попали: XZ Utils. Shai-Hulud, MavenGate, Ultralytics и многие другие. Для каждой их них Автор приводит ссылку для более детального изучения.
Помимо этого, Автор описывает наиболее «популярные» векторы:
🍭 Phishing
🍭 Control Handoff
🍭
pull_request_target и issue_comment🍭 Long-lived Credentials Exfiltration и не только
Для каждого из них в статье можно найти рекомендации по противодействию.
Очень хороший обзорный материал, который мы рекомендуем к ознакомлению!
words.filippo.io
A Retrospective Survey of 2024/2025 Open Source Supply Chain Compromises
Project compromises have common root causes we can mitigate: phishing, control handoff, and unsafe GitHub Actions triggers.
👍1
Хром будет открывать сайты в https по умолчанию с 154 версии.
Теперь у сайтов без htpps снизится юзабилити-будет постоянный вопрос.
https://security.googleblog.com/2025/10/https-by-default.html
Теперь у сайтов без htpps снизится юзабилити-будет постоянный вопрос.
https://security.googleblog.com/2025/10/https-by-default.html
Google Online Security Blog
HTTPS by default
One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secu...
https://attack.mitre.org/resources/updates/
Вышла 18 версия attack от Митре.
Основные изменения касаются части защиты.
Обнаружения заменили стратегиям обнаружения.
Вместо источников данных - компоненты данных.
Вышла 18 версия attack от Митре.
Основные изменения касаются части защиты.
Обнаружения заменили стратегиям обнаружения.
Вместо источников данных - компоненты данных.
Continuing Professional Education (CPE) credits for 2025 must be earned and reported by 31 December 2025. Visit your MyISACA dashboard to view your reporting requirements, report your CPEs, and monitor your progress.
👍2
Forwarded from Солдатов в Телеграм
Gartner: Automated Exposure Management и Zero Trust должны быть частью предложения MDR
Гартнер выпустил документ "Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust" (вложение), согласно которому автоматический контроль поверхности атаки и подходы нулевого доверия должны стать частью MDR в ближайшее время.
Что касается контроля поверхности атаки, то об этом не раз писали и Forrester и Gartner , и вопросов здесь не возникает, то про ZT и контроль Identity стоит поговорить поподробнее.
Чтобы не испытывать ограничения формата заметки в Telegram, подготовил статью.
Статья будет полезна тем, кто определяет продуктовую стратегию MDR и экосистем ИБ вообще, ибо, как не раз писал (например) MDR - это венец любой экосистемы, как практическое подтверждение ее эффективности и результативности в реальных условиях эксплуатации.
#vCISO #MDR #dev
Гартнер выпустил документ "Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust" (вложение), согласно которому автоматический контроль поверхности атаки и подходы нулевого доверия должны стать частью MDR в ближайшее время.
Что касается контроля поверхности атаки, то об этом не раз писали и Forrester и Gartner , и вопросов здесь не возникает, то про ZT и контроль Identity стоит поговорить поподробнее.
Чтобы не испытывать ограничения формата заметки в Telegram, подготовил статью.
Статья будет полезна тем, кто определяет продуктовую стратегию MDR и экосистем ИБ вообще, ибо, как не раз писал (например) MDR - это венец любой экосистемы, как практическое подтверждение ее эффективности и результативности в реальных условиях эксплуатации.
#vCISO #MDR #dev
Дзен | Статьи
Zero Trust в MDR
Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: В заметке в перечне важных фич приводится "Мониторинг Identity", что, как я понял, вызывает уже вопросики, но я наброшу еще больше,...
Forwarded from Солдатов в Телеграм
Emerging_Tech_Futur_G00830314.pdf
313 KB
Gartner
Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust
Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust
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