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

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

The Fault in Our Metrics: Rethinking How We Measure Detection & Response

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

Mistake #1 losing sight of the goal - теряем цель измерения, поэтому, когда придумываем метрику надо понимать в какую категорию она попадает (автор приводит эти категории для самопроверки - SAVER)
Mistake #2 Using quantities that lack controls - пытаемся измерять то, на что не можем влиять - это вообще классика, для этого придумали S.M.A.R.T.
Mistake #3 Thinking proxy metrics are bad - выбор красивых и зрелищных метрик, вместо полезных
Mistake #4 Not adjusting to the altitude - мы не объясняем бизнес-последствия от тех или иных значений показателей - N - это плохо? сильно плохо? или нормально? или, вообще, хорошо?
Mistake #5 Asking "why?" instead of "how?" - надо спрашивать себя что надо делать (how) - при такой постановке вопроса измеряемую проблему решить проще

Измерения не должны быть хаотичны, хаосом невозможно управлять, поэтому автор предлагает Treat Detection and Response Maturity Model (TDRMM), придуманной под впечатлением Threat hunting MM, ❗️и делится ею❗️. Она не гарантировано может быть взята в работу "как есть", но она точно - отличное начало для построения своей TDRMM.

Прикладываю во вложении слайды и TDRMM в виде Excel.

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

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

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

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

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

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

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

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

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

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

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

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

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

#РФ #vCISO

Zero trust... как много в этом звуке
Для сердца русского слилось!
Как много в нем отозвалось

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

Когда мы, работая безопасниками, придумываем контроли безопасности для какой-то ИС или бизнес-процесса, намного эффективнее контроли брать из какого-то более-менее универсального каталога контролей, анализировать их пригодность для решаемой задачи, модифицировать, адаптировать, или уже придумывать на их основе новые (поэтому я люблю, например, 53-й NIST). Все держать в голове невозможно и, если следовать книжкам по личной эффективности, - не нужно и очень вредно. Аналогичный подход может быть применен и к функциональным требованиям. Работая в заказчике я не раз был автором\соавтором функциональных требований к системам безопасности, отголоски той работы в изоблии можно найти на страницах моих прошлых публикаций (вроде этой про IDM или этой про DLP).

Разработка корпоративной ZTA - непростая задача, поэтому здесь также поможет тот же подход - посмотреть какими вообще свойствами\ функциональными возможностями обладают современные решения ZTA и выбрать те, которые нам подходят. "Подходят" здесь наиболее важное слово (может, это даже потянет на отдельную заметку), так как результирующая ZTA не должна быть продуктом наших несбыточных фантазий, а реалезуемым проектом в условиях имеющихся технологических, процессных, бюджетных ограничений. В целом, можно воспользоваться тем же NIST SP 800-207, но есть вариант еще лучше!

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

The purpose of this research is to perform a systematic literature review (SLR) focused on the applications of ZTA. Considering the recent boom in research in this area, the conducted SLR aims to gather, and synthesise the existing studies on ZTA with a goal to provide a comprehensive taxonomy useful for researchers and practitioners who wish to apply the ZTA-oriented framework to fortify security defenses.

#vCISO

На днях обсуждали с друзьями процессную модель операционного подразделения ИБ, и принципиальный вопрос:

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

Поток мыслей по этому вопросу записал в свежем лонгриде "Формализация"

Очень приветствуется ваш опыт решения поставленных вопросов, ваша граница красоты\баланса.

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

Мой старый добрый знакомый, Дэн Батранков, видимо, ввиду обостренного чувства справедливости, не на шутку озадачился вопросом сравнения XDR и SIEM, что отразилось в следующих многочисленных артефактах: заметка Отличие XDR от SIEM, а также презентация на SOC Forum 2024, доступная по ссылке.

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

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

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

При этом, я не исключаю (более того, считаю это логичным) построение XDR на базе SIEM, так как если SIEM умеет работать с неструктурированными логами, то с предопределенной телеметрией у него точно получится. Широкие возможности по автоматизации на базе XDR как раз и обусловлены предопределенностью и структурированностью обрабтаываемой телеметрии. "Сырые" (== оригинальные, в первозданном виде) логи ИС, предназначенные для ручной обработки админами, - именно для работы с такими данными и придумывали SIEM, а необходимость корреляции событий разных ИС создала потребность в нормализации. Хранение сырых логов долго и централизовано требуется и регуляторами и для ретро (ну мы же не хотим, чтобы наша система умерла вместе со всеми своими логами, поэтому логи надо уносить) - это тоже функция SIEM. Ранее я упоминал про Log management, и эта заметка отчасти повторяет те же мысли. Больше различий я пособирал в табличке. Как всегда ваши предложения и критика приветствуются!


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

16 мая в 11:00 (MSK) мой коллега Алексей Пешик из команды SOC Consulting обсудит тему ИИ в кибербезе.

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

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

Регистрируйтесь!

#ml #vCISO

Приятно видеть, что наш с Денисом вебинар не остался совсем не замеченным и на наиболее значимой конференции по ИБ его упоминают! Очень приятно.

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

#MDR #vCISO

Про пилоты и проекты

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

Но я не работаю в Продажах, я отвечаю за delivery, однако, для меня пилот тоже очень значим и на всех мероприятиях я постоянно всех приглашаю к нам на пилоты. Основных причин - две.

Во-первых, аналитика по данным инцидентов всегда интересна, так как она в какой-то степени отражает ландшафт угроз, под который надо адаптировать и наши способности по управлению угрозами и наши ресурсные возможности. А чем больше разных клиентов мне удастся помониторить, пусть даже непродолжительное время, тем лучший TI я соберу, тем более объективны, лучше отражать действительность, будут мои прогнозы. Как раз при подготовке к Сеулу я готовил контент, где анализировал данные, представленные в наших аналитических отчетах за 2020-2024 годы, выделял тренды и проверял их на данных Q1 2025, спойлер: многие предсказания сбылись. Я не люблю повторять одни и те же слайды, но по части этого сеульского доклада я дал промах (все когда-то делается в первый раз) и эту презентацию уже успел рассказать и на русском языке. Английский вариант обязательно выложу, так как именно к нему есть скрипт, подстрочник к слайдам, его можно будет просто почитать.

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

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

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

#MDR #vCISO

Обсуждаем XDR и SIEM

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

Если формат понравился, пишите, что еще интересно обсудить.

Также, конечно же, пишите если где-то не согласны с нами, обязательно обсудим!

#MDR #vCISO