Реагування на інциденти
План реагування на інциденти, playbooks для AI-інцидентів, стратегії стримування та відновлення
📎ОФІЦІЙНА ДОКУМЕНТАЦІЯ
Реагування на інциденти
Ефективне реагування на інциденти безпеки мінімізує збитки та час відновлення. AI-інциденти мають свою специфіку та потребують спеціалізованих playbooks.
Фази реагування на інциденти
Preparation (Підготовка)
Команда реагування (CSIRT)
| Роль | Відповідальність |
|---|---|
| IR Lead | Координація реагування, комунікація з керівництвом |
| Security Analyst | Аналіз інциденту, forensics |
| DevOps Engineer | Ізоляція систем, відновлення сервісів |
| AI/ML Engineer | AI-специфічні інциденти |
| Legal Counsel | Правові аспекти, compliance |
| Communications | Зовнішні та внутрішні комунікації |
Необхідні інструменти
- SIEM -- Microsoft Sentinel, Splunk, Elastic SIEM
- EDR -- Microsoft Defender for Endpoint, CrowdStrike
- Forensics -- Volatility, FTK, Autopsy
- Communication -- захищений канал (не корпоративна пошта)
- Documentation -- інцидент-трекер (Jira, ServiceNow)
AI-специфічні інциденти
Playbook: Prompt Injection Attack
Prompt injection може призвести до витоку конфіденційних даних, несанкціонованих дій або маніпуляції результатами AI.
Detection:
- Аномальні патерни у промптах (injection keywords)
- Несподівана поведінка AI-системи
- Незвичайний output від моделі
Containment:
- Тимчасово вимкніть AI-ендпоінт або функціонал
- Заблокуйте IP-адресу зловмисника
- Збережіть логи промптів та відповідей
Eradication:
- Додайте input validation для виявленого вектора
- Оновіть системний промпт з додатковими guard rails
- Розгорніть оновлений WAF-правила
Recovery:
- Увімкніть AI-ендпоінт з оновленим захистом
- Моніторьте підвищену активність
- Перевірте, чи не було витоку даних
Playbook: Data Poisoning
Detection:
- Аномальна поведінка моделі після оновлення
- Drift у якості відповідей
- Trigger-based аномалії
Containment:
- Відкатіть модель до попередньої версії
- Ізолюйте підозрілі тренувальні дані
- Зупиніть pipeline тренування
Eradication:
- Ідентифікуйте та видаліть забруднені дані
- Перетренуйте модель на чистих даних
- Впровадьте data validation
Playbook: AI-згенерований вразливий код
Detection:
- SAST/DAST знайшов критичну вразливість в production
- Exploit виявлений через IDS/WAF
- Bug bounty report
Containment:
- Деплойте hotfix або WAF-правило
- Ізолюйте вразливий компонент
- Перевірте, чи не було exploitation
Eradication:
- Виправте вразливість у коді
- Додайте тест для цього типу вразливості
- Оновіть SAST-правила
Шаблон плану реагування
Класифікація інцидентів
| Severity | Опис | Час реагування |
|---|---|---|
| P1 - Critical | Активна компрометація, витік даних | < 1 години |
| P2 - High | Потенційна компрометація, critical vulnerability | < 4 годин |
| P3 - Medium | Підозріла активність, medium vulnerability | < 24 годин |
| P4 - Low | Інформаційне сповіщення | < 72 годин |
Комунікація
| Severity | Кого сповіщати |
|---|---|
| P1 | CSIRT, CISO, CEO, Legal, регулятори |
| P2 | CSIRT, CISO, менеджмент |
| P3 | CSIRT, team lead |
| P4 | Security team |
Post-Incident Review
Після кожного інциденту проводьте blameless post-mortem:
- Timeline -- хронологія подій
- Root cause -- першопричина інциденту
- Impact -- масштаб збитків
- Response effectiveness -- що спрацювало, що ні
- Action items -- конкретні дії для запобігання повторенню
- Lessons learned -- уроки для команди
Post-mortem має бути blameless -- фокус на системних проблемах, а не на пошуку винних. Це заохочує чесну звітність та покращує процеси.
Див. також
SIEM та виявлення інцидентів
Вимоги до звітності про інциденти
Превентивна ідентифікація загроз