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

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

#ml

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

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

#MDR #vCISO

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

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

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

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

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

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

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

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

Покрытие MDR

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

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

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

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

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

#MDR #vCISO #kaspersky

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

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

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

#vCISO

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

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

#MDR

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

#MDR

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

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

#vCISO

Brian Komar. PKI and Certificate Security

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

#книги

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

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

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

#MDR

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

#vCISO

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

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

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

#здоровье

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

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

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

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

#MDR

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

#MDR

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

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

The researcher demonstrated how he could trick ChatGPT into believing a targeted user was 102 years old, lived in the Matrix, and insisted Earth was flat and the LLM would incorporate that information to steer all future conversations. These false memories could be planted by storing files in Google Drive or Microsoft OneDrive, uploading images, or browsing a site like Bing—all of which could be created by a malicious attacker

OpenAI, вроде, поправили, но прецедент...


#ml

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

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

#MDR #vCISO

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

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

#MDR