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

Gartner
Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust

п. Шляпа 3 к.с.

Наверно, завершающая публикация о нашем летнем путешествии, предыдущие серии:
Часть 1. Общее описание и п. Яма
Часть 2. п. Котел
Часть 3. п. Карниз
Часть 4. Карельская природа

Порог Шляпа - последний на р. Тумча, после него река впадает в огромное Иовское водохранилище, на берегу которого у нас запланирован антистапель, и куда за нами приходил катер на следующий день, ибо идти на веслах от устья Тумчи до п. Зареченск нам не представлялось реальным. В течение 3,5 часов путешествия на катере от места антистапеля до Зареченска, я многократно убедился в правильности решения выброски катером, хотя история знала немало героев, кто успешно прогребал Иовское водохранилище, и даже без мотора.

До п. Шляпа в походном порядке (каяки, К2, К4) мы прошли без просмотра п. Каньонный, п. Змейка и еще какие-то, согласно описанию они где-то должны были быть. В 13:50 18.08.2025 встали на ЛБ перед п. Шляпа. На пороге было многолюдно - ребята катались по порогу на легком К2, затем подплывали в бочку и сражались со стихией - нос ката зажимало в бочку, корма приподнималась, гребцы гребли, вероятно, они отрабатывали разные сценарии оверкиля. Участники нашей экспедиции, кто наблюдал эти упражнения подольше, сообщили, что катающиеся достигли ожидаемого успеха и перевернулись. В этих упражнениях я усмотрел давний философский смысл, что все наши жизненные сложности мы создаем себе сами, что и закреплено в старой поговорке:

Дороже всего нам обходится собственная глупость

То, что я поначалу принял за ПБ оказалось островом, а за ним была живописная протока, по которой тоже можно было пройти. Но мы поши по основной - левой протоке. Согласно описанию проходить можно и ближе к острову с риском прижима к скале и ближе к ЛБ с риском упасть в яму. Мы пошли ближе к ЛБ, что позволило наблюдателям нас живописно снять (видео).

Порог мы прошли как запланировали, без каких-либо сложностей. Встали на ЛБ, с которым было очень много проблем: на пляже стояла группа из г.Иваново, у них тоже антистапель, а выше по берегу на поляне очень грязно и из земли торчали какие-то арматуры, что создавало риск покалечиться.

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

#здоровье

Автономные SOC

Последнее время все резко заговорили об автономном SOC: эфир AM Live (напишите, нужно ли писать заметку с комментариями ряда утверждений, а еще лучше - какие утверждения нужно прокомментировать), и Дэн написал заметку, приятель Игорь продолжает эксперименты с агентскими системами, поднимается воодушевление, но в то же время Gartner в декабре 2024 писал вполне адекватный док "Predict 2025: There Will Never Be an Autonomous SOC", есть и немало неплохих статей (например). В общем, видимо, надо поделиться мнением.

Уже 8 лет назад я рисовал что можно сделать с угрозой. Абстрактность описания этого принципа позволяет ему быть аксиоматичным, т.е. он прекрасно работает в условиях любой автоматизации. ML/DL - не что иное, как новые возможности по автоматизации. Если у нас некоторый автомат, - не важно что у него внутри: поиск битовых последовательностей в файле или действий в логе поведения, или пороги вероятности True positive в задаче регрессии при машобуче с учителем или отклонение от профиля при обучении без учителя, или там будет LLM-агент, запускающий автоматически реакцию для каких-то сценариев - умеющий автоматически выполнять инвазивные действия, то это всем нам давно известный сценарий, отмеченный на упоминаемой картинке как "Prevent", реализуемый исторически "антивирусом". Антивирусы начинались как файловые, но с расширением спектра применяемых тактик и техник атакующих, расширялись и технологические возможности средств защиты: подтянулась облачная поддержка (без подобного фанатизма, конечно же) и много других технологий, новички, в желании постричь уже зрелый рынок повторно, изобрели новые термины и подняли хайп "антивирусы мертвы" (или "антивирусы не нужны") - типичный пример говноPRа, когда вместо доказательств преимуществ своего решения фокусируются на недостатках конкурентов, нередко вымышленных и преувеличенных.

Все на той же картинке мы видим стрелочки, когда угрозу, обнаруженную вручную (Threat hunting) потом обнаруживают и, по возможности, предотвращают автоматически. Сейчас у нас [уже давно] есть новые возможности по автоматизации, которые, конечно же, используются. Машобуч, как и любая другая автоматизация, никогда не заменит полностью человека, иначе нас ждет конец. Любая работа при достижении определенного уровня профессионализма превращается в рутину, эту рутину будут автоматизировать, а человеку надо будет грызть новый гранит науки, снова сначала что-то делать вручную, затем это алгоритмизировать и передавать автоматам.

#vCISO #ml

Подписчик поделился видео.

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

Согласие, несогласие, дополнения, уточнения - приветствуются в комментариях!

#ml #саморазвитие #книги

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

#управление

Защитник короны

Мой первый компьютер - совместимый с ZX Spectrum, когда я был еще школьником в средней школе. На нем я писал программки на Basic, а еще, конечно же, играл. Помню, мне нравилась стратегическая игра Defender of the Crown. Действие игры происходит в средневековой Англии, сразу после смерти короля, когда различные фракции борются за контроль над страной. Игрок начинает игру за одного из саксов и пытается сражаться с ордами норманнов. Цель - получить контроль над большей территорией.

Одним из элементов игрового процесса были рыцарские турниры (Joust), где предлагается два вида ставки: за деньги (for money) и за славу (for fame).

Деньги были нужны для найма армий, проведения осад и содержания замков. Ставка "For Money" была более надежным, но менее прибыльным в долгосрочной перспективе способом пополнения казны.
Слава была критически важным параметром. Чем выше была слава, тем:
- чаще другие лорды предлагали союзы;
- больше солдат присоединялось к армии бесплатно во время путешествий по стране;
- проще было добиться поддержки в борьбе за трон.
Т.е. накопленная слава прибыльна в долгосрочной перспективе. Поэтому в зависимости от текущей ситуации в игре надо было понять когда нам нужен успех прямо сейчас (сражаемся за деньги) или на дальнем горизонте планирования (сражаемся за славу)

Эта маленькая, упрощенная функциональность игры неплохо отражает нашу действительность: нередко нам приходится выбирать между работой за деньги и работой за опыт. Почему так происходит - в новой небольшой статье.

#управление

Тем временем нас - красивое число!

Большое спасибо за доверие и интерес к моим рассуждениям!❤️

Едва ли мне удастся более подробно рассказать о нашей поездке в Тбилиси, чем это уже сделал Евгений Влентинович, но на одной непопулярной достопримечательности я, все же, остановлюсь - памятник Нико Пиросмани.

Лично мне эта скульптура, установленная в 1975 году по проекту скульптора-монументалиста Элгуджи Давидовича Амашукели показалась очень глубокой. Пиросмани изображён стоящим на коленях и держащим на руках овечку. Овечка - агнец - жертва, символизирует всю жизнь художника, смиренно, коленопреклоненно принесенную им в жертву ради искусства, которое было по достоинству оценено, но уже только после его трагичного ухода. А вокруг памятника - розовые кусты, поскольку знаменитая история из песни Пугачевой на стихи Андрея Вознесенского рассказыват о безответной любви Нико к французской актрисе Маргарите де Севр. Кстати, портрет Маргариты работы Нико нам всем хорошо известен и находится Государственном музее искусств Грузии, в Тбилиси. Но ряд работ Пиросмани также можно встретить и в Третьяковской галерее. В частности, я их видел на экспозиции Русского авангарда, и заметил, что скоро будет тематическая выставка - обязательно напишу, если удастся добраться.

#искусство

How to build AI agents into your SOC

Одним из положительных моментов путешествий является избыток свободного времени в аэропорту. На этот раз, по пути домой в столицу, мне наконец-то удалось закончить ознакомление с замечательным гайдом от Red Canary по созданию надежных и эффективных AI-агентов для интеграции в операционную работу SOC. Тема мне небезразлична, поэтому поделюсь мыслями из доки. Сразу замечу, что если вы уже имеете хоть какой-то практический опыт написания агентов, хотя бы на уровне упомянутого здесь курса, то дока покажется вам скучной, но для начинающих джедаев материал может стать неплохой базой, упорядочивающей понимание и перечисляющей очевидные грабли, которые можно обойти.

Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либо программному болвану AI-агенту, никакая формализация не может быть лишней. Основной тезис документа: надежность важнее новизны, поэтому ключ к успеху лежит не в использовании самой передовой модели, а в построении детерминированных рабочих процессов, строгих ограничений и постоянном измерении результатов. Документ содержит не только теоретические основы, но и практические примеры на Git, а кто любит за трапезой посмотреть что-то полезное есть видео на Youtube Elevate and empower your SOC with AI.

Ключевые принципы построения надежных AI-агентов
1. Структура и Детерминизм. Большие языковые модели по своей природе вероятностны и могут давать разные результаты при одних и тех же входных данных. Для SOC это недопустимо, так как критически важна повторяемость, поэтому Канарейки рекомендуют использовать детерминированную оркестрацию в сочетании с ограниченным рассуждением агентов: задачи разбиваются на явные, небольшие шаги, а агенты используются только там, где их вероятностная природа может приносить пользу (например, для анализа и корреляции), а не для принятия ключевых решений.

2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.

Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.

В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.

#ml #MDR

Red Canary. How to build AI agents into your SOC