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

#управление

Защитник короны

Мой первый компьютер - совместимый с ZX Spectrum, когда я был еще школьником в средней школе. На нем я писал программки на Basic, а еще, конечно же, играл. Помню, мне нравилась стратегическая игра Defender of the Crown. Действие игры происходит в средневековой Англии, сразу после смерти короля, когда различные фракции борются за контроль над страной. Игрок начинает игру за одного из саксов и пытается сражаться с ордами норманнов. Цель - получить контроль над большей территорией.

Одним из элементов игрового процесса были рыцарские турниры (Joust), где предлагается два вида ставки: за деньги (for money) и за славу (for fame).

Деньги были нужны для найма армий, проведения осад и содержания замков. Ставка "For Money" была более надежным, но менее прибыльным в долгосрочной перспективе способом пополнения казны.
Слава была критически важным параметром. Чем выше была слава, тем:
- чаще другие лорды предлагали союзы;
- больше солдат присоединялось к армии бесплатно во время путешествий по стране;
- проще было добиться поддержки в борьбе за трон.
Т.е. накопленная слава прибыльна в долгосрочной перспективе. Поэтому в зависимости от текущей ситуации в игре надо было понять когда нам нужен успех прямо сейчас (сражаемся за деньги) или на дальнем горизонте планирования (сражаемся за славу)

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

#управление

Тем временем нас - красивое число!

Большое спасибо за доверие и интерес к моим рассуждениям!❤️

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

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

#искусство

How to build AI agents into your SOC

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

Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либо программному болвану AI-агенту, никакая формализация не может быть лишней. Основной тезис документа: надежность важнее новизны, поэтому ключ к успеху лежит не в использовании самой передовой модели, а в построении детерминированных рабочих процессов, строгих ограничений и постоянном измерении результатов. Документ содержит не только теоретические основы, но и практические примеры на Git, а кто любит за трапезой посмотреть что-то полезное есть видео на Youtube Elevate and empower your SOC with AI.

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

2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.

Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.

В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.

#ml #MDR

Red Canary. How to build AI agents into your SOC

SANS 2025 AI Survey

До меня долетел опрос SANS об использовании ИИ в безопасности. Академическое исследование применимости публиковал ранее, а еще полезно посмотреть на опрос тех же ребят но о SOC, там тоже есть про ИИ. Кратко пробегусь что же там.

1. ИИ в безопасности используют слабо: хотя 50% организаций уже применяют ИИ, лишь половина из них использует его для задач ИБ, например, 33% используют ИИ для обнаружения и расследования инцидентов, и только 26% - для реагирования. Понимаю респондентов, мне бы автореспонсы от ИИ тоже доставили излишнюю обеспокоенность.

2. Страх перед ИИ-атаками намного выше, чем фактическое использование защитных ИИ-инструментов: 81% обеспокоены атаками с использованием ИИ, в частности - персонализированной социалкой (83%), дипфейками (73%), быстрым поиском уязвимостей (67%).

3. Чрезвычайно много фолсы: 66% команд отмечают, что ИИ генерирует слишком много ложных срабатываний, что, напротив, усиливает усталость от алертов (alert fatigue).

4. О том, что ИИ расширяет поверхность атаки и возникают новые риски, которыми надо управлять, задумываются немногие: только 35% имеют формальную программу управления ИИ-рисками, 42% - лишь начинают формировать политики, а 24% вообще не оценивают ИИ-риски у сторонних вендоров.

5. ИИ не заменяет людей: 65% говорят о необходимости более специализированного обучения по ИИ, 67% ожидают рост спроса на специалистов, совмещающих ИИ и безопасность (об этом есть здесь)

Документ содержит интересные разбивки о применимости ИИ в DFIR, AppSec и Red Teaming, их несложно посмотреть, не буду расписывать.

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

#ml #vCISO

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

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

#управление

Процессы и решения

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

Из триады Люди-Процессы-Технологии что первично?

Статья имеет своей задачей катализировать понимание что не так с этим вопросом и каковы связанные проблемы, если начать не с того.

Критика, мысли, альтернативные мнения, а также пожелания, какие темы следует раскрыть поподробнее, приветствуются в комментариях!

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

State of ICS/OT Security 2025

В ноябре SANS выдал противоречивый документ "State of ICS/OT Security 2025". Документ покрывает в основном США, Европу, Канаду и немного Азии, по отраслям: Энергетику (20%), ИТ (16%), Гос (9%) и 10% другого, однако, полагаю, приведенные в документе тренды актуальны и для Россия++.

Ключевые выводы можно почитать прямо на стр. 3, приведу для тех, у кого нет времени читать весь документ и всю эту заметку.
Инцидентов много и они серьезные: 22% организаций сообщили о инцидентах за последний год, 40% из них привели к сбоям в работе, а на устранение 20% ушло более месяца.
Обнаружение улучшается, но восстановление серьезно отстает: почти половина инцидентов обнаруживается в течение 24 часов, 60% локализуются за 48 часов, но устранение угроз и восстановление работы часто занимают дни, недели, а то и больше года.
Регулирование способствует повышению зрелости: организации, попадающие под регулирование, имеют схожий уровень инцидентов 😁, но на 50% меньше финансовых потерь и последствий для безопасности.
Threat intelligence: использование специализированного TI для ICS помогает организациям корректировать приоритеты.
Удаленный доступ - главный риск: половина всех инцидентов начались с несанкционированного внешнего доступа, при этом лишь 13% организаций полностью внедрили продвинутые средства контроля, типа записи сессий, доступ с учетом ICS/OT специфики.
Готовность неравномерна: только 14% респондентов чувствуют себя полностью готовыми к новым угрозам, вовлечение полевых техников в учения повышает готовность в 1,7 раза.
Инвестиции: основные инвестиции в 2025-2027 гг. направлены на обеспечение visibility активов, обнаружение угроз и безопасный удаленный доступ.

Основные тенденции
1. Инциденты и их влияние
- Основные причины инцидентов: несанкционированный внешний доступ (50%), программы-вымогатели (38%), внутренние ошибки/злоупотребления (41%).
- Помимо операционных сбоев (40%), инциденты приводят к финансовым потерям (13%), рискам для физической безопасности (8%), краже интеллектуальной собственности (6%).
- Временная шкала инцидентов: хотя обнаружение и локализация улучшаются (в среднем, управляются за 48 часов), этап исправления и восстановления остается самым долгим: 22% занимает 2-7 дней, 19% - более месяца, 3% - свыше года.

2. Планы реагирования
- 57% организаций имеют план реагирования на инциденты для ICS/OT (рост по сравнению с предыдущими годами).
- 39% тестируют план ежегодно, 25% - ежеквартально, а частое тестирование связано с разнообразием методов: операционные учения, упражнения "красных/фиолетовых команд" и т.п.
- 80% обновили свои планы в 2025 году, в основном из-за новостей из TI (41%) и изменений в регулировании (40%).

3. Разведка угроз и обмен информацией
- 67% используют TI, а 16% планируют
- Основные источники TI: специализированные поставщики (79%), государственные/публичные отчеты (77%), коллеги и ISAC-и (information sharing and analysis centers) (72%).
- Только 22% организаций активно делятся информацией с ISAC-ами, большинство (34%) лишь потребляют данные.
- Топ-3 Ценности TI: раннее понимание угроз (63%), стратегическое планирование (50%), улучшение обнаружения (48%), остальное - на картинке стр. 9.

4. Регулирование и приоритеты инвестиций
- 58% организаций имеют объекты, подпадающие под обязательные требования кибербезопасности (по-намшему - объекты КИИ).
- Регулирование стимулирует инвестиции в: логирование/мониторинг/обнаружение (72%), инвентаризацию активов (67%), безопасный удаленный доступ (52%), управление уязвимостями (50%).

5. Обнаружение и visibility
- Критический пробел: Только 13% организаций имеют полную visibility по всем Kill Chain ICS, 42% имеют частичную видимость с большими пробелами.
- Только 49% используют специализированные средства обнаружения для ICS/OT, из них лишь 26% считают свои возможности "высокоэффективными".
- Интеграция IT/OT: 50% координируют работу отдельных команд IT и OT, 48% используют общие инструменты сбора и корреляции логов (SIEM и т.п.).

6. Облака и удаленный доступ
- 83% организаций используют облако в средах ICS/OT или IT, но только 13% имеют полноценную интеграцию облачного мониторинга (удивительно смотрится эта проблема на фоне того, что несанкционированный внешний доступ - причина проникновения №1).
- Безопасный удаленный доступ - самое слабое звено: несмотря на то, что 50% инцидентов начинаются с него, внедрение продвинутых мер контроля низкое: сегментация удаленного доступа - 32% (полное внедрение), MFA - 30%, запись и воспроизведение сессий - 12%, анализ специфических протоколов ICS - 13%.
- Основные препятствия упомянутых проблем: нехватка внутренних ресурсов (60%), ограничения совместимости со старыми системами (46%).

7. Готовность к будущим угрозам
- Только 14% чувствуют себя полностью готовыми к будущим угрозам.
- Наиболее прорабатываемые сценарии: программы-вымогатели для OT (72%), компрометация цепочки поставок (67%), инсайдерские угрозы (60%).
- Факторы успеха "полностью готовых" организаций: в 66% случаев чаще включают полевых техников в учения, в 4 раза чаще имеют полную видимость по цепочке взлома (kill chain) ICS, 57% активно делятся информацией (против 22% в среднем).
- Только 21% проводят упражнения "красных/фиолетовых команд" или проактивный поиск угроз (threat hunting) в среде ICS/OT.

8. Киберустойчивость и непрерывность бизнеса
- Менее 10% организаций полностью интегрировали ИБ в общекорпоративное планирование непрерывности бизнеса и аварийного восстановления (BC/DR).
- Основная активность — резервное копирование для OT (66%).
- Только треть (33%) тестирует или моделирует процедуры восстановления для OT.
- 9% не имеют специфического для OT планирования устойчивости.

9. Технологии и инвестиции
- Основные развертывания за последний год: инвентаризация активов (50%), безопасный удаленный доступ с MFA (47%), сегментация (32%).
- Планы на 2026-2027: visibility активов (54%), обнаружение угроз (43%), управление уязвимостями (41%).
- Основные драйверы внедрения: регулирование (61%) и эволюция ландшафта угроз (61%).
- Метрики успеха: сокращение рисков (51%), готовность к аудиту (50%), операционные KPI (43%), финансовые метрики использует только 16%.

10. Культура безопасности
- 62% отмечают, что культура безопасности ICS/OT является высокой или улучшается.
- Ключевые индикаторы здоровой культуры: понимание IT ограничений OT (45%), понимание OT киберрисков (44%), включение безопасности в операционные решения (43%).
- Важнейший фактор высокой культуры - наличие специального плана реагирования на инциденты для ICS/OT.


#MDR #vCISO

SANS
State of ICS/OT Security 2025

Written by Jason D. Christopher
November 2025