Сегодня на 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, прослеживаются и как цель попродвигать свои подходы\продукты (потанцевать на костях), так и почти искреннее желание извлечь уроки, попытаться учиться на чужих ошибках.

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

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

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

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

Опубликовали слайды и видео с конференции по безопасности контейнерных сред БеКон

В новом лонгриде рассуждал о важности высшего образования. Попытался высказать, на мой взгляд, наиболее значимые и более-менее объективные причины необходимости получения высшего образования:
- широта, "базовость" и фундаментальность, позволяющая впоследствии легко перестраиваться, быстро адаптироваться и понимать многое
- тренировка нашей способности получать и обрабатывать информацию, корректно интерпретировать наше окружение, ВУЗ позволяет научиться учиться
- обучаться следует именно в молодости, так как далее будет сложнее по множеству причин
- продление школы, продление детства до момента обретения достаточной жизненной мудрости для самостоятельной жизни (21-25 лет)
- социальный трамплин и наш первый опыт в обществе

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

А что думаете вы?
Нужно ли высшее образование? Почему оно не нужно?

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

Сегодня в Cyber media вышло мое интервью. Всеми нами движут стереотипы, журналисты - не исключение, поэтому издание задавало вопросы, в основном, про "антивирус" (видимо, потому что я работаю в ЛК 😂). Однако, я имею опосредованное отношение к антивирусу и продуктам, поэтому отвечал про управление угрозами вообще. По-моему получилось нормально, вопросы и мнения - пишите в комментариях.

Формат интервью не предполагает ссылки на релевантные материалы, поэтому подкреплю свои слова соответствующими ссылками здесь.
1. Ну, про, передположительно, манипуляции мнением и желание отстроиться, или выдать "новизну", я не раз писал, все уже сказано
2. Когда в феврале 2016 года я из заказчика пришел работать в ЛК и за несколько месяцев окунулся в технологии, я реально был восхищен. И именно с тех пор я уверен, что лучшая реклама действительно передовых технологических компаний - это понятные описания используемых ими технологий. Какое-то время назад в ЛК для этих целей создали техновики, и там "на пальцах" рассказано как выглядит современный EPP.
3. Если описания технологий нет, то можно поискать и почитать патенты, они доступны публично. Например, в интервью я рассказываю о том, что есть технологии автоматически создающие правила обнаружения, поэтому, если кто-то один будет успешно скомпрометирован, то остальные уже будут защищены автоматически.
4. За технологиями стоит кропотливая работа высококвалифицированных аналитиков, и то, что не может\"не знает" автомат, в перспективе может попасть к человеку, о чем писал Евгений Валентинович у себя в блоге.
5. Насчет обнаружения атак по длинным цепочкам - чем длиннее цепочка, тем больше вариантов развития атаки => снижаются шансы угадать конкретный вариант, поэтому, на данный момент (может, в перспективе что-то поменяется, но пока такой подход работает хорошо), рабочим вариантом выглядит обнаружение как раз по каким-то атомарным действиям, техникам\процедурам, или их коротким комбинациям.

#mdr

Книжка - это хорошо, но не самый эффективный инструмент приобретения практических навыков... Поэтому мне вдвойне приятно, что Айман смог найти время и разработать курс Windows digital forensics!

Формат курса, однозначно, более эффективен для получения практического опыта, тем более, что автор курса - действующий эксперт DFIR в команде GERT, работающей по всему миру.
DFIR - основа и для Incident Response, для Compromise Assessment, а также, для Threat hunting-а, абсолютно необходим для Detection Engineering-а.

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

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

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

Классный исследователь безопасности и по совместительству подписчик нашего телеграм канала Luis Toro Puig совсем недавно выступил на конференции EuskalHack с воркшопом Kubernetes Security Fundamentals. Доклад затронул, наверное, все самые базовые темы в направлении Kubernetes Security.

100 must-have слайдов можно найти тут.

В далекие институтские годы, моя преподавательница по СУБД говорила, что неправильно из баз удалять, все что попадает в базу должно там оставаться навсегда. Это считается "правилами хорошего тона" и выглядит "профессионально". С тех пор, на протяжении всей своей жизни, при проектировании баз данных я всегда стремился не удалять данные, а помечать их как удаленные, и вопрос решать уже на уровне отображения...

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

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

Ну вот и публикация поспела про Github. Лишнее подтверждение тому, что все, что мы с вами вбили в Интернет, останется там навсегда.

Какое-то время назад пролетали слайды про атаки на AD через кривые ACL. Наконец-то дошли руки их полистать. Слайды хорошие: есть и базовая теория, есть и полезные ссылки, поэтому решил прикопать здесь.
А вот еще и видео к этим слайдам.

Когда на внутренних семинарах я рассказываю про профиль потенциального заказчика для MDR, Compromise Assessment и Incident Response, то обычно показываю эту картинку. Принципиальный момент здесь: если есть явные следы компрометации - то далее должна работать команда IR, а если следов компрометации нет и надо их поискать - это задача для команды CA. Но жизнь многогранна, поэтому случаются и исключения

Некоторое время назад закончили проект CA, который мы внутри прозвали что-то вроде "zero-lead IR" - идея в том, что заказчик пришел, как бы за IR, однако, явных следов компрометации (leads) не имел.

История в том, что к заказчику пришел местный регулятор и сообщил, что у него на сетевом периметре стоит уязвимое (и эксплуатабельное!) сетевое оборудование, и что практически нет сомнений, что в таких условиях его взломали и ему немедленно следует провести расследование. Заказчик пришел к нам и мы ему помогли, а для себя отметили этот, не совсем типовой, профиль заказчика для Compromise Assessment.

У истории счастливый конец, заказчика не успели серьезно поломать. Но я не писал бы об этой истории в пятницу, если бы ни одно обстоятельство. Вместе с требованием провести расследование регулятор рекомендовал заказчику срочно обновить уязвимое сетевое оборудование, что заказчик незамедлительно выполнил (еще бы, регулятор потребовал!), поэтому если и были какие-либо артефакты эксплуатации уязвимостей, они канули в Лету при обновлении :(

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

#mdr #пятница

27 июля 1841 на дуэли погиб Михаил Юрьевич Лермонтов. Писатель, перечитывая которого уже сорокалетним многодетным отцом, я не переставал поражаться как можно писать так глубоко в 25 лет!

Я ни раз был и на месте дуэли и на месте первого захоронения, пока бабуля не увезла любимого Мишеля в родовые Тарханы , но до сих пор меня не оставляет трагичность судеб самого Михаила Юрьевича и его бабули, Николая Соломоновича и его сестры..., и мысли плавно переходят к судьбам его литературных героев: Бэлы, Максима Максимыча, Мэри и Грушницкого...

#книги #история

Когда я готовился к OSCP успел стать фанатом HTB. Всем настоятельно рекомендую ресурс. (например, в мое время лабы OSCP для подготовки были очень старые, тогда как по факту на экзамене было все новенькое, HTB очень помог)

Однако, со времен знакомства с Алексеем Евгеньевичем Жуковым на 4-м курсе, испытывал немалую слабость к прикладной криптографии, что иногда выливалось в небольшие исследования (ZN, PHD ).

А вот на днях попался ресурс, как HTB, но для тех кто любит криптографию.

В общем, ждут меня снова бессонные ночи 😁...

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