На мероприятии меня заинтересовали несколько докладов с которыми я запланировал познакомиться поближе. Делюсь.

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

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

Автоаналиитка придумали в 2018, и, ЕМНИП, уже в 2020 году он был уже на проде. О нем много написано, коллеги по индустрии снабдили его новыми замечательными идеями (некоторые мы проверяли на старте, но они тогда не дали результата, а после доклада появилась мотивация их проверить заново), но заметка сегодня не о том.

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

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

Как наши дети - отражение нас, так и наши ML-помощники отражают насколько мы хорошо работаем на самом деле.

#MDR

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

Но проблема не только в том, что внешние злоумышленники ломают сети и воруют данные! Который раз самостоятельно замечаю, что всегда, когда я беру ипотеку или покупаю страховку, об этом волшебным образом узнают разные мутные люди, которые начинают мне названивать как с целью предложить "лучшие условия", так и просто мошенники представляющиеся "сотрудниками мобильного оператора", "майорами ФСБ или МВД", "сотрудниками банка" и прочими-прочими. Из чего делается неутешительный вывод, что сотрудники воруют данных не меньше, чем внешние злоумышленники. Но об этом порассуждаем как-нибудь потом, а пока вернемся к внешним атакующим.

Есть такие специализированные системы, DLP. Работая в заказчике, я изучал этот вопрос, занимался выбором подходящего решения, о чем написано несколько статей в старом блоге: раз, два, три. Однако, некий скепсис в эффективности DLP, как технологического решения организационной проблемы, у меня до сих пор сохранился. Вот и сейчас мне интересно: в тех компаниях, у кого фиксировались утечки, использовались DLP? Насколько эффективно они сработали? А если утечка произошла, проводился ли какой-либо анализ, что помешало DLP выполнить единственную свою задачу и предотвратить утечку?

Если есть подобные исследования\разборы Lessons learned или хотя бы маркетинговые листовки о том, как какое-либо решение DLP предотвращает утечки на примере какой-то фактической утечки, пожалуйста, дайте ссылки в комментариях. Буду очень благодарен.

#vCISO

Какое-то время назад мой знакомый Миша у себя в канале опубликовал список книг по невербальной коммуникации. Я не очень верю в эффективность всяких коучей личностного роста (тем более, эзотериков), однако, книжки по психологии, коммуникациям и, связанными с этим, манипулятивным техникам, и даже, было дело, гипнозу, я частенько почитываю, а также уверен в важности невербального общения, о чем рассуждал здесь (ну, конечно, без перегибов 😂). Поэтому списочек книг из Мишиной диссертации для себя прикопал. Делюсь и с вами.

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

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

Ну а если серьезно, то в моём понимании ФинСерт-у как раз и стоит сфокусироваться именно на мошенничестве и прочих схемах, завязанных именно на банковскую специфику, а блокировать MD5-ки новых образцов ВПО можно сохранить за специализированными вендорами. Фокусировка усилий - залог успеха, и фокусироваться надо туда, где иные участники ничего не делают. Например, антивирусные вендоры едва ли погружаются в схемы мошенничества, но в борьбе с техниками и инструментами атакующих они точно эффективнее, чем движок на основе ВПО-фида ФинСерт). Отраслевым SOC с вендорами и внутренними командами надо строить гибридную модель, тогда у каждого получится занимать тем, где он наиболее осведомлен и результативен.

#vCISO

Если у вас есть интересные исследования, то рекомендую воспользоваться возможностью посетить SAS2024.

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

Мои коллеги из команды SOC Consulting подготовили статью об использовании MITRE для приоритезации бэклога разработки детектирующей логики. Также по теме можно посмотреть вебинар, правда, на иностранном языке. Может быть полезно для команд так или иначе связанных с Detection engineering-ом, а также поклонников MITRE ATT&CK.

#MDR

Сашу Зайцева, нашего Head of Offensive всегда интересно послушать!

Иногда наши эксперты разговаривают не только кодами, но и голосом. В подкасте «Смени пароль» – серьёзный разговор про становление героя, который более 20 лет занимается оффенсивом (конечно же, только этические пентесты и «красные команды»). Как всё начиналось, как устроена эта профессия сейчас и с какими проблемами сталкиваются пентестеры в своей работе – рассказывает Александр Зайцев:

«В школе тебе дарят 286 компьютер, работающий на частоте 12,5 МГц, его потенциально можно подключить к Интернету по диалапу на скорости 9600 бод. Правда, диалап очень платный, надо искать демо-доступы, обзвонить кучу систем, найти гейты в сеть X.25, оттуда искать возможность зацепиться по PPP и вообще понять, где ты находишься и куда тебя выпустит… Тогда это был необходимый клубок вещей, которые нужно знать, если ты хотел получать доступ к растущим объёмам недоступной ранее информации. Сама среда задавала высокий порог входа.»

Слушать тут: https://podcast.ru/e/7Y9dddSWOjk

А другой выпуск того же подкаста посвящён тяжёлой доле специалистов по AppSec, которые анализируют защищённость веб-приложений:

«Печально, когда заказчик не верит в уязвимость и не может понять, как воспроизвести атаку. Ему уже и скрипт скинули, а он всё говорит, что у него есть защита от такого брутфорса. Приходится очень долго объяснять, даже записывать видео с атакой».

Слушать тут: https://podcast.ru/e/9dn8sQEP7wP

Не могу сказать, что Дуолинго - супер эффективный инструмент для изучения иностранных языков. Да и с учётом последних достижений LLM необходимость в изучении иностранных языков становится все призрачней...

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

#саморазвитие

PS: в августе я две недели в водном походе на Кольском, без связи, жалко, что красивые 1234 сгорят 😢 но мы их компенсируем замечательными пейзажами Карелии 😁 !!

Стали доступны видео докладов с прошедшей конференции CloudNativeSecurityCon North America 2024. Слайды доступны на сайте конференции.

Определенно рекомендуем ознакомиться с ними.

Сегодня на Cyber Media вышла обзорная статья про Compromise Assessment (CA).

Исходя из названия, в статье рассказывают что из себя представляет услуга CA и кому она нужна. С составом работ и анализируемыми источниками опрошенные респонденты в статье более-менее справились (добавлю, разве что, только Customer-specific Threat intelligence, что позволит более внимательно отнестись к релевантным угрозам), а вот по части зачем CISO нужен CA приведено не совсем все. Наша команда практически с запуска MDR предоставляет и CA, поэтому позволю себе добавить ряд критериев необходимости проведения СА.

В статье написано, в частности, следующее:

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

Assume breach - основной принцип Threat hunting-а, поэтому зрелая контора находится в постоянном поиске следов компрометации, однако, приглашать внешнюю команду точно надо, если:
- поломали партнера (Trusted relationship и Supply chain мы и в MDR видим достаточно часто)
- поломали коллегу по индустрии (помнится как ребята с Cobalt strike ломали банки, если нас почему-то пока нет, то лучше провериться)
- откуда-то появилась информация, что нас поломали (откуда угодно), однако, никаких свидетельств компрометации мы в своих системах не нашли (окончание цитаты выше "...или были обнаружены следы взлома" некорректно, так как есть обнаружены следы взлома => взлом налицо => надо инициировать проект DFIR )
- сценарий M&A (отмечен в статье) или\и любой инфраструктурной интеграции, когда мы соединяем сеть с известным уровнем обеспечения ИБ с сетью с неизвестным уровнем ИБ
- внедрение новых решений обеспечения безопасности, особенно тех, что работают на "аномалиях" (как ни крути, но навесные решения ИБ зависят от "чистоты" инфраструктуры, особенно в момент инсталляции. Любой уровень выше зависит от безопасности уровня ниже (безопасность прикладного ПО, зависит от безопасности системного ПО, безопасность системного ПО - от безопасности аппратного обеспечения и т.п.)
- в ряде стран, например, в Саудовской Аравии, CA требуется для соответствия требованиям местного регулятора (с регуляторным драйвером для рынка ИБ не все замечательно, но, тем не менее, если заказчику не все равно, регулятор может стать хорошим катализатором)

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

#vCISO

Коллеги из нашей команды Detection engineering-а продолжают радовать новыми исследованиями, в общем-то, уже далеко не новых тем - Kerberos, ADCS и повышение привилегий.

#mdr

Gartner Market Guide for Managed Detection and Response

На днях проскакивал свежий документ Gartner об MDR, прилагаю.

Что там, на мой взгляд, полезного\интересного:
- ключевые и опциональные возможности предложения
- интересно про Threat hunting: какой-то "every day" - часть предложения, а по клиентским запросам - возможно в рамках отдельного сервиса
- частыми дополнениями к MDR предлагаются "exposure validation" (в качестве примера приводится BAS и "offensive exercises") и, понятное дело, DFIR
- заказчики не влияют на детектирующую логику MDR и не должны ожидать ее глубокой кастомизации, однако, поставляют информацию для реализации корректных сценариев обнаружения, например, информацию о критических бизнес функциях и активах, и т.п.
- однако, глубока кастомизация может быть дополнительным компонентом предложения
- разные профили заказчиков MDR и какие их потребности закрываются (MDR будет пригоден для любого заказчика)
- есть предложения MDR с расширениями для Internet of Things (IoT), Cyber-Physical Security (CPS) Systems и Operational Technology (OT)
- некоторые поставщик под MDR понимают немного иное, чем Gartner, в частности:
-- Co-managed security monitoring, когда MDR - расширение над EDR
-- SOC as a service - полноценный SOC (возможно, в составе предложения MSSP), вплоть до аутстаффинга
- некотореы поставщики MDR готовы работать с источниками телеметрии, имеющимися у заказчиков, но с ограничениями
- заказчики рассматривают MDR как усиление возможностей существующего in-house SOC и ожидают от поставщика MDR расследования, локализации инцидента и сокращения поверхности атаки (exposure reduction, для тех кто поставляет такой сервисный компонент)
- заказчики ожидают от поставщика MDR активного реагирования на выявленные инциденты, однако, только по согласованию заказчика
- несколько раз отмечается тенденция на необходимость Exposure management в предложении MDR
- многие поставщики MDR предлагают заказчикам сервис\интерфейс самообслуживания, где можно посмотреть что "под капотом" и как-то поуправялть объемом и некоторыми настройками, но без влияния на качество обнаружения
- наиболее интересная часть - репрезентативный с т.з. Гартнера список поставщиков, где подавляющее большинство компаний - из США, одна из Канады, не более пяти из Европы, ни одной из APAC, META и Латинской Америки, ни одной из РФ и СНГ, что лишний раз подтверждает ориентированность Gartner исключительно на рынок США, что не плохо и не хорошо, но что обязательно надо учитывать при принятии каких-либо управленческих решений на основе текстов Gartner

Приятного чтения!

#MDR #vCISO

Читатели нашего канала недавно поделились с нами своей статьей "Threat Detection in the K8s Environment" в которой рассказывают об опыте работы своего SOC в Kubernetes. В статье идет речь про кастомный Tetragon и анализ Kubernetes Audit Log. К правилам/сигнатурам для Tetragon (как и ко всем правилам) есть вопросы, но вот Audit Policy (она полностью приводится в статье и ее можно взять за базу) и сценарии анализа ее результатов очень классные. Единственное, что на наш взгляд тут можно было бы добавить это сочетание использования с PolicyEngine (в статье о данном клаcсе решений ничего не говориться), чтобы предотвратить множество кейсов и не доводить их до расследования вообще.

В общем, очень рекомендуем для изучения (ребята молодцы!), особенно в преддверии нашего сегодняшнего вебинара «Ловим злоумышленников и собираем улики в контейнерах Kubernetes» в 11:00, где мы покажем как, на пример, можно ловить переименования бинарей (для bypass rules) вообще без правил/сигнатур/аномалий и при этом собрать артефакты для forensic ;)

P.S. Если вы написали статью или инструмент по тематике канала, то не стесняйтесь скидывать =)

Два года, с 2001 по 2002, еще будучи студентом, я работал программистом, писал на Perl и C под Unix (FreeBSD, Solaris). В то время мне здорово помогали книжки с готовыми решениями типовых задач, типа Perl Cookbook или Операционная система Unix, где приведены конкретные фрагменты кода (написанные правильно, в хорошем стиле), которые можно забирать к себе в проект... Вообще, таких Cookbook-ов можно найти на любом языке: для Java вспоминается книжка Коли Смирнова (Коля преподавал у нас на кафедре), для С++ я использовал ровно вот эту Терренса Чана. Еще раньше, когда я только погружался в С, мне здорово помогла классическая - Керниган, Ритчи, где также было полно примеров кода, которые можно брать и играться, эксперементировать... В общем, думаю, мне удалось быть убедительным, что книжки с готовыми примерами кода, с которыми можно эксперементировать, крайне полезны для погружения

Не раз писал, что я фанат онлайн обучения (может, когда-нибудь распишу подробно почему учиться - это здорово, а учиться онлайн - это еще и удобно), так вот, прослушивая очередной курс, ну конечно же про машинное обучение (!), я набрел на неплохую книжку про pandas (Effective Pandas), которой с удовольствием делюсь в этой заметке. В книжке приведена масса конкретных примеров, с комментариями и пояснениями, с которыми можно эксперементировать и таким образом изучать, в общем, как все как я люблю!

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

Ну вот, потихоньку, начинают появляться исследования по использованию роботов для эксплуатации зеродеев, т.е. температура LLM здесь уже явно не 0, модель находит то, чему не могла учиться (0-day), однако результат ее работы попадает в цели.

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

#mdr #ml

Восстановление открытого ключа по подписи

При разработке криптосхем во внимание берутся модели нарушителя. Ну, например, можно вспомнить классические атаки типа Known-plaintext, когда известны открытый текст и шифртекст, задача - найти ключ (кстати, ЕМНИП, эта атака была реализована на небезызвестную немецкую Энигму, поскольку в начале шифрованного сообщения передавались сводки погоды, которые были более-менее предсказуемы), или Chosen-plaintext, когда открытый текст нам не просто известен, а мы можем его выбирать...

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

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

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

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

За окном уже 21 июля, а сообщество продолжает обсуждать Crowdstrike, прослеживаются и как цель попродвигать свои подходы\продукты (потанцевать на костях), так и почти искреннее желание извлечь уроки, попытаться учиться на чужих ошибках.

Не хочется ощущать себя хайполовом, да и что бы я по этому поводу не сказал, гарантировано, невозможно быть находчивым, в общем, не написал об этом ни строчки (хотя, наврал, были комментарии).

Поэтому передаю послушать моего коллегу Володю Дащенко в студии РБК.

В интервью проскользнула мысль, что мы становимся супер-зависимыми от цифровых технологий и что решение - выезжать в лес и жечь костер. В точку! Я писал, любая наша зависимость от чего-то - это ограничение нашей свободы, а нам надо оставаться могучими ("могущими многое")... В общем, в этом году, в первые две недели августа, как и во многие предыдущие годы, я отправляюсь в водный поход, в этот раз - на Кольский, где у меня будет прекрасная возможность, в очередной раз, потренировать свою могучесть, проверить насколько я привязан к бытовому комфорту, насколько погода и насекомые способны определять мое настроение, провести переоценку ценностей, заново полюбить вещи, к которым мы уже привыкли и не замечаем... в общем, первые две неделе августа - не теряйте. Но, пробую пообещать, что напишу отчет и поделюсь им здесь с тегом #здоровье 😁

Всем добра, а обновления тестируйте в типовых окружениях и накатывайте волнами, начиная с наименее критичных систем!