Некоторые SOC пренебрегают онбордингом новых аналитиков или не уделяют этому должного внимания, а зря.

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

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

На днях был вынужден искать определенную тему среди своих старых презентаций и набрел на слайды с ISACA Moscow chapter, проходившего в марте 2019 года.

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

1. Реактивный подход к выстраиванию системы контролей ИБ (будем это звать СУИБ - система управления ИБ на предприятии) может показаться не самым разумным, но он наиболее просто обосновывается, так как раз у нас был тот или иной инцидент, о его вероятности не приходится много задумываться
2. В связи с этим, безопасность из Operations - вполне себе рабочий подход: мы строим операционные процессы, например, мониторинг и управление инцидентами, а по мотивам работы по инцидентам и проблемам - появляются наши новые контроли ИБ
3. Все предусмотреть невозможно, поэтому невозможно избегать ошибок (об этом еще порассуждаем в новых заметках, это одна из моих любимых тем), но возможно и нужно качественно отрабатывать ошибки, совершенствуя свою СУИБ в результате, поэтому fuck-up-driven management - абсолютно рабочий подход

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

Один из выдающихся хакеров современности и мой давний знакомый Саша Поляков сейчас переключил свое внимание на безопасность машобуча и ИИ.

К одной из его заметок с демонстрацией инъекции в модный GPT-o1 я не смог удержаться от комментария (он же на картинке).

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

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

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

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

Пишите ваше мнение в комментариях! Особенно интересно мнение профессионалов!

#пятница #ml

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

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

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

#vCISO

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

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

#здоровье

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

На прошедшем Offzone мои коллеги Андрей и Наташа делились особенностями ToddyCat.

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

Видеоапись выступления

#MDR #offzone

Red Canary выпустила традиционно неплохой отчет: 2024 Threat Detection Report, MIDYEAR UPDATE, Anin-depth look at the most prevalent threats, MITRE ATT&CK techniques and identity trends for the first half of 2024, который лучше рассматривать вместе с 2024 Threat Detection Report, Techniques, Trends & Takeaways, поскольку нового немного, а тенденции, подмеченные в течение 2023 продолжились и в 2024.

Делюсь своими заметками\наблюдениями.

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

Наблюдения за H12024
- атакующие охотятся за учетными данными - "Identity is the new perimeter". Это вполне может быть очередным толчком для развития IAM/IDM (много писал об этом лет десять назад, например, презентацией поделюсь)
- популярны атаки на браузеры - упомянуты ChromeLoader и схемы с ним, а кластер активности "Scarlet Goldfinch" под видом обновления браузера 😁 предлагает жертвам поставить RMM/RAT
- как и ранее, утверждается растущая популярность атак на MacOS - рассказывается про Atomic Stealer
- рост популярности T1114.003: Email Forwarding Rule и попадание в TOP - T1564.008: Email Hiding Rules

Отчет во вложении

#MDR

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

#vCISO

Не перестараться бы с фильтрацией...

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

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

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

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

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

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

История с KIA напомнила старый добрый 2002-ой, когда мы с коллегой разбирались с HP-UX...
Тогда коллега выдал:

Hewlett Packard делает замечательные принтеры.
Ну зачем они решили сделать операционную систему?!

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

Если вам интересна тема automotive security, то вот начальный список для ознакомления

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

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

И этот тоже (нужен VPN, прикладываю)

Про CAN в картинках

Основные проблемы автомобильной безопасности

#MDR #vCISO #automotive

Пароли в командных строчках

Пароли в командных строках – это небезопасно. Командные строчки логгируются в открытом виде (bash_history, powershell), в общем, не считаются конфиденциальной информацией, а, следовательно, операционные системы не обеспечивают для них должный уровень безопасности, как для пароля, поэтому наличие пароля в командных строках – это уязвимость, и в инфраструктурах с адекватными командами ИТ, скорее, аномалия. Тем не менее, по требованиям безопасности, можно ожидать пароли в командных строках, поэтому в решениях *DR может существовать какая-либо автоматика для маскирования паролей в командных строчках.

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

Пароль атакующего для обнаружения скомпрометированных систем
В одном из инцидентов атакующий использовал подломанную сервисную УЗ (пароль, хороший, стойкий, случайный, в открытом виде был взят из конфигов) для сбора информации BloodHound-ом, команда выглядела примерно так:
<...> Invoke-StandardCollector –c DcOnly –d domain.corp –prettyjson –nosavecache –ldapusername user_name –ldappassword user_password

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

Описанный фокус работает и с другими излюбленными инструментами атакующих – psexec, paexec, impacket, rdesktop, evil-winrm и т.п.


Пароль атакующего для снятия последствий ущерба
Шифровальщики – тип инцидента №1 с которым приходят за расследованием. Про шифровальщики есть масса публикаций (ну..., можно Ладу послушать, например, там профиль SMB, но для общего понимания – то, что надо; и Канарейки про них постоянно пишут, ну больше всех публикаций, конечно же у ЛК, один из свежих), но надо понимать следующие современные особенности:
– Непосредственно работе шифровальщика предшествует человекоуправляемая атака
– Обычно начинают запускать шифровальщик, когда сеть уже поломана, например, взят домен и шифровальщика раскатывают групповыми политиками или через корпоративные системы инвентаризации и управления типа SCCM или какие-то управляющие сервера (для целей унижения любят использовать сервера управления систем безопасности, которые, очевидно, как и все, в домене, а следовательно, скомпрометированы)
– Часто шифруют легитимные инструментами, типа Bitlocker, VeraCrypt, Kryptor, DiskCryptor и т.п.
– Либо используют кастомизированные сборки популярных Babuk, Conti, LockBit, Chaos, Xorist и т.п., а если мешает EPP, то его выносят разными способами в рамках человекоуправляемости атаки (часто используются легитимные методы, так как нелегитимные - шумные и блокируются, поэтому пока вынесут, ребят успеют локализовать)

В одном из инцидентов злоумышленник для шифрования использовал Bitlocker, команда выглядела примерно так:
manage-bde -on C: -rp very_long_random_recovery_password -sk C:\ -s -used -RemoveVolumeShadowCopies

Пароль восстановления доступен непосредственно в командной строке...

#MDR

Юрий Лотман. Комментарии к роману "Евгений Онегин"

Пушкин - наше все! Но большое видится на рсстоянье, а огромное можно рассмотреть только стоя на плечах гигантов. В Евгении Онегине Пушкин смог вместить невместимое, но для неподготовленного читателя многое остается непонятным. Юрий Михайлович Лотман - величайший исследователь творчества Пушкина, его публикации позволяют иначе взглянуть на знакомые с детства строки, понять новые смыслы, скрытые и не замеченные ранее, а его "Биография А.С. Пушкина" лучше раскроет поэта как личность, поведает о событиях его эпохи, что, безусловно, нашло отражение в произведениях.

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

В подтверждение своих слов, приведу несколько цитат из "Комментариев к роману..." .

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

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

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

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

#книги

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

Мой коллега, Владислав Тушканов (доклад про 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