Event-Driven Ansible + MaxPatrol SIEM: автоматическая изоляция хоста без дежурного

В августе мы разбирали первый боевой сценарий с Event-Driven Ansible - расширение LVM по алерту Zabbix. Тогда всё крутилось вокруг инфраструктурной рутины: диск заполнился, плейбук вырос LV, дежурный спит. Сейчас история другая - клиент из финансового сектора, у которого стоит MaxPatrol SIEM, попросил закрыть следующий класс задач: автоматическая изоляция хоста при срабатывании инцидентного правила.

Задача звучит просто, но в ней достаточно нюансов, чтобы провозиться несколько недель.

Зачем вообще автоматика на изоляцию

Классическая ситуация: SIEM детектирует подозрительное поведение - горизонтальное перемещение, аномальный дамп учёток, нетипичные коннекты изнутри наружу. Правило срабатывает, создаётся инцидент. Дальше SOC-аналитик должен его увидеть, оценить, принять решение и выполнить изоляцию вручную. В рабочее время это 15-30 минут при хорошем раскладе. Ночью - может быть час и больше, пока дежурный проснётся и разберётся.

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

Но важный момент: мы не автоматизируем всё подряд. Только правила, которые клиент явно пометил как «изолировать автоматически» - с соответствующим уровнем уверенности и пройденной процедурой согласования с командой безопасности.

Архитектура связки

flowchart LR
    SIEM["MaxPatrol SIEM"] -->|webhook / REST API| EDA["EDA Controller"]
    EDA -->|rulebook match| AWX["AWX Controller"]
    AWX -->|плейбук isolate-host| FW["Firewall / ACL"]
    AWX -->|уведомление| Zabbix["Zabbix"]
    AWX -->|комментарий| SIEM

MaxPatrol SIEM умеет отправлять уведомления во внешние системы через webhook при изменении статуса инцидента. Это стандартная интеграция, хотя документация по ней местами скудная. EDA слушает входящий webhook, разбирает событие по rulebook-условиям и при совпадении запускает job template в AWX. Плейбук изолирует хост - в данном случае через правило на межсетевом экране, которое блокирует весь трафик с хоста, кроме управляющего. После изоляции AWX пишет обратно комментарий в инцидент SIEM и обновляет статус хоста в Zabbix.

Rulebook: условие срабатывания

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

sources:
  - ansible.eda.webhook:
      host: 0.0.0.0
      port: 5002

rules:
  - name: Isolate host on SIEM high-confidence incident
    condition: >
      event.payload.incident.status == "New" and
      event.payload.incident.severity in ["High", "Critical"] and
      event.payload.incident.auto_isolate is defined and
      event.payload.incident.auto_isolate == true and
      event.payload.incident.asset.ip is defined
    throttle:
      once_within: 60 minutes
      group_by_attributes:
        - event.payload.incident.asset.ip
    action:
      run_job_template:
        name: "isolate-host-firewall"
        organization: "Default"
        job_args:
          extra_vars:
            target_ip: "{{ event.payload.incident.asset.ip }}"
            target_fqdn: "{{ event.payload.incident.asset.fqdn | default('') }}"
            incident_id: "{{ event.payload.incident.id }}"
            incident_url: "{{ event.payload.incident.url }}"

Несколько решений, которые здесь принципиальны:

• auto_isolate == true - кастомное поле, которое аналитики SOC проставляют на правилах, прошедших согласование. Без него плейбук не запустится, даже если инцидент Critical.
• throttle: once_within: 60 minutes - один хост может породить лавину событий при активной атаке. Дроссль гарантирует, что изоляция запустится один раз.
• incident_url в extra_vars - ссылку на инцидент передаём в плейбук, чтобы она попала в комментарий обратно в SIEM. Когда аналитик откроет инцидент утром, там уже будет запись о том, что изоляция выполнена автоматически и когда именно.

Где возникли сложности

Поле auto_isolate не всегда приходило в webhook. MaxPatrol SIEM отправляет только заполненные поля, и если поле не проставлено в правиле, в JSON его просто нет. EDA при обращении к несуществующему полю бросает ошибку. Починили через is defined в условии - стандартная практика для EDA, но в документации это не особо акцентировано.

IP-адрес мог быть множественным. Хост с несколькими сетевыми интерфейсами отдаёт массив IP. Плейбук изначально ожидал строку и падал при первом же реальном срабатывании на сервере с двумя интерфейсами. Пришлось добавить логику выбора «основного» интерфейса по заранее согласованной с клиентом подсети управления.

Обратная запись в SIEM. MaxPatrol имеет REST API для добавления комментариев к инцидентам. API задокументирован, но аутентификация работает через токен с ограниченным временем жизни. В первой реализации мы хранили токен в AWX как статическую переменную, и через несколько дней плейбук начал падать на этом шаге. Переписали на получение свежего токена в начале каждого запуска через отдельную задачу.

Плейбук изоляции

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

В конце:

• Комментарий в инцидент MaxPatrol с временной меткой и результатом
• Изменение макроса хоста в Zabbix - статус «изолирован»
• Уведомление в рабочий канал SOC

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

Текущий статус

Схема работает на двух правилах с auto_isolate=true. За время работы было несколько реальных срабатываний - в части случаев после ручной проверки аналитик подтвердил корректность, в одном пришлось снимать изоляцию после разбора. Ложное срабатывание - неприятно, но обработали его быстро именно потому, что в инциденте была полная информация о том, что произошло автоматически и когда.

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