Для большинства компаний реального сектора SOC — это небольшая команда, которая следит за разнородной инфраструктурой: от офисных сетей до технологических и производственных площадок, где простой стоит дорого. Центральное место в такой связке занимает SIEM, но чем больше времени уходит на обслуживание системы, тем меньше остаётся на анализ событий и расследование инцидентов. Если систему приходится постоянно обслуживать, команда всё чаще занимается сбоями и настройками вместо содержательной работы. К тому же в повседневной работе не всегда хватает прозрачности: в каком состоянии находятся источники, откуда взялось событие, почему корреляция сработала именно так.
Выбирая или меняя такой инструмент, компании обычно опираются на демонстрацию и пилот, то есть на спокойные условия, где у команды есть время вникнуть. Куда реже удаётся узнать, как система ведёт себя, когда времени нет, событий слишком много, а разбираться с ней приходится параллельно с реальной атакой. О кибербитвах чаще рассказывают с позиции атакующих, а защитники редко делятся тем, как именно они работали с инструментами и что в этом помогало или мешало. Поэтому мы решили поговорить с командой, у которой такой опыт только что появился.
На кибербитве Standoff 17 команда akPots защищала отрасль «Телеком» в режиме обнаружения и расследования. Красные реализовали 9 критических событий из 37 заложенных архитекторами, а в инфраструктуре одновременно действовали более десяти атакующих групп. Центральной точкой сбора и корреляции событий для защитников стал R-Vision SIEM: в нём команда вела мониторинг, анализ и расследование инцидентов. Большинству участников akPots предстояло разобраться с ним уже по ходу игры.
Мы расспросили команду о том, чем кибербитва отличается от рутины SOC, как организовать работу, когда событий больше, чем рук, и что показал опыт работы с новым инструментом в боевых условиях.
— Кто-то из вас на кибербитве Standoff впервые, кто-то уже бывал. Что тянет сюда возвращаться и чем всё это отличается от обычных будней SOC?
Состав у нас был смешанный. Для части ребят Standoff 17 стал первым, и рядом были те, кто на битве уже бывал. Они подсказывали, как быстрее и точнее замечать действия атакующих. Мы сами познакомились со Standoff в 2023 году, на пилотном проекте. Тогда нам доверили защищать металлургический комбинат Metal&Tech. Мы расследовали очень разные инциденты: от утечек данных контрагентов и персональных данных сотрудников до шифровальщика и утечек по гособоронзаказу. Это был первый и незабываемый опыт.
Возвращаться хочется из-за масштаба и того, как всё развивается. Организаторы каждый раз придумывают такие сценарии, с которыми в обычной жизни почти не сталкиваешься: нарушение работы системы автоматического сопровождения спутника, редактирование сетки вещания IPTV, выпуск безлимитной eSIM. Согласитесь, это совсем другой уровень. В повседневной практике набор стандартный: шифровальщики, кража персональных данных, эксплуатация известных уязвимостей.
И плотность событий другая. В обычном SOC мы в основном видим огромное количество безуспешных сетевых атак, а в логах EDR чаще всего ложные срабатывания, действия админов или пользователь, который полез не туда. Этот опыт полезен: мы настраиваем системы и передаём знания внутри SOC. Но будем честны, иногда это наскучивает, глаз замыливается и пропадает охотничий азарт. На кибербитве что ни алерт, то успешная эксплуатация или критическое событие. Начинаешь разбирать каждый шаг атакующего и докапываться до корней.
Ещё одно отличие в том, что в жизни злоумышленники не могут навалиться на все организации одинаково мощно и одновременно. Массовыми бывают в основном сканирования, а таргетированные атаки растянуты во времени. На полигоне всё сжато, поэтому сложно провести атрибуцию и понять, чьи именно это перемещения. Кроме того, нельзя просто спросить у сисадмина или владельца системы, что тут нормально, а что нет. Условия максимально приближены к бою.
— Что оказалось самым сложным или неожиданным?
Что-то одно не выделишь, сложность набиралась из нескольких вещей сразу.
Во-первых, масштаб. Было реализовано 9 критических событий, и все они разные. Когда в инфраструктуре одновременно орудуют больше десяти команд, двигаются горизонтально, пробуют эксплойты, добиваются недопустимых событий, то при самых лучших правилах корреляции в любой SIEM-системе наступает хаос. Событий становится так много, что решение захлёбывается, и вычленить действительно важное среди этого шума становится нетривиальной задачей.
Во-вторых, поиск точки первоначального доступа. Сначала прилетает колоссальное количество сканеров и фонового шума, а потом в SIEM вдруг «вываливается» событие, которое прямо говорит о глубокой компрометации. В реальной жизни внешний SOC может уточнить версии пакетов, сложность паролей, как их могли украсть. Здесь приходится одновременно разбирать целый пласт векторов, и часть из них даже после детального разбора нельзя однозначно исключить.
И в-третьих, новые инструменты. Осваивать их пришлось в реальном времени, а не на сохранённых логах, как на тренировках. Красные ещё и сразу заприметили нашу инфраструктуру: видимо, решили на нас отыграться.
— Какой момент запомнился больше всего?
Первая реализация критического события. Она была одной из первых не только у нас, но и на всём мероприятии. Первая мысль была: «Ну вот, приплыли». Но именно после этого команда мобилизовалась по-настоящему. Стало понятно, что соревнование началось и атакующие перешли к активным действиям.
А самым интересным по сути был инцидент с определением геолокации абонента. Тут нужен был почти детективный подход. На полигоне абоненты каждые минут двадцать перемещаются между базовыми станциями, и злоумышленнику надо было сопоставить номер телефона с конкретной станцией, то есть с примерным местоположением человека.
Устроено это было так. Панель базовых станций показывает только хэши абонентов и то, к какой станции они подключены. Номеров там нет. Зато биллинг хранит соответствие «номер ↔ хэш». Атакующий спрашивает у биллинга хэш нужного номера, потом ищет этот хэш в панели станций, и найденная станция выдаёт приблизительное положение абонента.
В логах мы увидели это отчётливо. Сначала запрос к API биллинга с конкретным номером и получение хэша, потом обращение к панели управления станциями по этому хэшу. В этот момент стало ясно, что перед нами атака, которая выходит далеко за рамки классических веб-уязвимостей и вредоносного ПО. Нужно было проследить всю цепочку и понять, как данные из разных систем складываются для злоумышленника в одну картину.
— Как вы организовали работу команды?
Основной костяк у нас — пять-семь человек, которые регулярно ездят на соревнования. В этот раз мы позвали талантливых коллег из других офисов, и команда оказалась распределённой по всей России. Для нас это был новый опыт. Мы быстро поняли, что без чёткой организации просто утонем в информации.
Выручили три фактора. Первый — общий чат с отдельной веткой под каждое критическое событие. Там делились версиями и гипотезами, и весь контекст по инциденту оставался в одном месте. Второй , пожалуй главный, — общий документ. В него по хронометражу все складывали найденные IOC, артефакты и доказательства. Он стал нашей общей базой знаний, которая росла в реальном времени. Тот, кто отвлёкся или освободился, мог сразу подхватить контекст. Третий — капитан. Он распределял события между участниками, чтобы нагрузка была равномерной, и вёл переговоры с организаторами, так что мы не отвлекались на организационные вопросы.
До реализации критических событий мы сами или небольшими группами следили за действиями атакующих и искали связи между инструментами, сетевыми индикаторами и конкретными командами. Это нужно было, чтобы потом быстрее отсекать шум. Когда критическое событие происходило, несколько человек садились за расследование и отчёт. Если события оказывались связаны, группы объединялись и раскручивали весь Kill Chain целиком.
И честно говоря, иногда приходилось принимать непростые решения. Понимая, что физически всё не успеваем, мы брали самое критичное, а остальное фиксировали для пост-анализа. Так мы не утонули в потоке и довели ключевые расследования до конца. В итоге, хоть мы и сидели в разных городах, чувствовали себя единым механизмом.
— Какими средствами защиты вы пользовались? Что знали заранее, а что пришлось осваивать на ходу?
Центральной точкой сбора и корреляции был R-Vision SIEM: в него стекались все логи и события от EDR. С этой системой в живом режиме мы работали впервые. Раньше пересекались с ней только поверхностно, на разборе готовых сохранённых логов. Нам провели вводные брифинги и раздали обучающие материалы, но когда счёт идёт на минуты, теория быстро забывается. Поэтому нам пришлось осваивать систему и адаптироваться к ней уже в ходе соревнований, буквально на лету разбираясь с её функционалом и особенностями.
Остальной арсенал был разнообразным. PT Application Firewall показывал запросы и ответы на границе сегментов, PT NAD — трафик и сессии, чтобы понять, что именно делал злоумышленник и чего добился на каждом этапе. В PT Sandbox стекались подозрительные файлы, и мы оценивали их вредоносность. Инфраструктура красных была построена на Kubernetes, поэтому очень помог PT Container Security. Он мониторит события на уровне ядра Linux через eBPF и показывает, что происходит внутри оркестрируемой среды, где классические средства часто слепнут. Для части команды новым был и сервис ловушек Xello.
С PT AF и PT NAD мы дружим в повседневной жизни, это наши рабочие лошадки. А вот PT Container Security до этого видели только на брифингах.
— Насколько сложно было быстро освоиться с новыми инструментами?
Приятно удивило, что интерфейсы оказались очень «человеко-юзабильными»: продуманная навигация, понятные панели, логичные переходы. Часа через три мы уже чувствовали себя как рыба в воде. У тех, кто работал с похожими системами, адаптация шла ещё быстрее: логика у них схожая.
Но одно дело — ориентироваться в интерфейсе, и совсем другое — искать сложные события. Для нетривиальных кейсов нужны запросы с особыми условиями и фильтрами, и тут мы периодически открывали методички, чтобы вспомнить синтаксис. Я бы разделил адаптацию на два этапа. К интерфейсу привыкли быстро и без боли, а глубину функционала осваивали уже параллельно с боевыми задачами.
— Для каких задач вы использовали R-Vision SIEM и что выручало чаще всего?
Через неё шёл основной поток данных. Инфраструктура была новой и заранее нами не изученной, поэтому мы использовали SIEM в первую очередь как мощный агрегатор сырых событий из разных источников. Можно было открыть таймлайн по конкретному хосту и быстро понять, что там делал атакующий, не погружаясь в особенности каждой системы.
Искали мы в основном следы действий злоумышленников. Смотрели, нет ли обращений к C2, то есть подозрительных исходящих соединений и каналов управления красных. Проверяли выполнение команд ОС, особенно тех, что намекали на горизонтальное или вертикальное перемещение. Следили за доступом, чтобы восстановить карту движения атакующего: куда он ходил и к чему имел доступ. А по событиям EDR разбирали процессы, чтобы находить следы эксплуатации и внедрения вредоносного ПО.
Чаще всего выручали четыре вещи. Сквозной поиск через raw like "%%" — настоящий мастхэв, особенно когда нужно найти иголку в стоге сена, а алертов приходит десятками тысяч. Настраиваемые поля отображения, благодаря которым с одного взгляда понятно, о чём событие. Группировка, которая схлопывает похожие события и не даёт тонуть в тысячах однотипных записей. И исключение из общего списка заведомо безопасных и фоновых событий, чтобы шум не отвлекал.
Помогло и то, что синтаксис запросов оказался понятным. Не приходилось заранее учить жёстко индексируемые поля, структуру данных мы познавали прямо в ходе расследования. А ещё на подготовке мы заранее собрали кастомные дашборды под ключевые сценарии. Они позволяли заметить намерения и артефакты атакующих раньше, чем те получали значимый результат или сдавали отчёт.
— Хватало ли функциональности для расследований?
В целом да. Как и с любым новым инструментом, базовые потребности закрываются «из коробки» без долгой подготовки. А вот чтобы глубоко копать специфические данные и строить кастомные сценарии, нужно чуть больше времени на адаптацию и освоение тонкостей платформы.
— Чего вам не хватило бы для полного счастья? Какие функции добавили бы?
Есть три пожелания.
Первое касается дашбордов. Хорошо бы «в один клик» проваливаться из виджета к списку конкретных сырых событий. Эффективные дашборды требуют накопленной экспертизы, и рядовому аналитику не обязательно разбираться, как устроены запросы под капотом. Ему нужно просто воспользоваться опытом коллег, который в дашборд заложен, и сразу перейти к разбору событий. Это пожелание мы уже передали разработчикам.
Второе — готовые типовые сценарии на основе экспертизы вендора. Например, нажать «Обнаружение загрузки .exe-файлов» или «Использование wget/curl» и сразу получить все подходящие события. Это ускорило бы первичный отсев, и не пришлось бы вручную собирать сложные запросы.
Третье — вложенная группировка. Скажем, сначала по хосту, а внутри по типу события, с количеством записей. Тогда было бы видно иерархию инцидента: на каком хосте что происходило, сколько раз и в какой последовательности.
— А что в R-Vision SIEM показалось самым удачным?
Нам понравилось, что система работает гладко, стабильно и тянет большой объём информации. Современный дружелюбный интерфейс, понятный синтаксис запросов и удобная работа с сырыми данными позволяют быстро влиться в работу. Отдельно отмечу настройку полей отображения и приятное адаптивное добавление фильтров. Дальше, как с любым инструментом, вопрос умения: надо уметь работать с фильтрами и грамотно выставлять временные интервалы.
— Что лично вам дала кибербитва Standoff?
Во-первых, бесценную практику. В обычной работе мы сталкиваемся с типовыми инцидентами, а здесь было 37 событий совершенно разного характера. Начинаешь смотреть на атаки под другим углом, лучше понимаешь тактики, техники и процедуры реальных злоумышленников и видишь, как цепочки атак строятся от начала до конца.
Во-вторых, это прокачка работы с новыми инструментами. R-Vision SIEM и PT Container Security мы освоили в боевых условиях, и это совсем другое погружение, чем по методичкам в спокойной обстановке. Начинаешь чувствовать инструмент, понимать его сильные и слабые стороны, находить нестандартные решения.
В-третьих, опыт командной работы в стрессе. Когда тебя одновременно атакуют больше десяти команд, а трафика так много, что места под него не хватает, ты учишься быстро принимать решения, доверять коллегам и действовать как единый механизм.
И в-четвёртых, это перезагрузка. Рутина иногда замыливает глаз, а Standoff возвращает азарт и желание докопаться до сути каждого события. К тому же это шанс подсмотреть у коллег приёмы, которые можно перенести в свой мониторинг. После таких дней лучше понимаешь, в какую сторону развиваться дальше.
— Что посоветуете тем, кто собирается на Standoff впервые?
Готовьтесь заранее. Изучите защищаемую инфраструктуру: какие сервисы там развёрнуты, какие в них могут быть уязвимости, какими путями пойдёт злоумышленник. В обычном SOC у вас есть время разглядывать хосты и общаться с владельцами систем. На кибербитве с первой секунды на вас обрушивается лавина алертов, многие из которых вы никогда не видели. Каждую непрочитанную заранее статью всё равно придётся изучать, только уже в цейтноте. Пройдите курсы вендоров по тем продуктам, которые будут на полигоне.
Заранее отработайте командную работу: распределите роли, договоритесь о каналах связи и о том, как фиксировать находки. Будьте готовы к нагрузке: спать будет некогда, красные будут активны и изобретательны. Распределяйте силы и делайте паузы, чтобы не выгореть в первый же день.
И не пытайтесь успеть всё. Хаос неизбежен, все события одинаково глубоко не расследуешь. Ставьте приоритеты, а остальное фиксируйте для пост-анализа. И кайфуйте от процесса. Да, это стресс, но это возможность прожить то, что в обычной жизни почти недоступно. Наслаждайтесь каждой минутой, даже когда всё идёт не по плану. Именно в такие моменты рождаются настоящие эксперты.
Реклама. Рекламодатель ООО «Р-Вижн», ИНН: 7723390901, erid:2SDnjcGKXn3
