Как правильно: "SIEM" или "SOC"?

Некоторое время назад ЛК и К2К делали исследование о SOC-ах к подготовке которого немного приложился и ваш покорный слуга. Вот ссылка на пресс-релиз, а отчет будет доступен попозже.

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

Причин, почему не имеющие SIEM не планируют его внедрять, достаточно много, но я бы выделил две, как наиболее часто встречающиеся, по моему мнению.
- SIEM, как правило, является выдленной системой ИБ, тогда как собриать и обрабатывать журналы регистрации ИС – общая задача ИБ и ИТ. В компаниях со зрелыми подразделениями ИТ вопрос сбора журналов всех ИС, в том числе и с выделенных решений ИБ, таких как межсетевые экраны, системы защиты конечных точек (EPP-EDR) или сетевые системы обнаружения сетевых вторжений или NDR, традиционно решен. Поэтому, для подразделений ИБ значительно эффективнее переиспользовать LM-системы ИТ (LM – Log management), тем более, что современная LM-система позволяет покрыть все основные сценарии ИБ, а вместе с тем обеспечивает нилучшее покрытие, не ограничиваясь только системами ИБ и не стремясь остаться в рамках лицензионных ограничений EPS.
- В компаниях со зрелыми инженерными командами предпочитают свободно распростаняемые решения, что дает практически безграничную гибкость, а следовательно, безграничные возможности по адаптации. Выбор opensource еще более очевиден для компаний с большими возможностями по разработке собственного ПО.

Первый пункт принципиально важен. Что бы мы не говорили, но ИБ в компании обеспечивают подразделения ИТ! Именно ИТ разрабатывают, внедряют и обслуживают информационные системы с соблюдением требований безопасности, за ИБ остаются функции законодателя и контролера. Именно поэтому безопасность не может быть обеспечена там, где у ИБ и ИТ плохие отношения или ИТ - ленивые разгильдяи имеют низкий уровень зрелости. Уровень ИБ напрямую зависит от зрелости ИТ. Как правило, у зрелых ИТ вопрос управления журналами систем и приложений давно решен и, с точки зрения эффективности инвестиций, безопаснику логичнее подключиться к уже внедренным у ИТ системам LM, а не строить сбоку дорогостоящую городушку с кучей ограничений в виде SIEM. Собственно, когда где-то в 2006-2009 занимался созданием своего первого SOC, я ровно так и сделал. Правда, следует заметить, что позднее у меня появился и SIEM, но именно для корреляции на неполном объеме событий из-за ограничений по железу и EPS.
Если же в корпорации вопрос сбора логов не решен, то лучше это сразу решать совместо с ИТ: строить общий Data Lake, откуда ИТ будут брать данные для своего траблшутинга, а мы - для нашего обнаружения атак (какую-то их часть отправлять в SIEM для генерации алертов в SOC).

Итак, друзья мои, ответ на вопрос: "Можно ли построить SOC без SIEM?" - положительный, но с плотным вовлечением ИТ (повторюсь, что без плотного вовлечения ИТ безопасность обеспечить невозможно, именно ИТ делают безопасность!)

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

С другой стороны, если подумать, есть три книжки и как раз три участника. Так что встречайте победителей «Апофеоза кибервойны 2»:

— Кибертерроризм (Сергей Солдатов);
— Интервью с участником Народной CyberАрмии (Мария Коледа);
— Правительство обязало Минцифры разработать проекты постановлений о двух новых ГИС в рамках ЕАЭС (Валерий Коржов).

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

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

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

#crypto #ml

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

О том, как попасть на очередное такое мероприятие, расскажем уже в следующем году. А пока – пример одного из докладов с последнего митапа: наш коллега Георгий Кигурадзе рассказал, как сдампить Lsass, оставаясь под радарами стандартных хантов. Было много запросов пошарить слайды этого доклада, и вот они – в приложенном файле.

TL;DR: Извлечение секретов из lsass – один из логичных шагов на этапе постэксплуатации в Windows-инфраструктурах. Однако большинство готовых решений гарантировано детектируется стандартными средствами. Наше решение: разработать свою реализацию дампа, на основе примитивов доверенного инструмента.

Основная идея в том, чтобы использовать прямое чтение физической памяти через подписанный Microsoft драйвер, который используется расследователями для снятия дампа оперативной памяти. Сканируя память, мы находим ядерную структуру EPROCESS для процесса lsass.exe. После парсинга этой структуры проходимся по всем VAD-ам, принадлежащим процессу, и ищем lsasrv.dll. Именно в этой библиотеке находятся необходимые нам ключи шифрования и контексты пользователей. Прочитав физическую память по нужным адресам, можно расшифровать контексты пользователей и получить их NTLM-хэши.

Всё это мы реализовали как BOF для Mythic C2 (про создание собственного Mythic-агента расскажем чуть позже).

Ну и полезный совет для стороны защиты: подобные атаки можно обнаружить по регистрации подозрительного драйвера для форензики (смотрите IoC на последнем слайде).

Я не люблю делать прогнозы, но, как я писал здесь:

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

Канал Sachok опубликовал мой прогноз под номером 2222 (видимо, это знак 😁)

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

Как всегда, ваше мнение относительно моих прогнозов приветствуется в комментариях.

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

Когда безопасность побеждает безопасность -

- подумалось мне, когда после установки последних обновлений у меня отъехал токен => перестала работать двухфакторная аутентификация.

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

Пока чинил вспомнил пару случаев неудачных обновлений. Один, ну конечно, с Crowdstrike, вот можно почитать их объяснения (без комментариев нет слов).

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

Решение по недопустимости - очевидное, но, поскольку на практике не всегда работает, приведу его здесь:
- инвентаризация активов: надо знать какие версии какого ПО установлены
- обновления перед принудительной установкой тестировать на всех конфигурациях, выявленных при инвентаризации
- даже протестированные обновления накатывать волнами, начиная с "менее значимых"\более простых в траблшутинге подразделений
- если хочется заинфорсить актуальность версий системного и прикладного ПО, то применять более мягкие сценарии, типа, не пускать в сеть на NAC, если патчлевел не тот, что нужен
- надо вести учет такого рукож**ого конфликтного ПО (в частности, КриптоПРО) и при инвентаризации и тестировании обновлений на это явно обращать внимание (~ любые ошибки должны делать нас лучше).

#пятница #vCISO

На разного рода эфирах и интервью я не раз говорил, что наступательная кибербезопасность - хороший инструмент проверки эффективности нашей операционной ИБ (SOC-а с технологиями, процессами и командой). Но, как любой хороший инструмент (практика показывает, что чем большую эффективность от инструмента мы хотим, тем на более узком объеме его следует рассматривать), пентест (в этой заметке для простоты буду использовать "пентест", но понимать буду более широкий спектр различных активностей по анализу защищенности) для проверки SOC годится лишь отчасти, так как:
- в задачи пентеста, как правило, не входит необходимость действовать скрытно, поэтому они шумны и обнаруживаются. Безусловно, все зависит от задач на пентест, но если поставить цель действовать скрытно, то такие работы растянутся на долгие месяцы и будут экономически нерентабельные (решение есть - иметь внутреннюю команду)
- упомянутая выше ограниченность во времени влияет и на глубину проработки. Я не раз рассказывал случай, когда на одном из моих проектов пентестеры нашли потенциальную RCE в Sendmail на HP-UX, однако, ввиду не особой популярности ОС, доступного эксплоита не было, а нечеловеческие усилия не позволили разработать эксплоит самостоятельно в рамках работ на проекте.
- связанная проблема - ограниченность подготовки. На пентесте будут использоваться какие-то старые собственные заготовки, либо вообще публично доступные инструменты, никакие полностью кастомизированные, разработанные исключительно для этой конкретной атаки тулы использоваться не будут.

В общем, пентест существенно отличается от реальной атаки. Ну а обнаруживать-то хочется реальную атаку! И здесь нам на помощь придет Compromise Assessment (например, этот, или этот, или какой другой), который как раз и направлен на обнаружение пропущенных в прошлом атак. По сути CA выдаст список прошлых инцидентов, относительно которых можно далее заглянуть в историю работы своего SOC и посмотреть что там было видно, почему не видно и наметить какие-то улучшения.

На мой взгляд CA, как и пентест, - хороший инструмент оценки результативности SOC, причем, основанный не на синтетических сценариях, а на реальных инцидентах. Все уже давно осознали необходимость периодического пентеста, и даже регуляторка это требует, а вот с СА пока такого нет (ну, разве что, в регионе META я такое видел), а ситуация ровно такая же: периодически надо получать уверенность, что не было пропущенных инцидентов, за одно и проверить результативность SOC-а.

Маленькая очевидная ремарка: если у нас операционная безопасность обеспечивается решениями одного вендора, то СА надо брать от другого вендора. Подобная кросс-валидация решений одного вендора решениями другого позволит и конкуренцию усилить, и, как следствие, повысит качество предложения на рынке.

Итак, CA - отличный инструмент для заказчика, чтобы проверить результативность его SOC: инструментов (NDR, EDR, MDR, MXDR), процессов и профессионализма команды, а также, чтобы наметить дальнейшие планы развития бизнес-функции операционной безопасности.

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

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

Особенно я люблю смотреть напутствия студентам. Всегда полезно оглянуться назад и сравнить свою жизнь с тем, что рекомендуют уважаемые люди. Настоятельно рекомендую всем посмотреть Стива Джобса, но вот поспело и выступление Эвана в Финансовом Университете, и здесь пара моментов меня задели.

1. Работать в компании, которая часть вознаграждения выплачивает собственными ценными бумагами. Это действительно частая практика, и это выгодно работодателю - относительно бесплатно привязывать к себе ценных сотрудников (именно таким дают подобные опционы). Однако, с позиции работника, в соответствии с очевидным принципом диверсификации инвестиций, напротив, вкладываться в акции\облигации собственного работодателя выглядит сомнительно: я уже получит доход от компании-работодателя в виде зарплаты, поэтому разумнее "лишние" деньги вложить в другие компании, пусть они мне тоже приносят дивиденды\купоны. Здесь же работает очевидная логика по тяжести потери: положив все яйца в одну корзину, пережить сложности работодателя будет значительно больнее. Да, Эван, безусловно прав, что получив "за просто так" ценные бумаги мы автоматически становимся инвесторами, что лучше, чем не быть инвестором (это просто открывает для нас фондовые рынки как дополнительный инструмент сохранения капитала), но получать просто деньги и дальше самостоятельно решать что с ними делать - всяко лучше, чем бумаги непонятного стартапа (вполне возможно, еще и с кучей ограничений).

2. Инвестиции в криптовалюту. Про крипту у Эвана есть отличный базовый материал. Полностью согласен, и история это многократно подтверждала: когда из каждого утюга кричат о какой-то инвестиционной идее в какой-то актив, это значит, что из этого актива пора выходить. Сейчас все говорят про крипту... Криптография - часть моего университетского образования, и я знаю как технически работают криптовалюты, однако всегда к ним относился опасливо, а после серии заморозок активов в 2022 однозначно для себя решил, что инфраструктурных рисков там слишком много и пока они не будут решены нести туда деньги опасно. Приведу мои аргументы (они все спорные, их можно бесконечно оспаривать, у меня нет задачи дискутировать, я просто делюсь мнением):
- криптовалюта нематериальна - она не имеет физического эквивалента, как драгоценные металлы или деньги, это просто запись в каких-то компьютерах (в чьей они юрисдикции? кто и как ими управляет?).
- иногда мне кажется, что криптовалюта - это бэкап-план хозяев доллара, - новый проект мировых алхимиков, продолжающих следовать принципу, озвученному Родшильдом в начале 19 века: "Дайте мне право выпускать и контролировать деньги страны, и мне будет совершенно всё равно, кто издает законы". Невозможно выиграть у шулера в его игру на его условиях.
- для обеспечения ликвидности нужны криптобиржи - в чьей они юрисдикции? Мы точно всегда сможем поменять наши записи в криптокошельках на бумажные деньги, оставаясь территориально в РФ и гражданином РФ? Прициденты ограничений для россиян широко известны.
- я подожду полной легализации криптовалют в РФ и\или полностью локализованных в РФ криптовалют с локальными биржами, на которых не будет риска ограничений, все инфраструктурные риски будут сняты, в общем, я подожду пока государство хоть как-то мне прогарантирует справедливость правил игры

Ну а то, что надо постоянно учиться и развиваться - с этим я полностью согласен с Эваном, я тоже вижу перспективу в машобуче\ИИ, ИБ и ИТ!

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

#финансы #саморазвитие

Публичные роудмапы

Выбор решения ИТ или ИБ - это как выбрать бизнес партнера, также непростая задача.

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

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

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

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

Применение ИИ в информационной безопасности

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

И вот (наконец-то) попалась настоящая хрестоматия использования ИИ в различных направлениях ИБ - Generative AI and Large Language Models for Cyber Security: All Insights You Need (прямая ссылка на PDF).

На 50 страницах статьи авторы:
- дают ссылки на более узкие публикации;
- рассматривают варианты применения ИИ для широкого спектра прикладных направлений: анализ защищенности, обнаружение атак, DFIR, разработка кода, управление уязвимостями и др.;
- анализируют эффективность 35 ведущих моделей, таких как GPT, BERT, LLaMA;
- касаются вопросов уязвимостей LLM, таких как инъекция промптов, враждебные инструкции на естественном языке, небезопасная обработка выходных данных;
- рассматривают проблемы, связанные с развертыванием LLM для целей ИБ, обеспечения ее надежности и возможные последствия от атак на нее;
- касаются новомодных продвинутых методологий типа Reinforcement Learning with Human Feedback (RLHF) и
Retrieval-Augmented Generation (RAG) для улучшения работы.

Если мы с вами озадачены:
- выбором модели для какой-либо задачи в ИБ;
- выбором сценариев применения ИИ в ИБ;
- необходимостью относительно быстро въехать в тему применения ИИ в кибербезопасности, - то эта работа, думаю, первое, с чем следует ознакомиться.

#ml #vCISO

Дорогие друзья, коллеги, подписчики и единомышленники!

Поздравляю вас с наступающим Новым годом!

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

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

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

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

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

С Новым годом! Пусть он принесет вам радость, уверенность в завтрашнем дне, крепкое здоровье, вдохновение для новых свершений и счастья всем, кто вам дорог!

Всем эффективных и результативных выходных!

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