Глава 20. Реагирование на инциденты

«Zero Trust не предотвращает все атаки. Оно гарантирует, что взлом одного сервиса не станет взломом всей инфраструктуры.»

Предыдущие главы строили защиту: идентичность, устройства, сеть, приложения, данные, наблюдаемость, политики. Но даже при идеальной реализации Zero Trust инциденты будут происходить. Вопрос не «если», а «когда» — и насколько быстро организация обнаружит, ограничит и восстановится.

20.1 Зачем: принцип «предполагай взлом»

NIST SP 800-207 строит всю архитектуру на предположении, что атакующий уже внутри:

«Zero trust security models assume that an attacker is present in the environment and that an enterprise-owned environment is no different — or no more trustworthy — than any nonenterprise-owned environment.»

Это не паранойя — это операционная модель. Тенеты 5-7 прямо определяют IR-требования:

Тенет	Требование для IR
5: Мониторинг всех активов	Непрерывная оценка состояния → обнаружение
6: Динамическая авторизация	Ревокация доступа в реальном времени → сдерживание
7: Сбор информации об инфраструктуре	Полная телеметрия → расследование

NIST SP 800-61 Rev 3 (апрель 2025)

NIST обновил руководство по реагированию на инциденты, заменив классическую 4-фазную модель (Preparation → Detection → Containment → Post-Incident) на маппинг к NIST Cybersecurity Framework (CSF) 2.0:

CSF 2.0 Function	IR-активности
Govern	Политики IR, роли, юридические аспекты
Identify	Инвентаризация активов, оценка рисков
Protect	Превентивные контроли (всё, что мы строили в главах 5-19)
Detect	Обнаружение аномалий, alerts, SIEM/SOAR
Respond	Сдерживание, анализ, коммуникация
Recover	Восстановление сервисов, lessons learned

Источник: csrc.nist.gov/pubs/sp/800/61/r3/final

20.2 Радиус поражения: как Zero Trust ограничивает ущерб

SolarWinds: чему учит провал

В декабре 2020 года обнаружена компрометация SolarWinds Orion — ~18 000 организаций получили троянизированные обновления. Атакующие (APT29) использовали имплант SUNBURST для латерального перемещения по сетям жертв.

Что бы изменил Zero Trust:

Микросегментация → SolarWinds Orion изолирован в отдельном сегменте, латеральное перемещение заблокировано на уровне политик
Минимальные привилегии → Orion имеет доступ только к необходимым API, а не ко всей сети
Наблюдаемость (глава 18) → Аномальные DNS-запросы к avsvmcloud.com обнаружены автоматически
Workload identity (глава 7) → SVID с коротким TTL вместо долгоживущих токенов

Colonial Pipeline: VPN ≠ Zero Trust

В мае 2021 года группа DarkSide получила доступ через компрометированный VPN-аккаунт без MFA (см. главу 1).

Что бы изменил Zero Trust:

ZTNA вместо VPN (глава 11) → Доступ к конкретным приложениям, не ко всей сети
MFA обязательна (глава 5) → Скомпрометированный пароль недостаточен
Непрерывная оценка (глава 9) → Аномальное поведение аккаунта обнаружено
Сегментация OT/IT → Ransomware не распространяется на операционные системы

Формула радиуса поражения

Радиус поражения = f(привилегии × доступ × время)

Zero Trust минимизирует каждый множитель:

Привилегии → минимальные (JIT, RBAC/ABAC)
Доступ → только к необходимым ресурсам (микросегментация)
Время → короткоживущие токены (SVID 1h, JWT 5min), быстрое обнаружение

20.3 SOAR: автоматизация реагирования

SOAR (Security Orchestration, Automation and Response) — платформа, объединяющая инструменты безопасности и автоматизирующая типовые реакции.

Зачем автоматизация

Среднее время обнаружения (MTTD) + время реагирования (MTTR) = окно атаки. Ручное реагирование: часы-дни. Автоматизированное: секунды-минуты.

Detection (SIEM/XDR) → Decision (Playbook) → Action (SOAR) → Verification
         │                    │                     │
         ▼                    ▼                     ▼
   Ch.18 Наблюдаемость   Ch.19 Политики    Automated response

Платформы SOAR

Платформа	Экосистема	Особенности
Palo Alto Cortex XSOAR	Мультивендорная	87+ предустановленных playbooks, 600+ интеграций
Splunk SOAR	Splunk	2 800+ автоматизированных действий, 300+ коннекторов
Microsoft Sentinel Playbooks	Azure	Основаны на Azure Logic Apps, нативная интеграция с Defender XDR
Google SecOps SOAR	GCP	Orchestration 300+ инструментов, Mandiant integration

20.4 ZT-специфичные playbooks

Playbook 1: Компрометация учётных данных

Триггер: Обнаружение impossible travel / credential stuffing (глава 5)
  │
  ├─ 1. Ревокация сессий
  │     ├─ Entra ID: Revoke-AzureADUserAllRefreshToken
  │     ├─ AWS: aws iam delete-login-profile + rotate access keys
  │     └─ GCP: gcloud auth revoke
  │
  ├─ 2. Принудительная MFA re-enrollment
  │     └─ Entra: Reset MFA registration, CA policy: require re-registration
  │
  ├─ 3. Анализ
  │     ├─ Что делал аккаунт за последние 24h?
  │     ├─ Какие данные были доступны?
  │     └─ Были ли попытки повышения привилегий?
  │
  └─ 4. Восстановление
        ├─ Новый пароль (если применимо)
        ├─ Проверка MFA-устройств (не добавлены ли чужие)
        └─ Уведомление пользователя

Playbook 2: Компрометация workload identity

Триггер: Аномальные запросы от SPIFFE ID / необычный API pattern
  │
  ├─ 1. Изоляция рабочей нагрузки
  │     ├─ kubectl cordon node (предотвращение миграции pod)
  │     ├─ Cilium: CiliumNetworkPolicy → deny all egress
  │     └─ Istio: AuthorizationPolicy → deny from source principal
  │
  ├─ 2. Ротация SVID
  │     ├─ SVID с TTL 1h ротируется автоматически
  │     ├─ Для немедленной ревокации: удалить Registration Entry в SPIRE
  │     └─ spire-server entry delete -entryID <id>
  │
  ├─ 3. Forensics
  │     ├─ Сохранить pod для анализа: kubectl debug
  │     ├─ Собрать логи из OTel/Loki за период аномалии
  │     └─ Проверить image integrity (cosign verify)
  │
  └─ 4. Восстановление
        ├─ Redeploy из проверенного образа
        ├─ Новая Registration Entry
        └─ Post-incident review

Playbook 3: Аномальный доступ к данным

Триггер: Bulk download / доступ к данным вне рабочего паттерна
  │
  ├─ 1. Ограничение доступа
  │     ├─ OPA: переключить политику на read-only / deny
  │     ├─ Lake Formation: отозвать грант
  │     └─ BigQuery: удалить Row Access Policy
  │
  ├─ 2. DLP enforcement (глава 16)
  │     ├─ Purview: Block + encrypt
  │     └─ Macie: quarantine S3 object
  │
  ├─ 3. Анализ
  │     ├─ Data lineage (глава 17): какие downstream затронуты?
  │     ├─ Объём и тип данных
  │     └─ Было ли это эксфильтрация или легитимный bulk job?
  │
  └─ 4. Уведомление
        ├─ Data owner
        ├─ Compliance team (если PII/PHI)
        └─ Legal (если breach notification required)

Playbook 4: Некомплиантное устройство

Триггер: Intune/CrowdStrike: устройство не соответствует политике (глава 8-9)
  │
  ├─ 1. Автоматическая блокировка
  │     ├─ Conditional Access: Require device compliance → Block
  │     └─ CrowdStrike ZTA score < порог → Zscaler deny
  │
  ├─ 2. Уведомление пользователя
  │     └─ "Ваше устройство не соответствует политике. Действия: ..."
  │
  ├─ 3. Remediation
  │     ├─ Автообновление ОС (если причина — устаревшая версия)
  │     ├─ Включение BitLocker/FileVault
  │     └─ Обновление EDR сигнатур
  │
  └─ 4. Повторная проверка
        └─ Intune re-evaluation → если compliant → доступ восстановлен

20.5 MITRE ATT&CK и Zero Trust

MITRE ATT&CK описывает тактики и техники атакующих. Zero Trust прямо противодействует трём ключевым тактикам:

Тактика	ATT&CK ID	Как ZT противодействует
Lateral Movement	TA0008	Микросегментация блокирует east-west трафик. Per-session access (тенет 3)
Credential Access	TA0006	MFA + FIDO2 (глава 5). Короткоживущие токены. Workload identity без секретов (SPIFFE)
Privilege Escalation	TA0004	Least privilege + JIT (глава 6). Непрерывная авторизация (тенет 6)
Discovery	TA0007	Микросегментация ограничивает видимость. DNS-фильтрация
Exfiltration	TA0010	DLP (глава 16). Network policies. Data classification

Для каждой тактики и её техник следование принципам Zero Trust снижает вероятность успеха атакующего и повышает вероятность раннего обнаружения.

20.6 Лаборатория: IR playbook для скомпрометированной рабочей нагрузки

Цель

Смоделировать обнаружение и реагирование на компрометацию рабочей нагрузки в Kubernetes с использованием kubectl и Cilium.

Предварительные требования

Kubernetes-кластер (kind, minikube, или cloud)
kubectl
Cilium CLI (опционально)

Шаг 1: Создание тестовой рабочей нагрузки

yaml

# compromised-workload.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: suspicious-app
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: suspicious-app
  template:
    metadata:
      labels:
        app: suspicious-app
    spec:
      serviceAccountName: default
      containers:
        - name: app
          image: nginx:latest
          ports:
            - containerPort: 80

bash

kubectl create namespace production 2>/dev/null || true
kubectl apply -f compromised-workload.yaml

Шаг 2: Обнаружение — имитация аномалии

bash

# Имитация аномального поведения: попытка доступа к Kubernetes API
POD=$(kubectl get pod -n production -l app=suspicious-app \
  -o jsonpath='{.items[0].metadata.name}')

# Попытка обращения к API server изнутри pod
kubectl exec -n production "$POD" -- \
  curl -sk https://kubernetes.default.svc/api/v1/namespaces 2>&1 | head -5
# Результат: 403 Forbidden (если RBAC настроен корректно)

Шаг 3: Сдерживание — изоляция через NetworkPolicy

yaml

# isolate-workload.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-suspicious-app
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: suspicious-app
  policyTypes:
    - Ingress
    - Egress
  # Пустые правила = deny all ingress + egress

bash

# Применение изоляции
kubectl apply -f isolate-workload.yaml

# Проверка: pod больше не может выходить в сеть
kubectl exec -n production "$POD" -- \
  curl -s --connect-timeout 3 https://example.com 2>&1
# Результат: timeout (egress заблокирован)

Шаг 4: Forensics — сохранение артефактов

bash

# Сохранение состояния pod
kubectl get pod -n production "$POD" -o yaml > pod-snapshot.yaml

# Сохранение логов
kubectl logs -n production "$POD" --timestamps > pod-logs.txt

# Информация о контейнере
kubectl describe pod -n production "$POD" > pod-describe.txt

# Проверка: какой образ реально запущен
kubectl get pod -n production "$POD" \
  -o jsonpath='{.status.containerStatuses[0].imageID}'

Шаг 5: Восстановление

bash

# Удаление скомпрометированной рабочей нагрузки
kubectl delete deployment suspicious-app -n production

# Удаление NetworkPolicy изоляции
kubectl delete networkpolicy isolate-suspicious-app -n production

# Redeploy из проверенного образа (с фиксированным тегом, не :latest)
# kubectl apply -f verified-deployment.yaml

Очистка

bash

kubectl delete namespace production

20.7 Чек-лист

[ ] IR-план документирован и включает ZT-специфичные playbooks
[ ] SOAR или автоматизация Logic Apps настроена для типовых сценариев
[ ] Ревокация сессий автоматизирована (< 5 минут от обнаружения)
[ ] Изоляция рабочих нагрузок возможна через NetworkPolicy / Cilium / Istio
[ ] Forensics процедуры определены (сохранение pod, логов, артефактов)
[ ] MITRE ATT&CK маппинг выполнен для основных тактик
[ ] Табличные учения проводятся минимум раз в квартал
[ ] Post-incident review процесс формализован (blameless)

20.8 Итоги

Реагирование на инциденты в Zero Trust отличается от традиционного подхода:

Assume breach = подготовка, а не паника — если вы всегда предполагаете компрометацию, IR-план уже активен
Радиус поражения минимален — микросегментация + least privilege + короткоживущие токены ограничивают ущерб ДО того, как IR-команда вступит в действие
Автоматизация критична — SOAR playbooks сокращают MTTR с часов до минут
Телеметрия уже есть — если главы 7-18 реализованы, у IR-команды полная видимость
MITRE ATT&CK показывает: ZT не устраняет все тактики, но существенно повышает барьер для латерального перемещения, кражи учётных данных и повышения привилегий

В следующей главе мы завершим Часть VII, рассмотрев комплаенс и управление — как Zero Trust маппится на SOC 2, ISO 27001, PCI DSS и GDPR.

Глава 20. Реагирование на инциденты ​

20.1 Зачем: принцип «предполагай взлом» ​

NIST SP 800-61 Rev 3 (апрель 2025) ​

20.2 Радиус поражения: как Zero Trust ограничивает ущерб ​

SolarWinds: чему учит провал ​

Colonial Pipeline: VPN ≠ Zero Trust ​

Формула радиуса поражения ​

20.3 SOAR: автоматизация реагирования ​

Зачем автоматизация ​

Платформы SOAR ​

20.4 ZT-специфичные playbooks ​

Playbook 1: Компрометация учётных данных ​

Playbook 2: Компрометация workload identity ​

Playbook 3: Аномальный доступ к данным ​

Playbook 4: Некомплиантное устройство ​

20.5 MITRE ATT&CK и Zero Trust ​

20.6 Лаборатория: IR playbook для скомпрометированной рабочей нагрузки ​

Цель ​

Предварительные требования ​

Шаг 1: Создание тестовой рабочей нагрузки ​

Шаг 2: Обнаружение — имитация аномалии ​

Шаг 3: Сдерживание — изоляция через NetworkPolicy ​

Шаг 4: Forensics — сохранение артефактов ​

Шаг 5: Восстановление ​

Очистка ​

20.7 Чек-лист ​

20.8 Итоги ​

Глава 20. Реагирование на инциденты

20.1 Зачем: принцип «предполагай взлом»

NIST SP 800-61 Rev 3 (апрель 2025)

20.2 Радиус поражения: как Zero Trust ограничивает ущерб

SolarWinds: чему учит провал

Colonial Pipeline: VPN ≠ Zero Trust

Формула радиуса поражения

20.3 SOAR: автоматизация реагирования

Зачем автоматизация

Платформы SOAR

20.4 ZT-специфичные playbooks

Playbook 1: Компрометация учётных данных

Playbook 2: Компрометация workload identity

Playbook 3: Аномальный доступ к данным

Playbook 4: Некомплиантное устройство

20.5 MITRE ATT&CK и Zero Trust

20.6 Лаборатория: IR playbook для скомпрометированной рабочей нагрузки

Цель

Предварительные требования

Шаг 1: Создание тестовой рабочей нагрузки

Шаг 2: Обнаружение — имитация аномалии

Шаг 3: Сдерживание — изоляция через NetworkPolicy

Шаг 4: Forensics — сохранение артефактов

Шаг 5: Восстановление

Очистка

20.7 Чек-лист

20.8 Итоги