Incident Response — план реагирования

Incident Response (IR) — структурированный процесс обнаружения, анализа, сдерживания и восстановления после инцидентов безопасности, направленный на минимизацию ущерба и предотвращение повторения.

Зачем нужно

Без плана реагирования команда теряет драгоценное время в панике во время инцидента. Наличие заранее прописанных шагов сокращает время простоя, ограничивает распространение утечки и помогает соответствовать регуляторным требованиям (GDPR, PCI DSS).

Где используется

  • Утечки данных пользователей (data breach)
  • Взлом аккаунтов или инфраструктуры
  • DDoS-атаки и деградация сервиса
  • Обнаружение вредоносного кода в зависимостях (supply chain)

Основной контент

6 фаз Incident Response (NIST SP 800-61)

1. Preparation        — подготовка инструментов, ролей, runbook'ов
2. Detection          — обнаружение аномалий через мониторинг/алёртинг
3. Containment        — изоляция заражённых систем, отзыв токенов
4. Eradication        — удаление вектора атаки, патчинг уязвимостей
5. Recovery           — восстановление из бэкапов, проверка целостности
6. Post-Incident      — разбор полётов (post-mortem), улучшение процессов

Чек-лист первых 15 минут инцидента

# 1. Зафиксировать время обнаружения
echo "Incident detected at $(date -u)" >> incident.log

# 2. Сохранить текущие логи до их ротации
cp /var/log/nginx/access.log /tmp/incident-nginx-$(date +%s).log

# 3. Изолировать скомпрометированный сервер (пример AWS CLI)
aws ec2 modify-instance-attribute \
  --instance-id i-xxxxx \
  --groups sg-isolated

# 4. Отозвать скомпрометированные токены/ключи
# (через панель управления или API: AWS, GitHub, Stripe)

# 5. Уведомить команду — Slack/PagerDuty, зафиксировать в тикете

Шаблон Post-Mortem

## Incident: [название]
**Date:** YYYY-MM-DD | **Duration:** X hours
**Severity:** P1/P2/P3

### Timeline
- HH:MM — что произошло
- HH:MM — кто обнаружил
- HH:MM — какие меры приняты

### Root Cause
[Описание первопричины]

### Impact
[Число затронутых пользователей, данных, систем]

### Action Items
-  Задача 1 — Ответственный — Срок
-  Задача 2 — Ответственный — Срок

Частые ошибки

  • Отсутствие актуального runbook'а — команда не знает, кому звонить и что делать первым
  • Попытка "тихо" решить инцидент без уведомления — нарушение GDPR (72 часа на уведомление регулятора)
  • Работа с live-системой без изоляции — улики уничтожаются, атакующий может продолжать
  • Отсутствие post-mortem — те же инциденты повторяются

Связанные темы

Ресурсы