Любой SIEM за ваши деньги, или запуск новых SIEM-платформ в SOC

Центры мониторинга и оперативного реагирования на ИБ-инциденты (SOC — Security Operations Center) часто пытаются конкурировать по количеству используемых SIEM-систем. Как устроен процесс подключения новой платформы в SOC и что стоит за громкими заявлениями в реальности?

1. Введение
2. Процессы коммерческого и внутреннего SOC
3. Операционные задачи
4. Общие задачи SOC и накопление опыта
5. Выводы

Введение

Мы — центр мониторинга и реагирования на кибератаки Solar JSOC, и наш основной инструмент — SIEM-система. Периодически мы слышим от заказчиков: «А сделайте точно такой же сервис, как вы делаете сейчас, только на SIEM-системе вендора А, Б, В, вы же профессионалы». Или видим тезисы в маркетинговых материалах конкурентов, где говорится, что они готовы в рамках своего сервиса поддержать 8—9—10 платформ в параллели. Мы, со своей стороны, не навязываем какую-то точку зрения, однако два года назад мы решили, что пора «взять на борт» второго SIEM-вендора и работать не только с американским HPE ArcSight, но и с российским MaxPatrol от Positive Technologies, поэтому можем на собственном опыте рассказать, как происходит интеграция нового SIEM в работу центров мониторинга (SOC) — а вы уже делайте выводы.

Процессы коммерческого и внутреннего SOC

В общем виде процессы SOC, непосредственно связанные с SIEM, выглядят следующим образом.

Операционные задачи мониторинга:

• Мониторинг и анализ инцидентов, выявленных SIEM-системой (в работу вступают поочерёдно 1-я, 2-я и 3-я линии мониторинга / обороны), - корневая функциональность SOC, которую многие и считают его единственной задачей .
• Поддержка сценариев выявления инцидентов (контента SOC) под источники информации об ИБ-событиях в инфраструктуре, доработка / запуск сценариев в конкретной компании-заказчике. Это — работа аналитика, который отвечает за то, чтобы поддерживать упомянутую компанию в защищённом состоянии.

ИТ-функции в жизни SIEM:

• Администрирование SIEM — ИТ-функция вокруг ИБ-системы: мониторинг работоспособности, устранение сбоев, обновление и т. д.
• Управление сервисом — планирование и проведение работ, контроль сроков и внутренних / внешних SLA, оценка эффективности работы, формирование отчётности. Во внешнем сервисе выделяется в функциональность сервис-менеджера, внутри обычно является обязанностью руководителя отдела / группы / подразделения SOC.
• Интеграция со смежными системами SOC — формирование профиля передачи информации между SIEM и ticketing- / IRP-системами, профилей мониторинга работоспособности и моделей здоровья и т. д.

Экспертные задачи, нацеленные на исследование и развитие защиты:

• Работа с данными и информацией киберразведки (Threat Intelligence).
• Общее исследование и долгосрочное развитие контента.

Каждый из этих процессов имеет ряд нюансов, связанных с SIEM, поэтому пройдусь по ним последовательно.

Операционные задачи

При интеграции новой SIEM-системы ключевой проблемой или, если угодно, задачей в операционной деятельности SOC является формирование профильной квалификации аналитиков по новому продукту — иначе говоря, обучение персонала. Особенно болезненно это отражается на 1-й линии (если говорить о линии разбора инцидентов, а не диспетчеризации). Как бы ни была формализована и алгоритмизирована инструкция по обработке инцидентов, на линии всё равно всегда остаётся «свобода воли» и свобода выбора путей для дальнейшего анализа. Они могут закрыть инцидент как ложноположительное срабатывание, могут пойти по скрипту, который описывает, как реагировать на инцидент конкретного типа, могут отправить аналитикам линией выше на дополнительное расследование.

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

Когда мы начали использовать MaxPatrol, мы изначально формировали отдельную дежурную смену под новый SIEM-продукт, поскольку вариант «“влить” всю экспертизу в одного человека» был явно и более сложным, и менее надёжным. Потом было решено дополнительно разделить первую линию на две группы по уровню квалификации. Параллельно, чтобы минимизировать риски ошибки сотрудников, мы провели работу по типизации всех встречающихся инцидентов, и теперь на карточке каждого из них отображается категория сложности анализа.

И всё равно, несмотря на все эти меры, нам пришлось удвоить объём дежурной смены, чтобы выдерживать SLA по времени разбора и выдачи заказчикам рекомендаций по противодействию. В конечном счёте процесс работы первой линии с новой SIEM мы успешно отладили, но я считаю, что правила работы с двумя разными платформами — это максимум, который может удержать в голове специалист первой линии. Если когда-то мы всё-таки решимся на третий SIEM в нашем SOC, то под него точно будем заводить ещё одну независимую команду.

Поэтому, когда мы говорим о центре мониторинга, работающем в режиме 24х7, подключение новой SIEM-платформы оказывает колоссальную нагрузку на штат первой линии. И если формирование отдельной смены финансово обосновано — например, у SOC под именно эту платформу есть крупный заказчик (или несколько средних), который обеспечит новых людей работой, а центр мониторинга — достаточным объёмом денег на фонд оплаты труда, то вопросов нет. В ином случае либо мы говорим о работе 8х5 (если вас атаковали в пятницу вечером, ждите начала рабочего дня в понедельник), либо о «маркетинговой реальности».

В свою очередь, аналитикам и специалистам по разработке контента опыт позволяет держать в голове несколько платформ, и совокупно в штате SOC их нужно меньше, чем специалистов первой линии. Проблема возникает в другой части: у зрелых центров мониторинга существует большой пакет базовых сценариев, которые сразу подключаются любому новому заказчику, а потом постепенно дополняются / расширяются. Подключение нового SIEM моментально формирует огромный «технический долг»: надо «быстро, решительно» разработать под новую платформу эти базовые сценарии, правила корреляции ИБ-событий, аналитические отчёты и прочие инструменты SOC. В норме в случае большой тиражируемой услуги это — совместный труд большой команды в течение многих лет. При запуске новой системы вся нагрузка, как правило, ложится на одного-двух очень ценных и высококлассных специалистов, которые должны выстроить всю цепочку от нормализации и категорирования событий до формирования корреляционных / инцидентных правил верхнего уровня и аналитических отчётов для расследования. Работа — ресурсозатратная, требует времени и моральных сил всех участников.

Иногда, впрочем, мы сталкиваемся и с другим запросом заказчиков: «У нас в SIEM все события уже поступают, давайте мы будем передавать их в ваш SIEM, стандарты логов же унифицированы, а дальше вы уже своими правилами будете выявлять инциденты». Даже если оставить в стороне то, что в этом случае заказчик будет по факту дважды платить за лицензии SIEM (и на своей стороне, и на стороне SOC), мы на своём скромном опыте пришли к заключению, что работы при таком варианте только добавляется. Для того чтобы нормализовать и уложить в свои порядки и таксономию события, обработанные до этого другой SIEM-платформой, требуется чуть ли не больше усилий, чем на подключение источника с нуля и написание правила в новой SIEM-системе.

Общие задачи SOC и накопление опыта

В этом блоке принятие «нового мирового порядка» для SOC существенно проще. Управление сервисом зависит не столько от платформ, сколько от построенных процессов. Интеграция SIEM — колоссально сложная и трудоёмкая, но разовая работа. Она сказывается на сроках и расходах только первого клиента новой услуги или реализуется за счёт инвестиций самого сервис-провайдера.

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

Как говорила Алиса в стране чудес, для того чтобы оставаться на месте, нужно бежать в три раза быстрее. Это в полной мере справедливо для любой деятельности в сфере информационной безопасности, в том числе и для центров мониторинга. Как SOC может реагировать на новые угрозы, используя SIEM?

• Можно насыщать SIEM базовыми данными Threat Intelligence (TI) — фидами, индикаторами компрометации систем, маркерами новых вредоносных программ.
• Изучением TTP (техник, тактик и процедур) злоумышленников и созданием новых сценариев по выявлению и противодействию их активности или правил для проактивного поиска угроз (Threat Hunting).
• Системная проработка новых векторов угроз и / или новых потенциальных источников событий. Угрозы удалённого доступа, выявление атак в инфраструктуре, построенной на Docker, подключение песочницы или закрытие рисков, связанных с виртуализацией и переводом в облака — всё это требует большой системной аналитической работы со стороны SOC.

И если первый пункт вполне прост для реализации на любом количестве платформ, то второй и третий несут в себе отдельную нагрузку и требования по разработке для каждой отдельной SIEM-платформы. У нас на текущий момент работают две независимые команды разработки контента для каждой из платформ, настолько сложны и принципиально отличаются правила формирования контента в ArcSight и MaxPatrol.

Выводы

Резюмируя, хочу сказать, что добавляя себе в портфолио очередное SIEM-решение, каждый коммерческий SOC фактически встаёт перед выбором:

• создать легковесное решение с самыми базовыми сценариями и ограничениями в объёме аналитики — как правило, такой вариант ориентирован на закрытие задачи соответствия требованиям регуляторов (compliance);
• формировать тяжеловесную «заказную» разработку с выделением команды, которая вся целиком будет работать на один-два проекта с новым SIEM;
• инвестировать, надеясь на перспективы развития рынка.

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