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

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) · Ссылки на артефакты · CAPA/сроки · Статус.

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; обновление Политики и куки/CMP при изменениях поставщиков/целей.
Включение инцидента в матрицу рисков и пересмотр порогов/контролей.

17) CAPA и пост-мортем (≤ 72 часа после стабилизации)

Структура отчета: факты/таймлайн · импакт · первопричина · что сработало/нет · список CAPA (владелец, срок, критерий успеха) · дата проверки эффективности (через 30–60 дней).

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

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

TL;DR

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