Мир кибербезопасности полон инструментов информационной безопасности (далее ‒ ИБ). Наиболее новый элемент постоянно прогрессирующих технологий – SOAR-платформа (Security Orchestration, Automation, and Response platform), которая, как обещают производители, сокращает время реагирования на инциденты, улучшает работу функций безопасности и облегчает жизнь командам безопасности [1]. Данная статья посвящена основным проблемам выстраивания процесса реагирования на инциденты информационной безопасности с помощью встраивания SOAR-платформ в экосистему SOC, выбора SOAR-платформы в соответствии с требованиями к системе управления инцидентами ИБ, взаимодействия SOAR-платформы и SIEM-системы, а также определению преимуществ интеграции SOAR-платформы с иными системами ИБ.
1. Введение
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].
2. Методы и принципы исследования
Рисунок 1
систематизирует и отражает место SOAR-платформы в экосистеме операционного центра безопасности (далее ‒ SOC, Security Operations Center) при решении задач управления инцидентами ИБ. В самой SOAR-платформе есть набор playbooks, сконфигурированный по личным предпочтениям, который представляет собой сущность, формализующую workflow обработки инцидента, скрипты автоматизации и отчетность. Эти инструменты позволяют автоматизировать рутинные задачи в рамках workflow [8].
Место SOAR-платформы в экосистеме ИБ
Стрелка «инциденты»: Важной особенность 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
отражает детализацию этапа «регистрация».
Детализация этапа «регистрация»
Анализ:
1. Оповещение об инциденте ИБ;
2. Запрос на легитимность.
К этапу «анализ инцидента» аналитик получает полную информацию об инциденте. Далее аналитик фокусируется на базовом анализе, проверяя, является ли событие ИБ ложным срабатыванием. Здесь возможны следующие варианты:
– аналитик классифицирует событие ИБ как «ложное срабатывание» и переходит на этап «пост-инцидент анализ»;
– аналитик классифицирует событие ИБ как «легитимная активность» и переходит на этап «пост-инцидент анализ»;
– аналитик классифицирует событие ИБ как «инцидент», оповещает об инциденте при помощи скриптов оповещения и переходит на этап «реагирование на инцидент». В случае, если инцидент вызван легитимным действием пользователя в ИТ-инфраструктуре, аналитик отправляет запрос на подтверждение легитимности. Если легитимность не подтверждена, аналитик переходит на этап «пост-инцидент анализ».
Рисунок 3
отражает детализацию этапа «анализ».
Детализация этапа «анализ»
Реагирование:
1. Реализация мер реагирования;
2. Постановка задач в ITSM-систему.
Как только инцидент переходит на этап «реагирование на инцидент», формируется список задач (большой список/список, специально предназначенный под тип инцидента). Либо аналитик выбирает эти задачи по реагированию (автоматизация с участием человека) и подтверждает их реализацию, либо SOAR-платформа выполняет действия, внедрив их в ITSM и синхронизовав связь выполнения задач, настроенные на данный тип инцидента (полная автоматизация). Как только задачи были выполнены, осуществляется проверка реализации устранения инцидента. Если удалось ‒ SOAR-платформа оповещает об этом всех необходимых лиц и осуществляется переход на этап «пост-инцидент анализ».
В случае, если проверка показала, что инцидент не устранен, может запуститься playbook по расследованию. К моменту, когда аналитик начинает анализировать инцидент и способ реакции, SOAR-платформа может выгрузить все логи для разбора. Далее ‒ аналогичные этапы по реагированию: полностью автоматизированные или автоматизированные с участием человека. Окончательными действиями будет дополнительная проверка на устранение инцидента и оповещение об устранении инцидента, после чего происходит переход на этап «пост-инцидент анализ».
Рисунок 4
отражает детализацию этапа «реагирование».
Детализация этапа «реагирование»
Пост-инцидент анализ:
1. Формирование отчетов.
Процесс выстраивания кастомного workflow под определенный тип инцидента на практике заключается в следующем:
Имеющийся файрвол веб-приложений (далее ‒ WAF, Web Application Firewall) фиксирует попытку web-атаки на внешнем web-сервисе, являющимся критичным для бизнеса. Таким образом, запускается playbook по обработке данного инцидента.
Первым этапом формируется содержание карточки (тип инцидента, критичность, детали инцидента из WAF, IoC: IP внешний) при помощи интеграции с WAF.
Вторым этапом осуществляется обогащение инцидента ‒ сбор данных по веб-сервису, поиск событий по IP внешнему, фиксирование артефактов. SOAR-платформа находит ранее зафиксированное событие (выявленный артефакт): попытка неуспешной авторизации на веб сервисе из-под УЗ сотрудника.
В следующем этапе реализуется проверка нахождения этого внешнего IP-адреса в базе угроз. В данном примере данный внешний IP-адрес был замечен во вредоносной активности, что фиксируется в карточку инцидента.
Вся информация об инциденте, а именно анализ сформированной карточки, классификация как инцидент и подтверждение реализации базовых мер, передается аналитику. В рамках обогащения инцидента было выявлено, что инцидент связан с потенциальной компрометацией УЗ сотрудника. Исходя из всего этого, аналитик формирует набор мер ‒ добавление IP-адреса в black list, блокировка УЗ сотрудника, оповещение о необходимости смены пароля.
Последний этап ‒ подготовка всей отчетности по результатам устранения инцидента (заполнение карточки инцидента).
Рисунок 5
систематизирует и отражает процесс выстраивания кастомного workflow.
Кастомный workflow
3. Основные результаты
Создаваемые или развивающиеся в настоящее время 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
Уровень | Инструментарий | Функции |
1 | SIEM | Базовый мониторинг событий |
2 | SIEM+базовый сетевой мониторинг | Мониторинг событий, тюнинг контента |
3 | SIEM+NTA | Базовое обнаружение аномалий, периодические пентесты |
4 | SIEM+NTA+EDR | Анализ ВПО, базовый threat hunting, киберучения red/blue team |
5 | SIEM+NTA+EDR+UEBA+SOAR | Интегрированные мониторинг и реагирование, threat hunting, продвинутая аналитика для обнаружения аномалий, red team |
SOC высшего уровня зрелости, который должен состоять из множества платформ, определенных в зависимости от входа/выхода информации, изображен на Рисунок 6.
Платформы SOC высшего уровня зрелости
Таким образом, SOAR-платформа является неотъемлемой частью полноценного SOC.
4. Обсуждение
Из нормативно-правовых актов РФ можно выделить следующие требования к системе управления инцидентами ИБ:
Централизованный сбор и хранение информации по инцидентам ИБ, автоматизация процесса реагирования на инциденты;
- Интеграция со смежными системами и СЗИ;
- Управление жизненным циклом ИТ-активов и их взаимосвязями;
- Управление жизненным циклом уязвимостей на контролируемых объектах ИТ-инфраструктуры;
- Хранение и контроль срока действия документов, регламентирующих деятельность по ИБ;
- Визуализация информации в различных форматах представления данных, включая отображение различных диаграмм, графиков и интерактивных схем;
- Формирование различной отчётности;
- Централизованное управление параметрами работы компонентов системы, включая их обновление.
Неправильный выбор 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], подобный подход требует высокого уровня зрелости компании в области ИТ и сопряжен со значительным количеством трудностей. Поэтому данный подход в анализе не рассматривался.
Сравнение решений SOAR-платформ
Критерии выбора решения | R-Vision IRP/ SOAR | Security Vision | КСУИБ (ICL) | Forti SOAR | IBM Resilient |
Наличие функционала по управлению инцидентами ИБ | Да | Да | Да | Да | Да |
Наличие интеграции с внешними системами и СЗИ для автоматизации реагирования | Да | Да | Нет | Да | Да |
Наличие функционала по управлению уязвимостями | Да | Да | Нет | Нет | Нет |
Наличие функционала по управлению активами | Да | Да | Нет | Нет | Нет |
Наличие сертификации ФСТЭК или в процессе ее получения | Да | Да | Нет | Нет | Нет |
Присутствие в реестре отечественного ПО | Да | Да | Нет | Нет | Нет |
Поддержка взаимодействия с ФинЦЕРТ | Да | Да | Нет | Нет | Нет |
Для дальнейшего сравнения необходимо использовать персонализированные весовые критерии выбора решения в соответствии с инфраструктурой компании:
- Критерии соответствия регуляторным требованиям;
- Критерии соответствия архитектурным требованиям;
- Критерии соответствия требованиям по ИБ;
- Критерии соответствия требованиям по контролю и мониторингу;
- Критерии соответствия требованиям по управлению инцидентами;
- Критерии соответствия требованиям по управлению активами;
- Критерии соответствия требованиям по управлению уязвимостями;
- Критерии соответствия требованиям по визуализации и отчетности.
Совместная работа 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-системы для этого не предназначены.
5. Заключение
Исходя из вышесказанного, можно выделить следующую пользу от внедрения SOAR-платформы в ИТ-инфраструктуру:
– Снижение времени реагирования на инцидент ИБ за счет автоматизации рутинных задач и задач реагирования;
– Фокус персонала на анализ инцидента ИБ за счет автоматизации первичной обработки и реагирования;
– Повышение зрелости процессов за счет их прозрачности и измеряемости (SLA/KPI (Key Performance Indicator ‒ ключевые показатели эффективности));
– Автоматизация отчетности по инцидентам в рамках передачи в ФинЦЕРТ/НКЦКИ.
The additional file for this article can be found as follows:
Further description of analytic pipeline and patient demographic information. DOI:
None
None