Стратегия 5 Часть 2: Сколько нужно аналитиков?

Это один из наиболее частых вопросов, который возникает при создании SOC как у руководства, так и у новичков в области обеспечения безопасности сетей. К сожалению, на него очень трудно ответить, поскольку в процессе возникает много сложностей. В этом разделе рассмотрим факторы, которые влияют на штатное расписание SOC, а на примере моделей крупных SOC из разделов 4.1.2 и 4.3.3 покажем, как грамотно обеспечить персоналом каждое подразделение SOC.

7.2.1 Общие соображения

Доступные ресурсы по вопросу подбора персонала для SOC чаще всего предлагают наиболее распространенные модели, где используются простые соотношения: либо количество аналитиков к количеству контролируемых устройств, либо количество аналитиков к количеству клиентов [93]. Наиболее часто цитируемый коэффициент – один аналитик на каждые 50 – 75 устройств [94, с. 9]. Практический опыт доказывает, что зачастую все не так просто. Во-первых, эти модели работают для конкретного SOC, когда все остальные предположения остаются неизменными. Как уже подчеркивалось ранее, нужно рассматривать картину целиком: людей, процессы и технологии. Во-вторых, эти модели обычно подразумевают аналитиков 1-й Линии, тогда как мы хотим охватить все роли в SOC: Линию 2, анализ данных киберразведки, системное администрирование и т.д.

Давайте рассмотрим все факторы, которые влияют на количество персонала в SOC:

  • Задача SOC и имеющиеся возможности;
  • Размер, географическое распределение и неоднородность клиентов;
  • Количество инцидентов (обнаруженных или иных) в клиентских системах;
  • Организационная модель SOС;
  • Размер, область охвата и разнообразие систем мониторинга и аналитики SOC;
  • Ожидаемый и текущий набор навыков персонала SOC;
  • Часы работы/покрытия каждого подразделения SOC (8×5, 12×5, 24×7 и т.д.);
  • Уровень автоматизации в мониторинге, корреляции и аналитике SOC;
  • Объем финансирования кадровых ресурсов SOC.

Давайте остановимся на нескольких ключевых моментах. В начале раздела 7 говорилось о том, что один опытный аналитик, усиленный передовыми технологиями, например, SIEM, может быть столь же эффективным, как 100 начинающих аналитиков со скудным инструментарием. В разделе 6 мы увидели, что SOC предоставляет набор различных возможностей и логично, что он сможет достичь разного уровня зрелости для каждой предлагаемой им услуги. В разделах 4.2 и 4.3 говорилось о том, что SOC могут быть разными по структуре и размеру. Из Приложения D следует, что режим 8×5 требует одного полного рабочего дня сотрудника (FTE), тогда как для режима 24×7 требуется 4,8 FTE.

Теперь очевидно, что расчет требуемого персонала для SOC будет более сложным, чем использование простого соотношения: есть список нескольких независимых переменных, каждая из которых потенциально оказывает значительное влияние на результат. Для новых SOC некоторые из этих факторов могут быть зафиксированы при первоначальном создании (например, при первичном распределении бюджета). Для многих SOC результат определяется постепенно по мере их роста и развития. Руководители SOC обычно используют одну из четырех возможностей для расширения или распределения своего персонала: (1) после крупного инцидента, который привлек внимание руководителей клиентских организаций, (2) при изменении организационного положения SOC, (3) на раннем этапе ежегодного планирования бюджета или (4) после крупной инспекции или оценки.

Однако добавлять сотрудников нужно только после исчерпания других вариантов решения вопроса повышения эффективности и изменения текущих процессов и технологий.

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

Если зарплата посредственного аналитика равна X, а зарплата хорошего аналитика – X * 1,25, но хороший аналитик выполняет в три раза больше работы, чем посредственный аналитик, то эффективнее нанимать или выращивать меньшее количество хороших аналитиков. Однако поиск или выращивание хороших аналитиков может стать серьезной проблемой из-за большого спроса при ограниченном количестве квалифицированных кандидатов и темпа работы, который иногда не оставляет времени для личного роста.

В следующих разделах мы рассмотрим основные факторы, влияющие на обеспечение персоналом каждого подразделения. Важно также иметь в виду, что часы работы, которые требуются для каждого подразделения, могут отличаться. Для 1-й Линии персонал может быть нужен в режиме 12×5 или 24×7, тогда как остальная часть SOC может работать с ограниченным графиком 8×5.

7.2.2 Аналитики 1 Линии

Вернемся к обсуждению работы 1-й Линии из раздела 2.2 и раздела 4.1. Есть команда младших сотрудников, которые выполняют львиную долю рутинной работы SOC: обрабатывают телефонные звонки и отслеживают правильно настроенные потоки событий. Время, которое они могут уделить любому из интересующих событии, ограничено. Из всех отделов SOC кадровая модель этого подразделения наиболее предсказуема. Если мы посчитаем среднее количество минут, которое требуется аналитику, чтобы установить причину возникновения события, и количество событий, требующих их внимания за смену, можно вычислить, сколько аналитиков требуется [9, с. 401]. Приблизительно. Вспомним один из самых важных уроков, который был извлечен при обсуждении мониторинга 1-й Линии:

Никогда не заставляйте сотрудников 1-й Линии работать с абсолютно неотфильтрованными потоками данных. Это приведет к тому, что большая часть времени уйдет на обработку безобидных алертов и аналитики утратят фокус внимания к действительно аномальной или злонамеренной активности.

Если на панелях мониторинга отображается слишком большое количество событий, у аналитика 1-й Линии два варианта действий: (1) активно подтверждать или пропускать большое количество событий, не анализируя их целиком, или (2) выбирать и обрабатывать случайные события из своего потока. Вместо этого у аналитиков 1-й Линии должна быть возможность увидеть дискретные наборы данных, которые можно полностью оценить за время их смены. Количество событий, которые аналитики должны успеть обработать за смену, зависит от многих факторов, в первую очередь, от качества и количества данных, которые проходят через их инструменты, и применяемой к ним аналитики. Лучше всего, если аналитикам будут предоставлены наборы данных, которые не являются просто списком событий. Современные SIEM системы предоставляют все виды средств визуализации данных. Таким образом, использование какой-либо математической формулы для прогнозирования необходимого числа сотрудников Линии 1 скорее приносит вред.

Насколько правильно настроены SIEM и IDS? Фиды данных? Консолидируются ли все оповещения на одной или нескольких панелях SIEM или они разбросаны между множеством отдельных инструментов? При этом внедрение новой технологии сенсоров или добавление новой панели в SIEM вовсе не означает, что нужно нанять больше аналитиков. Можно полностью автоматизировать некоторые сценарии работы мониторинга и отправлять автосгенерированные кейсы непосредственно на Линию 2. Очевидно, что здесь много неоднозначных моментов.

Кроме того, нужно рассмотреть другие задачи, стоящие перед сотрудниками Линии 1. В небольшом SOC Линия 1 может заниматься рутинным сбором данных киберразведки или сканированием уязвимостей. Помимо этого может быть персонал, выделенный под другие рутинные задачи, например, под отслеживание веб-серфинга клиентских организаций или задачи по контролю соответствия требованиям (compliance). Это, естественно увеличивает их нагрузку. Здесь необходимо использовать концепцию действий SOC при эскалации (CONOPS), поскольку Линия 2 может передать обработку рутинных событий, таких как заражения вредоносными программами, на Линию 1 при условии, что ее сотрудники продемонстрируют способность компетентно и согласованно действовать в отношении определенных инцидентов. С другой стороны, нам может потребоваться свести к минимуму действия, выполняемые Линией 1, просто из-за ограниченности физического пространства, например, если Линия 1 работает в тесном операционном помещении, а Линия 2 и остальная часть SOC находятся в просторном бэк-офисе.

В зависимости от размеров организаций, которые необходимо обслуживать, у крупных централизованных SOC обычно от двух до шести аналитиков в каждой смене 1-й Линии. Это может быть не очевидным для постороннего, который, гуляя по этажу комбинированного NOC/SOC, видит только аналитиков 1-й Линии и руководство этажа, не замечая других подразделений SOC, которые расположены в бэк-офисе и не менее важны для выполнения функции SOC.

7.2.3 Сотрудники Линии 2

На количество людей, которые нужны для выполнения обязанностей Линии 2, непосредственно влияют 3 фактора:

  • частота и количество событий (кейсов), переданных с Линии 1 или из других подразделений SOC (например, из отдела анализа данных киберразведки и выявления трендов);
  • количество времени, которое SOC может уделить каждому событию;
  • возможности каждого аналитика по разбору событий, на что влияют их навыки и инструменты.

Например, некоторые SOC могут застрять на цикле реагирования: найти вторжение, отключить модуль из сети, восстановить модуль. Как обсуждалось ранее в этой книге, это непродуктивно. Другую крайность представляют собой SOC, участвующие в разборе действий злоумышленника, анализе данных разведки и обладающие продвинутыми возможностями по реверс-инжинирингу. Более того, SOC может обладать этими возможностями, но они могут быть разделены на различные «расширенные возможности», «анализ угроз» или «экспертизу инцидентов», как описано в разделе 11.1. Некоторые SOC на самом деле будут поддерживать весь каталог вредоносных программ и средства для анализа, что еще больше увеличивает потребности в персонале.

Обеспечение персоналом этого подразделения в значительной степени зависит от возможностей SOC находить (и оплачивать) персонал, способный выполнять анализ на Линии 2, а также от общего ландшафта уязвимостей и угроз организации. Если клиентскую организацию постоянно взламывают, очевидно, что спрос на сотрудников, ответственных за обработку инцидентов будет выше, чем в случае относительно спокойной обстановки. Кроме того, SOC может быть вынужден проводить циклы реагирования на инциденты, связанные со злоупотреблением доступом к ИТ-инфраструктуре, например, просмотром порносайтов или сайтов азартных игр в рабочее время. SOC достаточно легко заниматься такими событиями, потому что у него есть подходящие инструменты для их расследования, хотя такие случаи скорее должны быть перенаправлены в другое подразделение, например, в службу безопасности или кадровую службу (HR).

В зависимости от всех этих факторов, у SOC могут быть коэффициенты соотношения сотрудников Линии 1 и Линии 2 от 2:1 до 1:2. Это означает, что на каждых двух аналитиков Линии 1 в дневной смене может быть от одного до четырех аналитиков Линии 2, в зависимости от структуры операционных процессов и процесса эскалации инцидента на следующий уровень. Что касается реальных рабочих мест (FTE), соотношение будет ближе к 5:1 или 3:1, поскольку работа Линии 1 вероятнее всего потребует задействовать персонал в режиме 24×7 в отличие от Линии 2.

7.2.4 Анализ данных киберразведки и выявления трендов

Это подразделение SOC выполняет самую безграничную часть функционала SOC. У сотрудников есть установка получать как можно больше данных киберразведки и с сенсоров для выявления аномальной активности. Поэтому число сотрудников для работы в этом подразделении почти полностью зависит от способности SOC финансировать и находить квалифицированный персонал. Кадровое обеспечение здесь также будет зависеть от доступа SOC к данным киберразведки. Если данных киберразведки и потоков информации мало, сотрудникам будет нечего делать, а если у SOC налажены тесные отношения с партнерскими SOC, ведется всесторонний мониторинг и расширенная аналитика, возможности практически бесконечны.

В целом, обеспечение персоналом этого подразделения скорее всего будет примерно эквивалентно Линии 2. Если какое-то из подразделений увеличится более чем в два раза по отношению к другому, концепцию работы SOC или кадровый план потребует пересмотра. Меньшие по размеру SOC будут иметь меньшее подразделение по выявлению трендов вследствие ограниченных ресурсов. У гибридных многоуровневых, координационных или национальных SOC скорее всего будет очень большое подразделение по выявлению трендов, поскольку их фокус в значительной степени смещается от наблюдения за сетью в сторону наблюдения за злоумышленником. В самых крайних случаях национальные SOC могут выделить ряд подгрупп, каждая из которых ориентирована на конкретный образ злоумышленника или географический регион.

7.2.5 Сканирование уязвимостей

Вопрос обеспечения персоналом для сканирования уязвимостей или сетей несложен, поскольку зависит всего от нескольких факторов. У некоторых SOC нет такого функционала вообще (что делает решение вопроса довольно простым). Для тех SOC, у которых есть данный функционал, нужно учесть количество сканируемых систем, сложность и эффективность инструментов, которые обеспечивают сканирование и сбор данных, и есть ли подразделение сканируемых объектов на несколько отдельных сетей. Некоторые инструменты сканирования, к примеру, очень эффективны при разделении задач сканирования и выполнении их с удаленно управляемых узлов. Другие могут требовать ручного запуска сканирования для каждого сегмента и сбора результатов вручную.

SOC, которые самостоятельно выполняют сканирование сети или уязвимостей, часто формируют команду от двух до пяти человек и более, если работают с очень большой клиентской организацией; либо выделяют одного человека, если область сканирования невелика.

7.2.6 Оценка уязвимостей/тестирование на проникновение

Расчет персонала в какой-то мере аналогичен расчету персонала для анализа данных и трендов киберразведки. Деятельность по оценке уязвимостей/тестированию на проникновение (VA/PT) может быть очень неопределенной для многих клиентских организаций. Всегда будет оставаться работа, которую можно выполнить. В результате SOC, скорее всего, будет нанимать столько людей, сколько позволит финансирование со следующими оговорками.

Во-первых, руководству SOC рекомендуется не наращивать огромный отдел VA/PT при недостатке персонала в других отделах, таких как Линия 2 или подразделению по выявлению трендов. Во-вторых, SOC должен тщательно управлять своей рабочей нагрузкой, используя полномочия и правила вовлечения, оговоренные с руководством клиентских организаций. В условиях, когда команда VA/PT обладает большей свободой действий, она может сама установить себе объем работ для операционной деятельности. В-третьих, эта команда может задействовать персонал из других разделов. Чтобы объединить усилия команд для больших «задач», SOC должен обучить сотрудников как защитным, так и наступательным методам и предоставить информацию о системах и сетях клиентских организаций. Здесь следует проявлять осторожность, поскольку ротация персонала с позиции аналитиков означает, что все события, с которыми они работали, должны быть либо приостановлены, либо переданы другому сотруднику. Кроме того, сотрудники должны регулярно практиковать VA/PT, чтобы их навыки не утратились.

Функциональные возможности этого направления также могут быть напрямую связаны с обеспеченностью персоналом. Предположим, SOC рассчитал, что в среднем для одной оценки требуется команда из трех человек плюс один ведущий специалист, а для выполнения «работы» от начала до конца обычно требуется три недели. Это составляет 12 человеко-недель на одну оценку. Четыре оценки потребуют 48 человеко-недель работы, то есть у нас есть формула, которая рассчитана для четырех оценок в год для каждого эквивалента полной занятости, включая обучение и периоды отпусков. Таким образом, можно оценить объем функционала и потребности в кадрах. Конечно, это не всегда так просто (некоторые задачи больше других), но по крайней мере, это отправная точка. SOC также может использовать этот расчет для прогнозирования того, как часто требуется пересматривать данную сеть, сайт или программу (в зависимости от того, как выполняются оценки).

7.2.7 Настройка и обслуживание сенсоров

В начале этого раздела рассматривались сложности, которые возникают, если при расчете персонала для SOC опираться на количество управляемых устройств или сенсоров. Тем не менее, есть одно подразделение в SOC, для которого такое соотношение можно смело использовать – отдел настройки и обслуживания сенсоров. Для функций обслуживания и настройки сенсоров мы можем рассматривать это как отношение, но не количества сенсоров, а сенсорных платформ или типов. Это происходит за счет экономии масштаба, которая достигается благодаря централизованному управлению, доступному в современных коммерческих и открытых технологиях сенсоров:

  • 0,5 полноценно занятого сотрудника на 1 сенсорный тип при небольшом развертывании сенсоров (<25 сетевых сенсоров, <200 серверных сенсоров или <2000 сенсоров настольных компьютеров)
  • 1,0 полноценно занятого сотрудника на каждое развертывание сенсоров среднего размера (25 – 100 сетевых сенсоров, 100 – 500 серверных сенсоров или 2000 – 10 000 сенсоров настольных компьютеров)
  • 2.0 полноценно занятого сотрудника (или более) на каждое крупное развертывание сенсоров (> 100 сетевых сенсоров, > 500 серверных сенсоров, или > 10,000 сенсоров настольных компьютеров).

В очень небольших развертываниях управление сенсорными и сигнатурными/эвристическими политиками относительно несложно. Однако по мере роста числа сенсоров, управление усложняется, поскольку разнообразие и количество различных сценариев развертывания и разнообразие в наборах правил требуют больших расходов на управление. Также нужно учесть корректировки для сенсорных платформ, которые влекут за собой сложности в интеграции, требуют постоянного обслуживания или создания и настройки большого количества пользовательских наборов правил. На крупных предприятиях нет ничего необычного в том, чтобы команда из трех или четырех человек работала только над обслуживанием комплекса систем обнаружения/предотвращения вторжений (HIDS/HIPS). Частично это связано с его тесной интеграцией с серверной средой и рабочих станций. Подобная кадровая статистика может побудить некоторые SOC к пересмотру своих предпочтений относительно того, действительно ли определенные пакеты мониторинга стоят этого.

Но это еще не все. Существует ряд других задач, которые администраторы сенсоров и систем должны выполнять ежедневно.

По мере усложнения аналитических средств многие SOC также вынуждены привлекать персонал к поддержанию и совершенствованию этих систем. Такие задачи могут включать в себя поддержку SIEM или системы сбора аудита, систем сбора и хранения PCAP или репозиториев вредоносных программ. Часть этих задач будет обязательно включать работу по администрированию специализированной платформы или базы данных (например, настройку и оптимизацию хранилища данных). SOC, которые полагаются на свою SIEM систему, обычно выделяют одного человека в качестве менеджера контента SIEM, чья работа заключается в настройке и управлении множеством пользовательских правил корреляции, фильтров, панелей инструментов и эвристик, заложенных в SIEM. Другие SOC, которые поддерживают большую систему сбора журналов аудита, вынуждены выделять одного или двух сотрудников для того, чтобы обеспечивать правильные потоки данных, соответствующие потребностям пользователей. Рассмотрим SOC, поддерживающий комплекс по сбору данных аудита, который обслуживает большое количество системных администраторов и сотрудников службы безопасности в большой клиентской организации – для базы данных такого размера потребуются выделенные ресурсы системного администратора.

В зависимости от того, насколько оснащена и изолирован SOC от остальной клиентской организации, ему возможно потребуется выделить персонал для следующих функций:

  • Обслуживание рабочих станций аналитиков SOC, контроллеров домена, объектов Active Directory и объектов групповых политик (GPO).
  • Обновление инфраструктуры SOC и сенсорных систем.
  • Ведение внутренней базы данных для отслеживания инцидентов.
  • Поддержание инфраструктуры сетевого коммутатора, маршрутизатора и межсетевого экрана SOC.
  • Обновление клиентского или внутреннего сайта SOC.
  • Поддержание ресурсов сетевого хранилища (NAS) или SAN SOC.

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

7.2.8 Разработка

На штат отдела разработки SOC влияют пять факторов:

  1. Количество и сложность систем SOC в эксплуатации.
  2. Как часто новые возможности привносятся в работу.
  3. Имеет ли SOC какие-либо собственные или нестандартные возможности, на которые он должен выделить циклы разработки.
  4. Где проходит граница между системным администрированием и инженерными функциями.
  5. Количество бюрократической работы, которую SOC должен выполнить в результате взаимодействия с отделом разработки своей головной организации и вследствие ее документооборота/жизненного цикла.

SOC, которые разделяют системное администрирование и проектирование, обычно имеют соотношение системных администраторов к инженерам 1:1 или 2:1. Другими словами, если у SOC в штате есть шесть настройщиков сенсоров и системных администраторов, достаточно команды из трех или четырех инженеров. Этот пример совершенно произвольный, потому что многие инженерные функции могут выполняться другими подразделениями SOC. Такие задачи включают разработку новых сигнатур сенсоров или написание скриптов, которые ранее выполнялись вручную. Во многих случаях очень трудно четко установить грань между операционным уровнем и проектированием. SOC постоянно обретает новые возможности для поддержания паритета с противником – гибкость является ключевым фактором.

Многие SOC полностью разрушают границу между отделами, отвечающими за обслуживание и поддержку, и проектирование систем, полностью объединяя эти две команды. В таких случаях можно рассчитать потребность в системных администраторах и увеличить ее на некоторый множитель, например, 1,5, и рассчитать общее количество сотрудников, необходимых для системного администрирования и разработки. На самом деле, это скрывает дополнительную эффективность, полученную благодаря интеграции проектирования и работы. Если у SOC нет интегрированной инженерной функции, то появление  новых возможностей или модернизация существующих проходит с большими задержками и меньшим соответствием требованиям операторов. В результате операционному уровню приходится выделять дополнительные ресурсы для решения проблем (например, чтобы заставить инструменты работать так, как задумано).

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

Поделиться записью: