Процедури при витоку даних

1) Мета і область застосування

Мета: мінімізувати збитки, виконати юридичні вимоги і швидко відновити нормальну роботу при підтвердженому або ймовірному витоку персональних/платіжних/операційних даних.
Охоплення: PII гравців і співробітників, платіжні артефакти, логи/токени доступу, документи KYC/AML, дані афіліатів/партнерів, конфіденційні артефакти продуктів та інфраструктури.

2) Визначення та критерії «витоку»

Витік даних (data breach) - порушення конфіденційності, цілісності або доступності персональних даних (або іншої інформації, що охороняється) внаслідок інциденту безпеки або помилки процесу.
Підтверджена vs підозрювана: будь-які індикатори (аномалії SIEM, повідомлення від вендорів/користувачів, Paste-сайти) запускають процедуру до спростування.

3) Класифікація серйозності (приклад)

4) SLA і «інцидент-бридж»

Ініціація: при Medium + створюється war-room (чат/дзвінок), призначається Incident Commander (IC).
SLA: Low - 24 год· Medium - 4 год· High - 1 год· Critical - 15 хв.
Каденс апдейтів: кожні 30-60 хв (внутрішні), кожні 2-4 год (зовнішні зацікавлені сторони).

5) RACI (укрупнено)

6) Процедура реагування (покроково)

1. Ідентифікація та первинна валідація

Сигнал з SIEM/EDR/антифрода/вендора/користувача → запис до реєстру інцидентів.
Збір мінімальних фактів: що/коли/де/скільки, порушені типи даних і юрисдикції.

2. Containment (стримування)

Відключення вразливих ендпоінтів/фіч, гео-відрізки, тимчасові ліміти, заморожування релізів.
Ротація ключів/токенів, відкликання доступів, блокування скомпрометованих облікових записів.

3. Eradication (усунення)

Патч/конфіг-фікс, чищення шкідливих артефактів, перезбирання образів, перевірка субпроцесорів.

4. Recovery (відновлення)

Канарний введення трафіку, моніторинг регресій, проходження чеків цілісності.

5. Форензика та оцінка впливу

Підрахунок обсягу, чутливості, географій, ризику для суб'єктів; підтвердження порушених записів.

6. Повідомлення та комунікації

DPO/Legal визначають обов'язок і терміни повідомлень; підготовка текстів; розсилка адресатам.

7. Пост-мортем і CAPA

Розбір причин (5 Whys), план коригувальних/попереджувальних заходів з власниками і термінами.

7) 72-годинне вікно та юридичні адресати (орієнтири)

Нагляд за даними (DPA) - повідомити не пізніше 72 годин після виявлення істотного витоку, якщо ризик для прав/свобод суб'єктів не виключений.
Користувачі - «без невиправданої затримки» при високому ризику (зі зрозумілими рекомендаціями).
Регулятор азартних ігор - при впливі на гравців/стійкість/звітність.
Банки/PSP - при ризиках платежів/компрометації токенів/підозрілих транзакціях.
Партнери/вендори - якщо порушені загальні потоки/дані або потрібна їх дія.

8) Форензіка і «ланцюжок зберігання доказів»

Знімки томів/логів, експорт артефактів з хешуванням (SHA-256).
Робота тільки з копіями/снапшотами; вихідні системи - read-only.
Протокол дій: хто/коли/що зробив, використані команди/інструменти.
Зберігання в WORM/об'єктному сховищі; обмежений доступ, аудит.

9) Комунікації (внутрішні/зовнішні)

Принципи: факти → заходи → рекомендації → наступний апдейт.
Не можна: публікувати PII, будувати неперевірені гіпотези, обіцяти терміни без контролю.

• Що виявлено?· Масштаб/категорії· Поточні заходи· Ризики· Наступні кроки· Наступний апдейт в HH:MM.

10) Взаємодія з вендорами/субпроцесорами

Перевірити їх реєстри інцидентів, логи доступу, SLA повідомлень, перелік субпроцесорів.
Запитати звіти (пентест/форензика), зафіксувати підтвердження видалення/повернення даних.
При невідповідності DPA - ескалація і тимчасова ізоляція/призупинення інтеграції.

11) Шаблони повідомлень (фрагменти)

11. 1 Наглядовому органу (DPA)

Короткий опис події і часу виявлення, категорії/приблизний обсяг даних, групи суб'єктів, географії, наслідки і ризики, прийняті/заплановані заходи, контакт DPO, додатки (таймлайн, хеш-зведення).

11. 2 Користувачам

Що сталося; які дані могли постраждати; що ми зробили; що ви можете зробити (зміна пароля, контроль транзакцій, фішинг-поради); як зв'язатися; посилання на FAQ/центр підтримки.

11. 3 Партнерам/PSP/регулятору

Факти і порушені інтерфейси; очікувані дії партнера; дедлайни; контактні особи.

12) Реєстр інцидентів (мінімум полів)

ID· Час виявлення/підтвердження· Серйозність· Джерело· Системи/дані· Обсяг/категорії· Географії· Задіяні вендори· Вжиті заходи (за часом)· Повідомлення (кому/коли)· Відповідальні (RACI)· Посилання на артефакти· САРА/терміни· Статус.

13) Метрики та цільові орієнтири

MTTD/MTTC/MTTR (виявлення/стримування/відновлення).
% повідомлень в 72 год - 100%.
Частка інцидентів зі встановленою першопричиною ≥ 90%.
CAPA закриті в термін ≥ 95%.
Повторні інциденти з однієї причини ≤ 5%.
Частка інцидентів, закритих в SLA (Medium/High/Critical): 90/95/99%.

14) Чек-листи

14. 1 Старт (перші 60 хвилин)

• Призначений IC і відкритий war-room
• Стабілізуючі заходи (відключення/ліміти/ротація ключів)
• Збір мінімальних фактів і скріншотів/логів
• Повідомлений DPO/Legal, визначений preliminary клас
• Заморожування релізів і протоколів очищення логів

14. 2 До 24 годин

• Форензіка: обсяг/категорії/географії (draft)
• Рішення по повідомленнях, підготовка текстів
• План рековері/перевірки цілісності
• Пакет доказів в WORM, таймлайн подій

14. 3 До 72 годин

• Надсилання сповіщень DPA/регуляторам/PSP (якщо потрібно)
• Комм користувачам (при високому ризику)
• Оновлений план CAPA, власники та терміни

15) Типові сценарії та заходи

A) Експорт бази саппорт-чатів у відкритий сегмент сховища

Заходи: закрити доступ, інвентаризувати скачування, повідомити порушених, посилити політики S3/ACL, DLP-правила на експорт.

B) Компрометація токенів доступу до API

Заходи: негайна ротація, відкликання refresh-токенів, перевірка журналу викликів, ре-підпис вебхуків, сегментація трафіку.

C) Витік KYC-сканів через вендора

Заходи: ізоляція інтеграції, підтвердження видалення, повторна верифікація high-risk клієнтів вручну, ревізія DPA/утримань.

D) Публікація дампа в пабліку

Заходи: фіксація артефактів (хеші), легальне зняття посилань (takedown), повідомлення, моніторинг подальших публікацій.

16) Інтеграція з комплаєнсом і приватністю

Зв'язка з GDPR-процесами: DSAR, RoPA, DPIA/DTIA; оновлення Політики та куки/СМР при змінах постачальників/цілей.
Включення інциденту в матрицю ризиків і перегляд порогів/контролів.

17) CAPA і пост-мортем (≤ 72 години після стабілізації)

Структура звіту: факти/таймлайн· імпакт· першопричина· що спрацювало/ні· список CAPA (власник, термін, критерій успіху)· дата перевірки ефективності (через 30-60 днів).

18) Дорожня карта зрілості процесу

Місяць 1: актуалізувати playbook, контакти, шаблони, WORM-архів, тест повідомлень.
Місяць 2: навчання tabletop (витік PII/вендор/токени), SOAR-плейбуки.
Місяць 3 +: квартальні ретроспективи, аудит вендорів, bias-тести моделей антифроду/детекції, регулярна ревізія порогів.

TL; DR

При витоку: швидко стабілізуємо (containment), точно підтверджуємо (форензика), повідомляємо вчасно (DPA/користувачі/партнери), прозоро документуємо (реєстр, таймлайн, докази) і виправляємо першопричину (CAPA). Результат - менше збитку, відповідність вимогам і відновлена довіра гравців і партнерів.