Мужчина становится мужчиной только после того, как он завоюет любовь женщины.

С праздником, мужчины!

Для составления объективной картины действительности хорошим методом является потребление большого количества информации из разных источников. Это относится и к составлению понимания ландшафта угроз, которое так важно для объективной оценки рисков. Однако, важно понимать, что Аналитический отчет MSSP - это отражение его видения, сильно искажающее действительность. Эти искажения нужно понимать, и, при построении собственного мнения, уметь их нивелировать. Ввиду этих же искажений нельзя просто сопоставлять отчеты разных поставщиков, а сами отчеты должны отвечать на многие вопросы, в том числе и по методологии, чтобы их контент был в принципе интерпретируемым.

Обо всем этом рассуждал в своей новой статье об искажениях\отражениях MSSP в своих аналитических отчетах.
https://dzen.ru/a/ZdcunHptMCiNsNeE

#vCISO

Когда клиентская база достаточно большая, дополнительный объем в 10к новых эндпоинтов в мониторинг не требует дополнительных ресурсов. Однако 100 клиентов по 100 - совсем не одно и то же, что 10 клиентов по 1000 или, тем более, 1 клиент с 10 000 эндпоинтов! И причина тому - необходимость адаптации. После этой заметки, думаю, станет понятнее почему малое количество крупных клиентов на долго проще в обслуживании множества мелких с короткими периодами обслуживания.

99% ложных срабатываний связаны с особенностями заказчиков, поэтому для огромного количества правил обнаружения есть клиентские фильтры, - чем больше клиентов, тем больше клиентских фильтров. Фильтрами надо управлять, отслеживать что они фильтруют фолсу и, что еще важнее, - не фильтруют инциденты. В общем, создание фильтра - это только начало, далее следует нелегкий процесс управления клиентскими фильтрами. Средняя продолжительность адаптации одного клиента среднего размера (до 10 000 эндпоинтов) составляет 1-2 месяца, т.е. за это время большая часть его контекстной фолсы будет отфльтрована (== фолсящие на сети клиента правила будут адаптированы), далее эта адаптация будет продолжаться постоянно, догоняя процесс управления изменениями в ИТ-инфраструктуре клиента. На период адаптации трудоемкость по обработке алертов с клиента увеличивается примерно в 2 раза, как раз за счет необходимости реализации адаптации (== фильтровать контекстную фолсу).

Понятно, что если фильтры не делать, то контекстной фолсы будет очень много, и это будет сильно снижать эффективность работы команды: все будут заняты разбором ложных срабатываний, что не может не отразиться на усталости\утомленности и, в конечном счете, результате работы. Но это в долгосрочной перспективе. В краткосрочной перспективе мы имеем х2 трудоемкости без очевидного выхлопа по качеству обнаружения.

Простота подключения к MDR делает возможным множество пилотов, поэтому, усредненно по году по миру 20-30% объема мониторинга - пилоты. Продолжительность пилота - 1 месяц... и здесь следует заметить, что а) поскольку не всегда есть уверенность, что клиент после пилота станет коммерческим клиентом, адаптация на пилоте делается по-минимуму, не в указанные выше х2 трудоемкости, б) месяца пилота недостаточно чтобы закончить процесс адаптации, в) даже если уложимся в месяц, увидеть результат в долгосрочной перспективе - не судьба😔. Как результат, фолсы на пилоте очень много и с ней приходится мириться, ввиду всего описанного. Следовательно, совокупная конверсия детектирующей логики на пилотах ощутимо ниже, а если пилоты берутся во внимание при расчете общей конверсии по всем клиентам (и пилотам, и коммерческим), то описанная ситуация с пилотами приводит к снижению общей конверсии.

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

Поэтому, чтобы популярность техник у разных провайдеров была сравнима, нужно чтобы сенсоры в частности и возможности по обнаружению вообще были одинаковы, хотя бы примерно

За вычетом геополитического налёта и аттрибуции, достаточно полезное чтиво

https://www.ncsc.gov.uk/news/svr-cyber-actors-adapt-tactics-for-initial-cloud-access

Не могу не поделиться нашим поздравлением друг друга с 238 мартраля!

Есть мнение, что надо строго разделять работу и неработу, я с этим согласен лишь отчасти. Как бы мы не пытались быть сдержанными и формальными, все равно отношения в коллективе не всегда удается ограничить исключительно производственными. Поэтому наше человеческое, наши психологические особенности влияют (а во многом и определяют!) на то, как мы работаем.

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

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

Можно сказать, что сегодня юбилей альбома "The Time of the Oath" группы Helloween. Альбом увидел свет 29 февраля 1996 года, 28 лет назад. Не так много вещей в Helloween мне нравились, но среди них есть немало и из "эпохи Дериса", и из "эпохи Киске". И вроде бы ничего особенного, мне нравится совершенно разная музыка, причем увлечения заметно меняются во времени, но неизменно близкими остаются композиции с историей.

У меня есть замечательный друг, вокалист-природник, Олег Савченко. Мы любили собраться в его гостеприимном доме, попеть в караоке. И где-то в 2013-2015 Олег напомнил мне о Forever and one, которую я слышал и ранее, но как-то подзабыл. Вот тут я и решил ее разучить.
Оригинальная тональность мне не удобна, на высоких нотах получалось грязновато, но, пониженная на 2, оказалась вполне рабочей. И в январе 2016, аккурат в 20-летний юбилей альбома, я записал ее в студии на конкурс "Роснефть зажигает звезды" (тогда я работал в Роснефти, а, имея с детства не реализованные мечты театрального актера, и тогда и сейчас стараюсь не пропускать возможность поучаствовать во всякого рода самодеятельности).

Итак, вашему вниманию предлагается мой вариант Forever and one 8-летней давности, не судите строго, зато от души. В комментарий к этой заметке заброшу отдельно аудио-дорожку.

#музыка

Конверсия, Вклад и Адаптация

На конференции PHD я немного коснулся метрик качества правил обнаружения, будем называть их "ханты" (официальное название - IoA, Indicator of attack), - конверсии и вклада. Коротко напомню, что конверсия - это отношение количества True positive алертов к общему количеству алертов по данному ханту, фактически, это True positive rate (TPR) ханта. Конверсия измеряет эффективность (effectiveness) ханта, т.е. из множества "выстрелов" данного ханта сколько попало в цель.
Вклад - это отношение True postive алертов по данному ханту к общему количеству True postive алертов, или, что лучше отражает смысл - отношение инцидентов, выявленных с помощью данного ханта, к общему количеству инцидентов, т.е. какую долю инцидентов мы находим непосредственно с помощью этого ханта. Вклад измеряет результативность (efficiency) ханта, т.е. из множества попавших в цель выстрелов, сколько будут из данного ханта.

Конверсия - один из годовых KPI команды Detection Engineering-а, с начала времен работ по созданию детектов. На начальных этапах развития погрешностями измерения конверсии, связанными с проблемами адаптации, пренебрегали. Но с повышением как самого значения конверсии по хантам, так и уровня зрелости процессов разработки детектов, захотелось минимизировать погрешность адаптации.

С начала этого года в регулярных метриках хантов начали учитывать четыре разные конверсии - для каждого типа клиентов. А типы пока ввели следующие:
- com - коммерческий клиент, для которого прошел период адаптации (пока настроили статично: прошло 60 дней с начала работ, в перспективе, этот период можно сделать динамическим, может даже вычисляемым с использованием ML, в зависимости от клиента, так как для разных клиентов адаптация длится разное время)
- poc - пилотный проект
- new - коммерческий клиент, для которого период адаптации еще не закончен (еще не прошли 60 дней с момента начала работ)
- not_mdr - клиенты, с которыми работа проводится по сценарию MDR, но в рамках других проектов - например, облачный сценарий Compromise Assessment.

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

Ах да, чуть не забыл, в KPI команде исследований будем ставить конверсию по com-клиентам.

Досмотрел! До эфира у меня было четкое понимание purple teaming-а, но во время эфира оно стало размываться, глубоко интерферируя с red-teaming-ом, пентестами, багбаунти, BAS-ами и прочими платформами автоматизации ИБ. Спасибо Сергею Повышеву из Северсталь Менеджмент, который подключился в середине дискуссии и вернул диалог в конкретные практические вещи. После его включения, я снова обрел уверенность в четкости своего понимания purple-teaming-а.

У меня много драфтов статей, которые я по разным причинам не закончил, есть и про purple teaming. После эфира я понял, что обязательно надо найти время и довести ее до конца, поскольку сам часто обращаюсь к термину «purple teaming», и мне нужно обозначить границы того, что я под этим понимаю, ибо каких-то «общеизвестных» или «всем понятных», как я понял из эфира, нет.

Несколько лет назад, одна моя знакомая, Зена Олсен, писала диссертацию по теме Enterprise Purple Teaming, я был одним из респондентов, мы обсуждали эту тему в разных перспективах. В рамках подготовки к диссертации Зена собрала достаточно материалов по теме, думаю, для понимания, этот каталог ресурсов будет полезен:
https://github.com/ch33r10/EnterprisePurpleTeaming

Positive Hack Days - замечательное мероприятие! Здесь можно встретить тех, кого давно не видел, пообщаться вживую (помним, что более 65% информации передается невербально!), познакомиться с новыми интересными людьми, в конце концов послушать интересные доклады и просто ментально отдохнуть...

15.03 - окончание приема заявок от потенциальных спикеров, т.е. у нас с вами только 10 дней!
Я подался в бизнес-секцию на этот раз, а вы?

Надеюсь, увидимся!

Дорогие дамы, девушки, женщины, красавицы, умницы, люди с активной жизненной позицией, кибер-леди и ИТ-богини!

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

Март, весна – начало года,
Начло новых дел, задач.
Успехов вам во всем! Удач!
И достойного дохода!

Не надо нового бояться,
Оно - движения вперед.
Кто, ошибаясь, исправлялся
С годами мудрость обретет.

Жалю я, чтобы сквозь годы
Вы прошли бы без потерь,
И назло временным невзгодам
От счастья ключ нашел бы дверь!

Поздравляю вас с Международным женским днем! Пусть у нас с вами все получится, а я буду стараться изо всех сил радовать интересным контентом!

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

Мои коллеги из команды DFI разработали плейбук, ссылкой на который я с удовольствием делюсь.

Как обещал, делюсь размышлениями относительно фиолетовых команд. С учетом текущей своей профдеформации, Фиолетовые для меня, в первую очередь, конечно же, команда Detection engineering-а. Их задача – разработка детектирующей логики, и даже шире, поскольку чтобы что-то продетектить нужны события, их обогащение и обработка, а чтобы сработавший алерт приносил результат, он должен быть корректно обработан командой мониторинга, т.е. должны быть плейбуки и ранбуки.

Откуда же команда Detection engineering-а берет идеи для правил обнаружения? Да откуда угодно! Но, с полным пониманием того, что неразумно пытаться объять необъятное, поэтому фокусируясь в первую очередь на том, что действительно стреляет. Эксперты по управлению уязвимостями используют термин «трендовая уязвимость», с тем же смыслом можно придумать термин типа «трендовых ТТР» – на них в первую очередь и фокусируются Фиолетовые Detection engineer-ы.

Вопрос степени «трендовости» ТТР неоднозначен, так как, если какая-то ТТР не популярна в объеме исследований нашей TI-команды, это не означает, что мы не будем через нее атакованы, а, следовательно, не надо беспокоиться о ее покрытии правилами обнаружения. Но лично я считаю, что есть сценарий, когда вероятность использования ТТР близка к 100% – это анализ защищенности, поскольку факт применения ТТР налицо!

В небольшой заметке я как раз и порассуждал об этом сценарии работы Фиолетовой команды. По опыту замечу, что разобрать отчет от Красных, составить план и добиться его исполнения – вполне себе непростой проект. И лично мое мнение, purple-teaming – прекрасное поле для консалтинга. Объем проекта может быть следующий:
– Составление ТЗ на анализ защищенности
– Опционально: проведение анализа защищенности (может быть и другой поставщик)
– Приемка результата анализа защищенности
– Анализ отчета Красных, формирование плана мероприятий (~ЧТЗ на проект повышения уровня ИБ по результатам анализа защищенности)
– Консалтинг в рамках проекта реализации выработанного плана мероприятий
Любой консалтинг-проект – уникален, поэтому объем, конечно же, обсуждаем!

А вы что думаете о Фиолетовом консалтинге?

#vCISO