Мы все, конечно же должны стремиться к тому, чтобы никогда не ошибаться. Но возможно ли сделать так, чтобы ошибок не было? Возможно ли, чтобы стрелок никогда не промахивался, чтобы с конвейра никогда не выходил брак, а 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

Red Canary -> Zscaler

В новой статье рассуждал о сервисах в продуктовых компаниях.

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

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

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

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

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

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

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

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

#MDR #мир #vCISO

Гибридный SOC 2025

В прошлом году мы много говорили о том, что все SOC - гибридные (видео , статья , Gartner в тему ) и, видимо, наши аргументы показались Сообществу убедительными, так что уже в этом году гибридные SOC обсуждали на ежегодных посиделках Anti-Malware.

А 26.06 в 11.00 МСК на CISO Club будет вебинар - Гибридный SOC 2025: как AI, автоматизация и люди вместе побеждают киберугрозы , где будет принимать участие мой друг и коллега - Алексей Пешик.

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

Я зарегистрировался...

#MDR #ml #vCISO

Ежемесячно Open AI выпускает отчет о борьбе с вредоносным использованием ИИ. Вот июньский, pdf .

За вычетом пафосных моментов, типа:

we believe that making sure AI benefits the most people possible means enabling AI through common-sense rules aimed at protecting people from actual harms, and building democratic AI. This includes preventing the use of AI tools by authoritarian regimes to amass power and control their citizens, or to threaten or coerce other states; as well as activities such as covert influence operations (IO), child exploitation, scams, spam, and malicious cyber activity

документ мне показался полезным.

Поделюсь мыслями, возникшими в процессе изучения документа.

1. Документ содержит практические сценарии использования (о сценариях говорили здесь ), т.е. там, где эффективность подтверждается самой практикой

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

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

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

5. Документ о том, какие сценарии использования своей модели Open AI считает неправильными - интересен, но еще более интересным был бы подобный дайджест о правильных сценариях использования, в которых бы описывались конкретные практические реализации. Сейчас есть что-то , более напоминающее маркетинговые листовки. Такая популяризация "правильных сценариев", тоже способствовала бы снижению количества "неправильного использования".

#ml #vCISO

Плейбук на срабатывание антивируса

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

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

#vCISO #MDR

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

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

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

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

Но вермнемся к дебатам. 4 участника, два полуфинала, один финал. В каждом раунде по два тура по полторы минуты. Темы полуфиналов были известны заранее, а кому какая тема и какая позиция выпадет - выбиралось жеребьевкой. Финальная тема не была известна заранее, позиция выбиралась монеткой, как в футболе. Голосование за аргументацию производилось участниками мероприятия через Телеграм-бота.

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

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

То, о чем сегодня говорят на Кибер кэмпе, завтра говорит весь рынок

Будем стараться оправдывать доверие и ожидания!

#vCISO

Варианты тем дебатов по ИБ

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

2. Безопасность vs. Требовния правообладателя: можно ли нарушать лицензионное соглашение для целей исследования безопасности (дело Майкла Линна из ISS против Cisco, Дима Скларов из Элкомсофта против Adobe)
да, так как это повышает качество продукта и защищает наши права, права потребителей
нет, так как закон нарушать нельзя, ибо правообладатель не разрешил явно

3. Отрицательная мотивация
- Стоит ли увольнять CISO из-за инцидентов ИБ
да: за прохую работу надо платить
нет: у него появился бесценный опыт
- Вообще, если сотрудник допустил ошибку и расследование показало, что злого умысла не было, его стоит наказывать? (тема полуфинала)
да: так как за все надо платить и это будет ему уроком
нет: так как были объективные причины, и виной всему обстоятельства, а наказине демотиврует и мы получим худший результат

4. Open-source проекты безопаснее проприетарных
да: так как открыт код для аудита
нет: так как код изучают и атакующие, не всегда понятно кто туда что коммитит, история знает случаи закладок (хотя и в проприетарных тоже)

5. Чем строже compliance, тем выше безопасность => государство должно ужесточать требования
да: стандарты дисциплинируют и задают базовый уровень, а ответственность стимулирует исполнять
нет: compliance != безопасность и появляюется новый вид апродуктивной деятельности - обход комплаенса, к тому же может создаваться опасная иллюзия безопасности, как раз из-за комплаенса

6. Этичен ли hack-back?
да: если меня атаковали, я имею права на активную защиту (в том числе 3rd party инфраструктуру, которая использовалась злоумышленниками)
нет: так как это может вести к злоупотреблениям и основаниям для хакерских атак

7. Этично ли нанимать на работу хакеров (с темным прошлым или настоящим)?
да: они супер-профессионалы
нет: они прежде всего криминальные элементы

8. Уничтожит ли сильный искусственный интелект (AGI) Человечество? (тема финала)
да, потому что
нет, будучи инструментом, он всегда останется инструментом


#vCISO

Kaspersky Cyber Insights 2025

В завершающей заметке по теме (слайды) делюсь ссылками на записи выступлений, доступные на Brighttalk.

У меня профессионально исковерканный субъективный взгляд, но все равно, приведу личные рекомендации, что можно посмотреть:
Kaspersky SOC in 2025: Key Observations and Findings
Know Your Adversary with the Threat Landscape
AI-Related Threat Landscape: 2025 and Beyond
Panel Beyond the Perimeter: Practical Strategies to Leverage Threat Intelligence for Proactive Cybersecurity

#MDR #vCISO

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

Видимо, все это и имеет в виду уважаемый Gartner, в своем "новом" документе "Emerging Tech: Top Use Cases in Preemptive Cyber Defense" от 13 августа 2024 (вторник, не пятница), но его чтение мне заметно подняло настроение, о чем не могу не написать в пятницу.

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