Integrating SOAR Tools into the SOC Ecosystem to Automate the IS Incident Response Process

Security Orchestration, Automation and Response (далее ‒ SOAR) ‒ платформа, обеспечивающая сбор данных о событиях, инцидентах информационной безопасности (далее ‒ ИБ) из нескольких источников, координацию (оркестрацию) и автоматизацию реагирования на выявленные инциденты ИБ [2]. Таким образом, платформа SOAR позволяет сводить воедино данные об угрозах безопасности из разных источников, выявлять риски, давать им оценку и автоматически обеспечивать на основе собранных сведений адекватный и своевременный ответ, защищая инфраструктуру на самой ранней стадии появления аномальной активности.

По данным Gartner, исследовательской и консалтинговой компании, к концу 2022 года 30% организаций с группой безопасности численностью более пяти человек будут использовать инструменты SOAR-платформ в своих операциях по обеспечению безопасности, по сравнению с менее чем 5% сегодня [3].

Исходя из названия, SOAR-платформы осуществляют 4 процесса.

Агрегация – сбор событий, инцидентов ИБ со всех источников: Security information and event management (далее ‒ SIEM), средств защиты информации (далее ‒ СЗИ), VirtualMachine (VM) tools, threat intelligence- (TI-) services/ Threat Intelligence Platform (далее ‒ TIP), IT Service Management (далее ‒ ITSM), e-mail;

Оркестрация – интеграция с различными ИТ- и ИБ-системами для выполнения отдельных задач в рамках соответствующего заданного алгоритма, подхода (workflow) реагирования на каждый тип инцидента ИБ;

Автоматизация ‒ автоматизация отдельных задач реагирования на каждый тип инцидента ИБ в рамках соответствующего workflow;

Реагирование ‒ определение workflow и задач реагирования на каждый тип инцидента ИБ с контролем SLA/OLA (далее ‒ Service Level Agreement/Operational-level agreement) [4].

Gartner в 2017 году определила, что SOAR-платформа ‒ совокупность следующих платформ [5]:

– SAO (Security Automation and Orchestration) ‒ платформа оркестрации и автоматизации операционных задач информационной безопасности; [6]

– IRP (Incident Response Platform) ‒ платформа управления жизненным циклом инцидентов информационной безопасности;

– TIP – платформа управления данными киберразведки.

Таким образом, можно выделить следующие основные задачи, которые возможно реализовывать их с помощью SOAR-платформ:

Реагирование на инциденты из SIEM/СЗИ/ITSM ‒ обработка инцидента по заданному workflow, автоматизация первичной обработки, обогащение инцидента ИБ, проверка на вредоносность с помощью Threat Services, автоматизация задач реагирования в инфраструктуре, отчетность;

Ретроспективный анализ событий ИБ ‒ проверка событий ИБ в инфраструктуре на наличие полученных индикаторов компрометации (далее ‒ IoC, Indicators of Compromise) от Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере (далее ‒ ФинЦЕРТ)/Национального координационного центра по компьютерным инцидентам (далее ‒ НКЦКИ)/TI-services/TIP;

Обработка уязвимостей ‒ приоритизация уязвимостей, обогащение, автоматизация задач устранения уязвимостей [7].

Рисунок 1 систематизирует и отражает место SOAR-платформы в экосистеме операционного центра безопасности (далее ‒ SOC, Security Operations Center) при решении задач управления инцидентами ИБ. В самой SOAR-платформе есть набор playbooks, сконфигурированный по личным предпочтениям, который представляет собой сущность, формализующую workflow обработки инцидента, скрипты автоматизации и отчетность. Эти инструменты позволяют автоматизировать рутинные задачи в рамках workflow [8].

Рисунок 1 - Место SOAR-платформы в экосистеме ИБ

Примечание: УЗ – учетные записи

DOI:10.23670/IRJ.2022.124.8.1

Стрелка «инциденты»: Важной особенность SOAR-платформы является оркестрация. Для реагирования на инциденты и автоматизированного выполнения задач необходима интеграция с различными средствами и технологиями инфраструктуры. Так, для получения инцидентов возможна интеграция с SIEM/СЗИ и ITSM.

Стрелка «обогащение», «ретроспектива по IoC»: Запуск playbooks (сценарии по обработке инцидентов) влечет за собой первичную обработку по playbooks (классификация и приоритизация инцидентов). На данном этапе возможно обогащение событий ИБ из SIEM/СЗИ и ИТ-инфраструктуры в зависимости от типа инцидентов, а также проверка выявленных IoC во внешних базах угроз.

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

Стрелка «синхронизация», «задачи»: Далее выбирается стратегия реагирования. Стоит учесть, что все задачи можно загрузить в SOAR-платформу и за счет скриптов автоматизации автоматизировать либо выполнение самих этих задач на СЗИ, ИТ-инфраструктуре, либо создать эти задачи в ITSM-системе и получать некую синхронизацию по статусам.

Стрелка «отчетность»: По итогам устранения инцидентов аналитикам предоставляется отчетность по проделанным действиям и характеристикам инцидентов. Дополнительно SOAR-платформа предоставляет возможность настройки интеграцию с внешними регуляторами (ФинЦЕРТ/НКЦКИ) для предоставления отчетности об инцидентах.

Процесс выстраивания одного общего базового workflow для всех типов инцидентов состоит из следующих компонентов:

Регистрация:

1. Классификация инцидента;

2. Определение критичности инцидента;

3. Обогащение (сбор необходимой информации);

4. Заведение карточки инцидента;

5. Назначение ответственного.

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

В зависимости от определенного типа инцидента и его критичности инцидент обогащается (заполняются все необходимые поля для данной карточки инцидента с использованием скриптов интеграции под каждый тип инцидента). Для этого могут использоваться обращения в SIEM, СЗИ, Active Directory, CMDB (база данных управления конфигурацией) и др.

Если в рамках обогащения были выявлены IoC, то SOAR-платформа автоматизирует задачу проверки IoC на вредоносность, отправляя выявленные IoC во внешние базы угроз, с которыми настроена интеграция. Если проверка дала положительный результат, ‒ IoC был выявлен базе угроз ‒ дополнительно запускается поиск аналогичных инцидентов в ИТ-инфраструктуре.

Далее SOAR-платформа отправляет все данные по инциденту и назначает ответственное лицо за этот инцидент с соответствующим уведомлением.

Рисунок 2 отражает детализацию этапа «регистрация».

Рисунок 2 - Детализация этапа «регистрация»

DOI:10.23670/IRJ.2022.124.8.2

Анализ:

1. Оповещение об инциденте ИБ;

2. Запрос на легитимность.

К этапу «анализ инцидента» аналитик получает полную информацию об инциденте. Далее аналитик фокусируется на базовом анализе, проверяя, является ли событие ИБ ложным срабатыванием. Здесь возможны следующие варианты:

– аналитик классифицирует событие ИБ как «ложное срабатывание» и переходит на этап «пост-инцидент анализ»;

– аналитик классифицирует событие ИБ как «легитимная активность» и переходит на этап «пост-инцидент анализ»;

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

Рисунок 3 отражает детализацию этапа «анализ».

Рисунок 3 - Детализация этапа «анализ»

DOI:10.23670/IRJ.2022.124.8.3

Реагирование:

1. Реализация мер реагирования;

2. Постановка задач в ITSM-систему.

Как только инцидент переходит на этап «реагирование на инцидент», формируется список задач (большой список/список, специально предназначенный под тип инцидента). Либо аналитик выбирает эти задачи по реагированию (автоматизация с участием человека) и подтверждает их реализацию, либо SOAR-платформа выполняет действия, внедрив их в ITSM и синхронизовав связь выполнения задач, настроенные на данный тип инцидента (полная автоматизация). Как только задачи были выполнены, осуществляется проверка реализации устранения инцидента. Если удалось ‒ SOAR-платформа оповещает об этом всех необходимых лиц и осуществляется переход на этап «пост-инцидент анализ».

В случае, если проверка показала, что инцидент не устранен, может запуститься playbook по расследованию. К моменту, когда аналитик начинает анализировать инцидент и способ реакции, SOAR-платформа может выгрузить все логи для разбора. Далее ‒ аналогичные этапы по реагированию: полностью автоматизированные или автоматизированные с участием человека. Окончательными действиями будет дополнительная проверка на устранение инцидента и оповещение об устранении инцидента, после чего происходит переход на этап «пост-инцидент анализ».

Рисунок 4 отражает детализацию этапа «реагирование».

Рисунок 4 - Детализация этапа «реагирование»

DOI:10.23670/IRJ.2022.124.8.4

Пост-инцидент анализ:

1. Формирование отчетов.

Процесс выстраивания кастомного workflow под определенный тип инцидента на практике заключается в следующем:

Имеющийся файрвол веб-приложений (далее ‒ WAF, Web Application Firewall) фиксирует попытку web-атаки на внешнем web-сервисе, являющимся критичным для бизнеса. Таким образом, запускается playbook по обработке данного инцидента.

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

Вторым этапом осуществляется обогащение инцидента ‒ сбор данных по веб-сервису, поиск событий по IP внешнему, фиксирование артефактов. SOAR-платформа находит ранее зафиксированное событие (выявленный артефакт): попытка неуспешной авторизации на веб сервисе из-под УЗ сотрудника.

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

Вся информация об инциденте, а именно анализ сформированной карточки, классификация как инцидент и подтверждение реализации базовых мер, передается аналитику. В рамках обогащения инцидента было выявлено, что инцидент связан с потенциальной компрометацией УЗ сотрудника. Исходя из всего этого, аналитик формирует набор мер ‒ добавление IP-адреса в black list, блокировка УЗ сотрудника, оповещение о необходимости смены пароля.

Последний этап ‒ подготовка всей отчетности по результатам устранения инцидента (заполнение карточки инцидента).

Рисунок 5 систематизирует и отражает процесс выстраивания кастомного workflow.

Рисунок 5 - Кастомный workflow

DOI:10.23670/IRJ.2022.124.8.5

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

– NTA (или NFT) (Network traffic analysis/Network forensics tool) - Средства анализа сетевого трафика и/или расследования сетевых инцидентов;

– EDR (Endpoint Detection & Response) - решения для обнаружения и изучения вредоносной активности на конечных точках;

– UEBA (User and Entity Behavior Analytics) - технологии анализа поведения пользователей и организаций;

– SOAR-платформы.

Построению моделей зрелости SOC и SIEM посвящено значительное количество литературы [9] при этом, как сказано выше, использование SOAR в них остается за пределами анализа.

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

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

Рисунок 6 - Платформы SOC высшего уровня зрелости

DOI:10.23670/IRJ.2022.124.8.7

Таким образом, SOAR-платформа является неотъемлемой частью полноценного SOC.

Из нормативно-правовых актов РФ можно выделить следующие требования к системе управления инцидентами ИБ:

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

- Интеграция со смежными системами и СЗИ;

- Управление жизненным циклом ИТ-активов и их взаимосвязями;

- Управление жизненным циклом уязвимостей на контролируемых объектах ИТ-инфраструктуры;

- Хранение и контроль срока действия документов, регламентирующих деятельность по ИБ;

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

- Формирование различной отчётности;

- Централизованное управление параметрами работы компонентов системы, включая их обновление.

Неправильный выбор SOAR-платформы может повлечь за собой следующие риски:

1. Нанесение ущерба компании за счет неэффективного реагирования на инциденты ИБ. Факторы риска:

1) простои в работе критичных для бизнеса систем и сервисов;

2) утечки конфиденциальной и другой критичной для бизнеса информации;

3) уничтожение / утрата критичных для бизнеса данных и систем;

4) нанесение вреда деловой репутации компании.

2. Причина низкой эффективности существующего процесса реагирования на инциденты ИБ:

1) отсутствие актуальной информации об ИТ-активах (данные разрознены по нескольким системам);

2) отсутствие автоматизированного контроля жизненного цикла управления инцидентами ИБ и уязвимостями;

3) отсутствие средств автоматизации реагирования на инциденты;

4) отсутствие полноценной и оперативной отчетности для принятия эффективных управленческих решений.

В связи с этим был проведен сравнительный анализ следующих решений SOAR-платформ: R-Vision IRP/ SOAR (Россия), Security Vision (Россия), КСУИБ (ICL) (Россия), Forti SOAR (США), IBM Resilient (США), отраженный в Табл. 2. Хотя в научной литературе указывается на возможность создания SOAR систем c использованием продуктов Open-Source [10], подобный подход требует высокого уровня зрелости компании в области ИТ и сопряжен со значительным количеством трудностей. Поэтому данный подход в анализе не рассматривался.

Для дальнейшего сравнения необходимо использовать персонализированные весовые критерии выбора решения в соответствии с инфраструктурой компании:

- Критерии соответствия регуляторным требованиям;

- Критерии соответствия архитектурным требованиям;

- Критерии соответствия требованиям по ИБ;

- Критерии соответствия требованиям по контролю и мониторингу;

- Критерии соответствия требованиям по управлению инцидентами;

- Критерии соответствия требованиям по управлению активами;

- Критерии соответствия требованиям по управлению уязвимостями;

- Критерии соответствия требованиям по визуализации и отчетности.

Совместная работа SIEM-системы и SOAR-платформы будет выглядеть следующим образом [11]:

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

2. Аналитик L1 оценивает эти предупреждения, чтобы определить, какие из них являются реальными инцидентами, а какие – ложными. Эти действия могут занять несколько часов, прежде чем аналитик сможет перейти к глубокому интеллектуальному реагированию на инциденты.

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

4. После получения предупреждения от SIEM-системы SOAR-платформа автоматизирует процесс обогащения и оценку предупреждения, создавая инциденты и удаляя ложные срабатывания. Затем SOAR-платформа создает и назначает заявку в системе отслеживания инцидентов. Таким образом SOAR-платформа автоматизирует деятельность L1.

5. Аналитик L2 получает первоначальное предупреждение вместе с другой информацией из внутренних и внешних источников. SOAR-платформа могут автоматизировать начальные шаги с помощью Digital Playbooks ‒ шагов, которые необходимо заполнить для устранения инцидента. Таким образом, SOAR-платформа экономит драгоценное время отклика и служит ускорителем кибербезопасности.

Важно понимать, что SOAR-платформы выводят возможности реагирования SIEM-систем на новый уровень. Решения SOAR-платформ дополняют, а не заменяют SIEM-системы. Можно определить следующие ключевые отличия [12]:

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

- SIEM-системы и SOAR-платформы могут собирать журналы напрямую;

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

- SOAR-платформы поддерживает сторонние источники, такие как службы анализа угроз и другие внешние источники;

- SOAR-платформы могут интегрироваться с другими продуктами безопасности и сетями. SIEM-системы для этого не предназначены.

Исходя из вышесказанного, можно выделить следующую пользу от внедрения SOAR-платформы в ИТ-инфраструктуру:

– Снижение времени реагирования на инцидент ИБ за счет автоматизации рутинных задач и задач реагирования;

– Фокус персонала на анализ инцидента ИБ за счет автоматизации первичной обработки и реагирования;

– Повышение зрелости процессов за счет их прозрачности и измеряемости (SLA/KPI (Key Performance Indicator ‒ ключевые показатели эффективности));

– Автоматизация отчетности по инцидентам в рамках передачи в ФинЦЕРТ/НКЦКИ.