2.2 Задачи и темп действий

SOC могут варьироваться от небольших команд в пять человек до огромных национальных координационных центров. Типичная задача SOC среднего уровня обычно включает следующие элементы:

  1. Предотвращение инцидентов кибербезопасности:
    1. Непрерывный анализ угроз;
    2. Сканирование сетей и узлов для поиска уязвимостей;
    3. Координация развертывания противодействия;
    4. Консалтинг в области политики безопасности и архитектуры.
  2. Мониторинг, обнаружение и анализ потенциальных вторжений в режиме реального времени и через отслеживание трендов из значимых источников данных в области безопасности.
  3. Реагирование на подтвержденные инциденты путем координации ресурсов и контроля за использованием своевременных и соответствующих ситуации защитных мер.
  4. Предоставление соответствующим организациям актуальной информации о текущей ситуации, а также отчетов о статусе кибербезопасности, инцидентах и тенденциях в поведении злоумышленников.
  5. Разработка и управление средствами защиты компьютерных сетей, такими как системы обнаружения вторжений или системы сбора/анализа данных.

Среди перечисленных обязанностей наиболее трудоемкими, пожалуй, являются обработка и анализ большого количества данных, относящихся к безопасности. Как правило, основным источником данных о состоянии безопасности, используемым SOC, являются системы обнаружения вторжений (также известные как СОВ, IDS). IDS — это системы, размещенные на узле или в сети для обнаружения потенциально злонамеренной или нежелательной активности, которая требует дополнительного внимания аналитика SOC. В сочетании с журналами аудита безопасности и другими каналами данных типичный SOC ежедневно собирает, анализирует и хранит десятки или сотни миллионов событий безопасности.

Согласно [42], событие — это «любое наблюдаемое происшествие в системе и/или сети. Иногда события указывают, на возникновение инцидента» (например, сообщения/алерты, генерируемые IDS или службой аудита безопасности). Событие — это всего лишь необработанные данные. Для установления определения оправданности дальнейших действий, требуется дополнительный анализ со стороны человека — процесс оценки выделения значимой информации из набора данных о состоянии безопасности, как правило, с помощью специализированных инструментов.

Обработка постоянного притока данных аналогична обработке потока пациентов в чрезвычайной ситуации — есть сотни раненых, но как определить, кому требуется помощь в первую очередь? Адаптация определения из источника [4, стр. 16], приоритезация — это процесс сортировки, категоризации и определения приоритетности входящих событий и других запросов на ресурсы SOC.

Обычно SOC выделяет отдельную команду специалистов, занятых приоритезацией событий в режиме реального времени, а также разбором телефонных звонков от пользователей и другими рутинными задачами. Эта группа часто упоминается как 1-я Линия.[1] Если специалист 1-й линии определяет, что событие достигло установленного заранее критического порога, создается кейс (case), который переводится на 2-ю Линию. Этот порог может быть определен в зависимости от различных типов потенциальной «опасности» (типа инцидента, атакуемого актива или информации, затронутого процесса и т. д.). Как правило, период времени, в течение которого 1-я Линия должна обработать каждое событие, представляющее интерес, длится от 1 до 15 минут. Его длина зависит от политики эскалации SOC, концепции операций (CONOPS), количества аналитиков, размера клиента SOC и объема событий. Сотрудникам первой  линии не рекомендуется выполнять углубленный анализ, поскольку они не должны отвлекаться от обработки поступающих событий в режиме реального времени. Если для оценки события требуется более нескольких минут, оно будет переведено на Линию 2.

2-я Линия получает события от 1-й Линии и выполняет углубленный анализ, чтобы определить, что произошло на самом деле (насколько это возможно при имеющихся временных ресурсах и информации) и необходимы ли дальнейшие действия. Для определения масштаба и тяжести события может потребоваться несколько недель для сбора и проверки всех необходимых данных. Поскольку Линия 2 не отвечает за мониторинг в режиме реального времени и состоит из более опытных аналитиков, ее сотрудники могут потратить больше времени на полноценный анализ каждого набора действий, получение дополнительной информации и согласование решения с клиентом. Обычно Линия 2 (или выше) отвечает за подтверждение факта возникновения инцидента. Согласно [42],

инцидент — это оцениваемое событие, которое

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

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

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

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

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

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

Когда признаки атаки достаточно хорошо поняты, чтобы закодировать машиночитаемую сигнатуру IDS, атака может быть предотвращена автоматически, например, с помощью системы предотвращения вторжений на узел (HIPS) или в сети (NIPS). Поскольку такие системы обычно используются для предотвращения самых базовых атак, степень, в которой они могут автоматизировать анализ, ограничена. Для нейтрализации крупных инцидентов участие человека необходимо всегда. Ряд технологий позволяет SOC ежедневно обрабатывать миллионы событий с поддержкой полного жизненного цикла инцидента. Инструменты SIEM собирают, хранят, сопоставляют и отображают данные о состоянии безопасности из множества источников, поддерживая операции сортировки, анализа, эскалации и реагирования. Системы обнаружения (IDS) и предотвращения (IPS) вторжений являются двумя из множества систем, которые поставляют данные в SIEM. Как показывает опыт, технологии IDS/IPS могут быть необходимы, но не достаточны для обнаружения инцидентов (хотя они по-прежнему актуальны и полезны — этот вопрос подробно обсуждается в Разделе 8.2). В совокупности имеющееся разнообразие источников информации позволяет использовать для анализа как разрозненные и неподтверждённые, так и достоверные в контексте ситуации данные. Любой источник событий безопасности имеет низкую ценность сам по себе; целое больше, чем сумма составляющих.

SOC не ограничивается получением информации со стороны своих потребителей; он также собирает информацию из различных внешних источников, которые обеспечивают понимание угроз  и уязвимостей, а также тактик, техник и процедур злоумышленников. Эта информация называется данными киберразведки (threat intelligence) и включает в себя новостные фиды в области кибер-безопасности, обновления сигнатур, отчеты об инцидентах, сообщения об угрозах и предупреждения об уязвимостях. Как защитник, SOC находится в постоянной гонке вооружений, чтобы поддерживать паритет с изменяющейся средой и ландшафтом угроз. Ключом к победе в этой гонке для SOC является постоянный сбор данных киберразведки инструментами мониторинга. За неделю SOC обрабатывает десятки фрагментов данных киберразведки, которые могут дать сигнал к применению различных защитных мер, от обновлений сигнатур IDS до срочной установки патчей. SOC должен уметь отбирать данные киберразведки для использования; они должны быть своевременными, актуальными, точными, конкретными и действенными в отношении инцидента, уязвимости или угрозы, которую описывают.

Составляя описание всех ролей, выполняемых в SOC, учитывайте, что подход к разделению ролей может варьироваться в различных SOC, а некоторые функции — накладываться друг на друга. Некоторые SOC выполняют углубленный анализ и реагирование в рамках 2-й Линии. Другие передают некоторые из этих функций на третий уровень. Мы не будем описывать все возможные варианты. На рисунке 1 представлены типовые пути эскалации инцидента и ключевые роли в SOC.

Роли SOC и эскалация инцидента
Рисунок 1. Роли SOC и эскалация инцидента

Другие сущности в рамках структуры потребителя услуг SOC могут быть аналогичны SOC, но их следует признать отдельными и самостоятельными. SOC отличается от:

  • Центра управления сетью (Network Operations Center, NOC), поскольку SOC в основном ищет кибератаки, тогда как NOC занимается эксплуатацией и обслуживанием сетевого оборудования.
  • ИТ-директора (CIO) или подразделения информационной безопасности, поскольку SOC выполняет функции в режиме реального времени, а его усилия по мониторингу обычно не предназначены для обеспечения стратегического планирования (хотя некоторые SOC могут напрямую подчиняться CISO или CIO).
  • Программы непрерывного мониторинга информационной безопасности (ISCM) [45], поскольку SOC отвечает за обнаружение и реагирование на инциденты
  • ISSO или ISSM, потому что SOC отвечает за мониторинг и реагирование на полномасштабную кибер-угрозу по всей клиентуре, тогда как ISSO обычно связаны с наблюдением за ИТ и обеспечивают безопасность конкретных систем
  • Команд эксплуатации компьютерной сети (CNE) или компьютерных сетевых атак (CNA), поскольку SOC обычно не выполняют действия по атаке или проникновению вне своей клиентуры.
  • Мониторинга физической безопасности (например, «ворота, охранники, вооружение»), поскольку SOC занимается кибер-сферой, в то время как мониторинг физической безопасности в первую очередь касается защиты физических активов и обеспечения безопасности персонала.
  • Правоохранительных органов, поскольку SOC обычно не являются следственными органами; они могут найти вторжения, которые могут привести к правовым последствиям, но их основная обязанность, как правило, не заключается в сборе, анализе и представлении доказательств, которые будут использоваться в судебных разбирательствах.

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


[1] — Мы придерживаемся иерархии анализа и эскалации в рамках SOC, происходящей из разделения уровней в службе технической поддержки ИТ и организациях системного администрирования. Описанный режим работы не следует путать с многоуровневыми SOC, которые представляют собой несколько объединенных SOC в структуре одного большого клиента (обсуждается далее, в разделе 4.3.7).

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