Настройка автоматического реагирования на инциденты безопасности

Среднее время обнаружения 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 общается с known 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