2.3 Характеристики

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

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

Наши рассуждения опираются на материалы из Carnegie Mellon CERT [4] [8], все обновления или концептуальные изменения будут указаны отдельно. Эти характеристики будут использоваться далее в оставшейся части книги.

2.3.1 Положение потребителей услуг SOC

SOC являются либо частью организации, которую они обслуживают, либо являются внешней по отношению к ней сущностью.

К SOC, которые являются внешними по отношению к своим клиентам, относятся поставщики услуг безопасности (MSSP), которыми управляет сервис-провайдер, предоставляющий услуги клиентам за оплату. К ним также относятся SOC, ориентированные на конкретный продукт, например, SOC компании-разработчика, которому необходимо оперативно реагировать на выявленные в их продукте уязвимости.

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

Большая часть рекомендаций, приведенных в этой книге, подразумевает внутреннее положение потребителей услуг SOC. Это определение согласуется с определением потребителей услуг SOC, приведенном в [4, с. 12].

2.3.2 Организационная модель

В отношении внутренних SOC можно выделить пять организационных моделей, в соответствии с разделом 3.2 в [4]:

  1. Команда безопасности. Отсутствует отдельная единица для обнаружения или реагирования на инциденты. В случае возникновения инцидента компьютерной безопасности, собираются ресурсы (как правило, из числапотребителей услуг SOC) для решения проблемы, восстановления систем, после чего команда прекращает свою работу. Результаты могут сильно различаться, поскольку нет центрального наблюдателя или единой базы знаний, а процессы обработки инцидентов обычно плохо определены. Эту модель, как правило, выбирают клиенты, состоящие из менее 1000 пользователей или IP-адресов.
  2. Внутренний распределенный SOC. Постоянный SOC существует, но в основном состоит из лиц, организационно находящихся за пределами SOC, чья основная работа связана с ИТ или безопасностью, но не обязательно связана с защитой компьютерных сетей (CND). Один человек или небольшая группа отвечает за координацию действий по обеспечению безопасности, но сложные задачи выполняются лицами, привлеченными из других организаций. В эту категорию часто входят SOC, обслуживающие клиентов малого и среднего размера, от 500 до 5000 пользователей или IP-адресов.
  3. Внутренний централизованный SOC. Выделенная команда специалистов в области информационных технологий и кибербезопасности.  Обеспечивает непрерывную защиту компьютерных сетей (CND), выполняя задачи на постоянной основе. Ресурсы и полномочия, необходимые для ежедневного поддержания безопасности сетей, выделены в отдельную официально признанную единицу, обычно с собственным бюджетом. Эта команда отчитывается перед руководителем SOC, который контролирует программу CND своих клиентов. Большинство SOC относятся к этой категории, обычно обслуживая клиентов, составляющих от 5000 до 100 000 пользователей или IP-адресов.
  4. Внутренний комбинированный распределенный и централизованный SOC. SOC состоит как из центральной команды (как в случае внутренних централизованных SOC), так и из других ресурсов из потребителей (как в случае внутренних распределенных SOC). Лица, поддерживающие операции CND за пределами основного SOC, не рассматриваются как отдельная сущность SOC. Для более крупных клиентов эта модель поддерживает баланс между наличием согласованной, синхронизированной команды и поддержанием осведомленности об отдаленных ИТ-активах и анклавах. SOC, обслуживающие заказчиков, состоящих из 25 000-500 000 пользователей / IP могут использовать этот подход, особенно если их потребители географически распределены или они обслуживают очень разнородную вычислительную среду.
  5. Координирующий SOC. SOC выступает посредником и облегчает деятельность CND между несколькими подчиненными SOC, как правило, для крупного заказчика, который может включать миллионы пользователей или IP-адресов. Координирующий SOC обычно предоставляет консультационные услуги заказчику. Как правило, у него нет всей полноты картины вплоть до конечного узла, а полномочия в отношении потребителей услуг – ограничены. Координационные SOC часто служат распределительными центрами для киберразведки, формирования лучших практик и обучения. Они также могут предлагать услуги по анализу и расследованию по просьбе подчиненных им SOC.

На практике немногие SOC точно соответствуют какой-либо из этих категорий – большинство SOC попадают в область где-то между чисто распределенной и чисто централизованной моделью. Кроме того, многие координационные SOC согласуют деятельность подчиненных им SOC, а также выполняют свои собственные прямые задачи по мониторингу и реагированию. В любом случае, SOC должен оптимально сочетать глубокое понимание принципов защиты сетей и знание всех активов и задач системы. Вместе они образуют «репутацию» SOC (т.е. восприятие ценности и возможностей SOC потребителями его услуг и другими SOC). Поскольку это жизненно необходимо для успеха SOC, мы будем неоднократно возвращаться к этой теме в течение всей книги. В разделе 4 обсуждаются вопросы определения организационных моделей SOC в зависимости от размеров потребителей, которых они обслуживают.

2.3.3 Полномочия

Полномочия подразумевают степень свободы в действиях SOC по отношению к активам заказчиков – необходимость их согласования с другими группами, получения разрешения. Мы используем структуру полномочий, описанную в [4, с. 37], с некоторыми изменениями. SOC может обладать тремя уровнями полномочий:

  1. Нет полномочий. SOC может предлагать или пытаться влиять на действия, которые потребители его услуг должны предпринять. Однако у SOC нет ни формальных средств для оказания давления, ни вышестоящей организационной единицы, способной это сделать. Только заказчик решает, рассмотреть или игнорировать рекомендации SOC.
  2. Разделяемые полномочия. SOC может давать рекомендации руководству заказчика (например, ИТ-директорам, руководителям ИБ подразделений (CISO), генеральным директорам, владельцам систем), у которого есть полномочия для реализации предложенных изменений. Эти рекомендации сравниваются с предложениями других заинтересованных сторон до принятия решения, давая SOC возможность “высказаться”.
  3. Полные полномочия. SOC может давать потребителям своих услуг указания на определенные действия, не дожидаясь одобрения или поддержки со стороны участников более высокого уровня. Способность SOC диктовать изменения признается, по крайней мере, на практике.

Полномочия SOC никогда не является абсолютными, даже если он имеет «полный авторитет» в рамках какой-либо сферы его деятельности. Официальные полномочия SOC следует использовать до определенной границы, после которой SOC должен использовать скорее влияние, чем требования. Для агрессивных контрмер или реагирования, как например, отключение ключевого корпоративного сервера, требуется понимание и одобрение высокого уровня. В то время как SOC может отключать систему от сети, потому что что-то негативное уже произошло, он не может требовать изменения конфигурации для компании, потому что что-то негативное может произойти. Часто полномочия SOC  прописывают таким образом, что SOC могут использовать их часть только при обнаружении серьезного инцидента. На практике, все SOC используют как официальные, так и неофициальные внутренние полномочия, а также влияние и авторитет своих экспертов. Исходя из [4], мы классифицируем полномочия по двум этапам жизненного цикла инцидента:

  1. Реактивные. Реактивные меры, предпринятые после подозреваемого, либо подтвержденного инцидента. Действия обычно более тактические по своей сути – они временны и влияют только на те составляющие и системы, которые непосредственно затронуты инцидентом. Например, логическая или физическая изоляция узла, сбор журналов с сервера или сборка артефактов по конкретной ситуации.
  2. Проактивные. Предупредительные меры, предпринятые до того, как будут обнаружены прямые доказательства инцидента. Эти действия носят более стратегический характер – они, как правило, долговременны и влияют на значительную часть потребителей услуг SOC. Например, срочная установка патчей на весь домен Windows, “черные дыры” в DNS или блокировка IP для сетей, принадлежащих злоумышленнику, сброс пароля вне цикла для пользователей веб-портала или изменение политики безопасности.

Независимо от полномочий, возложенных на SOC, ничего не происходит без тесных рабочих отношений с владельцами систем, системными администраторами и ИТ-руководителями. В разделе 5 обсуждаются полномочия SOC на практике, а в Приложении A перечислены многие точки взаимодействия с SOC.

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