Дорогие друзья, этой статьей мы начинаем мини-цикл из нескольких постов, посвященных обзору публикации MITRE «11 стратегий SOC-центра мирового уровня». Данный документ является международно признанным сборником лучших практик по построению и управлению SOC-центрами, мониторингу и реагированию на кибератаки, обеспечению слаженной работы персонала, процессов и технологий SOC. В нем излагаются практические рекомендации на основе многолетнего опыта работы различных центров мониторинга и широкой экспертизы авторов публикации. В нашем сегодняшнем посте - обзор введения (условная «Стратегия №0») и первых трех стратегий из указанной публикации (Стратегия №1 «Знайте, что вы защищаете и почему», Стратегия №2 «Обеспечьте SOC необходимыми полномочиями для выполнения задач», Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании»). Приступим!

Оглавление:
Стратегия №0 «Введение»
Стратегия №1 «Знайте, что вы защищаете и почему»
Стратегия №2 «Обеспечьте SOC необходимыми полномочиями для выполнения задач»
Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании»

---

Введение (Стратегия №0)

MITRE - это некоммерческая организация, основанная в 1958 году на базе научной лаборатории Массачусетского технологического института (MIT). В настоящий момент MITRE работает в различных направлениях, самым известным из которых является область кибербезопасности, включая такие проекты, как MITRE ATT&CK, CAPEC, CWE, CVE, STIX, MAEC. Совместная работа MITRE с различными SOC-центрами, коммерческими организациями, центрами исследований и разработок послужила основой для разработки методологии и лучших практик по управлению SOC-центрами, которые были представлены в 2014 году в публикации «10 стратегий SOC-центра мирового уровня» (англ. "Ten Strategies of a World-Class Cybersecurity Operations Center"). Публикация получила большую известность, а полученная обратная связь и изменения киберландшафта послужили причиной выпуска обновления публикации в марте 2022 года, которая теперь называется  «11 стратегий SOC-центра мирового уровня». Авторами издания являются три человека с богатым и разнообразным опытом работы в ИБ, при этом они подчеркивают, что при написании широко использовались сторонние материалы, список которых предоставлен в Приложении «A» к указанной книге.

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

Рекомендации из книги основаны на опыте работы зрелых SOC и содержат предложения по архитекторе, инструментам и процессам SOC, предлагают обоснования выделения ресурсов на SOC, описывают методы увеличения пользы инвестиций в сотрудников и технологии SOC, указывают на внешние условия, которые могут оказать влияние на успешность SOC. В новом издании рассмотрено управление киберинцидентами в различных средах, включая облачные, мобильные, OT-инфраструктуры, при этом внимание уделено таким популярным технологиям кибербезопасности, как SIEM, TIP, EDR, UEBA, SOAR, большие данные, машинное обучение, симуляторы атак и взломов.

Публикация «11 стратегий SOC-центра мирового уровня» начинается с вводной части, которую авторы условно обозначили «Стратегия №0»: в ней собраны базовые понятия и принципы работы SOC, даны определения важным терминам, описаны применяемые в SOC технологии. Обзору данной вводной стратегии посвящен настоящий пост.

Итак, в Стратегии №0 авторы книги перечисляют некоторые причины роста популярности SOC в последнее время (несмотря на то, что первые SOC-центры появились еще в 1990-х годах):

·         рост числа APT-атак и эволюция тактик, техник и процедур (далее - TTPs: Tactics, Techniques and Procedures) атакующих;

·         цифровая трансформация бизнесов, диджитализация большинства процессов;

·         размытие традиционного сетевого периметра вкупе с массовым переходом на удаленную работу из-за пандемии;

·         распространение и интеграция систем SCADA, АСУТП, элементов OT-инфраструктуры;

·         повышение информационного освещения вопросов кибербезопасности, вплоть до обсуждения на уровне ведущих мировых СМИ;

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

В публикации также дается определение SOC (англ. Security Operations Center, Центр мониторинга кибербезопасности) как команды, состоящей преимущественно из специалистов в области кибербезопасности, сформированной для предотвращения, выявления, анализа, реагирования на инциденты кибербезопасности и предоставления соответствующей отчетности. Основной задачей SOC является киберзащита своих клиентов/заказчиков (англ. constituency), которая подразумевает защиту от несанкционированных действий в киберпространстве, включая мониторинг, выявление, анализ, реагирование, восстановление после киберинцидентов. Заказчики могут быть внешними (в случае коммерческих SOC) или внутренними (в случае включения SOC в организационную структуру компании), которые пользуются услугами SOC по поиску, анализу, реагированию на кибервторжения, при этом SOC могут быть различными по структуре, функционалу, численности, ресурсам, а также могут именоваться по-разному. Например, зарубежом применяются такие термины, как Computer Security Incident Response Team (CSIRT), Computer Incident Response Team (CIRT), Computer Incident Response Center (CIRC). Кроме того, в литературе встречается также термин Computer Emergency Response Team (CERT), который является зарегистрированной торговой маркой Университета Карнеги-Меллона и был впервые использован в 1988 году во время эпидемии ВПО «Червь Морриса».

Объектами защиты SOC являются пользователи, сайты, IT/OT/облачные активы, данные, сети, организации, а также элементы IT-инфраструктуры (on-prem и удаленной), облачной, мобильной, OT-инфраструктуры заказчиков. Миссия типового SOC среднего размера может заключаться в выполнении следующих задач:

·         Предотвращение киберинцидентов с помощью таких проактивных мер, как непрерывный мониторинг угроз, поиск уязвимостей, применение контрмер, консультирование заказчиков по вопросам политик ИБ и ИБ-архитектуры;

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

·         Реагирование на подтвержденные инциденты путем скоординированного выделения ресурсов и применения оперативных и релевантных контрмер;

·         Предоставление заказчикам ситуационной осведомленности и отчетности о состоянии киберзащищенности, инцидентах ИБ, тенденциях кибератакНастройка и эксплуатация технологий SOC (настройка источников данных с устройств и сетей, сбор событий безопасности, управление аналитическими системами).

 

В документе также даются определения некоторым терминам, применяемым в работе SOC:

·         Событие (Event) - это зафиксированная ситуация в системе и/или сети;

·         Предупреждение (Alert) - это уведомление о наступлении определенного события или серии событий;

·         Киберинцидент - это действия, выполненные с использованием информационной системы или сети, которые привели к действительному или потенциальному негативному воздействию на информационную систему, сеть и/или обрабатываемую в них информацию;

·         Триаж - это процесс сортировки, категорирования и приоритизации входящих событий и иных запросов к ресурсам SOC.

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

1. Триаж, анализ, реагирование на киберинциденты:

1.1. Мониторинг и триаж предупреждений в режиме реального времени;

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

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

1.4. Сдерживание, устранение, восстановление для снижения текущего негативного влияния инцидента и предотвращения повторных инцидентов;

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

1.6. Форензический анализ артефактов инцидента для получения детальной информации о произошедшем, анализа содержимого носителей, построения timeline инцидента;

1.7. Анализ ВПО для получения информации о происхождении, функционале, целях применяемого ВПО;

1.8. Реагирование на инцидент с выездом на площадку к заказчику.

 

2. Управление данными о киберугрозах, поиск и анализ киберугроз:

2.1. Сбор, обработка, обогащение данных о киберугрозах с помощью TIP-систем, TI-фидов и отчетов о киберугрозах, обработка и интеграция данных о киберугрозах в системы SOC;

2.2. Анализ и формирование сведений о киберугрозах для слежения за атакующими, корреляции и выявления тенденций в их поведении, последующей поддержки принятия риск-ориентированных решений путем формирования отчетов об атакующих, их TTPs, вредоносных кампаниях;

2.3. Распространение и предоставление доступа к данным о киберугрозах партнерам, другим SOC, ИБ-сообществу»

2.4. Поиск киберугроз (Threat Hunting) путем выполнения проактивных действий для обнаружения потенциально вредоносной активности, основываясь на предположении о том, что атакующие уже находятся в инфраструктуре или проводят атаку в настоящее время;

2.5. Настройка сенсоров и аналитики, включая сопровождение и оптимизацию средств обнаружения, аналитических средств, сигнатур, правил корреляции и реагирования в системах SOC, включая решения EDR, SIEM, SOAR;

2.6. Создание кастомизированных средств анализа и выявления кибератак на основе знаний о TTPs атакующих и инфраструктуре заказчика;

2.7. Data Science и машинное обучение для поддержки функций SOC.

 

3. Расширенные функции SOC:

3.1. Эмуляция кибератак и аудиты, включая red и purple teaming, тестирование на проникновение, эмуляцию действий атакующих, атак и взломов для повышения эффективности SOC и возможностей по защите;

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

3.3. Борьба с инсайдерами путем выявления, анализа, проведения расследований вредоносной или аномальной активности легитимных пользователей.

 

4. Управление уязвимостями:

4.1. Инвентаризация активов путем сбора и сопровождения базы знаний об активах, сетях и сервисах заказчиков, построения их взаимосвязей, расчета уровней критичности и риска активов;

4.2. Сканирование активов на наличие уязвимостей, получение информации о конфигурациях активов, статусе уязвимостей, установленном ПО и обновлениях для расчета уровня киберриска и комплаенс-статуса активов;

4.3. Анализ уязвимостей путем систематического изучения информационных систем или программных продуктов для оценки адекватности применяемых защитных мер, выявления недостатков защиты, оценки эффективности предлагаемых контрмер и подтверждения их корректной имплементации;

4.4. Получение и анализ отчетов об уязвимостях от исследователей для применения соответствующих компенсирующих мер;

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

4.6. Установка обновлений безопасности, снижение риска эксплуатации уязвимостей.

 

5. Инструменты, архитектура, инжиниринг SOC:

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

5.2. Развертывание, настройка, поддержка, эксплуатация сетевых средств защиты, включая создание и поддержку сетевых соединений и передачи данных между решениями;

5.3. Развертывание, настройка, поддержка, эксплуатация хостовых средств защиты, включая создание и поддержку сетевых соединений и передачи данных между решениями;

5.4. Развертывание, настройка, поддержка, эксплуатация облачных средств защиты, включая создание и поддержку сетевых соединений и передачи данных между решениями;

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

5.6. Развертывание, настройка, поддержка, эксплуатация средств защиты для OT-инфраструктуры, включая создание и поддержку сетевых соединений и передачи данных между решениями;

5.7. Развертывание, настройка, поддержка, эксплуатация аналитических платформ (таких как SIEM, SOAR, TIP, UEBA, решений для анализа больших данных), включая создание и поддержку сетевых соединений и передачи данных между решениями;

5.8. Развертывание, настройка, поддержка, эксплуатация элементов операционной среды SOC, таких как тестовые среды, серверы, АРМ, принтеры, файловые ресурсы и сетевое оборудование SOC;

5.9. Создание кастомизированных инструментов и систем для выполнения задач SOC в случае отсутствия подходящих готовых решений.

 

6. Ситуационная осведомленность, взаимодействие, тренинги:

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

6.2. Проведение внутреннего обучения и тренингов для работников SOC в целях повышения их профессионального уровня;

6.3. Проведение внешнего обучения и тренингов для работников заказчика для повышения их осведомленности в вопросах кибербезопасности;

6.4. Проведение киберучений и тренировок для подготовки к реагированию на киберинциденты.

 

7. Руководство и управление SOC:

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

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

7.3. Обеспечение непрерывности деятельности SOC путем создания и оценки планов поддержания бизнес-процессов SOC во время и после сбоев;

7.4. Разработка, измерение, предоставление отчетности по метрикам (показателям) эффективности операционных процессов, результатов деятельности SOC, состояния ситуационной осведомленности заказчика.

 

В Стратегии №0 авторы также выделяют несколько важных общих тезисов для эффективной работы SOC:

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

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

3. Наличие возможностей по обнаружению кибератаки до проникновения атакующих в инфраструктуру (left of hack) и по сдерживанию атакующих после их закрепления в атакованной сети (right of hack);

4. Эффективность выявления и реагирования на инциденты ИБ зависит от возможностей SOC по охвату всех этапов жизненного цикла кибератаки вкупе с пониманием TTPs злоумышленников на каждом из этапов;

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

---

Стратегия №1 «Знайте, что вы защищаете и почему»

 

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

Для эффективного предоставления услуг заказчикам SOC должен понимать, поддерживать и обмениваться данными ситуационной осведомленности (далее - СО) (англ. Situational Awareness, SA). СО можно определить как восприятие состояния кибербезопасности и ландшафта киберугроз заказчика во времени и пространстве, понимание их взаимосвязи (т.е. киберриска), а также прогнозирование их статуса на ближайшее будущее. Цикл принятия ситуационно-ориентированных решений соответствует циклу OODA (англ. observe, orient, decide, act - наблюдение, ориентирование, принятие решения, выполнение). В SOC все аналитики, иногда неосознанно, выполняют действия в соответствии с OODA-циклом, который может длиться от минут до месяцев, при этом происходит непрерывное повышение СО операторов об инфраструктуре заказчика и актуальных для него киберугрозах. Достижение SOC качественной СО занимает длительное время, но это позволяет предоставлять заказчику оперативную актуальную информацию и отвечать на вопросы вида:

·         Каково состояние кибербезопасности компании в текущий момент времени?

·         Какие последствия будут у успешной кибератаки, включая последствия для предоставляемых и потребляемых услуг?

·         Какие злоумышленники являются реальной угрозой для компании?

·         Каким образом злоумышленники атакуют компанию и каковы их цели?

·         Как лучше реагировать на эти кибератаки?

·         Каково состояние установки обновлений безопасности в инфраструктуре компании, установку каких патчей следует приоритизировать?

·         К каким системам следует применить определенный набор мер защиты для наиболее эффективной минимизации киберрисков?

·         Как изменяются киберугрозы, направленные на компанию, как меняются TTPs атакующих, что нужно компании для мониторинга и защиты от этих новых угроз?

·         Кто из сотрудников или контрагентов компании выполняет нехарактерные действия, и является ли это угрозой?

 

СО в контексте SOC может быть разделена на следующие 5 областей:

1. Понимание бизнеса и миссии заказчика

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

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

·         Основные направления ведения бизнеса (англ. lines of business), включая все обеспечивающие службы и функции, а также соответствующие показатели выручки и затрат

·         Географические и физические локации осуществления бизнес-процессов

·         Соответствие и взаимосвязи между направлениями ведения бизнеса и цифровыми активами, службами, данными, местами хранения информации

·         Деловые взаимоотношения между компанией-заказчиком и другими компаниями, организациями, государственными учреждениями.

Для понимания бизнеса заказчика SOC совместно с другими ИБ-подразделениями компании может использовать следующие практики и техники:

·         Нанимать в SOC сотрудников, у которых есть опыт работы в бизнес-подразделениях компании-заказчика

·         Взаимодействовать на постоянной основе с сотрудниками компании, компетентными в области ИБ (англ. security champions, «чемпионы по кибербезопасности»), и по возможности включать их в штатную структуру SOC

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

·         Обеспечивать проведение регулярных технических тренировок и учений-симуляций для владельцев основных информационных систем

·         Поддерживать и эффективно эксплуатировать систему учета информационных активов и сервисов

·         Вовлекать и задействовать ИБ-подразделения компании для оценки киберрисков и критичности инцидентов

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

·         Учитывать информацию о бизнес-процессе при принятии сервиса на мониторинг в SOC

·         Поддерживать актуальную информацию о бизнес-подразделениях, например через реестр сервисов.

 

2. Понимание применимых юридических, регуляторных и нормативных требований

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

·         Типы применимых правовых систем

·         Типы применимых законодательных требований (например, уголовное законодательство, законодательство о защите интеллектуальной собственности или персональных данных)

·         Роль SOC в соответствии применимым юридическим и регуляторным требованиям

·         Применимые отраслевые стандарты (например, правила уведомления о киберинцидентах, стандарты хранения персональных данных).

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

·         Назначение контактных лиц по юридическим вопросам (например, координаторов проведения аудитов и юрисконсультов)

·         Разработка внутренних нормативных документов SOC, которые описывают ответственность SOC в разрезе выполнения требований нормативных документов

·         Разработка руководства по выполнению определенных юридически значимых действий (например, по сбору компьютерной криминалистической информации)

·         Составление списка внутренних контактных лиц, ответственных за поддержку проведения регулярных аудитов.

 

3. Понимание технической среды, критических систем и данных

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

3.1. Расположение цифровых активов заказчика:

·         Географическое расположение элементов IT и OT инфраструктуры

·         Количество, тип, расположение, сетевая связность IT- и OT-активов, включая ПК, серверы, сетевые и мобильные устройства, IoT-устройства

·         Сетевая топология, включая физическую и логическую связность, границы между сетевыми сегментами, внешние точки подключения

·         Архитектура активов, сетей, приложений (включая информацию об аутентификции, контроле доступа, аудите)

·         Места хранения информации (например, закрытая сеть, облако, мобильные устройства).

3.2. Уровень критичности цифровых активов заказчика:

·         Самые важные типы информации и места ее обработки и хранения

·         Какие системы выполняют критичные для компании функции и к каким данным предъявляются повышенные требования по конфиденциальности, целостности, доступности.

3.3. Состояние цифровых активов заказчика:

·         Какое состояние считается нормальным (штатным) для активов в основных сетевых сегментах и на устройствах

·         Изменения в состоянии активов, например, изменения в конфигурации, поведении устройства, используемых портов и протоколов, объеме сетевого трафика

·         Уязвимости устройств и приложений, примененные контрмеры для снижения возможности эксплуатации уязвимостей.

Для понимания технической среды, инфраструктуры и данных заказчика SOC совместно с IT-, OT- и сетевыми администраторами, а также с другими ИБ-подразделениями компании может использовать следующие практики и техники, предписывающие:

·         Участвовать и поддерживать проведение комплексной инвентаризации IT и OT-активов, включая поддержку актуальности сетевых схем и диаграмм основных информационных систем, сбор и анализ отчетов о сканировании на наличие уязвимостей, сопровождение и использование списка ответственных за системы работников компании-заказчика

·         Иметь доступ к основным системам заведения заявок в IT и к трекинг-системам, использующимся для управления IT-изменениями

·         Собирать данные телеметрии и поддерживать доступ к источникам событий ИБ, включая приложения и базы данных для основных приложений и хранилищ информации

·         Использовать сетевые сенсоры, хостовые сенсоры, анализ больших данных, системы Log Management и SIEM.

В публикации «11 стратегий SOC-центра мирового уровня» также подчеркивается важность построения и поддержания в актуальном состоянии перечня защищаемых активов и их свойств, используя все доступные разнородные источники данных, которых может быть особенно много в крупных компаниях. Инвентаризационную информацию следует получать не только с on-prem устройств, но и из облачных инфраструктур (PaaS и SaaS, облачные хранилища), а также учитывать IoT-устройства и хосты, которые могут быть изолированы от сети. Данные об ИТ-активах можно получать из таких источников, как:

·         LDAP-каталоги, службы Active Directory

·         Данные DHCP

·         Инвентаризационные данные от различных подразделений (представленные в различных форматах, от Excel-таблиц до данных из комплексных систем инвентаризации)

·         Инвентаризационные данные из облачных инфраструктур

·         Данные из MDM и EDR решений, включая события обнаружения неизвестных устройств

·         Данные сканеров сети

·         Данные сканеров уязвимостей

·         ИБ-решения, которые строят список активов на основании обработанных событий ИБ (например, таким функционалом могут обладать SIEM и UEBA системы, некоторые межсетевые экраны)

·         Системы управления конфигурациями, обновлениями безопасности, распространением ПО (например, Microsoft SCCM, HCL BigFix, Ivanti Unified Endpoint Manager).

 

4. Понимание пользователей и их поведения, а также сервисных взаимодействий

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

·         Значение действий пользователей и сущностей (субъектов доступа) в корпоративной сети и на устройствах заказчика, с учетом бизнес-контекста

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

·         Описание типичного формата работы (с помощью baseline-метрик) пользователей с различными системами и данными, особенно с критичными

·         Процессы авторизации и делегирования полномочий при взаимодействии пользователей и сервисов, а также между сервисами

·         Зоны (контуры) доверия и взаимозависимости доверия внутри компании и внутри бизнес-направлений.

Для понимания пользователей и их действий, а также поведения сервисов и иных сущностей, SOC совместно с другими ИБ-подразделениями компании может использовать следующие практики и техники, предписывающие:

·         Поддерживать в актуальном состоянии и использовать данные инвентаризации сервисов и активов

·         Иметь доступ к системам авторизации пользователей и приложений

·         Иметь компетенции внутри SOC по технологиям управления доступом и  «нулевого доверия»

·         Иметь доступ к базе знаний об архитектуре и дизайну использующихся систем управления доступом (например, к информации о AD-лесах и выстроенных отношениях доверия между доменами)

·         Собирать информацию о событиях входа/выхода субъектов доступа, доступа пользователей к объектам, изменения объектов директорий

·         Использовать и поддерживать UEBA-платформу на уровне, соответствующем потребностям SOC.

 

5. Понимание киберугроз

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

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

5.2. Какие типы или группы атакующих с большой долей вероятности будут атаковать компанию? Атакующие могут быть случайными хакерами, инсайдерами, хактивистами, опытными киберпреступниками или членами APT-групп. Понимание возможностей актуальных нарушителей поможет корректно выстроить систему киберзащиты.

5.3. Какие киберинциденты случались у заказчика ранее? Понимание типов атакованных систем, скомпрометированных данных, влияния и последствий предыдущих киберинцидентов поможет приоритизировать усилия SOC.

 

В финале описания Стратегии №1 приводится ряд советов для того, чтобы постепенно повышать уровень ситуационной осведомленности SOC:

1. Следует постепенно, но непрерывно повышать уровень СО и не стремиться достичь всеобъемлющего понимания сразу

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

3. Необходимо собирать перечень нормативных требований, которые применимы к деятельности SOC

4. Требуется проводить непрерывную оценку IT-среды, за которую отвечает SOC

5. Следует работать совместно с другими подразделениями компании для повышения СО, например, с ИТ-департаментом, руководителями, юристами

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

7. Рекомендуется использовать средства автоматизации для хранения и контекстуализации информации

8. Вместе с руководителями компании следует непрерывно проверять понимание SOC приоритетов бизнеса

9. Следует выстраивать стандартные операционные процедуры (англ. standard operation procedures, SOPs) и TTPs для деятельности SOC, проводить учения и тренировки по сбору информации, уведомлению об инциденте, координации действий и предоставлению отчетности в рамках действий по защите приоритетных направлений бизнеса компании.

 

---

Стратегия №2 «Обеспечьте SOC необходимыми полномочиями для выполнения задач»

 

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

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

В Уставе SOC должны присутствовать такие положения, как:

1.      Назначение SOC единым центром киберопераций и мониторинга кибервторжений, киберзащиты, реагирования на киберинциденты заказчика

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

3.      Полномочия SOC на выполнение следующих действий:

·         Развертывание, эксплуатация, поддержка хостовых и сетевых систем активного и пассивного мониторинга;

·         Проактивное и реактивное сканирование хостов и сетей для составления карты сети и выявления активов, определения их настроек безопасности и статуса уязвимостей, установки патчей;

·         Выполнение или обеспечение выполнения активных и пассивных мероприятий противодействия киберугрозам, включая, но не ограничиваясь отключением или блокированием сетевых подключений, хостов, учетных записей, сетей

·         Реагирование на подтвержденные киберинциденты при прямом взаимодействии и сотрудничестве с необходимыми лицами и подразделениями

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

4.      Ожидаемая мера сотрудничества со стороны технической поддержки, работников департаментов ИБ и ИТ (сетевые, системные администраторы) при оповещении, диагностике, анализе, реагировании на проблемы, поломки, инциденты и иные задачи, решение которых может потребовать вовлечение ресурсов указанных подразделений и лиц

5.      Роль SOC в проектировании, приобретении, создании, интеграции, эксплуатации, поддержке систем мониторинга, функций и операционной среды SOC;

6.      Уровень контроля SOC над выделением ресурсов для создания инструментов и их поддержки, найма и удержания персонала, покрытия операционных затрат, относящихся к функциям SOC

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

 

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

1.      Обладать самыми высокими полномочиями для подчиненных SOC-центров

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

3.      Координировать действия подчиненных SOC при реагировании на инциденты;

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

5.      Управлять устройствами, агрегирующими релевантные ИБ-данные от подчиненных SOC, и сенсорами, установленными на хостах и в сетях, особенно когда у подчиненных SOC отсутствуют соответствующие компетенции;

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

7.      Предлагать внутренние ИБ-стандарты и рекомендации, например, в части выбора практик и технологий для сетевого мониторинга и мониторинга кибербезопасности;

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

В дополнение к ВНД, которые непосредственно определяют функционирование SOC, в компании-заказчике должны быть разработаны и внедрены ИТ/ИБ-документы, которые помогут эффективно выполнять задачи SOC-центра. Совместно с ИТ и ИБ подразделениями, SOC должен участвовать в разработке или корректировке следующих документов:

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

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

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

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

5.      Перечень внешних разрешенных портов и протоколов, которые могут использоваться при пересечении периметра компании для доступа через DMZ, к ИТ-инфраструктуре контрагентов и открытых в/из Интернет;

6.      Стандарты присвоения имен хостам, включая требования по наименованию устройств для понимания их типа и роли на основании их DNS-имени;

7.      Иные политики по конфигурированию ИТ-систем и соответствию требованиям, от требований к сложности паролей до стандартов защищенной настройки устройств;

8.      Политики использования личных устройств и правила удаленной работы с корпоративной инфраструктурой, сетями, приложениями, данными с личных устройств работников;

9.      Перечень согласованных ОС, ПО, системных образов, стандартных baseline-настроек устройств различного типа (серверы, ПК, ноутбуки, сетевое оборудование, ПАК);

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

11.  Политика аудита с описанием типов событий ИБ, которые должны собираться на определенных видах систем, сроками хранения журналов аудита, перечнем ответственных за обработку, сбор и хранение журналов аудита;

12.  Роли и ответственные со стороны контрагентов применительно к реагированию на киберинциденты;

13.  Юридически значимые документы, касающиеся классификации информации, персональных данных, хранения информации, сбора улик и их применимости в суде, правила дачи разъяснений работниками и проведения внутренних проверок (расследований) по фактам выявленных киберинцидентов.

 

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

1.      Требования по сетевой доступности и пропускной способности;

2.      Планирование на случай недоступности потребляемых/предоставляемых услуг;

3.      Порядок уведомления о сетевых сбоях и инцидентах, временные нормативы по восстановлению, эскалации, отчетности;

4.      Порядок уведомления о киберинцидентах, процедуры восстановления, временные нормативы по эскалации и отчетности;

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

 

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

1.      Местоположение SOC в иерархии компании, выбор подчиненности SOC: SOC может подчиняться напрямую CIO/CISO, и это лучший вариант, в противном же случае (более низкое иерархическое положение SOC) надо предусмотреть ВНД, которые помогут SOC реализовывать необходимые для эффективной деятельности функции;

2.      Полномочия организации, которая является родительской для SOC;

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

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

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

6.      Выбранная организационная модель SOC: Tier-модель с дочерними SOC и родительским SOC или централизованная модель SOC.

 

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

 

1. Подчиненность CIO или CISO

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

2. Подчиненность COO

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

3. Подчиненность CSO

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

4. Объединение с NOC

Объединение SOC с NOC (Network Operations Center, центр сетевого мониторинга, как правило находится в подчинении департамента ИТ) может дать преимущества как в разрезе экономии бюджета (за счет объединения двух структур), так и в части объединения компетенций (например, сетевое оборудование, оснащенное функциями обеспечения сетевой безопасности, может администрироваться как в SOC, так и в NOC).

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

5. Размещение SOC в структуре бизнес-подразделения

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

 

---

Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании»

 

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

 

1. Драйверы выбора структуры SOC

1.1. Выполняемая миссия и защищаемый бизнес оказывают влияние на выбор структуры SOC в части понимания:

- бизнес-потребностей: размер и уровень зрелости компании, целесообразность и объем выделяемых SOC ресурсов, взаимодействие подразделений, выбор приоритетов в деятельности SOC;

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

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

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

 

1.2. Планируемая подотчетность и ответственность SOC

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

 

1.3. Какие услуги будет предоставлять SOC:

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

 

1.4. Операционная эффективность

Во всем мире ощущается нехватка квалифицированных специалистов по ИБ, и консолидация экспертов в едином подразделении SOC-центра позволит не только более эффективно применять их знания и умения, но и даст возможность специалистам повышать свою квалификацию и наиболее результативно трудиться.

 

1.5. Границы ответственности мониторинга и защиты SOC

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

 

2. Организационные модели SOC

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

 

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

2.1. Реагирование «по требованию». Применяется в организациях малого бизнеса, в которых до 1000 пользователей/устройств. При использовании такой модели в компании нет выделенной команды реагирования, ресурсы привлекаются по требованию при наступлении инцидента, а процессы управления инцидентами, как правило, недостаточно четко определены.

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

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

2.4. Централизованный SOC.  Данная модель применяется разнообразными компаниями, от средних до крупных, а также учреждениями федерального уровня, с числом пользователей/устройств от 10000 до 100000. При использовании такой модели ресурсы консолидируются в рамках одного подразделения (SOC-центра), у работников SOC есть четко определенные роли. Данная организационная модель SOC является самой распространенной, к ней применимо большинство советов рассматриваемой публикации.

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

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

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

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

2.9. Провайдер услуг по управлению кибербезопасностью (англ. MSSP, Managed Security Service Provider) или предоставление услуг SOC по подписке (англ. SOC-as-a-service). Такая модель может применяться компаниями различного масштаба с разным числом пользователей.  Её преимущества заключаются в самой аутсорсинговой модели предоставляемых услуг и возможности заказчика быстро подключить услуги и докупить их по мере необходимости.

 

3. Возможные организационные структуры централизованного SOC

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

- Выделенные ресурсы, специализация на управлении киберинцидентами;

- Причастность, вовлеченность, единое целеполагание и выработанная общая идентичность команды по реагированию;

- Централизованный мониторинг и управление всеми киберинцидентами, синхронизация всех ресурсов;

- Эффективная совместная работа и синергия благодаря отсутствию организационных барьеров;

- Экономическая эффективность, снижение затрат;

- Более высокий авторитет и полномочия SOC по сравнению с другими моделями;

- Квалифицированная и замотивированная команда выделенных экспертов;

- Непрерывное увеличение зрелости и эффективности процессов благодаря единой цели и сплоченной команде;

- Однозначно определенные зона ответственности и миссия.

 

Далее приводится описание некоторых возможных организационных структур SOC.

3.1. Условный (типовой) централизованный SOC

В примере типового централизованного SOC выделены:

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

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

- Группа управления данными о киберугрозах (англ. CTI, Cyber Threat Intelligence, управление данными о киберугрозах), поиска и анализа киберугроз, аналитики и выполнения расширенных функций SOC, отвечающая за управление данными о киберугрозах (сбор, обработка, обогащение, анализ, распространение и предоставление доступа к данным о киберугрозах, релевантных для компании, в тесном взаимодействии с другими группами SOC), поиск киберугроз, настройку сенсоров и аналитических платформ, кастомизацию средств анализа и выявления кибератак. Дополнительно данной группой могут выполняться такие задачи, как работа по направлениям Data Science и машинное обучение, эмуляция кибератак и аудиты, защита от внутренних нарушителей, deception-активности (обман и запутывание нарушителей для сокрытия активов компании и изучения TTPs атакующих). Работа данной группы позволяет SOC сфокусироваться на актуальных для компании киберугрозах и релевантных группах атакующих, а также предоставляет необходимую информацию членам SOC, разрабатывающим корреляционные правила, сигнатуры, плейбуки реагирования. Результатом взаимодействия данной группы с другими командами SOC станет синхронизация и синергия результатов поиска киберугроз, правил детектирования, триажа и расследования киберинцидентов.

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

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

 

3.2. Небольшой централизованный SOC

В случае небольших SOC-центров, в которых от 5 до 20 сотрудников, могут на регулярной основе не выполняться некоторые функции, такие как форензика и анализ ВПО, выезд к заказчику, поиск киберугроз, работа с Data Science, разработка собственных технических инструментов. Кроме того, авторы документа рекомендуют объединять некоторые функции в одной группе в небольших SOC. Так, группу CTI можно объединить с основной группой реагирования на инциденты, в группе инженерной поддержки может не быть разделения на специализации (технические средства или инфраструктура SOC), а руководители SOC могут участвовать в расследовании сложных инцидентов, проводить форензику и исследование ВПО. Также SOC может выполнять функции управления уязвимостями; в этом случае можно выделить отдельную группу, отвечающую за инвентаризацию информационных активов, сканирование на уязвимости, анализ отчетов об уязвимостях, управление обновлениями безопасности и мерами снижения рисков эксплуатации уязвимостей.

 

3.3. Большой централизованный SOC

В больших SOC-центрах будет больше функциональных возможностей и высокоуровневых позиций, функциональные группы будут более специализированы, большее количество действий по реагированию смогут быть шаблонизированы и регламентированы. Так, в группе реагирования на инциденты может быть выделена отдельная команда для триажа инцидентов, появится возможность осуществлять выезды на площадку к заказчику, проводить форензик-исследования и анализ ВПО на регулярной основе при помощи специализированных инструментов. Группы поиска киберугроз, управления данными о киберугрозах, борьбы с внутренними нарушителями могут быть самостоятельными сильными подразделениями. Может быть выделена команда пен-тестеров, специализирующаяся на инфраструктуре заказчика и тесно взаимодействующая с функцией управления уязвимостями. Может быть усилена внутренняя разработка кастомизированных инструментов, применение Data Science и машинного обучения может быть более обширным. Инженерные команды могут получить различные направления по специализациям и потребностям SOC, а взаимодействие между различными подразделениями SOC, с партнерами и стейкхолдерами потребует особого внимания.

 

3.4. Выбор между уровневой и безуровневой моделью SOC

В большинстве давно функционирующих SOC-центров есть классическое разделение по уровням (англ. Tier) функционирования, так называемые уровни L1/L2/L3 (на L1 происходит обработка входящего потока инцидентов, на L2/L3 - их подробный разбор, исследование, форензика при необходимости). При этом разделять SOC на уровни совсем не обязательно, а безуровневая модель SOC может быть основана на специализациях и функциях команд. Авторы публикации указывают, что выбор модели SOC в части уровней зависит от конкретного заказчика, но приводят рекомендации для эффективной организации работы обеих моделей.

 

Для SOC с моделью распределения по уровням рекомендуется:

- Не только определить целевые метрики, но и убедиться в том, что они понятны аналитикам и регулярно обновляются, а аналитики с ними согласны;

- Другим работникам SOC не следует смотреть на операторов L1 «сверху вниз», следует уважать труд всех работников SOC вне зависимости от уровня;

- Продвигать успешных операторов L1 на более высокие позиции, давать им возможность автоматизировать выполняемые ими действия;

- Не требовать от операторов L1 обязательного перехода на более высокие уровни и должности по прошествии определенного времени;

- Не следует привязывать размер компенсации к должности или роли, следует ориентироваться прежде всего на успехи конкретного работника.

 

Для SOC с безуровневой моделью рекомендуется:

- Позволять работникам SOC расти без ущерба для качества реагирования, для этого более опытные коллеги могут помогать новичкам, также можно использовать сценарии реагирования;

- Помогать работникам в приоритизации их действий, давать четкие указания на приоритетные действия;

- Управляйть распределением должностных обязанностей и устранять дублирующиеся функции;

- Строить культуру работы на основе сотрудничества и взаимовыручки.

 

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

- Реагировать на все предупреждения, проводить их триаж;

- Своевременно реагировать на предупреждения, при этом не допуская снижения качества в угоду соблюдению временных нормативов;

- Тщательно обрабатывать все предупреждения с учетом того, что некоторые из них могут потребовать много времени на анализ;

- Давать каждому работнику SOC задачи в соответствии с его уровнем знаний и навыков;

- Предоставлять сотрудникам возможность роста;

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

 

3.5. Иерархическая структура SOC-центров

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

 

3.6. Координирующий SOC

Координирующий SOC на своем уровне может предоставлять подчиненным SOC-центрам определенные уникальные возможности:

- Стратегический анализ TTPs атакующих, релевантных для инфраструктуры заказчика и его дочерних компаний;

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

- Анализ ВПО, форензик-исследования, экстренное реагирование на опасные киберинциденты;

- Агрегация и обмен знаниями, лучшими практиками, описаниями процессов ИБ, техническими руководствами и рекомендациями;

- Предоставление площадок и средств для защищенного взаимодействия и совместной работы подчиненных SOC-центров;

- Централизованное управление и предоставление лицензий на технические средства SOC-центро;

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

 

4. Выбор функций и услуг SOC

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

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

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

 

При принятии решения об объеме планируемых к предоставлению услуг SOC-центра авторы публикации рекомендуют учесть следующие положения:

1. Мониторинг и категорирование в режиме реального времени

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

2. Мониторинг и категорирование в режиме реального времени, анализ и расследование инцидентов

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

3. Анализ ВПО, форензик-анализ артефактов

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

4.Реагирование на инциденты с выездом на площадку заказчика

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

5. Настройка сенсоров и аналитики

В случае, если в ведении SOC находится парк оборудования и СЗИ для мониторинга (например, системы класса EDR, SIEM, UEBA, SOAR), то их настройка должна быть непрерывно поддерживаемой внутренней активностью, учитывающей обратную связь от аналитиков; следовательно, данная функция считается необходимой для SOC-центров, осуществляющих функции мониторинга. Важно отметить, что настройка сенсоров и правил является непрерывным процессом, необходимым для корректной работы парка технологий SOC, поэтому он должен осуществляться в рамках операционной деятельности SOC.

6. Анализ уязвимостей, симуляция атак и проведение аудитов

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

7. Устранение уязвимостей

Установка обновлений и обработка уязвимостей иным способом при росте SOC как правило передается в ИТ или в другое выделенное подразделение.

8. Оценка уязвимостей и сканирование на наличие уязвимостей

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

9. Разработка и управление функциями сетевой защиты

Сетевые СЗИ (IDS, IPS) и межсетевые экраны могут являться частью функционала многих устройств и инсталляций систем. В результате управление сетевыми СЗИ может быть передано в ИТ, при этом SOC остается получателем событий ИБ от сетевых СЗИ, а также участвует в настройке устройств и сигнатур.

 

При повышении зрелости SOC расширяется и количество возможностей, которые также в определенной мере зависят друг от друга:

1. Сбор и обработка данных о киберугрозах, настройка сенсоров и аналитики, с ростом до проактивного поиска киберугроз и создания кастомизированных сигнатур

Непрерывная работа с различными источниками данных о киберугрозах учит аналитиков более избирательному их применению, способствуют разработке новых методов защиты и выявления атакующих до их проникновения в инфраструктуру ("left of hack"). Понимание TTPs атакующих и инфраструктуры компании, а также приобретаемые аналитические навыки органично способствуют созданию кастомизированных сигнатур и методик выявления киберугроз.

2. Анализ инцидентов, анализ ВПО, создание кастомизированных сигнатур и аналитики, с ростом до создания и распространения собственных данных о киберугрозах

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

3. Анализ инцидентов и анализ форензик-артефактов, с ростом до анализа ВПО и внедренных вредоносных программных закладок-имплантов

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

4. Настройка и установка инструментария SOC, с ростом до разработки собственного инструментария

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

 

5. Следует ли создавать свой SOC?

Создание собственного SOC не может и не должно быть необходимым условием для обеспечения мониторинга и реагирования на киберинциденты - выбор способа реализации и способа получения данных процессов зависит от различных факторов (чаще всего от размеров компании, её зависимости от информационной инфраструктуры и финансовых возможностей). Некоторым компаниям подойдет и модель аутсорсинга, а кто-то наверняка предпочтет in-house реализацию. Можно выбрать и гибридную схему, при которой часть функций реализуется во внутреннем SOC (например, базовый мониторинг и реагирование), а на аутсорс отдаются выделенные задачи (например, тестирование на проникновение, анализ ВПО.)

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

- Имеет выделенную ИТ-функцию и признает ключевую значимость ИТ для бизнеса;

- Имеет в распоряжении тысячи устройств (IT, OT, сетевые устройства), в инфраструктуре работают тысячи учетных записей;

- Инвестирует в кибербезопасность, управляет рисками, назначает выделенного ответственного за ИБ, выстраивает процессы управления уязвимостями, соответствием законодательству, инженерными сервисами;

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

- Имеет возможности и желания по выделению ресурсов на поиск и удержание выделенных работников SOC, на инвестиции в технологии SOC, рассматривает вложения в повышение зрелости кибербезопасности как обоснованную инвестицию.

 

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

- Не имеет ресурсного обеспечения и компетенций в ИТ;

- Имеет в распоряжении менее тысячи устройств (IT, OT, сетевые устройства), в инфраструктуре одновременно работает менее тысячи уникальных учетных записей;

- Не инвестирует в кибербезопасность, не выстраивает процесс управления рисками, не обеспечивает ситуационную осведомленность внутри компании;

- Не обладает бюджетом для выделения более двух работников на обеспечение кибербезопасности;

- Не имеет возможности, потребности или желания работать с инструментами мониторинга, аналитики, сканирования, включая облачные и on-prem технологии;

- Осознает, что все ИБ-потребности будут закрыты MSS-провайдером или, в случае принадлежности к холдинговой или другой крупной структуре - SOC-центром родительской организации;

- Положительно оценивает возможность сторонней организации реагировать на инциденты с активами компании без рисков ошибок или высоких затрат на интеграцию;

- Не требует непрерывного участия ИБ-команды в работе компании;

- Ожидает оперативного получения услуг по мониторингу и реагированию, не заинтересована в развитии функции SOC внутри компании.

 

5.3. Факторы успеха при аутсорсинге

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

- Дефицит квалифицированных ИБ-специалистов;

- Компания не может позволить платить рыночные зарплаты работникам SOC в соответствующем географическом регионе;

- Компания недостаточно крупна для построения своего SOC;

- Невозможность заполнить необходимые штатные единицы в виду редкой востребованности (например, анализ ВПО) или запросов (круглосуточное дежурство, ночные смены);

- Ожидание всплесков потребности в сотрудниках, например, в случае крупных инцидентов;

- Необходимость быстро нарастить штат SOC, без ожидания естественного, постепенного роста в течение длительного времени;

- Одновременный уход большого числа работников SOC и необходимость оперативного временного закрытия образовавшихся пробелов.

 

5.4. Расширение штата SOC с помощью аутсорсеров

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

 

5.5. Выбор функций SOC, передающихся на аутсорс

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

- Триаж предупреждений вне стандартного рабочего времени

Данная функция обычно возлагается на SOC-операторов уровня L1, которые работают в режиме 24/7. При аутсорсинге данной функции следует учесть, что компании придется предоставить аутсорсерам доступ к некоторым своим инструментам, а также заранее определить, какие действия будут производиться в рамках триажа предупреждений. Также следует учесть, что зачастую операторы уровня L1 «вырастают» внутри SOC до более ответственных позиций, а если уровня L1 нет, то потребуется набирать уже подготовленных специалистов извне.

- Анализ ВПО и форензик-анализ накопителей

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

- Поддержка при реагировании в критических ситуациях

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

- Тестирование на проникновение и Red Teaming (анализ защищенности с помощью эмуляции действий атакующих)

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

 

5.6. Использование инструментов «под ключ» как форма аутсорсинга

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

 

5.7. Модель полного аутсорсинга

В случае небольшой инфраструктуры (менее 10000 устройств/пользователей) содержание собственного SOC может быть нецелесообразным, но мониторинг и реагирование на инциденты ИБ всё равно требуется осуществлять - в этом случае компания может обратиться к MSSP (Managed Security Service Provider, провайдер услуг управляемой кибербезопасности) для полной передачи ему всех функций SOC. Критериями выбора MSS-провайдера могут быть:

- Бизнес-модель и ценовая политика;

- Какие технологии будут использоваться;

- Как MSS-провайдер будет понимать, что именно он защищает (активы, инфраструктуру, бизнес-процессы заказчика);

- Как будет выстроено взаимодействие между MSS-провайдером и заказчиком (например, в форме регулярной отчетности);

- При каких условиях и как инциденты будут эскалироваться на уровень заказчика вне регулярных коммуникаций;

- SLA-метрики реагирования;

- Уровень загруженности аналитиков MSSP;

- Выполнение каких законодательных норм может обеспечить MSS-провайдер;

- Каким образом MSS-провайдеры обучают, удерживают, поддерживают своих сотрудников, велика ли у них кадровая текучка;

- Каким образом обрабатывается и защищается информация, получаемая от заказчиков; как выстроена работа с используемыми инструментами и облачными провайдерами.

 

6. Необходимость работы SOC в режиме 24/7

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

- Какова вероятность активности атакующих вне стандартного рабочего времени?

- Каков размер компании, используются ли её ресурсы вне стандартного рабочего графика, есть ли у работников круглосуточный доступ к ресурсам компании?

- Есть ли в компании критичные круглосуточные бизнес-процессы, зависящие от ИТ-инфраструктуры?

- Бывали ли случай выявления киберинцидентов, которые могли бы быть предотвращены, если бы SOC работал круглосуточно?

- Если кибератаку заметил аналитик SOC вне стандартного рабочего времени, можно ли оперативно привлечь ресурсы для реагирования до наступления следующего рабочего дня?

- Какова штатная численность SOC, есть ли возможности по расширению команды SOC для введения круглосуточного режима работы?

- Можно ли попасть в офис компании вне стандартного рабочего времени, можно ли сделать для SOC исключение?

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

- Допустима ли задержка при обработке накопленных событий ИБ, которые произошли не в рабочее время (особенно с утра в понедельник, в случае не круглосуточной работы)?

Если SOC не имеет возможности работать в круглосуточном режиме, то можно рассмотреть гибридные варианты, например, когда только часть команды SOC работает круглосуточно (операторы L1), когда SOC работает в режиме 12/5 (охватывая самые активные часы работы компании), когда ограниченное количество работников SOC выходит на дежурство в выходные дни, когда у SOC есть несколько географически распределенных локаций и можно распределить нагрузку на них с учетом разницы во времени (модель "Follow the Sun", буквально «следуй за солнцем»), также можно рассмотреть вариант передачи обязанностей по мониторингу и реагированию вне рабочего времени на родительский SOC или MSS-провайдеру.

Если же принято решение о круглосуточной работе SOC, то следует учесть, что на дежурстве в любое время должны быть как минимум двое работников SOC, каждая круглосуточная должность эквивалентна примерно пяти FTE (Full-Time Equivalent, эквивалент полной занятости) с учетом отпусков и больничных, а аналитики на ночных сменах могут ощущать себя недооцененными и незаметными для остальной команды (поэтому рекомендуется ротировать ночные и дневные смены).

 

7. Выбор местоположения для SOC центра

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

- Следует предоставить SOC-центру физическую локацию и инфраструктуру для работы (помещения, серверные комнаты, СКС, сетевую связность с сегментами сети компании и интернет): лучше всего для этого могут подойти помещения внутри офиса компании или дата-центра;

- Необходимо обеспечить обмен информацией и согласованность действий между подразделениями SOC;

- Следует разграничить зоны ответственности между SOC и ИТ/ИБ-подразделениями компании; физическое присутствие SOC в офисе компании поможет сгладить возможные трения;

- Коллективу и руководителям SOC следует тесно общаться с руководством компании и подразделениями компании;

- Аналитикам SOC следует предоставлять информацию о бизнес-процессах компании и контексте бизнес-операций для более эффективного выявления и реагирования на киберугрозы; физическое присутствие аналитиков в офисе компании поможет более тесно взаимодействовать с работниками компании и производить физические действия с элементами ИТ-инфраструктуры в рамках реагирования;

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

- Следует синхронизировать график работы большинства работников SOC с графиком работы компании;

- Рекомендуется предусмотреть географически распределенную структуру SOC для обеспечения непрерывности работы (COOP, англ. Continuity of Operations); инфраструктуру и операции SOC-центра следует включить в процессы обеспечения непрерывности деятельности и восстановления работоспособности.