Налаштування автоматичного реагування на інциденти безпеки

Середній час виявлення breach у індустрії — 207 днів, до containment — ще 73. Згідно з IBM Cost of a Data Breach, середня вартість одного інциденту перевищує $4,45 млн. За нашими оцінками, автоматизація критичних кроків скорочує MTTR до секунд і знижує витрати на 60%. Ми налаштовуємо SOAR-пайплайни, інтеграції з SIEM та cloud-native тригери, щоб інфраструктура реагувала без участі людини. За 5 років виконано 50+ проєктів автоматизації для клієнтів різних індустрій. Інженери сертифіковані за AWS, Kubernetes та CISSP. Зв'яжіться з нами — допоможемо підібрати рішення під вашу інфраструктуру.

Які інциденти варто автоматизувати?

Автоматизація правильно працює для добре вивчених патернів із чіткими критеріями: brute force з конкретного IP → блокування IP; скомпрометований IAM access key → деактивація; malware-хеш → ізоляція хоста; аномальний об'єм трафіку → throttling. Для неоднозначних сигналів створюємо тікет, збагачуємо контекстом та ескалюємо з playbook. Так автоматизація покриває 60–70% типових інцидентів, інші — з ручним підтвердженням.

Як працює SOAR-підхід

Архітектура: SIEM (Wazuh/Elastic Security/Splunk) → webhook або API → SOAR-двигун (Shuffle, TheHive+Cortex, Cortex XSOAR) → actions (AWS API, Slack, Jira, firewall API). Весь pipeline виконується за 3–5 секунд від моменту алерту.

Приклад автоматизації SSH brute force у Shuffle

{
  "name": "SSH Brute Force Response",
  "trigger": {
    "type": "webhook",
    "source": "wazuh",
    "filter": "rule.id == 5720"
  },
  "steps": [
    {
      "name": "enrich_ip",
      "app": "AbuseIPDB",
      "action": "get_ip_report",
      "input": {"ip": "$trigger.data.srcip"}
    },
    {
      "name": "check_whitelist",
      "app": "Internal",
      "action": "check_ip_whitelist",
      "input": {"ip": "$trigger.data.srcip"}
    },
    {
      "name": "block_if_malicious",
      "condition": "$enrich_ip.abuseConfidenceScore > 50 AND NOT $check_whitelist.is_whitelisted",
      "app": "AWS WAF",
      "action": "add_ip_to_blocklist",
      "input": {
        "ip": "$trigger.data.srcip",
        "duration": 86400,
        "reason": "SSH brute force - AbuseIPDB score: $enrich_ip.abuseConfidenceScore"
      }
    },
    {
      "name": "notify_slack",
      "app": "Slack",
      "action": "send_message",
      "input": {
        "channel": "#security-alerts",
        "message": "Blocked $trigger.data.srcip for SSH brute force. AbuseIPDB: $enrich_ip.abuseConfidenceScore/100. Action: $block_if_malicious.status"
      }
    },
    {
      "name": "create_ticket",
      "app": "Jira",
      "action": "create_issue",
      "input": {
        "project": "SEC",
        "summary": "SSH Brute Force from $trigger.data.srcip",
        "priority": "Medium",
        "labels": ["auto-blocked", "brute-force"]
      }
    }
  ]
}

Такий workflow у 10 разів швидший за ручний — MTTR падає з годин до хвилин.

Чому SOAR швидший за ручне реагування?

Ручний процес включає детекцію, аналіз, прийняття рішення та дії — кожен крок займає хвилини. SOAR виконує їх за секунди, паралельно збагачуючи дані із зовнішніх джерел (AbuseIPDB, VirusTotal). Це знижує втомлюваність команди та виключає людські помилки при виконанні рутинних операцій.

Як AWS Lambda допомагає в реагуванні?

Для AWS-інфраструктури нативний SOAR — EventBridge + Lambda. Приклад: GuardDuty виявляє CompromisedInstance (instance спілкується з відомим C2 server).

Приклад Lambda-функції для GuardDuty

import boto3
import json
from datetime import datetime


def respond_to_compromised_instance(event, context):
    ec2 = boto3.client('ec2')
    sns = boto3.client('sns')

    finding = event['detail']
    instance_id = finding['resource']['instanceDetails']['instanceId']
    finding_type = finding['type']
    severity = finding['severity']

    actions_taken = []

    if severity >= 7.0:
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=['sg-isolation-group-id']
        )
        actions_taken.append(f"Isolated instance {instance_id}")

    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'attachment.instance-id', 'Values': [instance_id]}]
    )
    for vol in volumes['Volumes']:
        ec2.create_snapshot(
            VolumeId=vol['VolumeId'],
            Description=f"Forensic snapshot - GuardDuty finding {finding['id']} - {datetime.utcnow().isoformat()}"
        )
        actions_taken.append(f"Snapshot created for {vol['VolumeId']}")

    sns.publish(
        TopicArn='arn:aws:sns:eu-west-1:123456789:security-incidents',
        Subject=f"[SECURITY] {finding_type} on {instance_id}",
        Message=json.dumps({
            'finding_type': finding_type,
            'severity': severity,
            'instance_id': instance_id,
            'actions_taken': actions_taken,
            'finding_id': finding['id'],
            'timestamp': datetime.utcnow().isoformat()
        }, indent=2)
    )

    return {'statusCode': 200, 'actions': actions_taken}

EventBridge rule запускає цю Lambda при будь-якому GuardDuty finding severity >= HIGH:

{ "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{"numeric": [">=", 7.0]}]
  }
}

Що, якщо автоматика не спрацювала?

Автоматизація обробляє 60–70% типових інцидентів. Решта вимагають людини, але зі структурованим playbook. Такий runbook живе в Git, версіонується та автоматично прикріплюється до тікета. Приклад playbook для privilege escalation:

## Playbook: Privilege Escalation Detected

**Trigger:** SIEM alert - rule 5503 (OSSEC) or T1548 (Elastic)

**Step 1 - Verify (2 min)**
- ausearch -k privileged -ui <uid> --start recent
- Check: is it a deploybot or real user?

**Step 2 - Scope (5 min)**
- who — who is currently logged in
- last -n 20 — recent sessions
- ps auxf — processes under suspicious UID

**Step 3 - Contain (immediate if confirmed)**
- If attacker active: pkill -u <uid>, then usermod -L <username>
- Rotate SSH keys: rm /home/<username>/.ssh/authorized_keys
- If service account compromised — rotate credentials in Vault

**Step 4 - Preserve**
- cp /var/log/audit/audit.log /evidence/$(date +%Y%m%d-%H%M%S)-audit.log
- ps auxf > /evidence/$(date +%Y%m%d-%H%M%S)-processes.txt

Кожна автоматична відповідь логується в SIEM з повним контекстом: IP-адреса, час, тип знахідки, вжиті дії. Це створює незмінний audit trail, необхідний для compliance-аудитів (PCI DSS, ISO 27001). Команда безпеки бачить повну картину інциденту навіть при нічному спрацюванні без участі людей. Це знижує навантаження на чергових інженерів та виключає втрату контексту при зміні зміни.

Що входить у роботу

• Аудит поточних процесів IR та визначення патернів для автоматизації.
• Проєктування архітектури SOAR (Shuffle, TheHive, Cortex XSOAR).
• Налаштування інтеграцій SIEM → SOAR, cloud-event triggers (EventBridge, CloudWatch).
• Розробка та тестування playbooks для типових інцидентів.
• Написання Lambda-функцій для AWS GuardDuty з використанням Python та boto3.
• Версіонування конфігурацій в Git, документація runbook.
• Навчання команди: як доопрацьовувати playbooks, як реагувати на винятки.
• Підтримка протягом місяця після запуску.

Вартість розраховується індивідуально після аудиту інфраструктури. Наші інженери сертифіковані, гарантуємо якість та дотримання термінів. Замовте консультацію по вашому проєкту — підберемо оптимальне рішення та розрахуємо терміни.

IBM Cost of a Data Breach Report 2024