Прошло 6 лет с моего выступления с темой «L1 в SOC не нужен» и я подумал, что можно вновь вернуться к теме разделения аналитиков SOC на уровни L1-L3. Оно преподносится как частая модель работы аналитиков в Security Operations Center (SOC), где выделяются аналитики трех уровней. Однако, такой подход на практике реализуется далеко не всегда. Нередко в компаниях, от крупных корпораций до стартапов, SOC чаще всего работает как единая структура, а не разбивается на несколько уровней. В других организациях уровней всего два. В третьих, те же три уровня, но значение у них отличное от привычного. То есть то, что преподносится как правило, на самом деле таковым не является.
Роль L1 нужна только для одного — служить отправной точкой для тех, кто пришел в ИБ со стороны и хочет погрузиться к реальную, а не бумажную кибербезопасность.
В LinkedIn тут прозвучала идея, что идея деления на три уровня зачастую является иллюзией, поддерживаемой венчурными капиталистами и стартапами, которые пытаются адаптировать этот подход под свои инвестиционные цели. Однако на практике многие компании не могут позволить себе содержать такие трехуровневые структуры из-за нехватки ресурсов и специалистов. Основная функция SOC заключается в базовой обработке инцидентов и распределении задач между другими командами, аналогично тому, как работает IT Helpdesk. Большая часть запросов и работы в SOC не требует глубокого анализа или участия специалистов высокой квалификации. Примерно 2-5% всех инцидентов эскалируются на команду реагирования на инциденты, которая занимается более серьезными угрозами.
Например, в Cisco не было классического вертикального деления на 3 уровня! Все стекалось в общий Service Desk, где атомарные события отрабатывались самими средствами защиты или различными инструментами автоматизации. Сложные кейсы, требующие внимания ИБ, уходили в Cisco CSIRT, где была горизонтальная структура со специалистами с нужной экспертизой (SME).
У меня всегда был вопрос — зачем поручать самую сложную работу по различению полезных сигналов ИБ от шума и ложных срабатываний наименее опытным специалистам, аналитикам L1? Тем не менее, многие компании инвестируют значительные средства в готовые и типовые продукты класса SIEM, разработанные под эту концепцию, и нанимают большие команды аналитиков, стремясь к круглосуточному покрытию, получая иллюзию полного покрытия и обнаружения всех угроз. И это часто приводит к пропуску инцидентов.
На самом деле гораздо лучше, если бы компании больше инвестировали в аналитиков, которые могут быть частью конвейера Detection Engineering as a Code, создавая эффективный контент обнаружения и автоматизируя значительную часть операций по расследованию и обогащению событий ИБ.
Не существует универсальной модели построения SOC и каждая компания уникальна. Но мы рано или поздно придем к тому, что в будущем эти большие и несколько неэффективные команды SOC будут заменены более оптимальным составом команды Detection & Response с инженерами, которые смогут писать код, управлять конвейерами данных, создавать контент обнаружения и проводить расследования. Большинство SOCов будет базироваться именно на многостаночниках. 1% крупных компаний сможет позволить себе иметь специальные команды для каждой функции detection engineering, но это будет скорее исключение, чем правило.
С какими вариантами я еще сталкивался в проектах по аудиту SOCов, которые отличаются от классики L1-L3?
- Аутсорсинг L1. Первая линия может аутсорситься через MSSP или MDR, а внутренний SOC работает как L2, который принимает уже отфильтрованные инциденты. Это более близкая история к классическому разделению, но в этом случае вы не имеете никакого контроля над первой линией.
- Интеграция с Service Desk. Можно объединить работу SOC с Service Desk. Это позволяет Service Desk решать часть задач L1, что способствует росту квалификации ИТ-персонала и высвобождает время для команды безопасности на решение более сложных задач. Схожий вариант реализуется в Cisco, как я упомянул выше. Но это требует зрелости от ИБ, которая не всегда готова отдавать в чужие руки часть своей ответственности.
- Автоматизация L1. L1 может быть заменен полной автоматизацией (для ограниченного числа use cases) или AI/ML.Ну это то, о чем я говорил 6 лет назад.
- Деление по областям экспертизы. В условиях ограниченных ресурсов можно разделять задачи по категориям с учетом специальных знаний (SME), что позволяет более эффективно распределять нагрузку на команды. В этом случае деление носит скорее горизонтальный, чем вертикальный характер.
Иногда кажется, что руководители ИБ специально поддерживают трехуровневую структуру, так как это позволяет им требовать больше людей в штат, а это в свою очередь повышает их значимость.
Мой бывший коллега по команде SOC в Cisco Кунал Хатод написал статью, в которой он делится мнением о том, кому подходит, а кому нет, трехуровневая модель SOC, и приводит вообще шестиуровневую модель по аналогии с современными больницами. Вот ключевые плюсы и минусы для каждого описанного им уровня:
- Рецепционист (L1, прием первичных событий):
- Плюсы: Быстрая реакция на угрозы, базовая проверка.
- Минусы: Ограниченные знания, перегрузка из-за объемов оповещений.
- Медсестра (L2, оценка и нейтрализация рисков):
- Плюсы: Глубокий анализ инцидентов, оценка рисков.
- Минусы: Требуется поддержка для сложных угроз.
- Старшая медсестра (L3, координация реагирования на инциденты):
- Плюсы: Координация ответных мер.
- Минусы: Ограниченные решения при крупных инцидентах.
- Врач (SME):
- Плюсы: Стратегическое руководство, глубокая экспертиза.
- Минусы: Меньшая вовлеченность в ежедневные задачи.
- Специалист-врач (работа со сложными угрозами):
- Плюсы: Продвинутая экспертиза для сложных угроз.
- Минусы: Узкая специализация.
- Парамедик (специалист по реагированию):
- Плюсы: Быстрая реакция на инциденты.
- Минусы: Ограниченное участие в мониторинге угроз.
Не надо ориентироваться на эти 6 уровней — это всего лишь модель, приведенная в качестве аналогии. Не рассматривайте ее буквально!
Эта шестиуровневая, а также более «простая», трехуровневая модель имеет три основных недостатка:
- Перегруженность и сложность для небольших организаций, у которых часто служба ИБ меньше, чем требуется для трехуровневого SOC.
- Возможное возникновение изоляции между уровнями, что при отсутствии четких правил перехода с уровня на уровень и за их пределы приведет к закукливанию SOC.
- Отсутствие гибкости, так как жесткое следование уровням может мешать эффективному реагированию на инциденты.
Модель с уровнями существует из-за отсутствия качественной работы с Detection Engineering. Если бы компании были способны грамотно выстроить этот процесс, уровни были бы не нужны. Так что лучше инвестировать в detection engineering, а не в рост штата аналитиков SOC под трехуровневую модель.
А по мере появления и развития автономных SOC — деление на 3 уровня и вовсе канет в небытие.
Буду об этом, среди прочего говорить на Positive SOCcon 2.0 в Минске 31 октября. Присоединяйтесь! Возможно и на SOCtech будут говорить о решениях, позволяющих реализовать правильную иерархию аналитиков в SOC!
