Практический разбор внедрения SOAR в коммерческом SOC: от кастомной интеграции с неподдерживаемой SIEM до автоматизации процессов, обогащения активов и мультитенантного реагирования. Реальные сложности, решения и выводы из живого проекта.
- 1. Введение
- 2. Взаимодействие с неподдерживаемой SIEM и миграция в SOAR
- 3. Кастомный процесс обработки инцидентов ИБ
- 4. Обогащение информаций об активах
- 5. Реагирование на инциденты в режиме мультитенантности
- 6. Выводы
Введение
Обработка инцидентов информационной безопасности требует системного подхода, соблюдения внутренних регламентов и, в ряде случаев, отчётности перед вышестоящей организацией или регуляторами, что подразумевает использование специализированных решений. Компании на невысоком уровне зрелости часто применяют для этого SIEM-системы, так как в большинстве случаев достаточно, чтобы подозрение на инцидент ИБ было зафиксировано, далее этот факт подтвердился или был опровергнут, после чего произошло расследование (иногда и реагирование) и, в идеале, постобработка.
Совсем другое дело, если речь идёт о провайдере SOC (центр мониторинга и реагирования на кибератаки, Security Operation Center). К необходимости внедрения различных инструментов автоматизации приводит:
- совокупность требований к управлению мониторингом и выявлению инцидентов ИБ в инфраструктуре других компаний;
- потенциальное расширение клиентской базы;
- добавление новых услуг;
- минимизация рутинных операций;
- желание соответствовать стандартам рынка.
На определённом уровне развития SOC одним из них становится система класса SOAR (оркестрация, автоматизация и реагирование на угрозы, Security Orchestration, Automation and Response).
При реализации подобного проекта в активно развивающемся провайдере SOC наша команда столкнулась с рядом особенностей, о которых я расскажу в этой статье: сбор подозрений на инциденты ИБ с неподдерживаемой SIEM; перенос процесса управления инцидентами ИБ во внедряемое решение класса SOAR; внедрение процесса управления активами и их связывание с подозрениями на инциденты ИБ; реализация реагирования на инциденты ИБ в режиме мультитенантности.
Взаимодействие с неподдерживаемой SIEM и миграция в SOAR
Решения класса SOAR, представленные на российском рынке, имеют широкий набор интеграций с SIEM «из коробки». Такая интеграция, как правило, занимает непродолжительное время. В большинстве случаев достаточно выполнить несколько несложных операций:
- настройка в SOAR адреса SIEM-системы;
- настройка аутентификационных данных для доступа к подозрениям на инциденты ИБ из SIEM в SOAR;
- маппинг правил корреляции на типы инцидентов ИБ на стороне SOAR.
Рисунок 1. Типовая схема передачи подозрений на инциденты ИБ из SIEM в SOAR
В некоторых случаях интеграции «из коробки» могут иметь двустороннее взаимодействие, но, как правило, это ограничивается отправкой изменения статуса из SOAR в SIEM после обработки подозрения на инцидент ИБ.
Рисунок 2. Схема передачи подозрений на инциденты ИБ из SIEM в SOAR
Схемы интеграции SIEM и SOAR, приведённые выше (см. рисунок 1 и рисунок 2), достаточны для компании, которая собирается перейти на новый класс решений (SOAR) с целью обеспечения процесса управления инцидентами ИБ. SOAR с определённой периодичностью опрашивает SIEM-систему, а дальнейший процесс обработки происходит в SOAR по предустановленным «из коробки» рабочим процессам (для этого, как правило, требуется маппинг правил корреляции из SIEM в SOAR).
В нашем случае такой подход был невозможен, так как у заказчика есть SIEM-система на базе платформы Elasticsearch, которая не поддерживается «из коробки» ни одним решением класса SOAR. В то же время система имеет на борту личный кабинет для клиентов, который необходимо было сохранить после завершения внедрения решения класса SOAR.
Эти задачи заставили нас начать разработку собственной, по-настоящему двусторонней интеграции с учётом одновременной работы в двух решениях.
Рисунок 3. Схема двустороннего взаимодействия SIEM и SOAR
Особенности интеграции SIEM и SOAR в провайдере SOC
Разработка кастомного процесса обработки инцидентов ИБ. В ходе нашего проекта была выполнена интеграция SIEM-системы, ранее не поддерживаемой ни одним решением класса SOAR, а следовательно, потребовалась проработка возможных и оптимальных механизмов передачи подозрений на инциденты ИБ и последующая синхронизация между системами. Инициатором передачи подозрений на инциденты ИБ является SIEM-система, а не SOAR, как это обычно бывает. Благодаря этому нам удалось снизить задержку между созданием подозрения на инцидент ИБ и началом работы с ним, а это один из показателей SLA (соглашение об уровне предоставления услуг, Service Level Agreement) коммерческих SOC.
Синхронизация информации из SOAR и SIEM-систем в режиме реального времени. Стояла задача не просто передать подозрение на инцидент ИБ из одной системы в другую, а выполнить синхронизацию статусов и комментариев при его обработке, исключить дублирование информации при синхронизации данных, учесть матрицу перехода по статусам и другие специфические моменты конкретного процесса управления инцидентами ИБ.
Такая потребность возникла, потому что в SIEM-системе заказчика реализован личный кабинет клиентов услуги MSSP, который на данном этапе внедрения решения класса SOAR было решено оставить. Процесс коммуникации между провайдером и клиентами SOC проходит в основном через электронную почту, но также есть возможность вносить изменения в статус и оставлять комментарии и в личном кабинете. Как результат, возникает лишняя нагрузка на сотрудников провайдера, которые должны отслеживать несколько каналов взаимодействия и вносить изменения статусов и комментарии в ручном режиме.
Бесшовный переезд. Переезд на новую платформу должен был быть незаметным для клиентов коммерческого SOC, так как процесс управления инцидентами ИБ нельзя останавливать ни на минуту. При этом каждая из систем должна сама инициировать передачу изменений в другую, а сотрудник провайдера видеть ответы и новые статусы от клиентов одновременно в двух системах без дублирования информации.
Кастомный процесс обработки инцидентов ИБ
Как упоминалось выше, наш заказчик имеет собственный выстроенный процесс управления инцидентами ИБ, который обеспечивает функционирование услуги по мониторингу и реагированию на инциденты ИБ для его клиентов.
По нашему опыту, наличие собственного процесса управления инцидентами ИБ всегда негативно сказывается на сроках внедрения решений класса SOAR, так как любой заказчик хочет автоматизировать ту часть процесса управления инцидентами ИБ, которая ранее выполнялась вручную. Иногда достаточно просто внести изменения в «коробку», но в нашем случае это было нерационально.
При анализе «коробочного» контента SOAR было выявлено большое количество неиспользуемых или отличающихся у заказчика элементов в процессе управления инцидентами ИБ. Изменение логики работы одного рабочего процесса сильно влияло на другие, что, по сути, привело бы к полному переписыванию всего контента, учитывая все взаимосвязи.
Перенос, а точнее создание процесса управления инцидентами ИБ в решении класса SOAR, позволил отказаться от заложенного вендором подхода по управлению инцидентами ИБ. Хорошо это или плохо — оставим за рамками данной статьи.
Создание кастомного процесса по управлению инцидентами ИБ потребовало дополнительных, вспомогательных рабочих процессов, которые запускаются на определённых этапах, по аналогии с выполнением реагирования. Всего было создано более 20 вспомогательных рабочих процессов. На рисунке ниже (см. рисунок 4) показан общий вид процесса управления инцидентами ИБ.
Замечу, что рабочий процесс имеет «начало», но не имеет «конца». Это не ошибка на рисунке, а реалии, с которыми мы столкнулись. После того как инцидент закрывается, иногда возникает потребность его переоткрыть по той или иной причине. На практике это может привести к большому количеству запущенных параллельно рабочих процессов, объём которых станет «смертельным» для SOAR.
Чтобы снизить нагрузку на SOAR, был реализован вспомогательный рабочий процесс по «архивации» инцидентов ИБ, которые прошли определённые стадии обработки. Благодаря этому решается проблема, когда по той или иной причине (хотя в идеальном мире такого быть не должно) инцидент ИБ «зависает» на статусе «Отправлено клиенту».
Рисунок 4. Процесс управления инцидентами ИБ нашего заказчика
Отдельно хочется сказать пару слов про механизм уведомления об SLA. Был реализован подход, при котором SOAR самостоятельно принимает решение, какой SLA используется, исходя из статуса и критичности подозрения на инцидент ИБ, и за некоторое время до его истечения уведомляет аналитика и его руководителя о необходимости его соблюдения.
Если взглянуть на схему передачи информации о подозрении на инцидент ИБ (см. рисунок 3), становится очевидным, что может быть ситуация, когда в SOAR передана информация о сформированном в SIEM подозрении на инцидент ИБ, но система не может получить перечень всех полей для заполнения карточки инцидента ИБ. Наш рабочий процесс предусматривает эту и другие аналогичные ситуации на стыке взаимодействия с разными системами.
Другими словами, при разработке рабочего процесса важно всегда держать в голове, что при передаче данных между различными системами и при их обработке могут произойти различные непредвиденные состояния, которые нужно уметь обрабатывать. То, что работало на стенде «как часы», в реальной эксплуатации может начать сбоить и приводить к остановкам бизнес-процессов.
Дополнительно все действия, которые выполняет аналитик при обработке подозрения на инциденты ИБ в SOAR, протоколируются и в последующем учитываются в аналитической отчётности, а также могут использоваться для отслеживания действий, которые выполнил аналитик, в случае если к подозрению на инцидент ИБ нужно подключить дополнительного сотрудника или заменить текущего.
Обогащение информаций об активах
Говорить о процессе обработки инцидентов ИБ в отрыве от активов неправильно. В нашем случае актив — это элемент ИТ-инфраструктуры компании, подключённый к сети передачи данных.
Правилом «хорошего тона» является консолидация всей информации о подозрении на инцидент ИБ в карточке инцидента. Как этого добиться? Очевидное решение — подгрузка (связывание) информации об активах, участвующих в подозрении на инцидент ИБ. Следующий вопрос — откуда эта информация может быть получена. В идеальном мире компания с первого дня осуществляет процесс управления активами на той же платформе, на которой работает решение SOAR.
Однако идеальные ситуации скорее исключение из правил, хотя некоторые решения класса SOAR имеют интеграции как с решениями класса Asset Management, так и со смежными системами, где может быть представлен перечень (не всегда полный) информации об активах (например, Kaspersky Security Center или Active Directory).
Заказчик выбрал решение, в котором есть возможность дедупликации данных об активах из разных источников. Информация об активах его клиентов была подгружена, правила обработки этой информации адаптированы к условиям работы провайдера SOC, каждый актив получил маркировку той организации, к которой он относится. Казалось бы, проблема решена, и теперь актив можно легко привязать к карточке инцидента ИБ. К сожалению, это не так.
Чтобы привязать актив к карточке инцидента ИБ, нужно учесть как минимум два параметра, которые говорят о том, что актив уникален: FQDN и наименование клиента. Часто бывает ситуация, при которой узел имеет динамический IP-адрес и новые подозрения на инциденты ИБ могут поступать с разными IP-адресами и одинаковыми FQDN в пределах одного клиента.
Иногда в карточке инцидента ИБ присутствует обрывочная информация, например только IP-адрес или имя узла. Другой распространённый случай, когда средства защиты информации или другой источник событий в поле FQDN пишут имя хоста или вообще IP-адрес. На практике это приводит к сложностям с корректным связыванием активов клиентов и информации из карточки инцидента ИБ.
Чтобы решить описанные выше проблемы, система класса SOAR должна иметь широкий перечень механизмов обработки полей карточки инцидента ИБ и (или) актива. Решение, которое мы внедрили, как раз из их числа и имеет более 30 встроенных механизмов преобразования информации из полей инцидента ИБ и актива. Благодаря этому у заказчика появилась база данных активов клиентов, которая периодически обновляется в автоматизированном режиме. В карточке активов присутствует история изменения. Информация из карточки инцидента ИБ, в случае обрывочности данных, дополняется, обогащается, преобразовывается и связывается с существующими активами.
Если в карточке инцидента ИБ присутствует актив, информация о котором не получена из автоматизированных систем (например, ещё не произошла синхронизация между системами или актив появился в нарушение внутренних процессов клиентов), то он будет создан, и при последующей синхронизации с автоматизированными системами информация по нему будет дополнена. Также с любым активом можно выполнить реагирование. Частным случаем реагирования является запуск процесса инвентаризации актива для получения текущего слепка информации по нему.
Каждый актив, участвующий в подозрении на инцидент ИБ, имеет ссылку на карточку инцидента ИБ. Заказчик сразу видит, на каких активах клиентов было зафиксировано наибольшее количество подозрений на инцидент ИБ, что позволяет быстрее принять решение.
Реагирование на инциденты в режиме мультитенантности
Вендоры SOAR-систем часто говорят, что их решение содержит всё, что требуется большинству компаний. Это утверждение, по большей части, верное, пока речь не заходит про провайдеров SOC.
Коммерческие SOC взаимодействуют с клиентами на основе договора об оказании услуг, в котором регламентируются действия по работе с подозрениями на инциденты ИБ. Ни для кого не будет секретом, что далеко не все клиенты готовы пустить провайдеров в свою ИТ-инфраструктуру и позволить выполнять блокировку на межсетевом экране и (или) доменных учётных записей, но есть и куда более безобидные рутинные операции, которые можно автоматизировать посредством SOAR-системы.
При анализе «коробочного» контента по реагированию мы обнаружили отсутствие адаптации под поставщиков услуг, а при анализе возможности доработки данного контента — что реагирование для разных систем реализовано по-разному. Оценив трудозатраты на приведение требуемого «коробочного» контента к единому виду, способному работать с учётом специфики провайдера SOC, было принято решение полностью переписать рабочие процессы с учётом специфики реагирования для каждого клиента и перечня СЗИ в нём.
Ниже (см. рисунок 5) приведён общий вид универсального процесса реагирования. Запуск реагирования осуществляется на объекте с типом «актив», который формируется и добавляется к карточке инцидента ИБ в процессе обогащения в SOAR (см. рисунок 3). Аналитик осуществляет запуск требуемого типа реагирования и переходит к этапу «Проверка возможности реагирования» — запрос в SOAR аутентификационных данных на выполнение требуемой операции на активе с учётом используемого СЗИ и организации, к которой относится актив.
В случае отсутствия таких данных в карточку актива записывается неуспешная попытка выполнения реагирования. Если аутентификационные данные для данного типа реагирования с учётом организации и СЗИ присутствуют в справочнике, то запускается «Вызов коннектора».
Рисунок 5. Общий вид универсального процесса реагирования
На этапе «Вызов коннектора» происходит запуск реагирования (команды и (или) скрипта) с использованием конфигурации для конкретной организации, СЗИ и сетевого диапазона, в котором расположен актив.
На этапе «Проверка выполнения» происходит обработка результата. Проверяется результат выполнения реагирования: при успешном завершении — нормализация и запись результата в карточку актива, в противном случае — возвращение ошибки (например, отсутствует сетевая доступность или недостаточно прав на выполнение команды) и её запись. Таким образом, при просмотре карточки актива аналитик в истории операций по активу видит, какие действия по реагированию были предприняты с активом, кто их выполнял и результат последнего выполнения.
Адаптация под мультитенантность и удобство тиражирования позволили нам в кратчайшие сроки реализовать более 50 реагирований.
Выводы
В ходе работы по внедрению решения класса SOAR мы столкнулись с рядом особенностей, присущих провайдерам SOC. Вероятность их появления у типового заказчика невелика, но и исключать её нельзя.
В заключение хочется сказать, что внедрение решения класса SOAR является ключевым шагом по развитию компании в области управления инцидентами ИБ. Чтобы сделать этот шаг, нужно перейти на определённый уровень зрелости, который появляется у всех в разный момент. Сделать это можно как самостоятельно, используя свой контент и чувство «что уже пора», так и воспользовавшись контентом вендора или помощью интегратора.
Важно, чтобы после внедрения решения класса SOAR в компании не появилось чувство «законченности». Многие российские вендоры идут по пути разработки продуктов на базе платформы, а это значит, что, как только компания будет готова развиваться далее и внедрять другие классы решений, у неё будет возможность бесшовной или быстрой интеграции с решениями класса SOAR, что при наличии квалифицированных кадров и выстроенных процессов повысит уровень информационной безопасности.
