Построение собственного центра мониторинга и реагирования на инциденты ИБ – дело нелёгкое. Кроме стандартных этапов построения (формулирование целей, определение основных процессов, подбор персонала, определение режимов работы и др.) есть неочевидное, но крайне выгодное для бизнеса решение – оптимизация линий поддержки SOCа. Об этом мы сегодня и поговорим.
Классический состав SOC
В разных статьях по построению центра мониторинга в организации встречается разделение специалистов по линиям поддержки:
Первая линия (L1) – специалисты, которые просматривают поток событий и инцидентов. В случае подозрения на потенциально-опасный инцидент первая линия заводит инцидент и эскалирует на вторую линию. После чего L1 продолжает мониторить.
Вторая линия (L2) – специалисты, которые анализируют подозрения на инциденты от первой линии, проводят расследование (сбор информации, проверку, анализ). Также к задачам второй линии относят взаимодействие с ГосСОПКА (при необходимости) и проведение анализа защищённости.
Третья линия (L3) – профильные специалисты, которые базируются в одном из выбранных направлений. Например, специалист по threat hunting, revers-engineering и прочее. Ещё к функциям третьей линии приписывают анализ угроз и разработку правил для системы мониторинга.
А собственно, руководитель центра мониторинга координирует деятельность SOC.
Мониторинг осуществляется в режиме 24х7, а расследование – 8х5. Значит, L1 работает круглосуточно, а L2 и L3 – в будни. Соответственно, чтобы построить свой SOC с графиком 24х7, специалистов L1 потребуется как минимум столько же, сколько в L2 и L3 вместе взятых.
Для наглядности рассчитаем, сколько человек нужно для нормального функционирования SOC 24х7:
Количество специалистов указано примерно с целью демонстрации их соотношения. В зависимости от целей и задач SOC количество специалистов на каждой линии может отличатся. Также не учитывались специалисты, отвечающие за работоспособность системы мониторинга.
Наверняка каждая из организаций уже столкнулась со сложностью поиска специалистов, особенно профильных и с опытом работы. Из-за всеобщего кадрового голода многие организации откладывают идеи по построению своего SOC в долгий ящик. Однако мы считаем, что центр мониторинга сегодня – как антивирус – должен быть во всех организациях, ведь SOC помогает снизить риски для бизнеса за счет своевременного выявления атак.
Именно поэтому мы предлагаем рассмотреть 3 подхода, которые позволят решить проблемы и оптимизировать работу SOC.
1. Определение целей и задач SOC
Первое, что можно сделать – это пересмотреть цели и задачи центра мониторинга.
Например, если от SOC требуется мониторить события и инциденты ИБ, а также формировать карточки с рекомендациями для передачи специалистам ИТ для их последующего выполнения, то стоит рассмотреть вариант центра мониторинга без L3 и без частичного функционала L2. Тогда правила SIEM будут формироваться только вендором, но даже так поставленные задачи будут исполнены.
Исходя из того, какие задачи необходимо выполнять силами центра мониторинга и в каком режиме он должен функционировать, формируется состав и определяется количество необходимых специалистов для решения этих задач.
По итогу может оказаться, что в вашей компании будет достаточно 3 специалистов L1 и 2 специалистов L2 (с учетом ротации), которые будут мониторить инциденты в рабочее время.
2. Объединение линий мониторинга
Второй вариант решения проблем – построить SOC без разделения специалистов центра мониторинга на линии.
При таком подходе специалисты будут мониторить поток событий и инцидентов из системы мониторинга, а в случае обнаружения подозрений на потенциально-негативные действия самостоятельно анализировать их и формировать карточки инцидентов.
Плюс такого подхода в том, что специалист, выявивший инцидент, полностью его отрабатывает. При этом работник центра мониторинга понимает специфику L1 и L2, что делает его более универсальным и широкопрофильным.
Из минусов – в процессе анализа возможного инцидента специалист не будет осуществлять мониторинг. Соответственно, если анализ инцидента займёт час, есть вероятность что-то пропустить. После расследования инцидента специалист будет просматривать всё то, что было зафиксировано за время, когда мониторинг не осуществлялся. И тут снова возникнет пауза в анализе событий и инцидентов, которые поступают в режиме реального времени.
Чтобы избежать этой цепочки, потребуется автоматизация и настройка системы мониторинга:
-
Постоянная работа с ложно-позитивными событиями и инцидентами. Те инциденты, которые были помечены как ложные, исключаются из системы мониторинга за счет адаптации правил.
-
Сценарии реагирования. Не все ложно-позитивные события и инциденты можно исключить из-за особенностей инфраструктуры. Для таких случаев нужно разработать типовые сценарии реагирования и вести базу знаний. Такой подход позволит сократить время на анализ и выдать решение по инциденту в короткие сроки.
-
Классификация и приоритизация. В каждой инфраструктуре есть критичные узлы, поражение которых может негативно повлиять на бизнес-процессы, и менее критичные узлы, поражение которых на бизнес-процессах не отразится. В зависимости от уровня критичности можно разделить и время реагирования на инцидент. Также сами атаки и инциденты могут потенциально нести различные негативные последствия. По аналогии с ресурсами угрозы можно разделить по уровню критичности. Получится некая матрица Эйзенхауэра, на основе которой можно распределить время реагирования.
Такой подход позволит быстро реагировать на то, что действительно требует срочной реакции и сократить время на инциденты, которые можно проанализировать позже.
Стоит отметить, что перед началом автоматизации процессов следует привести инфраструктуру в порядок (настроить сегментацию сети, ограничить использование устаревших и небезопасных протоколов, разграничить права доступов, убрать избыточные права, если они не требуются). Эти действия снизят количество ложно-позитивных инцидентов.
В итоге, за счет объединения L1 и L2, а также автоматизации получится сократить штат специалистов.
3. Автоматизация первой линии мониторинга
Третий вариант – полностью автоматизировать первую линию центра мониторинга. Это позволит снизить количество задействованных специалистов за счет делегирования их задач на технические средства.
Для того, чтобы автоматизировать 1 линию мониторинга, потребуется либо приобрести технические решения, функционал которых позволяет реализовать необходимые для автоматизации функции, либо разработать их самостоятельно в виде скриптов и утилит.
Рассмотрим, что именно нужно будет автоматизировать.
Мониторинг событий и инцидентов
Система мониторинга на примере SIEM способна аккумулировать в себе все поступающие с различных источников события (журналы операционных систем, события безопасности средств защиты, логи серверов и функционирующих приложений). Далее собранные события нужно пропускать через собственную аналитику и формировать подозрения на инциденты.
Инцидентов может быть много, причем большая часть будет ложно-позитивной. Чтобы специалисты L2 не утопали в потоке таких событий, необходимо с ними работать, т.е. анализировать, корректировать правила корреляции и параллельно исключать неактуальные.
В результате L2 будет работать с существенно меньшим количеством инцидентов. Конечно, полностью исключать возможность ложных срабатываний нельзя, но их точно станет меньше.
Приоритизация и автоматизация
На основе специфики инфраструктуры и процессов можно выделить наиболее критичные инциденты, для которых нужно разработать правила формирования инцидентов.
Отметим, что для этого потребуется хорошо знать внутреннюю инфраструктуру и понимать, как функционируют процессы.
Критичные инциденты – это не только события и инциденты ИБ. Например, не запустилась задача на бэкапирование данных и произошел сбой – это может привести к потере информации. Или если критичный сервис стал недоступным, перестал работать web-интерфейс интернет-магазина. Такой инцидент напрямую может нарушить бизнес-процесс организации.
Соответственно, такие инциденты будут более критичными, нежели фиксация попыток эксплуатации уязвимостей или заражения ВПО. В первом случае бизнес чувствует простой производства, во втором – эксплуатация может быть неудачной, а ВПО удалено антивирусным средством.
Реагирование на менее критичные инциденты можно автоматизировать за счет специализированных средств, позволяющих на основе сценариев реализовывать определенные действия.
К таким средствам можно отнести некоторые классы решений:
IRP\SOAR – класс решений позволяющий на основе разработанных сценариев реагирования (playbook) автоматизировано реагировать на инциденты, направляя соответствующие команды на внедренные в инфраструктуру системы, в том числе системы защиты.
EDR\XDR – класс решений, позволяющий собирать информацию с источников событий (подразумевает установку агента на конечные узлы), анализировать их и в случае подозрения на инцидент производить активные действия, например блокировку узла. Отличие EDR от XDR в том, что EDR работает с конечными узлами, а XDR помимо того, что включает в себя функционал EDR, дополнительно может анализировать ещё и события в ЛВС.
Стоит отметить, что использование средств автоматического реагирования подразумевает их тонкую настройку, чтобы исключить случаи ошибочной блокировки легитимных действий, которая может привести к нарушению критических процессов.
Как итог, значимость инцидента будет выше, а за счет автоматизированного реагирования специалистам второй линии потребуется реагировать только на действительно актуальные инциденты. Несмотря на это, ложно-позитивные события так или иначе будут появляться, но в меньшем количестве.
Заключение
Создание собственного центра мониторинга и реагирования на инциденты информационной безопасности — непростая задача, но существует ряд способов сделать этот процесс проще и дешевле.
Мы рассмотрели три подхода:
1. Определение чётких целей и задач SOC позволяет оптимизировать структуру центра и сократить избыточный функционал центра мониторинга.
2. Объединение функций L1 и L2 повышает универсальность специалистов и оптимизирует штат.
3. Грамотная автоматизация L1 освобождает сотрудников от рутинных операций и даёт возможность сосредоточиться на действительно значимых событиях.
Главное правило – начинать оптимизацию нужно постепенно, предварительно приведя инфраструктуру в порядок и настроив правильное распределение обязанностей и приоритеты реагирования. Со временем подобные меры заметно улучшат оперативность и точность работы SOC, сократив финансовые издержки и повысив общий уровень информационной безопасности компании.