Публикую слайды с сегодняшней встречи на площадке BI.zone по теме облегчения работы аналитиков SOC.

На слайдах есть ссылки на прошлые публикации\доклады по теме, во время презентации я старался не повторяться.

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

Организаторы сказали, что подобная встреча повторится еще раз, но уже с другими выступающими. Сегодня были Bi.zone, ЛК, Ангара и Яндекс. Все презентации организаторы обещали опубликовать.

#MDR

Наверно, это очевидно, что на КПЭ команд разработки положительно влияют выполненные ими CR/BRQ (Change Request, Business ReQurements) и негативно влияют дефекты (ошибки, bugs). Однако, даже от таких гигантов как Microsoft мы до сих пор нередко слышим, что какой-то баг - это вовсе не баг, а фича, что лишний раз подтверждает, что даже в зрелых конторах дефекты не всегда распознают как дефекты, или .... у них те же КПЭ - плюсы в карму за фичи, и минусы за баги.

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

#dev #пятница

На круглом столе присутствовал представитель АНО "Координационный центр национального домена сети Интернет", а освещаемый им вопрос - "Какие тенденции можно считать сегодня актуальными с точки зрения изменений в системах общих доменных имен как верхнего уровня, так и национального? С какими задачами сегодня сталкиваются специалисты в этой и смежных областях?"

Однако, в этой заметке хочется затронуть вопросы от представителей реального бизнеса, а их было примерно два:
1. Киберсквоттинг. Т.е. защита бренда компаний. Что делают регистраторы для того, чтобы ловкие ребята не захватывали доменные имена, релевантные крупным компаниям и не перепродавали их затем за бешеные деньги?
2. Фишинговые домены. Т.е. защита от появления доменов вредоносной направленности (по схеме тайпосквоттинга и т.п.), реализующие, например, воровство аутентификационных данных. Что делают регистраторы для того, чтобы подобные фишинговые сайты (пример, из последнего) не возникали в таком количестве, ввиду недопустимой простоты регистрации домена.

Короткий ответ на оба вопроса: регистраторы для решения проблем пп. 1-2 не дели ничего в 2001 году (мое первое место работы), ничего не делают сейчас, и не планируют. И для того, чтобы они что-то начали с этим делать, их надо обязать на уровне регулятора.

Дело здесь в том, что Регистратор - это коммерческая контора и, по большому счету, ему все равно с кого он получит свои $20 за домен, а чем больше регистрируется доменов - тем выше у него объем продаж. Поэтому, перекрывая какую-то долю потока регистрации доменов или как-то затрудняя процесс, что приведет к снижению регистраций доменов, Регистратор будет просто сокращать свои продажи, что, очевидно, экономически невыгодно. Поэтому здесь единственный инструмент - compliance, который надо потребовать со стороны госрегулятора.

Мероприятия по решению обеих обозначенных проблем (и захват доменов, и создание фишинговых сайтов) будут одинаковые, и в рамках круглого стола они были озвучены, приведу их:
0. Решить вопрос с SSL/TLS в стране, иначе проверить подлинность сайта не представляется возможным.
1. Заявления на регистрацию домена принимать только подписанными квалифицированной электронной подписью (КЭП).
2. Реализовать алгоритмы, аналогичные применяемым в услугах защиты бренда, по поиску доменных имен похожих на уже существующие. Направлять их на дополнительную проверку, как минимум. Можно даже начать с банального: если есть домен в зоне RU, при попытке регистрации такого же имени в другой зоне (SU, РФ и пр.) - уточнять, что то же юрлицо.

На мой взгляд п.1 уже будет вполне эффективным первым шагом.

Что еще можно предложить, пожалуйста, пишите в комментариях.

#РФ

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

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

#vCISO #управление

Друзья из БИзона опубликовали презентации и фотоотчет с крайнего митапа, посвящённого облегчению работы аналитиков в SOC. Там есть много интересного для автоматизаторов и методологов.

#MDR

Пресс-релиз о разрыве отношений повышает риск мгновенной кармы

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

Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много (ну, разве что вот пример, но не из ИБ, да и я, возможно, предвзят к "Студии Лебедева", работал с ними в 2007, надеюсь, сейчас они достигли зрелости), неверно, на то есть объективные причины, а, вполне возможно, факт того, что кто-то из заказчиков остался без защиты, вообще стоит скрывать. Но надо понимать, что в современном мире скрыть факты разрыва отношений крайне сложно, а сам факт этого повышает риск быть атакованным.

Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.

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

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

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

#пятница #MDR #vCISO

Крайне заманчива идея шагнуть дальше Автоаналитика и анализировать поведение глубокими нейросетями. Об этом говорят все, кому не лень, однако, практической реализации с хорошим качеством (именно на нейросетях, реализации на всяких бустингах есть и у нас) мне не попадалось.

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

#MDR #ml

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

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

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

#искусство

Мой коллега и друг Сарим, из нашей команды SOC Consulting, 23 декабря с 17 до 18 по Москве будет рассказывать методологические основы построения функции Detection Engineering-а на основе нашей практики проектов консалтинга по построению SOC.

Live webcast: From chaos to control: streamlining detection engineering in Security Operation Centers

Увидимся на мероприятии!

(язык вебинара - английский)

#MDR #vCISO #kaspersky

Ребята из A1 поделились видео о прошедшем мероприятии.

Всего две минуты прекрасно передают атмосферу A1 Tech Day. По-моему, на видео можно заметить всех докладчиков, в том числе и вашего покорного слугу.

В общем, предлагаю иметь в виду эту площадку для общения за пределами РФ, а если представится возможность - увидимся в Минске!

#vCISO

Непригодность нейросетей для решения задач нередко объясняется нашим "неумением их готовить". Поясню. У нас есть экспериментальный Волшебник Мерлин, который подсказывает аналитикам на что обратить внимание при расследовании алертов. О нем я упоминал в презентации на слайде 15. В качестве Подсказчика Мерлина используется обычная, не расширенная никакими RAG-ами и фью-шотами, развернутая в корпоративной инфраструктуре, LLM, в нашем случае - LLaMA. В ходе экспериментов было замечено, что если в Мерлина подать необработанный JSON алерта, то результат будет неудовлетворительным, однако, если JSON алерта переписать текстом, то результат будет вполне приемлемым. В нашем случае алерт - это совокупность событий, а каждому событию несложно поставить в соответствие его словесное описание (для этого не требуется никакой машобуч, там биективное соответствие)

Я уже писал о том, что конволюционные (по-русски, можно встретить термин "сверточные") нейросети (CNN), придуманные изначально для компьютерного зрения, стали пытаться применять для анализа связей в графах наряду с графовыми нейросетями (GNN).

Но вот эта публикация мне предсталяется более перспективной (абстракт, pdf). Здесь ребята извлекают фичи из образцов и преобразуют их в вид QR- и Aztec-кодов. Далее, полученные представления образца в виде QR/Aztec подают на вход CNN, классифицирующей малвару.

В целом, QR, как будто, хорошее представление входных данных для CNN, но под вопросом емкость такого представления, да и ограниченность на статистическом анализе малвары тоже не способствует универсальности метода. Но попытка засчитана!

Что ожидаю:
- повышение емкости входных данных для анализа. Если мы говорим о CNN, спроектированных для анализа изображений, то, может, кто-нибудь предложит трансформировать входные данные для анализа в изображение или видео.
- покрытие динамики. Динамика, на мой взгляд, более перспективна чем статика. Он закроет использование обфусцированной и полиморфной малвары, но, что еще более актуально, - сценарии Living-off-the-Land и поведенческое детектирование. Будем следить.

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

#MDR #ml

В СССР были замечательные хард-рок команды, о которых, к сожалению, почти никто и не помнит. Одной из таких групп является - Стелла. Группа была создана в 1988 году из проекта "Иск" – дуэта, в который входили вокалист Александр Кирсанов и басист Владимир Ширяев. Директором и художественным руководителем коллектива стал Валерий Иванов.

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

Группа попыталась возродиться в 2010 году усилиями автора всех песен и вокалиста Александра Кирсанова и продюсера Валерия Иванова, но широкой известности снова не приобрела.

20 июля 2021 года Валерий Иванов скончался от последствий COVID-19, 15 октября 2023 года умер Александр Кирсанов, а вместе с ними и окончательно ушла в историю группа Стелла.

"Мост нашей встречи" - вещь с альбома "Лихорадка", наверно, самая известная, на нее даже есть клип. Клип невольно вызывает улыбку, так как вспоминаются и Bon Jovi (и по части картинки, и по части звучания), и Helloween, и Skid Row, и много кто еще. Я эту песню услышал на сборнике русского рока, когда учился в институте и, как это водится с понравившимися вещами, разучил и иногда пою до сих пор.

Предлагаемая запись, как и все остальные, записанные дома на мобильный телефон, очевидно, не идеальна, однако, здесь, кроме всего прочего, есть ощущение, что я и не совсем правильно ее подобрал, тогда, будучи студентом, в 1997-м. Будем считать, что это мое индивидуальное исполнение.

#музыка

Наиболее часто используемые уязвимости в 2023 были зеродеями

Такое заключение сделала американская CISA. В целом это ожидаемо, с учетом объема автоматизации (поверхности атаки), что даже сама NVD уже не успевает все учитывать. В целом, это еще один маленький гвоздик в гроб стремления запатчить все подряд, ибо результативность патчевания продолжает стремительно падать.

В качестве рекомендаций CISA выдает:
1. SDLC. Согласен, код надо писать лучше (слабо понимаю, как это относится к стандартному интерпрайзу, который едва ли пишет сам себе софт), однако, никто не отменял ошибки конфигурации, что в условиях широкой функциональности (следовательно, сложной конфигурации) становится все более актуально. Поэтому я бы добавил Управление конфигурациями во всех его проявлениях: создание стандартных профилей, постоянный аудит их безопасности и контроль, что эти профили используются в инфраструктуре.

2. Стимуляция ответственного раскрытия информации об уязвимостях. Тоже так себе рекомендация для CISO, ну допустим. Немало пролетало исследований про автоматизацию пентеста и поиск уязвимостей с использованием нейросетей, поэтому здесь напрашивается 100% эффективная рекомендация😁: надо чтобы все новомодные штуки освоили разработчики ПО и находили свои уязвимости быстрее, чем это делают злоумышленники. Остается только один момент - невозможность отличия уязвимости от закладки.

3. Использование EDR. Здесь тоже соглашусь, но добавлю, может, MDR, так как чем сложнее инструмент, тем большая квалификация требуется от пользователя.

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

#MDR #vCISO

Windows User Account Forensics

В каком-то из каналов пролетал неплохой документ. Сохраню его здесь. Материал больше напоминает шпаргалку аналитика SOC и содержит базовые вещи, которые надо помнить при анализе событий Windows.

#MDR

BPL injection

Кто слышал о языке программирования Borland Pascal, наверняка слышал и о его объектно-ориентированном варианте Borland Delphi (ваш покорный слуга имел счастье на них еще и писать, где-то в конце 90-х, и скажу, что Borland Delphi - огонь!). У программ на Delphi есть свои динамически подгружаемые запчасти, реализованные в виде BPL-файлов (BPL - Borland Package Library). Файлы BPL, в целом, мало отлчаются от DLL, и даже file выдаст, что это DLL:

 % file vcl120.bpl  
vcl120.bpl: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
 %  

Ну разве что только strings выдаст особенности:

% strings vcl120.bpl| grep -i Delphi | wc 
      88      88    8117
 %

Однако, среди приложений на Delphi есть те, которые подгружают такие BPL-файлы. И для таких приложений можно эксплуатировать BPL injection. Идея ровно такая же, как и в случае с DLL: вредоносный BPL зкгружается легитимным исполняемым файлом.

Одним из таких легитимных бинарей является 8aed681ad8d660257c10d2f0e85ae673184055a341901643f27afc38e5ef8473 (A2D70FBAB5181A509369D96B682FC641). Его реальное имя rtthlp.exe, описание: IObit RttHlp, однако мы в инцидентах его встречали под разными именами: set-up.exe, setup.exe, install.exe и пр. В этих же инцидентах мы фиксировали и использованием BPL injection, и в одном из первых расследований вышли на статью от Kroll, где описывается BPL-инжект ровно в наблюдаемый нами бинарь A2D70FBAB5181A509369D96B682FC641. Инжектилось вот это - 3cbd60759ca91f846fe69e067cbef15f481e3a0be31b756ee434b54df668b7d2 (92650FCDC20ED3CBEBB6378B45C2E67D), имя - vcl120.bpl, вердикт KES - Trojan.Win32.Loader.npf. Окончательное назначение инструмента, где одним из компонентов был вредоносный BPL, - инфостилер, то была не человекоуправляемая атака (в MDR был инцидент критичности Medium), наблюдали не в РФ.

Несмотря на то, что Borland это, как будто, из прошлого, BPL injection - это из настоящего и будущего. Соответствующей подтехники Hijack Execution Flow еще нет, но Kroll пишут, что подали заявку.

В заключение хочу поблагодарить нашего аналитика D*, который в рамках нашего процесса Periodic Retro Hunting в свое время нашел такой инцидент, по мотивам которого позже наделали хантов.

#MDR

На SOC Forum 2022 я рассказывал о том, как кейсы от SOC передаются в DFIR и что это достаточно частый сценарий. Как правило причины две:
- реагирование MDR ограничено техническими возможностями MDR, и их не всегда достаточно => нужны какие-то альтернативные сценарии реагирования
- огромная проблема MDR - это покрытие, как человек не видит там, где нет глаз, так и MDR не видит событий с хостов, не покрытых сенсорами (в нашем случае - единый агент EPP-EDR) => со слепых зон данные приходится собирать альтернативными MDR способами

На самом деле эти две проблемы причинно-следственно связаны. Для организации эффективного реагирования необходимо располагать информацией о действиях атакующего, а информация нами получается из телеметрии. Если хост не в мониторинге, то с него нет телеметрии, а, следовательно, что на нем происходит расследовать невозможно. В условиях, когда наблюдаемая активность - однозначно человекоуправляемая атака, и не все участвующие в инциденте хосты покрыты мониторингом, надо рекомендовать подключение команды DFIR, так как неполное расследование приведет к неправильным мерам по реагированию и последствия будут куда хуже, даже в сравнении с полным бездействием (и такие случаи встречались в практике). В нашем случае, если заказчик согласен, инцидент эскалируется в Глобальную команду реагирования (GERT). Кстати, последние посиделки на AM Live с участием Константина Сапронова, руководителя GERT, доступны для просмотра.

Об одном из таких расследований по эскалации из MDR мои коллеги и друзья из команды GERT подготовили материал, с которым полезно ознакомиться, в статье приведены TTP и IoC-и

#MDR #kaspersky