Прошло 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!

Заметка Выбросьте деление на уровни L1-L3 в SOC на помойку! была впервые опубликована на Бизнес без опасности.

Подробнее…

​  

​Сообщения блогов группы «Личные блоги» (www.securitylab.ru)

Read More

Ваша реакция?
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0
+1
0
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x