Стратегия 2: Найти баланс между размером и гибкостью. Часть 1.

Клиенты SOC разнообразны по своему размеру, специфике бизнеса и географическому положению. Структура SOC должна соответствовать структуре своих клиентов, при этом  важно сбалансировать следующие потребности:

  1. Необходимость иметь сплоченную команду специалистов по защите компьютерных сетей.
  2. Необходимость поддерживать логическую, физическую или организационную близость к контролируемым активам.
  3. Ограничения в бюджете и полномочиях клиента SOC.

Вторая стратегия позволяет найти баланс между этими потребностями. Для этого мы должны будем дать ответы на три взаимосвязанных вопроса:

  1. Какая организационная модель SOC является наиболее подходящей.
  2. Как распределить функции SOC между отделами с линейным управлением и командной структурой.
  3. Где лучше физически разместить членов команды SOC и каким образом координировать их действия.

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

4.1 Выбор организационной модели

4.1.1 Предпосылки

Ключевыми предпосылками для выбора организационной модели предприятия являются:

  1. Размер клиента с точки зрения пользователей, IP-адресов и/или устройств.
  2. Частотность инцидентов.
  3. Запросы клиента относительно своевременности и точности реагирования на инциденты.

Размер организации, которую обслуживает SOC, — это и предпосылка, и задача одновременно. Нам необходимо создать группу высококвалифицированных специалистов по защите сетей, но они должны иметь полноценную видимость, действовать на уровне цикла принятия решений противника и поддерживать уровень обеспеченности ресурсами, пропорциональный IT-бюджету клиента. Препятствием для создания команды, охватывающей все предприятие крупного клиента, может стать её неспособность поддерживать нужную гибкость и темп развития.

Чем сильнее аналитик отдален от контролируемых активов — логически или физически — тем сложнее ему становится поддерживать актуальность сведений и понимание, какое поведение является нормальным и ненормальным на интересующих узлах и сетях. Как следствие, его способность своевременно и правильно реагировать на события безопасности также ухудшается.

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

Рис. 11. Подбор правильного размера клиента

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

4.1.2 Типичные сценарии

Опираясь на рассуждения выше, мы разработали пять «моделей» SOC, которые будут использоваться в дальнейшем в книге в качестве примеров. Они представлены в таблице 4.

1. Виртуальный SOC
Организационная модельВнутренний распределенный SOC.
Размер клиента1000 пользователей/ IP-адресов.
Видимость*Нет/плохая. Много ограничений, пересмотр логов пост-фактум.
УправлениеНи реактивное, ни проактивное: полномочия по предотвращению или реагированию на инциденты часто возлагаются на головную организацию SOC.
ПримерыSOC, обслуживающие малый и средний бизнес, колледжи и местные органы власти.
ЗамечанияПоскольку такой SOC состоит из децентрализованного набора ресурсов, он скорее всего работает из офиса ИТ-директора, офиса директора по ИБ или в Центре управления сетями (если таковой существует). Инциденты происходят не так часто, чтобы требовался постоянный мониторинг.
2. Малый SOC
Организационная модельВнутренний централизованный SOC.
Размер клиента10 000 пользователей / IP-адресов.
ВидимостьОт ограниченной до хорошей. Осуществляется через основные точки периметра, некоторые хосты и анклавы.
УправлениеЧастично реактивное, частично проактивное: SOC принимает участие в голосовании по решениям в отношении профилактических мер или действий по реагированию.
ПримерыSOC, обслуживающие средние предприятия, образовательные учреждения (например, университеты) или государственные учреждения.
ЗамечанияРесурсы для операций безопасности объединены в рамках одной организации. Однако, размер бюджета SOC ограничен размером клиента. Если SOC является частью более крупной организации, такой как коммерческий холдинг или крупный правительственный департамент, малый SOC может отчитываться перед многоуровневым или национальным SOC.
3. Большой SOC
Организационная модельВнутренний централизованный SOC с элементами распределенного SOC.
Размер клиента50 000 пользователей / IP-адресов.
ВидимостьВсесторонняя. Осуществляется для большинства хостов и анклавов.
УправлениеПолностью реактивное, частично проактивное: SOC может самостоятельно принимать тактические действия по реагированию и  участвовать в выборе превентивных мер.
ПримерыSOC, обслуживающие компании из Fortune 500 и Global 2000 и крупные правительственные агентства.
ЗамечанияЭтот SOC достаточно крупный, чтобы поддерживать расширенные сервисы, выполняемые из центра, но мал, чтобы осуществлять прямой мониторинг и реагирование. В более разнородных или географически распределенных клиентских организациях крупный централизованный SOC может использовать «гибридную» договоренность с отдельными сотрудниками на удаленных объектах для выполнения ряда функций по мониторингу и реагированию.
4. Многоуровневый SOC
Организационная модельВнутренний, комбинированный, распределенный и централизованный, смешанный с координационным SOC.
Размер клиента500 000 пользователей / IP-адресов.
ВидимостьВарьируется. Часть данных с конечных активов и анклавов поступает напрямую; большинство данных поступает в подчиненные SOC.
УправлениеПолностью реактивное, частично проактивное: SOC может самостоятельно выполнять тактические действия по реагированию, в том числе те, которые могут влиять на подчиненные SOC, может рекомендовать превентивные меры.
ПримерыSOC, обслуживающие транснациональные компании и крупные межотраслевые правительственные ведомства.
ЗамечанияВследствие размера клиента этот SOC объединяет несколько различных SOC. Существует центральный координирующий SOC со своими непосредственно контролируемыми активами и анклавами, которые, скорее всего, расположены вблизи интернет-шлюза или штаб-квартиры клиента. Существует также несколько подчиненных SOC, которые находятся в пределах определенных бизнес-подразделений или географических регионов, деятельность которых синхронизируется центральным SOC.
5. Национальный SOC
Организационная модельКоординирующий SOC.
Размер клиента50 000 000 пользователей / IP-адресов, представленных клиентскими SOC.
ВидимостьОграниченная, но с широким охватом. Отсутствует или ограничен доступ к исходным данным (изначально); целиком полагается на отчеты об инцидентах от клиентских SOC; не осуществляет мониторинг клиентов напрямую.
УправлениеНе реактивное, не проактивное: несмотря на свое громкое название, SOC национального уровня обычно не оказывает существенного влияния на клиентов; обычно он выполняет консультативную роль.
ПримерыSOC, обслуживающие национальные правительства или страны.
ЗамечанияЭто классический SOC на национальном уровне, который поддерживает десятки и тысячи SOC в пределах своих границ на базе правительственных, корпоративных и образовательных учреждений. Он либо не осуществляет мониторинг напрямую, либо, если осуществляет, предоставляет рекомендации подчиненным SOC. Иногда мы будем называть эти организации «мега-SOC». Клиентские SOC, действующие внутри мега-SOC, функционируют в основном автономно, что отличает эту модель от многоуровневой модели.

Таблица 4. Модели SOC.

* Примечание: под «видимостью» имеется ввиду степень контроля активов, доступная SOC. Включает в себя мониторинг, чтение логов, возможность осуществлять действия напрямую.

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

4.2 Структурирование SOC

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

Используйте следующие стратегии при структурировании SOC:

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

4.2.1 Малый SOC

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

Классический малый SOC будет включать два или три отдела:

  1. Линия 1. Включает аналитиков, которые выполняют рутинные обязанности, такие как просмотр консолей IDS или SIEM, сбор данных киберразведки и прием запросов от клиентов.
  2. Линия 2. Выполняет всесторонний анализ инцидентов, переданных ему с Линии 1 (например, анализ журнала и данных PCAP) и координирует процесс реагирования на инциденты с клиентами.
  3. Системное администрирование. Поддерживает системы и сенсоры SOC, что может включать в себя разработку и внедрение новых возможностей.

SOC с подобной структурой может обслуживать организацию небольшого размера, отделяя «первичный» анализ от углубленного анализа и реагирования. Это показано на рисунке 12.

Рис. 12. Малый SOC

Некоторые SOC, которые используют многоуровневый подход к анализу, не всегда выделяют линии в отдельные структуры. В качестве варианта структуры, представленной на рисунке 12, можно объединить все обязанности Линии 1 и Линии 2 в один большой отдел с одним руководителем. При такой структуре у нас будет две команды — операции и системное администрирование. Еще одним преимуществом такой структуры является то, что руководитель операций может быть заместителем руководителя SOC.

Большинству SOC такого размера трудно освободить аналитиков Линии 2 от ежедневного процесса по обработке инцидентов. Кроме того, есть множество инцидентов, которые не попадают в типичные сценарии, с которыми работает Линия 1. Если эту ситуацию не исправить, скорее всего, SOC ждет стагнация и увеличение текучки кадров. Предвосхищая раздел 11, отметим, что некоторые SOC предпочитают создавать отдел «с расширенными полномочиями», представленный на рисунке 13. Роли этого раздела могут различаться, но обычно включают такие функции, как анализ инцидентов Линией 3+, улучшение процесса, продвинутое обнаружение угроз и реагирование. Команда с расширенными полномочиями может состоять из сотрудников (переведенных с Линии 2), продемонстрировавших инициативу и нестандартное мышление, и может практиковать ротацию сотрудников, включая и выключая их из обязанностей, представляющих «ежедневную рутину».

Рис. 13. Альтернативная структура малого SOC

4.2.2 Большой SOC

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

  • Линия 1 фокусируется на обработке телефонных звонков, обнаружении событий и предупреждений в реальном времени в SIEM или на консолях других сенсоров, точно также как малый SOC.
  • Линия 2 фокусируется на полной обработке инцидентов, независимо от того, сколько часов или месяцев это займет, точно также как малый SOC.
  • Появляется отдел, который отвечает за получение актуальных данных киберразведки, анализ сетевой активности и тактик, техник и процедур злоумышленника за период в несколько месяцев и лет.
    • Эта работа часто является самой неоднозначной, поскольку аналитикам приходится искать незавершенные, неструктурированные угрозы, которые в настоящее время не детектируются.
    • В этот отдел лучше всего набирать активных, инициативных и нестандартно мыслящих специалистов (например, «рок-звезд», упомянутых в разделе 7.1.1).
  • Добавляются новые полномочия и новый отдел, который выполняет рутинную работу по сканированию сети, поиску уязвимостей и проведению тестов на проникновение в клиентские сети и системы (Blue/Red Teaming).
  • Работа, поддержка и проектирование систем SOC делится на отдельные группы в едином подразделении «Жизненный цикл систем».
  • В отделе системного администрирования можно выделить по одному или два человека на наиболее важные сенсоры и SIEM.
  • Достаточно крупный SOC обычно имеет отдельную должность заместителя, который может дополнять роль руководителя операций.
  • Некоторые руководители SOC считают полезным назначать руководителей среднего звена в каждой функциональной области — анализ и реагирование, сканирование/оценка и жизненный цикл системы.
  • Можно добавить «фронт-офис», чтобы избавить руководство SOC от административных и финансовых задач или ведения клиентов.
  • Хотя это не представлено, если SOC решит интегрировать обслуживание устройств защиты периметра, таких как брандмауэры, можно выделить третью команду в подчинении руководителя подразделения Жизненного цикла систем.

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

Потенциальная организационная модель для большого SOC представлена на рисунке 14.

Рис. 14. Пример: Большой SOC

Когда SOC становится большим, важно обеспечить эффективное перекрестное обучение и взаимодействие. Инженеры должны оставаться в курсе основных проблем и «болевых точек» группы операций и уметь быстро разворачивать 90% решений. В результате можно осуществлять ротацию персонала между позициями инженеров и разработчиков, как в команде опытных специалистов в модели «малый SOC». И несмотря на то, что может быть несколько уровней управления, операторы одного отдела не должны бояться работать напрямую с любым другим подразделением SOC.

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