В этой статье я хочу показать насколько SOAR удобнее, проще, понятнее и надежнее скриптов. Для этого будет использоваться продукт n8n, который тоже можно отнести к SOAR, так как с помощью него можно взаимодействовать с продуктами ИБ в том числе.

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

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

‍

Внешний вид. Или построение логики в виде блок-схемы

Сравним максимально простой процесс, который получает из Elasticsearch события за последнюю минуту и отправляет краткую информацию о нем в Telegram:

‍

> Сравнение процесса написанного в виде скрипта на Python и в SOAR (n8n)

‍

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

‍

Из плюсов:

* SOAR позволяет наглядно разбить весь процесс на подпроцессы (блоки), например, получение событий из Elasticsearch и отправка сообщения в Telegram – это 2 отдельных блока.

* Все параметры, связанные с подпроцессом, спрятаны в блоке, что позволяет четко видеть логику всего процесса.

* Все необходимые библиотеки и вся техническая часть нас не волнует, мы вводим только необходимые данные в выделенные поля.

‍

Из минусов:

* Одному блоку в SOAR может равняться как целая функция, так и однострочная команда.

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

‍

Секреты (учетные данные)

SOAR имеет свое хранилище секретов, куда могут входить учетные записи, ключи, сертификаты, токены и тд.

‍

> Пример учетной записи для Elasticsearch

‍

Каждый секрет привязывается к конкретному типу блока (Elasticsearch, Telegram и др.), который, в свою очередь, может также включать URL или IP+порт, версию API, игнор SSL (вкл, выкл) и другие.

‍

Из плюсов:

* SOAR избавляет нас от решения проблем хранения секретов.

* Все процессы обращаются в базу секретов, соответственно изменение пароля в хранилище отражается на всех процессах.

‍

Из минусов:

* Каждый блок жестко привязан к секрету, – использовать один блок для нескольких учетных записей или для нескольких хостов нельзя, придется использовать несколько одинаковых блоков с разными секретами.

* Редкий случай, если один и тот же секрет используется в разных типах блока, например Elasticsearch и Elastic Security – это 2 разных типа блоков, придется этот секрет дублировать.

Логирование. Или постоянный режим дебага

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

‍

< Иллюстрация загромождения основного кода

‍

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

‍

> Вкладка с отработанными процессами

‍

> История передачи информации от блока к блоку

‍

Из плюсов:

* Мы можем увидеть любой запуск процесса в любой момент времени и все данные, которые передавались от блока к блоку, а также ошибки (при их наличии).

‍

Из минусов:

* Стоит отказаться от передачи чувствительных данных от блока к блоку, например, теряется смысл использования блока Vault (хранилище секретов от HashiCorp), так как передача в него секретов будет видна в истории запущенных процессов в открытом виде, что небезопасно.

‍

Выводы

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

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