Инцидентные плейбуки и сценарии

1) Назначение раздела

Сформировать единый, версионируемый набор плейбуков (runbooks) для быстрого и согласованного реагирования на инциденты в контуре Операций и Комплаенса: от обнаружения до восстановления, коммуникаций, юридических уведомлений и улучшений.

2) Стандарт плейбука (карточка сценария)

ID: PB- <code >/Version: v <MAJOR. MINOR >/Owner: <role/name>
Title: <short and unambiguous>
Scope: <technology/payments/information security/compliance/PR>
Severity: S1    S2    S3    S4 (activation criteria)
Detection: <metrics/alerts/log signatures/sources>
Start triggers: <conditions and thresholds>
RACI: IC / Tech Lead / Sec Lead / Comms / Legal / Payments / CS / Data
Response steps:
0-15 min: <start actions, war room, holding statement>
15-60 min: <stabilization/bypasses/reserves/first external message>
1-4 hours: <in-depth diagnostics/fixes/targeted notifications>
Up to 24 hours: <final update/compensation/reports/retro slot>
Communications: <templates for status, players, partners, regulators, media>
Artifacts: <timeline, logs, dumps, screenshots, tickets, reports>
Legal: <to/when to notify, formats, languages>
Exit criteria: <conditions for closing the incident>
MTTD/MTTA/MTTR targets: <numerical benchmarks>
Prevention: <CAPA and backlog links to epics>
Last workout: <date/results/remarks>

3) Матрица серьезности и триажа (резюме)

S1 (критический): глобальные простои Core/кошелька, утечка PII/финданных, массовая недоступность платежей, регуляторные расследования.
Апдейты: ≤15 мин первое; каждые 30–60 мин далее.
S2 (высокий): региональные простои, падение конверсии платежей >10%, подтвержденная уязвимость без утечки.
S3 (средний): деградация отдельных провайдеров/фич, рост CS обращений >30% к базе.
S4 (низкий): локальные дефекты, единичные жалобы.

Триаж (быстрый чек): факт? масштаб? безопасность средств/данных? юридические сроки? резервные маршруты? канал первого сообщения и время следующего апдейта?

4) Роли и коммуникации

IC (Incident Commander): владелец таймлайна/решений.
Tech Lead (SRE/Platform): диагностика/фиксы/обходные пути.
Security Lead (AppSec/Blue Team): форензика/контейнмент/уведомления ИБ-органов при необходимости.
Payments Lead: PSP/банки, мульти-маршруты, ручная обработка.
Legal/Compliance: регуляторные уведомления, формулировки, сроки.
Comms Lead: статус-страница, e-mail/SMS/push, аффилиаты, медиа.
CS/CRM Lead: макросы, компенсации, таргет-сегменты.
Data/Analytics: оценка влияния, отчеты, контроль MTT.

Единый голос: любые внешние сообщения — через Comms + Legal.

5) Универсальные чек-листы

5.1 Запуск плейбука (0–15 мин)

• Назначен IC, открыт war room, назначен стенографист.
• Идентифицирована серьезность (S1–S4), радиус влияния.
• Приняты защитные меры (фичефлаги, лимиты, стоп-выводы при рисках).
• Подготовлен holding statement и ETA следующего апдейта.
• Созданы тикеты на фиксацию артефактов (логи/дампы/скриншоты).

5.2 Перед первым внешним сообщением

• Подтверждены факты, исключены секреты/PII.
• Юридическая проверка формулировок.
• Четкие инструкции пользователям «что делать сейчас».
• Время следующего апдейта указано явно.

5.3 Закрытие инцидента

• Корень устранен/компенсирующие меры внедрены.
• Компенсации начислены, спорные транзакции обработаны.
• Финальный отчет/статус обновлен; ретро назначено ≤7 дней.
• CAPA-пункты созданы с владельцами и сроками.

6) Типовые плейбуки (каталог)

PB-SEC-01: Утечка данных / компрометация учетных записей (S1)

Детектирование: аномалии входов, срабатывания EDR/WAF, жалобы на взлом аккаунтов, утечка на форуме.
0–15 мин: изоляция затронутых систем; ротация секретов; отключение скомпрометированных токенов; включение MFA-кампании.
15–60 мин: целевые уведомления затронутым; первое публичное сообщение; фиксация артефактов для форензики.
1–4 часа: аудит доступа к PII; запросы к провайдерам/облаку; подготовка регуляторных уведомлений.
До 24 часов: детальный отчет, смена ключей, обновление паролей, расширение мониторинга.
Коммуникации: статус-страница, e-mail затронутым, партнерам, при необходимости — медиа Q&A.
Юридически: уведомления регуляторов/банков/PSP в установленные сроки.
Критерии выхода: риск локализован; все токены заменены; игрокам отправлены инструкции; подтвержден отсутствующий/ограниченный ущерб.
Профилактика: bug bounty, hardening, DLP, секрет-менеджмент.

PB-PAY-02: Платежный кризис (PSP/банк недоступен) (S1/S2)

Детектирование: падение auth-rate, рост отказов, очередь выводов.
0–15 мин: переключение на резервные PSP/маршруты; мягкая приостановка авто-выводов; баннер в кассе «альтернативные методы».
15–60 мин: первое внешнее сообщение (касса/статус); ручной приоритет VIP/уязвимых групп; связь с PSP.
1–4 часа: перерасчет лимитов; компенсации за неудобства; отчет партнерам.
До 24 часов: финальный отчет; возвраты по SLA; обновление правил балансировки трафика.
Профилактика: мульти-эквайринг, health-checks по методам, авто-ребаланс.

PB-NET-03: DDoS / массовая деградация сети (S1)

0–15 мин: включить анти-DDoS профили; rate-limits/каппинг; защитные правила CDN/WAF; временно выключить тяжелые эндпоинты.
15–60 мин: гео-фильтры/черные списки; коммуникации с провайдером; первое сообщение пользователям с ETA.
1–4 часа: масштабирование фронтов; канареечные проверки; разбор телеметрии атаки.
Профилактика: регулярные DDoS-учения; адаптивные профили; запасные ASN/CDN.

PB-GAME-04: Сбой у игрового провайдера (S2/S3)

Детектирование: рост ошибок API провайдера, всплеск CS обращений по конкретным тайтлам.
Шаги: временно скрыть затронутые игры; показать подсказку/замены; синхронизация балансов; уведомление провайдера и игроков.
Профилактика: fail-open/close стратегии, кэширование каталога, health-маркировка игр.

PB-REG-05: Регуляторный инцидент (S1/S2)

Кейсы: нарушение бонусных условий, KYC/KYB сбои, нарушение рекламы.
Шаги: freeze спорных механик; консультация Legal/Compliance; нейтральные формулировки; отчетность по шаблонам.
Профилактика: pre-clearance промо, регулярные аудиты T&C.

PB-FRD-06: Мошенническое кольцо/абьюз (S2)

Детектирование: всплеск мультиаккаунтинга, бонус-абьюз, арбитражные аномалии.
Шаги: временные лимиты депозитов/выводов; целевой KYC; блокировка связок девайс/платеж/IP; отчет рискам.
Коммуникации: индивидуальные уведомления; избегать раскрытия антифрод-логики публично.
Профилактика: поведенческие модели, граф-аналитика, velocity-фильтры.

PB-DATA-07: Целостность данных/рассинхронизация балансов (S1/S2)

Шаги: перевод кошелька в «safe-mode»; запрет опасных операций; восстановление из журналов/снапшотов; сверка агрегатов; персональные уведомления.
Профилактика: двухфазные коммиты/идемпотентность, event-sourcing, инварианты.

PB-AFF-08: Падение трекинга аффилиатов (S3)

Шаги: починка пикселей/постбеков; компенсационные отчеты; уведомления партнерам; временные коэффициенты атрибуции.
Профилактика: мониторинг конверсий, резервные коллбеки.

PB-PR-09: Репутационный шторм (S2/S3)

Шаги: единая позиция; фактчек; Q&A; избегать споров в комментариях; подготовить лонг-рид с фактами.
Профилактика: медиатренинги спикеров, «dark site» с фактами.

PB-PHI-10: Фишинг/поддельные сайты (S2)

Шаги: сбор доказательств; уведомление регистраторов/хостеров; предупреждение игрокам; обновление антифишинг-страницы; DMARC/Brand Indicators.
Профилактика: мониторинг доменных похожестей, партнерство с анти-фишинг провайдерами.

7) Шаблоны сообщений (быстрые вставки)

Партнерам/аффилиатам: краткий бриф «что/как влияет на трекинг/временные меры/ETA».

Регулятору/банкам/PSP: формальное уведомление: факты, меры, клиентское влияние, план предотвращения, срок финального отчета.

8) Метрики и цели

Обнаружение: MTTD, сигнал-to-noise алертов.
Реакция: MTTA, TTS (time-to-statement), % апдейтов в SLA.
Восстановление: MTTR, RTO/RPO по затронутым сервисам.
Влияние: затронутые игроки/транзакции, недополученный GGR, chargeback-рейт.
Коммуникации: open/click-rate, охват, доля повторных обращений, CSAT/DSAT.
Комплаенс: своевременность обязательных уведомлений, полнота артефактов.

9) Артефакты и доказательная база

• таймлайн решений и действий (минутная точность);
• логи/дампы/скриншоты/экспорт графиков;
• версии конфигураций/билдов;
• копии сообщений и списки получателей;
• списки затронутых аккаунтов/транзакций;
• юридические уведомления (черновики/отправки/ответы).

10) Инструменты и интеграции

Инцидент-бот: `/declare`, `/severity S1..S4`, `/update <текст>`, `/close`.
Статус-страница: публичные ленты; интеграция с аптайм-датчиками.
Компенсации: калькулятор сегментов (по времени, гео, игре, платежному методу).
Секьюрити-стек: EDR/WAF/SIEM/IDS; плейбуки в SOAR.
Наблюдаемость: логи/метрики/трейсы, error budgets, SLO-дашборды.

11) Управление каталогом плейбуков (governance)

Версионирование: Git-репозиторий, PR-процесс, семантические версии.
Ответственность: у каждого плейбука — владелец и резерв.
Ревизии: минимум ежеквартально, после каждого S1/S2 — внеплановая.
Тренировки: table-top раз в квартал, live-drill по критичным сценариям раз в полгода.
Совместимость: ссылки на BCP/DRP, Матрицу эскалаций, Ответственную игру, Политику уведомлений.

12) Быстрый старт внедрения (за 30 дней)

1. Сформировать список топ-10 рисковых сценариев и назначить владельцев.
2. Для каждого — оформить карточку по стандарту (раздел 2) и завести в репозитории.
3. Подключить плейбуки к инцидент-боту (шорткоды и шаблоны сообщений).
4. Провести 2 table-top учения (платежи + ИБ) и 1 live-drill (деградация провайдера игр).
5. Запустить дашборд метрик (MTTD/MTTA/MTTR, TTS, % апдейтов в SLA).
6. Завести CAPA-бэклог, согласовать сроки и RACI.
7. Откатить «сухую» рассылку шаблонов (игрокам/партнерам/регуляторам) через sandbox.

• Кризисное управление и коммуникации
• План непрерывности бизнеса (BCP)
• Disaster Recovery Plan (DRP)
• Матрица эскалаций
• Система уведомлений и алертов
• Ответственная игра и защита игроков