Інцидентні плейбуки та сценарії

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) Шаблони повідомлень (швидкі вставки)

Партнерам/афіліатам: короткий бриф «що/як впливає на трекінг/тимчасові заходи/ЕТА».

Регулятору/банкам/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)
• Матриця ескалацій
• Система повідомлень і алертів
• Відповідальна гра і захист гравців