Солдатов в Телеграм

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

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

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

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

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

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

"Щегол" - третий роман писательницы, опубликован в 2013 году, а уже в 2014 году получил Пулицеровскую премию. Главный герой романа - Теодор Деккер (Тео), который в 13 лет потерял мать в результате террористического акта, который на протяжении произведения переживает довольно непростую жизнь, но относительно успешно балансировать на грани пропасти герою помогает в том числе и любовь к искусству. "Щегол" - картина не самого известного голландского художника Карела Фабрициуса, написанная в 1654 году, - полноправный герой произведения. Эта картина одна из немногих уцелевших после взрыва в результате которого погиб и сам художник. Принято считать, что если бы не ранняя смерть Фабрициуса и утрата его произведений, он мог бы стать в один ряд с такими фигурами голландского золотого века, как Рембрандт и Вермеер. А на страницах романа, "Щегол" снова переживает взрыв.

Роман Тартт, неверно, можно считать детективом, но отошедшим от классических канонов этого жанра, так как мы сразу знаем кто преступник. Этот момент перекликается с "Преступлением и наказанием" Федора Михайловича, чье влияние, наверно, я уже научился чуствовать (например, у Фицджеральда). Но упоминание Достоевского явно еще не раз встретится в романе, так как второй по значимости персонаж книги, Борис Павликовский, олицетворяет собой собирательный образ всех американских стереотипов о русских: пренебрежение к закону, непомерное употребления алкоголя, благородство и верность дружбе, любовь к Достоевскому и Толстому. Именно Борис, как будто, окажет самое негативное влияние на личность Тео, но, в то же время, именно он поможет все исправить (напишу максимально аккуратно, чтобы не палить сюжет)

В 2019 году роман был экранизирован режиссером Джоном Кроули, сценарий написал Питер Строган. Фильм получил смешанные и негативные отзывы, в которых критиковались сюжет и повествование, но хвалили операторскую работу и актёрскую игру. Сообщается, что Донна Тартт была настолько недовольна экранизацией, что дала понять, что больше не будет продавать права на экранизацию своих произведений (очень жаль, поскольку я люблю сравнивать книги и экранизации). На IMDb оценка 6.4 - означает, что, не зная предыстории, я бы не выбрал этот фильм для просмотра (обычно, я не смотрю фильмы с оценкой ниже 7.0 ). Но, у меня сложные отношения с кино, и, видимо, я слабо в этом разбираюсь, может, поэтому кино мне понравилось. Я даже повелся на то, как молодой Борис (Финн Вулфхард) имитировал русский акцент, но ребята спалились во время сцены перебранки с пьяным отцом, ибо разговаривали по-русски с чудовищным акцентом, особенно весело они коверкали русский мат 😂

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

#книги #кино

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

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

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

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

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

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

Место очень приятное, не менее красивое, чем Плес на р. Волга, которым вдохновлялся Левитан, о котором я упоминал в статье о Передвижниках (в статье есть панорама с "Горы Левитана"). Река здесь широкая, прямая, глубокая, течение спокойное, высокие песчаные берега покрыты лесом из сказочно красивых сосен. Комаров и мошки здесь было немного относительно других мест. Мы стояли одну ночь на левом берегу. Если мне не изменяет память, то старший во время утренней прогулки заметил кабана.

#здоровье

Atomic Red Team - широко известный фреймворк для тестирования наших с вами XDR, вокруг которого давно сложилось сообщество, и вклад которого в наше общее дело не менее значим.

В частности, попался вот такой репозиторий, который можно использовать для эмуляции известных APT - получится что-то вроде теста MITRE.

Но еще больше мне понравился вот этот - AttackRuleMap, так как здесь предложен маппинг правил Sigma и Splunk - неплохое начало для создания собственного контента обнаружения.

#mdr

Простые числа - основа криптографии. Именно потому что их бесконечно много и потому что их распределение, вроде бы, случайно, мы можем полагаться на схему RSA.

В RSA выбираются два простых числа p и q, но, поскольку эти числа очень большие, на практике выбираются случайные числа, прошедшие проверку на простоту. Тестов на простоту великое множество, когда-то давно в одной из курсовых работ я брал алгоритм, списанный вот из этой замечательной книжки - Ноден, Китте, Алгебраическая алгоритмика, за которой специально ездил в издательство "Мир" где-то в район ст. Москва-3 Ярославского направления. Важно запомнить, что на практике в схеме RSA используются "примерно" (прошедшие тесты) простые числа, что, безусловно, снижает криптостойкость.

Однако, изучение простых чисел не останавливается и до сих пор. И вот достаточно свежая публикация о разных способах вычисления (== понимания распределния, т.е. нарушение условия случайности) простых чисел. Да, ряд упомянутых методов помимо простых чисел выдают "примерно" простые (в статье их называют "грубые простые", rough primes), но это не супер-проблема, поскольку, во-первых, их процент не велик, а, во-вторых, на практике используются как раз те самые "примерно" простые, поэтому для целей практического криптоанализа подойдут.

Надо следить за темой. Кстати, Let's enrypt начали выдавать TLS-сертификаты на несколько дней. Понятно, что компрометация ключа, обычно, происходит не ввиду криптоанализа, но, тем не менее, тренд в сторону короткоживущих ключей - эффективное мероприятие.

#книги #crypto

Вопрос инвестиций и их сохранения непростой, так как на фондовый рынок влияет что угодно и предсказать это невозможно, особенно в РФ, особенно сейчас, когда последние 30 лет мы все свои стремления вкладывали в интеграцию в глобализм (наверно, разделение труда в мире, как и в обычной корпорации - это более эффективно, так как производственные возможности у разных стран разные), а последние несколько лет мы столь же стремительно разворачиваемся на 180 градусов. Представьте себе автобус, на полной скорости влетающий в препятствие и упруго отскакивающий в противоположном направлении, что при этом происходит с пассажирами?

Как уже отмечал, я никогда не рассматривал фондовый рынок, как инструмент заработка (зарабатывать нужно работая!), но как инструмент накопления и сохранения. Однако и в этом случае надо иметь какую-то стратегию. Если взять классические книжки по инвестированию, то все они топят за биржевые ПИФ-ы (а то и за ПИФ-ы, не торгуемые свободно на бирже), что можно понять, поскольку это существенно понижает порог входа: через ПИФ можно купить маленькую долю всей индустрии и не разбираться в показателях компании для принятия решения насколько перспективно вложиться в ее бумаги. Но история с фондами FinEx и то, что российский рынок не настолько многогранен, чтобы в нем было невозможно разобраться непрофессионалу, на мой взгляд, делает предложение о ПИФ-ах не очень подходящим для РФ. Инвестировать в зарубежные активы тоже выглядит крайне рискованно, если не сказать "безумием", даже в активы дружественных стран. Поэтому напишу свои мысли.

0. Надо понимать горизонт инвестирования. Это - самое сложное, так как "побеждают быстрые и решительные" и нам всем надо быть Agile.

1. За всю свою жизнь не видел дефляцию рубля на горизонте больше года, поэтому если мы планируем на срок более двух лет, то надо рассчитывать на обесценивание рубля. В этом случае инструменты у нас такие:
- акции российских "голубых фишек": Лукойл (LKOH), НЛМК (NLMK), Татнфеть (TATN), Сбербанк (SBER) и т.п.
- еврооблигации, номинированные в юанях (примеры: Роснефть CYN, Полюс CYN, Русал, и т.п.) или замещенные еврооблигации РФ или тех же "голубых фишек" (примеры: замещенные облигации Газпром Капитал, замещенные государственные еврооблигации РФ)

2. При планировании более чем на год акции не успеют показать достойную доходность (в сравнении с депозитом), хорошие облигации на срок до двух лет могут не найтись, а инфляция, судя по ставке ЦБ, в 2025 будет беспрецедентная (к тому же - это старый, проверенный инструмент, используемый в РФ для повышения доходов от экспорта, а доходы стране нужны...). Если к тому же точный срок, когда понадобятся деньги, не ясен, то здесь видится вариант с БПИФ Ликвидность. Юань (CNYM), как бы я не не любил ПИФ-ы.

3. При планировании на короткий срок, здесь, как правило, точно не ясно когда нужны деньги, поэтому ни короткие облигации, ни депозиты не подходят. Здесь можно воспользоваться БПИФ Ликвидность (LQDT). В свое время я его сравнивал с депозитом, доходность по нему сравнима с лучшими предложениями на рынке, но в отличие от депозита, средства можно снимать в любое время без потери процентов.

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

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

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


#финансы

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

Во время анализа сработавших хантов меня не покидало ощущение, что подобное исследование можно сделать просто по номенклатуре событий. И вот, в работе A Sysmon Incremental Learning System for Ransomware Analysis and Detection (pdf) ребята провели такое исследование: по номенклатуре событий Sysmon-а обнаруживали ransomware.

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

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

Описанные три пункта я планирую исследовать последовательно, так как есть ощущение, что даже первый примитивный анализ разных событий с хоста уже будет результативен для ряда сценариев. Задача здесь будет ставиться как подсветить хосты, которые следует включить в анализ нашего VSL-аналитика в рамка процесса Periodic Retro Hunting (упоминал его здесь)

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

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

#MDR #ml

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

Гибкая разработка

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

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

Дженнифер Грин, Эндрю Стеллман. Постигая Agile. Ценности, принципы, методологии

Майк Кон. Agile: оценка и планирование проектов

Дэвид Дж. Андерсон. Канбан. Альтернативный путь в Agile

#dev #книги #управление

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

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

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

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

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

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

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

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

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

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

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

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

И вот (наконец-то) попалась настоящая хрестоматия использования ИИ в различных направлениях ИБ - 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#пятница #vCISO

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

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

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

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

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

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

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

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

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

#crypto #ml

Продолжу рассказ о нашем путешествии по р. Умба в августе 2024.

Порог Падун, 3+ категории сложности, на мой взгляд, самый красивый на маршруте. Длина порога - около 1 км. Порог проходили в первый день, поэтому, можно сказать, им открылось наше путешествие. В основном видеоматериалы касаются первой ступени, где падение составляет около двух метров. Слив с первой ступени разделен симпатичным и легко узнаваемым островом. После первой ступени, река сужается, поток сильно разгоняется, однако, с крутого левого берега можно удобно наблюдать проходящих. Вторая ступень, скорее, шивера с обилием камней и крупными валами до полуметра. Третья ступень - на S-образном изгибе, у правого берега сливы до 1 метра с камнями, по центру и ближе к левому берегу - расположенные под углом к основной струе две бочки с валами.

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

#здоровье

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

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

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

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

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

#MDR #kaspersky

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

Windows User Account Forensics

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

#MDR

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

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

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

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

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

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

#MDR #vCISO

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

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

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

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

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

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

#музыка

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

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

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

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

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

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

#MDR #ml

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

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

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

#vCISO

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

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

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

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

#MDR #vCISO #kaspersky

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

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

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

#искусство

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

#MDR

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

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

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

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

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

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

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

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

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

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

#РФ

Вчера, ура!, добрался до Передвижников в Третьяковке.

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

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

#искусство

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

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

#dev #пятница

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

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

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

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

#MDR

Вчера мне довелось побывать в Государственной Думе. В зале ЛДПР состоялся круглый стол "Практика противодействия кибератакам", аудитория - представители отрасли, как поставщики решений, так и их потребители. Хочется выразить слова благодарности компании Angara security, персонально Сергею Петровичу Шерстобитову и Тимуру Зиннятуллину, и за организацию мероприятия и за возможность принять участие - чем плотнее экспертное сообщество будет работать с законодательной властью, тем эффективнее и результативнее будут наши общие усилия по противодействию кибератакам и кибертерроризму.

Мне выпал вопрос: "Как нам, как представителям индустрии, вести себя в разгар кибервойны, как выстраивать отношения со всеми вовлеченными сторонами, включая государство? Как разделять зоны ответственности, особенно между Заказчиками и Подрядчиками?". Так как записи нет тезисно отвечу на него здесь.

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

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

2. Стандартизация. Под типовые элементы инфраструктуры должны быть разработаны профили защиты, и эти профили должны быть обязательны для исполнения в ГИС и КИИ. Пример из жизни - NIST SP 800-53 - исчерпывающий каталог контролей, обязательный для исполнения в американских ГИС.

3. Потребовав исполнение профилей защиты, результат необходимо обязательно проверять.

3.1. На госпредприятиях есть "мероприятия по оценке защищенности" (МОЗ) по сценарию пентест, можно дополнительно ввести оценки соответствия - по каждому обязательному контролю убедиться, что он внедрен и работает с предполагаемым качеством.

3.2. Контроли необходимо обложить метриками и результаты их измерения собирать. По истории измерений метрик можно анализировать тенденции. Отчетность по измерению метрик работы контролей можно поднять на уровень федеральных координационных центров - как мы собираем информацию об инцидентах в НКЦКИ, можно собирать и данные о метриках контролей безопасности.

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

4. Эксплуатация доверительных отношений по данным статистики инцидентов за 2023 и 2024 входит в топ 5 векторов проникновения в сети, поэтому требования по контролям пп.2-3 необходимо распространить на подрядчиков, в целом, это должно стать квалификационным требованием. Это можно сделать, например, лицензированием, а подтверждать соответствие, например, могут лицензированные аудиторы\ пентестеры.

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

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

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

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

Следует поблагодарить Дэна за подробные разъяснения, а мне ничего не остается, кроме как его процитировать.
Проголосовать можно и за наш канал по ссылке
https://t.me/boost/soldatov_in_telegram

Выкладываю презентацию с мероприятия.

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

Если по презентации что-то еще не ясно\спорно, пишите вопросы в комментариях, непонятные моменты распишу в новых заметках.

#vCISO

Всем привет! Как обещал, сегодня я в Минске у друзей из А1 Беларусь, на A1 Tech Day.

Есть возможность/желание, пишите, пересечемся.

Мой друг и коллега, Саша Родченко, из нашей команды Detection Engineering MDR, в этом году на BH MEA будет рассказывать об ошибках атакующих, за которые их ловит SOC.

Но это не все!

Мой, не менее друг и коллега Амджед, из нашей команды Compromise Assessment, расскажет об анализе артефактов Google Drive, о чем можно почитать анонс в канале Управления Сервисов.

#MDR #kaspersky

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

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

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

#искусство

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

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

1. Вспомнился классический документ Федора про фингерпринтинг TCP/IP реализаций в разных ОС. И вот теперь мы поднялись на уровень приложения.

2. Построение системы безопасной аутентификации возможно только в ущерб приватности. Это еще один принципиальный постулат, аналогичный тому, что невозможно построить ML-модель, которую не сможет обмануть человек. Принцип в полной мере работает и в реальной жизни: предъявляя паспорт на входе вахтеру, который записывает его данные в свой журнальчик входов\выходов, я повергаю риску компрометации свои паспортые данные. Причем, чем более безопасный механизм аутентификации мне надо построить, тем больше своей приватности мне надо передать: чем более точно проверяющему надо определить меня, тем большую частью себя мне надо поделиться с проверяющим. Приложенная картинка с разбиранием приватности ради безопасности - прекрасная иллюстрация этого принципа. В этой связи, любой механизм профилирования всегда будет иметь "privacy impact", и поэтому доносимый статьей "мессидж" выглядит как очевидная очевидность. Тем не менее, статья содержит неплохой обзор того, что в принципе может собираться при профилировании.

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

Работа SOC напрямую зависит от работы аналитиков. Усталость, утомленность аналитиков негативно влияет на результат, ребята ошибаются.

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

За время работы нашего SOC с 2016 мы прошли долгий путь (часть его я прошел еще в прошлой жизни, поэтому в 2016 мы стартовали не с самых ужасных графиков), а в 2023 году, на SOC Forum, мой коллега и друг, Альберт Гонебный, сделал замечательный доклад о том, как нам удалось выработать сменный график, как нам кажется, наиболее комфортный для команды - "От ночных недосыпов к work-life balance, или как организовать комфортный график дежурств для аналитиков"

Слайды доступны во вложении.
Ссылка на видео.

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

В рамках подготовки к выступлению вспомнились два, не лишенных изъянов, но, в целом, не самых плохих документа от Gartner.

1. The CISO’s Guide to Your First 100 Days (доступен во вложении). Здесь все хорошо с методологической точки (теоретической) зрения, но есть сложности с практической реализуемостью в обозначенные в документе сроки. Абсолютно правильно, что надо выбрать какую-то конкретную область и по ней показать "quick win". Дока может быть полезна для новых CISO в качестве плана на ближайшее время: за 100 дней описанное там для крупного предприятия сделать невозможно, но можно выбрать что-то, как из меню + можно сузить объем анализа, например, начать с критических бизнес-процессов, или с наиболее вероятных векторов атак. Также, нужно быть готовым к тому что понять зрелость за 4 недели не получится и надо будет выискивать компромиссы, да и сама методика оценки "зрелости" в доке тоже не приводится (в общем, проблем немало 😕 ).

2. Презентация Treat Cybersecurity as a Business Investment for Better Outcomes. В ней правильно утверждается, что CISO, будучи экспертом, должен давать Бизнесу опции, из которых последний будет выбирать что для него допустимо, исходя из остаточного риска (кстати, о допустимом ущербе я немного рассуждал здесь), - сложно спорить с этой очевидностью, однако, не стоит ожидать, что Бизнес всегда способен объективно оценить какой остаточный риск для него действительно допустим, тем более, если этот риск выражен не в деньгах, а для CISO оценка рисков не исключает допущений и предположений (в общем, здесь тоже все нездорово)

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

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

Но время не стоит на месте и наши современные автомобили все больше напоминают гибридную компьютерную сеть, а в обращение входит термин Software-Defined Vehicles (SDV).

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

#vCISO #automotive

На днях общался с одним белорусским изданием.

Какие основные мысли я хотел донести.

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

2. Были вопросы про эффективность антивирусов, однако, в печатную версию нашего общения попало далеко не все. В целом, я не сказал ничего нового, относительно этого своего общения с CyberMedia.

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

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

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

И вот, по-моему, первая публикация на тему водяных знаков в LLM-генеренном тексте.

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

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

Реализация Google выглядит довольно бодро: водяной знак обнаруживается уже в тексте размером в 200 токенов.

Идея с вотермаркированием LLM-созданных текстов выглядит перспективно - подтверждение авторства важно для безопасности.

#ml

Maintenance и Freezing

Я для себя четко различаю maintenace и freezing применительно к функционалу или компоненту информационной системы, однако, при общении с командами разработки заметил, что встречается несколько иное видение. Пользуясь преимуществом автора этого блога, поделюсь своим мнением.

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

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

Однако, в девелоперских конторах под maintenace могут понимать то, что функционал поддерживается исключительно инфраструктурно: работает, не падает, а если в нем находят баги, их исправляют. При подобном подходе мы бы до сих пор пользовались каменным топором. В моем понимании - это Freezing, а не Maintenance, тем более, что эта инфраструктурная работа не несет прямой ценности для потребителя. Я уже писал о том, что успешные компании должны мыслить с позиции потребителя, да и все книжки про Agile, и прочие прогрессивные методы, пишут что нужно постоянно обеспечивать конвейер доставки ценности, ценности для потребителя. Однако, все еще встречается логика с позиции инженера-разработчика.

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

#dev #управление #пятница

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

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

#мир

В новой статье КПЭ операционного аналитика продолжу делиться опытом процессной организации SOC.

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

#vCISO #MDR

В прошлой жизни, ЕМНИП году в 2003-2005, для контроля неавторизованных изменений у меня был скрипт, который по расписанию по LDAP дампил весь домен AD в реляционную базу. Далее я сравнивал текущий дамп с предыдущими и находил различия, можно было отслеживать динамику. В основном я фокусировался на членстве в группах, находя таким образом предоставления доступа, которые не были согласованы с Безопасностью. Сейчас, конечно, есть еще масса других, более интересных, атрибутов объектов LDAP, которые имеет смысл отслеживать, в том числе и для обнаружения атак.

Мой друг и коллега, Саша Родченко из нашей команды Detection Engineering разработал инструмент и выложил его в общий доступ. Enjoy!

#MDR

Все 7 способов дампа памяти LSASS в одном инструменте. Очень удобно, в том числе и для исследований
https://github.com/Offensive-Panda/ShadowDumper

#MDR

28 ноября я планирую быть у друзей в BI.zone на митапе про SOC-и с докладом.

Будет возможность, приходите, пообщаемся!

Елена Съянова. Десятка из колоды Гитлера

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

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

Но история всегда повторяется. Несмотря на то, что с точки зрения любого законодательства НСД - преступление, в условиях балканизации все чаще просматривается концепция "правильного НСД" и "неправильного НСД", своего рода, оправдания кибертерроризма...

Почти 8 лет назад я уже писал об кибероружии массового поражения, пришло время проанализировать тему кибертерроризма - печальная тенденденция налицо.

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

Все правильно пишет Саша о том, что политика США никак не меняется от смены президента. И демократов и республиканцев спонсируют одни и те же олигархи, учредители ФРС, и если президент (наемный управляющий) решит заниматься самодеятельностью, его постигнет участь JFK.

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

Все то же мы уже наблюдаем в нашем автопроме, когда Лада стоит дороже Тойоты, а объяснения, приводимые отечественными производителями (вот сессия про NGFW с теми же вопросами, как и про Ладу Весту: почему так плохо и так дорого) ровно такие же, как и у АвтоВАЗ-а.

#мир

26 ноября я буду в гостях у Клавдия в замечательной Беларуси, на A1 Tech day, рассказывать об ожиданиях Бизнеса от CISO и как последнему их оправдать.

Вспомню своё прошлое - корпоративного менеджера по ИБ и Заказчика решений, подмешаю свое настоящее - исполнителя требований ИБ со стороны операционки, разработки, консалтинга и Поставщика решений. Постараюсь, чтобы было интересно!

Будете на мероприятии, найдём возможность обсудить то, что вас волнует!

Утром в рабочем режиме читал статью "STUBborn: Activate and call DCOM objects without proxy" и все-таки решил ее здесь прикопать. Во-первых, там много полезного для DFIR, во-вторых, статья содержит массу ссылок на дополнительные материалы по теме COM и DCOM

#MDR

Для всех, кто в отрасли ИБ и ИТ известно слово "импортозамещение"! Но есть одно, что импортозаместить не получится - это английский язык.

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

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

Видимо, у ЛК примерно такая же логика, поэтому все курсы, даже те, что читаются русскоязычными парнями, вроде меня, - на английском языке.

Но мы подготовили для них русское описание.

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

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

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

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

#управление

LOLAD - пополнение в проектах LotL. На сей раз применительно к Active Directory

#MDR

Наступательная кибербезопасность 2024 на AM Live. По какому принципу я выбираю эфиры? По составу спикеров!

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

13:41 Ручной анализ защищенности - некий следующий этап. Мне было бы очень интересно увидеть статистику уязвимостей, которые были найдены вручную, но не были найдены автоматизированными средствами. Далее, раскрутить эти уязвимости в ущерб и вообще понимать эту эффективность для всяких сканеров.

18:15 Все говорят о необходимости подъема результатов пентеста на бизнес-уровень. Я тоже об этом говорил. Однако, чем больше ценность мы хотим дать для бизнеса, там глубже требуется вовлеченность \погружение, чего сложно ожидать от подрядчика. Может, я все время работал в зрелых конторах, но мой опыт показывает, что подрядчик делает свою узкую задачу (чем она уже, тем лучше он ее делает), а затем уже внутренняя команда поднимает его результат на уровень корпоративных бизнес-процессов.

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

30:44 Утверждается, что ТЗ на пентест должно быть с открытым объемом. Не согласен, объем всегда должен быть определен, иначе невозможно ничего проконтролировать - ни качество, ни сроки, ни стоимость.

31:24 Удивительное утверждение, что заказ на пентест исходит из ИТ. Никогда такого не видел и с трудом могу представить этот сценарий.

1:22:40 "Чатик в Телеграмм для отчетности по пентесту" - ужас. Тут я побуду занудой - никогда не обменивайтесь такими данными по открытым каналам, даже на внутренних системах используйте, например, PGP/GPG

1:28:04 Background checks для участников bug bounty. Очень важный момент! При всем моем уважении к bug bounty, как к подходу \инструменту, надо что-то делать с риском, что за bug bounty могут скрываться реальные атакующие. Не уверен, что на доступных российских площадках bug bounty исполнители контролируются так же хорошо, как исполнители команды законтрактованного подрядчика (надо вопрос поисследовать, может, я неправ).

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

1:33:44 отразить в отчете все неуспешные попытки - отличный кейс, важность которого невозможно переоценить для внутреннего понимания рисков. Хотелось бы, чтобы это стало доступной опцией, и это не надо было бы выпрашивать. Как минимум:
- позволит понимать актуальность закрытых мною векторов
- позволит оценить стоимость атаки
- позволит оценить квалификацию подрядчиков 😁
- ... и много чего другого, может, сделаю отдельную заметку

1:47:23 результаты пентеста должны быть оформлены так, чтобы заказчик мог это правильно съесть. Важнейший момент! Надо разбираться почему из проекта в проект у одного и того же заказчика мы видим одно и то же, может, стоит для него снизить трудоемкость обработки нашего отчета. Например, чтобы он был машиночитаемым и мог конвертироваться в наряды на работу в корпоративной системе управления изменениями, или что-то в этом роде. Очень правильный поинт, что надо понимать как заказчик будет работать с результатами проекта и помогать эту работу сделать максимально эффективной. Если наш продукт неправильно используется и заказчик не получает предполагаемую нами ценность - это наша проблема!

1:58:19 Вопрос - как часто проводить пентест \анализ защищенности \проект. Все назвали все, но, почему-то, кроме очевидного: частота работ зависит от того, как быстро обрабатываются результаты предыдущих работ - не имеет смысла проводить новые работы с тем же объемом, пока не устранено все, что было найдено ранее.

#vCISO

Интерфейс пользователя должен быть удобным! Но как это измерить?

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

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

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

По цвету, расположению и размеру элементов предлагаю следующий тест. Профессионал в предметной области (SME), но ни разу не видевший тестируемый интерфейс, рассматривает интерфейс в течение N секунд (время определяется в зависимости от сложности интерфейса и на базе бенчмаркинга с аналогичными решениями), а затем его по памяти просят воспроизвести этот интерфейс на бумаге. При этом, стоит обратить внимание в какой последовательности SME будет зарисовывать интерфейс - это ответ на вопрос что он увидел в первую очередь, и сравнить это с функциональным назначением. Если SME не смог воспроизвести интерфейс по памяти, то с цветом, размером, расположением элементов есть проблемы, интерфейс надо перерабатывать. Более сложная, но и более эффективная реализация теста - это поискать ответ на вопрос: сколько нужно времени SME, чтобы запомнить его в достаточной для воспроизведения по памяти мере? Здесь надо уже привлекать нескольких SME. На практике у группы SME можно просто спросить их мнения (Метод Дельфи) и точечно отработать противоречия.

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

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

#dev #управление #пятница

Мой коллега Дима из команды Detection Engineering поделился очередным сценарием повышения через УЦ в составе Active Directory

#MDR

Руководство по оценке EDR от Red Canary мне показался полезным. Ниже приведу список, что мне показалось важным.

EDR - неотъемлемая часть AV, Next-Gen-ов и, собственно, EDR, обеспечивающего визибилити, о чем я писал 8 лет назад. Поэтому предлагаю использовать общий термин, подсмотренный у Gartner, - Endpoint Protection Platfrom (EPP).

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

Функциональные возможности, и необходимая телеметрия, EDR рассматриваются в перспективах: Visibility, Alerting, Prevention, Response, Reporting.

Open Cybersecurity Schema Framework (OCSF) - набирающий популярность стандарт

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

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

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

Приведен список респонсов и требуется возможность автоматического исполнения респонсов для некоторых алертов, для чего необходима "легковесная" оркестрация (часть SOAR)

Поскольку размыты границы между EDR/XDR, SIEM, SOAR, обязательно наличие функционального API.

Многе EDR имеют возможность запуска кастомных скриптов, однако надо иметь в виду совместимость версий требуемых интерпретаторов.

Подсвечен риск компрометации самой платформы EDR, что откроет перед атакующим безграничные возможности, а в качестве контроля предлагается MFA 😁. Без комментариев.

Особенно важна инвентаризационная отчетность, как о защищаемой системе (кстати, важная информация для корреляции), так и о состоянии самого защитного решения.

По всему документу можно отметить, что критерии больше подходят для облачного EDR/XDR, что понятно, зная модель бизнеса Канареек. Однако, не вижу большой проблемы поддержки тех же фич и в on-prem.

Документ будет полезен лицам, принимающим решение о выборе EDR\MDR для своей инфраструктуры.

#MDR #vCISO

Вопрос выбора адекватных контролей информационной безопасности зависит от величины допустимого остаточного риска или риск-аппетита. Риск-аппетит зависит от множества факторов и сильно варьируется для различных предприятий, поэтому объем требований к подразделениям операционной безопасности (короче, SOC) также сильно специфичен для каждого из предприятий. Чем больше требований выдвигается, тем более глубокая интеграция в корпоративные бизнес-процессы от SOC требуется, что затрудняет вывод SOC в аутсорсинг или делает его экономически нецелесообразным.

В целом, думаю, уже никто не будет оспаривать преиущества именно гибридной модели SOC, ибо, как невозможно аутсорсить ответственность, так и невозможно полностью все сервисы операционной ИБ передать в аутсорсинг (тем более, что чем глубже интегрирована в корпоративные БП безопасность, тем эффективнее она работает!). А раз так, то внутренней команде нужны инструменты.

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

Уверен, что среди нас есть пользователи Kaspersky MDR, - замечания и предложения по документу, пишите в комментариях или присылайте мне лично. Вместе у нас получится лучше!

#MDR #kaspersky

Полно случаев в практике, да и ни у кого не вызывает сомнения, что неправильное лечение может ухудшить состояние пациента. Можно загубить как сам предмет лечения, так и здоровые органы. Ну, например, если бездумно трескать "бесконечно полезные" биодобавки и витамины, то могут отъехать печень и\или почки, которые буду стремиться все эту инородчину выводить.

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

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

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

Вот такие мысли у меня возникли, когда я начал читать книжку Михаэля Зингера "Трениннг освобождения души". Нет, я не хочу сказать, что книжка плохая, правда, что она хорошая тоже не могу сказать, там слишком много шаманства и наукообразия (когда бредовые объяснения преподносятся как высоконаучные обоснования), а мне, ИТшнику, более близко что-то практическое, материальное, осязаемое, научно доказанное. Книга точно будет полезна всякого рода энеропрактикам (про внутреннюю энергию и чакры я уже успел многое там прочесть). Следует отметить, с учетом того, когда книжка была написана, что она - база всех энергопрактик, своего рода "Пикник на обочине" Стругацких для целого ряда последующих писателей про сталкеров.

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

Всем замечательной пятницы и выходных!
😁

#пятница #книги #саморазвитие

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

"Зри в корень!", - говорил Козьма Прутков.

После того, как Visa и MasteCard решили наказать граждан РФ отказом от своих обязательств, наши карты этих платежных систем стали "бессрочными". У меня самого есть кредитка Visa Signature, которая давно истекла, однако, я продолжаю ей пользоваться, так как по ней сохранились привлекательные условия по кешбеку, а полных аналогов от Мир нет.

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

Итого:
- карты не "бессрочные"
- чем дальше от срока exp. date на карте, тем больше вероятность, что карта "перестанет работать"
- надо иметь бэкап-план на случай, что протухшая карта действительно откажет

#финансы

Среди техник для горизонтальных перемещений SCCM представлен только в T1072: Software Deployment Tools, однако, SCCM имеет функционал удаленного подключения к рабочей станции, и поэтому может предлагать функционал аналогичный VNC или RDP, а за счет широкого распространения SCCM в корпоративных сетях может быть вполне себе LotL-инструментом горизонтальных перемещений.

В статье ребята подробно разобрали этот сценарий:
- согласие пользователя на подключение можно отключить будучи админом на целевой системе
- клиента можно запускать где угодно, не обязательно на сервере SCCM
- каких-то специальных прав "Администратора SCCM" для организации не надо

ЗЫ: А в MITRE SCCM в таком сценарии не предусмотрен. Что и следовало ожидать: ATT&CK со своим списком техник все больше отстает от реалий ITW, а они еще носом верятят, когда им техники заносят.

Делаем ханты, ребята...

#MDR

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

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

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

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

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

ЛК запустила функционал Threat landscape в составе своего TIP, где собрала известные кампании, разложенные по их TTP в нотации MITRE ATT&CK и целям: можно удобно выбрать интересующую индустрию и географическую локацию, и получить перечень релевантных атакующих и их ТТР.

Подробности будут на вебинаре. От нашей команды Detection engineering, а в прошлом - аналитик операционных линий, мой коллега и друг - Глеб Иванов.

#kaspersky #MDR

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

#MDR

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

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

Так вот, в части НСД мы уже давно доросли до подхода assume breach и threat hunting-а (презентацией той поделюсь, правда ей уже скоро 10 лет), т.е. мы уже допускаем тот факт, что атакующие есть в сети (уже есть НСД, собственно, про что вся безопасность!) и считаем это допустимым, пока нет ущерба недопустимого размера.

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

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

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

Более чем 14 лет назад я рассуждал об авторском праве, и о необходимости свободного доступа к знаниям и информации. И вот сейчас, но уже под соусом машинной обработки мы обсуждаем те же проблемы

#ml

Интересное сравнение EDR-ов, будем следить за проектом...

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

#MDR

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

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

#MDR #vCISO

Ребята из F.A.C.C.T. выпустили фундаментальное исследование про Shadow и Twelve и релевантные им проекты. Док крайне полезен для понимания современного ландшафта угроз для РФ, о чем, вроде бы, написано немало (1 , 2 ), но знания не бывают лишними (тем более, всегда интересно сравнивать отчеты разных поставщиков на схожие темы - это позволяет создать более объективное представление и сопоставить собственные наблюдения)! Делюсь.

#MDR

Старый PlugX до сих пор используется. До 2016 я не занимался атрибуцией, поэтому, если даже и встречался с проявлениями его использования, мало интересовался тем, что это как раз и есть то самое, что зовут немного маркетинговой аббревиатурой "APT". А уже в 2016, когда начал работу в ЛК, не раз с ним встречался, понимая и что это такое и какова мотивация его операторов.

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

В целом, с 2016 года за операторами PlugX наблюдалось большое разнообразие техник и инструментов, поэтому атрибутировать их удалось только по используемому кастомному трояну. Даже если у операторов и были\есть излюбленные техники и процедуры (как основа для атрибуции), то нет никакой гарантии, что команда операторов на протяжении 10 лет не меняется, а люди разные: кто-то любит Cobaltstrike (кстати, наряду с PlugX-ом использование Cobalt-а тоже наблюдалось), а кто-то предпочитает MSF, - могу предположить, что служба по контракту не длится вечно, поэтому люди точно будут меняться. Отчасти всеми этими мыслями объясняется мой небольшой скепсис к атрибуции, который просматривается в нашем обсуждении с Олегом.

Но какие краткие выводы по PlugX:
- надо детектить DLL side loading (как-нибудь обсудим)
- есть некие особенности (актуальные на сейчас): userinit с параметрами, именованные каналы, и более волатильные - C&C
- можно попробовать сделать детекты на discovery - едва ли бухгалтер будет дергать ipconfig /all или tasklist
- можно детектить переименованные бинари
- надо следить за детектами антивируса, в подобных атаках едва ли он будет совсем безмолствовать + стандартная гигиена: ставить патчи на периметре, обучать пользователей (чтобы не кликали на фишинг) и т.п.

#MDR

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

Маршрут можно проследить в Strava, кроме первого дня (не заметил, что в тренировке "Рафтинг" не записывается маршрут), но далее все записано.

Далее перечислю ходовые дни, без учета дневок, которые заметны по датам)
День первый, 05.08: Стапель (мост через р. Умба, на пути из г. Апатиты) - п. Падун (сразу после прохождения)
День второй, 07.08: п. Падун - входная шевера п. Разбойник
День третий, 08.08: п. Разбойник - п. Семиверстный - Жемчужный плёс
День четвертый, 09.08: Жемчужный плёс - п. Карельский - п. Канозерский - Канозеро
День пятый, 11.08: Конец Канозера - Падун-на-Низьме
День шестой, 12.08: Падун-на-Низьме - Медвежий плес (антистапель)

По логистике:
- 03.08. Поезд Москва - Апатиты
- 04.08. Автомобиль от г. Апатиты до моста через р. Умба
- 13.08. Автомобиль от пос. Умба до г. Кандалакша
- 14.08. Поезд Кандалакша - Кемь, катер - Соловки
- 15.08. Соловки
- 16.08. Катер Соловки - Кемь, поезд Кемь - Москва

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

Продолжение следует...

#здоровье

Теперь, когда мы разобрались с NTLM relay и как его теоретически можно обнаруживать по событию 4624, рассмотрим причины, почему на практике это работает плохо.
1. При аутентификации NTLM MS не гарантирует наличие IP-адреса, но, вроде как, обещает наличие NetBIOS имени. На практике это работает по-всякому: при аутентификации NTLM есть события в которых есть и IP и имя, где есть только IP (и нет имени!), и, конечно, где есть только имя (и нет IP). Картинки. Поскольку нам для успешного обнаружения нужны и IP и имя, для NTLM, в среднем, таких событий около 30-40%, т.е. на большей части событий предложенный детект построен быть не может.
2. В рамках логики обнаружения мы делаем резолв имени\адреса. Этот резолв может:
2.1. Ничего не вернуть, либо потому что для хоста нет записи в DNS, либо из-за какой-либо ошибки. Допустим в рамках корпоративного SOC обеспечить наличие в любой момент времени всех хостов в DNS можно, то на уровне внешнего поставщика SOC\MDR навести подобный порядок в инфраструктуре невозможно.
2.2. Вернуть другое имя\адрес, что на практике нередко, как минимум, по следующим причинам:
2.2.1. DNS-имя хоста не совпадает с NetBIOS-именем
2.2.2. Всяческие сценарии с крастерами\балансерами\шлюзами, когда на несколько нод с разными именами NetBIOS один адрес и\или одно DNS-имя
2.2.3. Иногда во внутренних сетях, видимо, для пущей безопасности, используются NAT. В этом случае хост имеет один IP-адрес, но в событии 4624, с аутентификацией с него, будет адрес после трансляции, который даже может nslookup-итья в какое-нибудь имя, сильно отличающееся от реального имени хоста-источника за NAT
2.2.4. Если у хоста несколько IP-адресов, то успех нашего детект зависит от того какие в итоге прописаны в файле DNS-зоны

Как уже отмечалось выше, если мы с вами внутренний SOC, и мы очень хотим ловить релеи менно по 4624, то при большой мотивации у нас есть возможность почистить фолсу для этого детекта, но успех составит, опять же, вынужден повториться, 30-40%, так как MS не гарантирует наличие IP-адреса в событиях аутентификаци по протоколам NTLM.

#MDR

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

#vCISO

Относительно этого детекта немного добавлю деталей:
- основное событие телеметрии для него - Kerberos ticket metadata, присылающее информацию о сохраненных в памяти TGT и TGS. Ближайшая аналогия - klist
- детект сравнивает имя хоста из SPN с именем хоста, откуда взят билет (откуда пришло событие телеметрии). Аномалия заключается в том, что находится билет для сервиса на локальном хосте, т.е. имя хоста из SPN билета совпадает с именем хоста.

#MDR

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

#саморазвитие #управление

Brian Komar. PKI and Certificate Security

Если вы - администратор корпоративной PKI от MS, то эта книга будет вам хорошим справочником и практическим советчиком.

#книги

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

С учетом описанного букета последствий и достаточно бытовой ситуации потери\утраты токена, сама идея использования криптографии ставится под сомнение. Решение здесь простое и старое, как сама идея PKI - депонирование ключей

#vCISO

Мой коллега и друг, Игорь Таланкин, человек, непосредственно занимающийся разработкой контента коммерческого SIEM, а также очень плотно участвующий в технологическом развитии нашего SOC по части автоматизации и плейбуков, 9 октября примет участие в AM Live по практическому применению SIEM

#MDR

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

А что касается Responder-а, то сценарий наловить NetNTLM хешей с последующими попытками их побрутить - всегда с нами, поэтому:
- все ненужные творения MS, вроде LLMNR и NBNS надо отключить (вообще, по принципу минимума полномочий, все ненужное лучше отключать)
- если нет возможности не использовать WPAD, полезно следить IDS-кой кто в сети пытается выдавать себя за WPAD-сервер (аналогично, полезно следить кто выдает себя за DHCP-сервер)
- если уж наловили хешей, то пароль должен быть сложный и не вечный (что бы не писал там NIST), чтобы поломать его было вычислительно сложно

#MDR

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

В целом, на рынке можно найти варианты (раз, два, и т.п. или собрать самостоятельно)

А если серьезно, то у каждого CISO должен быть предусмотрен сценарий уничтожения критичной информации в случае потери физического контроля или попытке нарушения физической безопасности. Этот вопрос следует решать в рамках корпоративных программ BCP &DRP. Для серьезных случаев следует предусмотреть автоматику, которая уничтожит данные при обнаружении нелигитимного физического проникновения, по аналогии с криптексом из "Кода Да Винчи". У меня был опыт разработки подобных мероприятий, и вот моменты, которые, как минимум, надо проработать:
- протестировать решение по экстренному уничтожению данных не так-то просто, поэтому надо придумать как получить уверенность, что в час Х система сработает как ожидается;
- надо продумать условия приведения системы в действие: если автоматически, то при наступлении каких ситуаций (например, физическое разрушение стен или дверей ЦОД), если вручную, то кто это делает, и надо обеспечить, чтобы у него (них, так как это должна быть группа) всегда была возможность сделать свою часть задачи;
- - разумно иметь "мягкий" сценарий, а точнее, некоторую этапность, чтобы угробить не все сразу, а по частям, сохраняя для более мягких сценариев возможность восстановления;
- надо не забыть про бэкапы: если есть риск их компрометации, их тоже надо уничтожать;
- следует продумать сценарии обеспечения непрерывности (в CISSP, помню, много посвящено BCP&DRP): переключение на резервный холодный\горячий\мобильный\в глубь страны ЦОД, откуда работают сотрудники и т.п.;
- надо продумать сценарии "защиты от дурака", защиты от ложных срабатываний, цена ошибки здесь велика;
- надо подумать о конфиденциальности всей схемы (всего плана BCP), чтобы, по возможности, снизить риски отказа системы уничтожения данных при наличии инсайдера среди непосредственных участников: не должно быть исполнителя, кто бы мог единолично сорвать весь процесс;
- с тестирования начал, тестированием и закончим: все участники процесса должны хотя бы раз симулировать поведение во всех предусмотренных сценариях (от самого мягкого, до самого жесткого), чтобы в час Х каждый точно знал, что он должен делать.

#vCISO

Покрытие MDR

Слабое место MDR – это покрытие, мы не видим там, где нас нет. Контроль покрытия – чтобы на всем объеме мониторинга был установлен и правильно сконфигурирован (все компоненты включены, настроен аудит ОС) агент – в ответственности потребителя.

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

В MDR есть моделька машинного обучения на аномалии, которая отслеживает в том числе и сценарии падения телеметрии по клиенту в целом. Здесь плохо работают жесткие пороги, так как количество активных хостов падает в нерабочее время, однако, ML с этими флуктуациями справляется удовлетворительно. Значительное падение телеметрии будет оформлено как инцидент с уточняющим вопросом о том, что происходит.

Более-менее объективным сценарием проверки работы MDR является анализ защищенности. С учетом описанной проблемы контроля покрытия, перед проведением анализа защищенности, одной из целей которого является проверка MDR, обязательно следует удостовериться, что объем анализа защищенности совпадает с объемом мониторинга MDR, т.е. на хостах в объеме пентеста установлены и правильно сконфигурированы агенты, а телеметрия с них долетает до облака (в Web-консоли MDR для каждого актива есть поле last seen/последнее появление).

Вообще, анализ защищенности проверяет защищенность объектов инфраструктуры, важным элементом защищенности является защищенность конечных точек, а наличие корректно работающего MDR – это элемент защищенности конечных точек. Отсутствие рабочего MDR на конечной точке, где он должен быть – несоответствие требованиям безопасности, а проводить пентест нужно все-таки для объектов, соответствующим внутренним compliance (грош нам с вами цена, если мы самостоятельно не можем проверить выполнение собственных требований на инф-ре, которую защищаем, и нам для этого нужен пентестер, да еще и внешний подрядчик!), поскольку проверки наличия безопасной конфигурации можно провести в рамках более дешевых процессов, которые в обязательном порядке должны быть в любой корпорации, типа периодической инвентаризации активов с параллельным аудитом соответствия, что можно сделать любой корпоративной системой управления активами, от элементарных групповых политик и скриптов, до SCCM. А если в корпорации пока еще нет процесса Управления активами (Управления конфигурациями), можно и задуматься, нужен ли прямо сейчас пентест...

#MDR #vCISO #kaspersky

Из чего же, из чего же сделаны наши SafeBoard’исты 😎
Из мыслей, общения, кофейных пауз и верных решений!

Стажировка в Kaspersky — твой шанс проявить себя, прокачать скиллы и добавить в жизнь ещё больше полезного опыта 😇

Заявку можно подать на любые три направления и на fast track в команду IT Service Desk. Направления этого набора:

▫️DevOps;
▫️UI/UX-дизайн;
▫️анализ данных;
▫️анализ защищённости;
▫️локализация ПО;
▫️разработка C, C++, Java Script, Python, С#;
▫️системный анализ;
▫️тестирование (ручное; авто, Python; авто, С#);
▫️IT Service Desk (fast track) — для тех, кто хочет попасть к нам быстрее.

Тебя ждёт работа над реальными задачами, зарплата и компенсация питания, сауна и игровые комнаты 😊

Присоединяйся, если учишься на любом курсе, в любом вузе Москвы и МО или в Школе 21.

Подавай заявку до 27 октября.

Выбирай то, что нравится, и сделай это новой гранью своих возможностей 🙌

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

В новом лонгриде порассуждал на тему что же такое инцидент, начав, как положено, с определения из ISO/ГОСТ, закончив некоторыми практическими примерами и соответствующими выводами.

#MDR #vCISO

Мой коллега, Владислав Тушканов (доклад про RAG был на offzone), руководитель нашей команды ML, кто доводит до практической реализации все наши бредовые идеи по применению ML/DL/AI в security operations, в своем канале, посвященном безопасности больших языковых моделей, опубликовал неплохую подборку материалов по базовым понятиям в безопасности LLM.

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

#ml

Пока не смотрел, но запланировал