На своем маршруте от Пушкина до Лермонтова (из SVO в MRV) листал интересный документ. Спасибо другу и коллеге Игорю, что поделился.

В документе, стандартно, перечислены наиболее популярные техники, к ним притянуты за уши контроли из 53-его NIST и рекомендации по обнаружению из той же MITRE.

Но наиболее интересное, на мой взгляд, начинается на странице 35, разделе Technique Sightings Co-Occurrence Analysis. В документе не содержится много информации, и

Co-occurrence analysis is an emerging area of ATT&CK analysis that begins to address the defenders’ need for sequence information. The Center is currently working on a related project called Attack Flow to develop a shareable data format, visualization tools, and examples to represent sequences (flows) of attacks. Stay tuned for more to come on that project

Стремления MITRE полностью пересекаются с моими последними увлечениями. В прошлом году я уже писал про анализ комбинаций, в этом году я поисследую последовательности событий, что, в общем-то, ровно то же, что делает MITRE со своими flow.

#MDR

На прошлой неделе вышел отчет по статистикам работы MDR в 2024. Как отмечал, не все наблюдения получается вместить в отчет, поэтому позволю себе ряд заметок по отсутствующим в отчете интересным статистикам. Сегодня поговорим про типы High severity инцидентов.

Итак, мы различаем следующие типы инцидентов критичности High:
- inc_apt - целевые атаки или в общем случае любая активность, где заметно непсредственное участие человека (human driven)
- inc_apt_trace - артефакты прошлых человекоуправляемых атак, но на момент обнаружения атака не была в активной фаза
- inc_rt - тоже человекоуправляемая атака, однако, заказчик подтвердил, что активность легитимная, что это - какие-либо киберучения
- inc_sec_policy_h - обнаружена подозрительная активность, выполненная от учетных записей, для которых не оснований считать, что они были скомпрометированы
- inc_insider_impact - такая же активность, выполненная от легитимных нескомпрометированных УЗ, но заказчик явно подтвердил, что имеет место работа внутреннего злоумышленника
- inc_mw_impact - инцидент, связанный с работой ВПО без непосредственного участия человека-атакующего, но потенциальный или фактический ущерб большой
- inc_se_impact - успешная социальная инженерия с развитием, с потенциальным или фактическим большим ущербом, возможно, атрибутированная к известным целевым кампаниям
- inc_vuln_impact - обнаружение критической уязвимости, эксплуатация которой очень вероятна
- inc_dos_impact - обнаружение [D]DOS атаки с потенциальным или фактическим большим ущербом

Ежегодно мы даем статистику распределения high severity инцидентов по этим типам, обычные лидеры - inc_apt, inc_mw_impact, inc_apt_trace, inc_rt. С прошлого года была введена inc_sec_policy_h, как возможность уточнения inc_insider, который также нередко занимал значимую долю.

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

21-ый год был выдающимся по количеству high severity инцидентов (14,34%) но в том же 2021 наблюдалась и наибольшая доля человекоуправляемых атак - 40,66% от общего количества критичных инцидентов (инцидентов с severity High). 2024 был не менее интересным: не смотря на малую долю high инцидентов (4,69%), процент inc_apt был наибольший за историю наблюдения с 2020 - 43,01%.

#MDR

В блоге Бизона увидел ссылку на прекрасную статью Виталия Моргунова о EDR. Мне статья очень понравилась, да и Виталий - замечательный эксперт, чьи публикации нечасты, но их крайне полезно просматривать, а экспертиза Бизона не вызывает сомнений - это замечательная компания, одна из немногих на нашем рынке, которой на месте заказчика я бы доверился (после ЛК, конечно же 😁 ).

Но как раз потому, что мне далеко небезразлично что пишет Бизон вообще и Виталий в частности, позволю себе не согласиться с идеей выделения EDR из состава EPP, так как это, на мой взгляд, формирует некорректное понимание рынка решений по безопасности как потребителями, так и производителями. Поток сознания на эту тему я изложил в небольшой статье.

Я не претендую на истину и никого ни в чем не убеждаю, просто делюсь собственным мнением - это относится ко всем моим публикациям.

#MDR

Мой коллега и друг, Доменико, прекрасный аналитик SOC, исключительный профессионал, для кого работа в операционке - не только рутина, но и возможность поисследовать интересные атаки, коих немало, действительно, каждый видит мир ровно так, как желает его видеть, сегодня стартовал серию статей по мотивом реальных инцидентов MDR.

Сегодня вышла первая статья

#MDR

MS в январе выпустило исследование Lessons from Red Teaming 100 Generative AI Products - блог, документ.

За вычетом маркетинга, что они такие молодцы, что одними из первых, аж с 2018, начали заниматься безопасностью ИИ, и что безопасность - основной принцип их ИИ-решений, в очередной раз муссировалась идея, что ИИ - как и любая новая технология, расширяет поверхность атаки - это мы уже обсуждали здесь, вместе с "Зенитными кодексами Аль-Эфесби"

В блоге выделены 3 важные идеи, но все 8 заслуживают внимания.

1. Understand what the system can do and where it is applied - когда исследуем безопасность ИИ-системы, надо разобраться в сценариях ее использования.

2. You don’t have to compute gradients to break an AI system - ИИ-пентестеры это промпт-инженеры. Почему-то вспомнились темы манипуляций и ведения переговоров (даю ссылки на неплохие, я бы сказал, базовые, книжки по этим темам, рекомендую к прочтению), только, очевидно, с машиной договориться проще, чем с человеком, иначе тест Тьюринга не работал бы 😁

3. AI red teaming is not safety benchmarking - бенчмаркинг не очень хорошо работает в случае с ИИ (хотя, наличие бенчмаркингов все равно лучше, чем их отсутствие), т.е. какого-то перечня проверок, прохождение которых будет давать уверенность в том, что моя ИИ - безопасна, не может быть, так как теоретически можно найти бесконечное количество уязвимостей - этим и занимаются ИИ-пентестеры, для этого им и надо понимать сценарии использования, чтобы хоть как-то сузить область исследований. Хотя, таким же динозаврам бумажной ИБ, как и я сам, известен основной принцип безопасности - принцип минимума полномочий\функционала, т.е. все что не используется должно быть выключено - ИИ, ввиду своей универсальности, этому принципу не соответствует

4. Automation can help cover more of the risk landscape - поскольку у нас бесконечная (ну, или очень большая) поверхность атаки, очевидно, автоматизации поможет выявить больше уязвимостей

5. The human element of AI red teaming is crucial - никто не сравнится с Человеком в умении обманывать\манипулировать\разводить\эффективно вести переговоры с ИИ

6. Responsible AI harms are pervasive but difficult to measure - очень сложно как-либо оценить безопасность ИИ (рассматриваем RAI), поскольку, ввиду вероятностности работы, нередки ситуации, когда ИИ выдает вредоносный ответ на безобидный запрос (запрос без злого умысла)

7. LLMs amplify existing security risks and introduce new ones - здесь все понятно: новая функциональность -> новые вектора атак -> новые риски

8. The work of securing AI systems will never be complete - выше уже писал, что поверхность атаки сложно оценить, а то, что нельзя инвентаризировать, невозможно защитить, поэтому эти Авгиевы конюшни нам не вычистить никогда, об этом тоже писал

#ml #книги

Трудно не согласиться с доводами Саши.
Ну что ж поделать...

Все более-менее объемные (когда написание занимает более 30 мин) мысли я публикую в Дзен. Старые публикации доступны еще на blogspot, также там можно встретить мысли моих бывших коллег и друзей - Игоря и Амирана.

С пропаданием Телеги, видимо, будем на связи в Дзен.
Не потеряемся!

#РФ #мир