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

Не могу сказать, что перечень рекомендуемых мер защиты чем‑то удивил или стал откровением: получился довольно стандартный набор по современным меркам, а ценность я увидел в практических советах по автоматизации мер защиты и в проактивном подходе к тестированию системы защиты на прочность с помощью ИИ‑инструментов.

На сгенерированной иллюстрации можно увидеть краткую выжимку по мерам и использованию ИИ, но рекомендую ознакомиться с оригиналом полностью, а вот про советы по приоритизации устранения уязвимостей сделаю отдельный пост, так как там есть что обсудить с учетом ответа одной организации на пост Anthropic😏

#anthropic #ai #controls #vulnerability #vm #exposure

И так, Anthropic предлагает следующую стратегию приоритизации устранения уязвимостей:
1️⃣Закрыть все уязвимости из каталога CISA KEV; уязвимости с сетевым вектором считаются первоочередными.
2️⃣Для остальных уязвимостей использовать EPSS и устранять те, у которых значение выше установленного порога.
3️⃣Патчить публично доступные из сети Интернет системы в течение 24 часов после появления эксплойта; все остальные уязвимости — в течение нескольких дней.

Как видно, рекомендации по приоритизации выглядят "избитыми", а где-то и размытыми. Я уже отмечал выше их очевидность и шаблонность: многие авторитетные эксперты указывают, что значительная часть предложений из статьи Anthropic уже давно воспринимается как базовая практика.

В общем-то, несмотря на очевидность, к первой и последней рекомендациям особых вопросов нет: больше всего вопросов вызывает использование фактически единственного критерия приоритизации — EPSS. Здесь, однако, стоит упомянуть, что в статье Anthropic подчеркивается важность автоматизации процесса установки обновлений, а приоритизация – это мера, которая позволит не утонуть в океане уязвимостей в моменте времени.
В то же время примечательна почти мгновенная реакция Empirical Security на рекомендацию использовать EPSS в статье Anthropic. Оно и понятно: Empirical Security, действуя при поддержке FIRST, фактически стояли у истоков методологии, поэтому они оперативно поддержали (1, 2) рекомендацию, но с важной оговоркой — EPSS даёт «глобальную» оценку вероятности эксплуатации уязвимости в ближайшие 30 дней и не учитывает специфику конкретной организации (контекст инфраструктуры и применяемые меры защиты).
А далее они решили воспользоваться минутой славы и предложили прокачать приоритизацию с помощью их продуктов:
➡️Empirical Global Model – обогащает прогнозы EPSS телеметрией об эксплуатации уязвимостей в сети Интернет в реальном времени. Условно "CISA KEV на стероидах".
➡️Empirical Local Model – по сути Global Model, обогащенная телеметрией конкретной организации (данными об активах, инцидентах, мерах защиты и т.п.)

Выводы:
➡️EPSS как единственный критерий приоритизации бесполезен даже по мнению создателей этой методологии.
➡️Контекст инфраструктуры крайне важен в приоритизации.
➡️Приоритизация не заменяет процесс планового обновления и патч-менеджмента.

#prioritization #vm #epss #context #kev

⚖️Эта неделя прошла под флагом приоритизации

➡️Anthropic сказал, что "благодаря" ИИ уязвимостей находиться (и создаваться тоже 😅) будет кратно больше, поэтому посоветовал обзавестись ресурсами, автоматизацией и заняться приоритизацией.

➡️NIST решил, что проблему с бэклогом по обогащению записей в базе NVD надо решать и... просто 90% долга перенес "в корзину"😂
Да, с 15 апреля NIST ввел новый порядок обогащения записей об уязвимостях в NVD. Обогащаться будут:
🟢Уязвимости из каталога CISA KEV
🟢Уязвимости в ПО, используемом в федеральных органах власти США
🟢Уязвимости в критически важном ПО в соответствии с указом EO 14028
Всё остальное будет недостойно внимания NIST, хотя есть опция попросить лично за конкретную уязвимость😐

➡️Seemplicity выпустила неплохое исследование на тему управления экспозициями (угроз и уязвимостей), где не обошли стороной вопрос приоритизации устранения угроз. В топе следующие критерии (в порядке убывания):
🟢Бизнес-критичность активов
🟢Методики оценки критичности (например, по CVSS)
🟢Данные о киберугрозах (Threat Intelligence)
🟢Вероятность эксплуатации (например, по EPSS)
🟢Комплаинс-требования
🟢Запросы руководства или стейкхолдеров
🟢Инженерные ресурсы (на устранение)
А еще подсветили, что если у вас в организации не выстроены базовые процессы по управлению активами (например, не определены владельцы и админы активов) и есть проблема с софт-скиллами, то автоматизация вам не поможет🤷

➡️А в субботу я провёл вебинар на тему подходов и инструментов приоритизации устранения уязвимостей в рамках очередного потока курса "Vulnerability Management" учебного центра Inseca, где поделился личным опытом по этой теме.

#nist #vm #cve #prioritization #kev #vulnerability #ai

На фоне большого количества статей и рекомендаций о необходимости мобилизации усилий по приоритизации и устранению уязвимостей в связи с появлением новых ИИ‑моделей, позволяющих находить десятки критических уязвимостей за считанные минуты, выделяется гайд Роба Фуллера "The Day-Zero
Normal" по перераспределению приоритетов и инвестиций в ИБ‑процессы и инструменты в эру ИИ.

Да, в руководстве подсвечиваются некоторые уже давно очевидные малоэффективные подходы и их решения, например, необходимость замены классических инструктажей точечными "обучениями в моменте", классического антивируса – поведенческим EDR, а ежегодного пентеста – непрерывным автоматизированным редтимингом.
В то же время, есть рекомендации (или призывы) по решению современных проблем:
➡️Необходимость глубокой интеграции решений класса CMDB с решениями CAASM, не забывая, что ИИ-сущности (агенты, mcp-серверы и т.п.) тоже надо учитывать, а также фиксировать какие identity-сущности (учетки, токены и т.п.) связаны с конкретным активом.
➡️Призывы к BugBounty-площадкам интегрировать ИИ-сканеры со специализированными моделями и предоставлять это как базовый функционал, а также ужесточить требования к артефактам, подтверждающим возможность эксплуатации уязвимостей, найденных "исследователями", с целью исключения нейрослопа.
А ещё предложения по внедрению новых подходов:
➡️Все-таки создать VulnOps в составе инженера и аппсека, снарядить их ИИ-инструментами, которые заменят SAST/DAST, а еще пусть они займутся реверс-инжинирингом, чтобы можно было захарденить или создать патчи для легаси-систем.
➡️Внедрить матрицу постоянных полномочий, закрепляющую возможность автоматизированного реагирования на инциденты с помощью ИИ, с закреплением ответственности за такие действия.
Отдельно автор подсвечивает необходимость переподготовки кадров:
➡️SOC-аналитики 1 линии должны стать операторами ИИ-агентов.
➡️AppSec-инженеры должны уйти от ручного триажа в сторону настройки, тюнинга и управления специализированными ИИ-моделями.
➡️GRC-специалисты должны научиться работать с LLM-моделями, чтобы уметь обрабатывать телеметрию от различных ИБ-инструментов для оценки эффективности процессов и соответствия требованиям.

В целом, с документом обязательно рекомендую ознакомиться полностью, так как все рекомендации расписаны очень подробно в разрезе доменов фреймворка NIST CSF 2.0, в том числе с приведением плана действий для CISO, метрик, которые должны выйти на первый план для оценки эффективности новой программы безопасности и советами по бюджету.

#ciso #ai #vm #vulnops #soc #appsec #bugbounty #metrics

На прошлой неделе было несколько интересных материалов и новостей на тему пентестов🛡

🔗Компания Cobalt поделилась (и я ниже поделился) результатами анализа тысяч пентестов, где показала, что:
– Пришло время непрерывного пентеста в виде Penetration Testing as a Service, а разовые пентесты бесполезны.
– В LLM-приложениях находят в 2,7 раза больше уязвимостей, чем в классическом ПО.
– Подсчет метрики устранения половины найденных уязвимостей лучше отражает состояние процесса VM, чем классическая MTTR.

🔗Вышла модель GPT-5.5, а вместе с этим разгорелись споры кто круче в пентестах: Claude Opus 4.7 или GPT-5.5.
Если интересно, то можно почитать сравнительный анализ и практические советы по использованию обеих моделей в пентестах.

🔗А ребята из Awillix запустили уже традиционную ежегодную премию Pentest Award 2026, и я, тоже как обычно, буду следить за результатами: номинаций, как всегда, несколько, в том числе есть и по направлению ИИ.

#ai #pentest #mttr #gpt #claude #awillix #award

Интересная статья о взаимосвязи подчиненности CISO и финансовой устойчивости компаний после кибератак.

В рамках исследования было проанализировано 32 случайно выбранных инцидента в период с 2013 по 2024 гг., о которых было сообщено в Комиссию по ценным бумагам и биржам США (SEC), а также изменение цен на акции компаний в течение 90 дней с момента раскрытия информации об инциденте.
Результаты сравнения показывают довольно явную зависимость между позицией подчинённости CISO и реакцией фондового рынка; это видно на приведённой иллюстрации.
Из интересного:
➡️В тех компаниях, где CISO подчинялся CEO, акции выросли в цене через 3 месяца после раскрытия информации об успешной кибератаке — возможно, это говорит о том, что рынок положительно оценил реакцию руководства компании на инцидент и верит в её устойчивость и дальнейший рост.
➡️В то же время там, где CISO подчинялся CIO/CTO или другому руководителю в структуре ИТ, дела обстояли хуже — падение акций достигло 11,1% через 90 дней после признания факта инцидента.
➡️Удивительно, что если позиция CISO вообще отсутствовала, падение акций было менее значительным, чем в компаниях, где CISO подчинялся CIO/CTO — видимо, отсутствие одного звена в структуре подчинённости способствовало более оперативному принятию решений на уровне CEO.
Примечательно, что во всех кейсах, где не было должности CISO, директор по ИБ появился в течение года после инцидента😄

В качестве наглядного примера приводится сравнение кейсов с инцидентами в сетях казино Caesars и MGM в 2023 году: обе компании были атакованы одной и той же группой злоумышленников с использованием идентичных методов социальной инженерии в течение одной недели, но в Caesars CISO подчинялся CEO, а в MGM — другому руководителю.
Возможно, такая структура подчинённости сыграла ключевую роль: Caesars согласилась на выкуп в 15 млн $ и через 90 дней после раскрытия информации об инциденте вышла в плюс по стоимости акций, а MGM отказалась и понесла убытки свыше 100 млн $.

Да, в исследовании много ограничений: выборка маленькая, и не рассматриваются другие критерии, влияющие на стоимость акций; но всё же гипотеза интересная, а структура подчинённости является надёжным, пусть и косвенным, показателем реального отношения компании к кибербезопасности. Правда, последние локальные исследования показывают интересную тенденцию (?), но об этом в другом посте расскажу.

#research #statistics #sec #impact #stock #costs #ciso #ceo

Ещё одна (свежая) статья о том, как инциденты кибербезопасности влияют на рыночную капитализацию компаний📈

Помимо полезных, но очевидных мыслей и выводов, можно выделить описанный жизненный цикл акций компаний после киберинцидента. На основе анализа различных исследований и наблюдений за стоимостью акций выделены четыре основные фазы этого цикла:
1️⃣Окно объявления – в первые три дня с момента раскрытия информации об инциденте происходит мгновенное падение стоимости акций в среднем от 0,3% до более чем 5%.
2️⃣Фаза "переваривания" (4-20 дней) – акции, как правило, достигают минимума, среднее снижение составляет около 7%, при этом показатели оказываются хуже показателей биржевых индексов.
3️⃣Проверка реальностью (21-120 дней) – в случае инцидентов с высоким уровнем влияния акции компании часто достигают дна на 60 день, где среднее падение достигает 4,6% и динамика стоимости акций все также отстает от показателей биржевых индексов.
4️⃣"Длинная тень" ( от 1 года) – для многих компаний, пострадавших от кибератак, может сохраняться негативная тенденция или показатели роста акций могут отставать на несколько процентных пунктов от рыночных.

Также в статье приведён обзор ключевых выводов о негативном влиянии киберинцидентов на стоимость акций из различных крупных исследований — правда, без ссылок на первоисточники🤷‍♀️
Дублировать текст не буду: достаточно взглянуть на скрин — там всё понятно и без перевода.

p.s. Ниже приведу ссылки на мои посты с обзором аналогичных исследований:
🔗Исследование Comparitech "How data breaches affect stock market share prices"
🔗Исследование "2024 True Cost of a Security Breach" от Extrahop
🔗Обзор влияния кибератак на курс акций компаний от 911Cyber
🔗Исследование о долгосрочном влиянии киберинцидентов на рыночную капитализацию компаний

#costs #breach #business #stock #market

На днях в рунете зафорсилась новость о том, что после апрельского взлома компании Take-Two и публикации злоумышленниками слитой информации рынок отреагировал очень позитивно и в моменте поднял капитализацию Take-Two на 1 млрд $ при росте акций на 2,63% за день🤑
Восприняли позитивно, так как в утекших документах была финансовая отчётность, декларирующая, что портфель игровых изданий, в т. ч. 12‑летней давности, до сих пор приносит большие деньги ежедневно.
Здесь впору делать диаметрально противоположные выводы: то ли искать зависимость рыночной капитализации от успешных кибератак бестолку, то ли этот случай — исключение и там всё не так очевидно.
На самом деле, если ознакомиться с текущей ситуацией вокруг компании Take-Two и ее будущего, то там действительно всё не так очевидно:
➡️Рост произошел довольно вовремя – до середины апреля акции компании падали на 25% от своего 52-недельного максимума, а ещё ведь их потенциально может поглотить Electronic Arts по цене в 25,74$ за акцию, что в 9 раз ниже текущей стоимости.
➡️Компании "повезло", что в утечке была только информация, составляющая коммерческую тайну, и при этом довольно приятная для инвесторов.
➡️Еще больше вопросов возникает с учетом того факта, что руководство компании за последние 90 дней совершило 26 сделок по продаже акций, в том числе и после публикации информации об утечке, а обратного выкупа акций не было🤨

А что если утечка не была случайностью? Может руководство хотело подстелить соломку? С одной стороны – не так дешево слить акции, а с другой стороны – подстраховаться и показать финансовую устойчивость перед потенциальным поглощением компанией EA, тем более что в мае ожидается финансовый отчет с не очень позитивными результатами😄

Пора завязывать с новостями про акции😅

#costs #breach #business #stock #market

Крупные страховые компании с начала 2026 года начали активно внедрять сублимиты и исключения в полисы по инцидентам, связанным с ИИ❌

В частности такие гиганты, как QBE и Beazley, ввели ограничение выплат в размере 10% от суммы покрытия полиса при LLMjacking (кража вычислительных мощностей ИИ-инструментов), а также сузили область действия полисов для иных ИИ‑инцидентов, "заручившись поддержкой" Insurance Services Office, которую называют «невидимой рукой» рынка, — организация ISO фактически санкционировала внесение изменений в стандартные страховые продукты, разрешив страховым компаниям запрашивать у клиентов приобретение специальных расширений полисов для покрытия ИИ‑инцидентов.
Оно и понятно: страховщики боятся разориться, так как для страховых случаев, связанных с ИИ, пока нет необходимого объёма исторических данных об инцидентах, выплатах и влиянии на бизнес, чтобы сформировалась рыночная и адекватная тарифная сетка и условия страхования.
К тому же существует проблема в распределении ответственности за инциденты: например, кто виноват в галлюцинациях ИИ или утечке данных через промпты – разработчик ИИ-инструмента, интегратор, который внедрял этот продукт или конечный пользователь?

Параллельно с ужесточением политик страховые компании начали выпускать гайды, в которых рассказывают об актуальных угрозах, направленных на ИИ‑инструменты, и о мерах митигации, которые можно нужно применять, чтобы не отказали в страховой выплате в случае инцидента.
Например, вышеупомянутая компания QBE выпустила руководство по защите от атак типа LLMjacking, где рекомендовала следующие меры защиты:
➡️Внедрение строгой политики ротации API-ключей каждые 30-90 дней.
➡️Использование уникальных API-ключей для различных сред (контура разработки, тестирования и продакшна).
➡️Удаленный административный доступ только с разрешенных ip-адресов.
➡️Настройка оповещений об использовании ресурсов и лимитов использования.
➡️Настройка оповещений о всплесках активности, которые могут указывать на вредоносное использование ресурсов.
➡️Отслеживание увеличения объема запросов или необычных шаблонов запросов.
➡️Логирование всех обращений к API с фиксаций того, кто совершил запрос.
➡️Аудит приложений на наличие жестко закодированных учетных данных в коде.
➡️Внедрение и регулярная проверка механизмов защиты от промпт-инъекций.
➡️Регулярные аудиты безопасности интеграций ИИ-систем.
➡️Разработка четкого плана реагирования при выявлении подозрительной активности и/или взлома.
➡️Внедрение технической возможности оперативного отзыва прав доступа для скомпрометированных учетных записей.
➡️Учет всех зависимостей, используемых ИИ-системами.

#llmjacking #insurance #ai #mitigation #guide

Awesome Large Language Models for Vulnerability Detection – репозиторий с коллекцией научных публикаций, посвященных применению больших языковых моделей (LLM) для обнаружения уязвимостей.
Помимо ссылок на публикации, есть ссылки на сами LLM-ки/скрипты🔥
p.s. Обновляется ежедневно.

#llm #vm #ai #research #vulnerability