Procedimientos para filtrar datos

1) Objetivo y ámbito de aplicación

Objetivo: minimizar los daños, cumplir con los requisitos legales y restaurar rápidamente el funcionamiento normal en caso de filtración confirmada o probable de datos personales/de pago/de funcionamiento.
Cobertura: PII de jugadores y empleados, artefactos de pago, logs/tokens de acceso, documentos KYC/AML, datos de afiliados/socios, artefactos confidenciales de productos e infraestructuras.

2) Definiciones y criterios de «fuga»

La filtración de datos (data breach) es una violación de la privacidad, integridad o disponibilidad de datos personales (u otra información protegida) debido a un incidente de seguridad o error de proceso.
Confirmado vs sospechoso: cualquier indicador (anomalías de SIEM, mensajes de vendedores/usuarios, sitios Paste) ejecuta el procedimiento antes de la refutación.

3) Clasificación de la gravedad (ejemplo)

4) SLA y «incidente puente»

Iniciación: con Medium + se crea una war-room (chat/llamada), se asigna un Comando de Incident (IC).
SLA: Baja - 24 h· Medium - 4 h· Alta - 1 h· Crítica - 15 min.
Cadence updates: cada 30-60 min (interior), cada 2-4 h (interesados externos).

5) RACI (ampliado)

6) Procedimiento de respuesta (paso a paso)

1. Identificación y validación primaria

La señal del SIEM/EDR/antifraude/vendedor/usuario → una entrada en el registro de incidentes.
Recopilación de hechos mínimos: qué/cuándo/dónde/cuánto, tipos de datos afectados y jurisdicción.

2. Contenido (contención)

Desconexión de endpoints/fich vulnerables, geo-segmentos, límites de tiempo, congelación de lanzamientos.
Rotación de claves/tokens, revocación de accesos, bloqueo de cuentas comprometidas.

3. Eradication (eliminación)

Parche/fix de configuración, limpieza de artefactos maliciosos, reconfiguración de imágenes, comprobación de subprocesadores.

4. Recuperación (recuperación)

Entrada de tráfico canario, seguimiento de regresiones, paso de cheques de integridad.

5. Forenzica y evaluación de impacto

Contar el volumen, la sensibilidad, las geografías, el riesgo para los sujetos; confirmación de los registros afectados.

6. Notificaciones y comunicaciones

Las DPO/Legal determinan el deber y los plazos de las notificaciones; Preparación de textos; Envío a los destinatarios.

7. Post mortem y CAPA

Análisis de causas (5 Whys), plan de medidas correctivas/cautelares con los propietarios y plazos.

7) Ventana de 72 horas y destinatarios legales (puntos de referencia)

Supervisión de datos (DPA) - Notificar a más tardar 72 horas después de la detección de una fuga significativa, a menos que se excluya el riesgo para los derechos/libertades de las entidades.
Usuarios - «sin demora injustificada» con alto riesgo (con recomendaciones comprensibles).
Regulador del juego - cuando afecta a los jugadores/sostenibilidad/reporting.
Bancos/PSP - En riesgo de pagos/compromiso de tokens/transacciones sospechosas.
Socios/vendedores: si los flujos/datos comunes se ven afectados o se requiere su acción.

8) Forenzika y «cadena de custodia de pruebas»

Instantáneas de volúmenes/registros, exportación de artefactos con hashing (SHA-256).
Trabajar sólo con copias/snapshots; sistemas de origen - sólo lectura.
Protocolo de acción: quién/cuándo/qué hizo, los comandos/herramientas utilizados.
Almacenamiento en el almacén de objetos/WORM; acceso restringido, auditoría.

9) Comunicaciones (internas/externas)

Principios: hechos → medidas → recomendaciones → próximo apdate.
No se puede: publicar el PII, construir hipótesis no verificadas, prometer plazos sin control.

• ¿Qué se encuentra?· Escala/categorías· Medidas actuales· Riesgos· Próximos pasos· Próxima actualización en HH: MM.

10) Interacción con vendedores/subprocesadores

Comprobar sus registros de incidentes, registros de acceso, notificaciones SLA, lista de subprocesadores.
Solicitar informes (pentest/forensic), confirmar la eliminación/devolución de datos.
En caso de no conformidad, DPA: escalamiento y aislamiento temporal/suspensión de la integración.

11) Plantillas de notificación (fragmentos)

11. 1 Autoridad de Supervisión (DPA)

Breve descripción del evento y el tiempo de detección, categorías/volumen aproximado de datos, grupos de sujetos, geografías, consecuencias y riesgos, medidas tomadas/planificadas, contacto DPO, aplicaciones (línea de tiempo, resumen hash).

11. 2 Usuarios

Qué pasó; qué datos podrían haber sido afectados; lo que hicimos; lo que puede hacer (cambio de contraseña, control de transacciones, consejos de phishing); cómo contactar; enlace a FAQ/centro de soporte.

11. 3 Socios/PSP/regulador

Los hechos y las interfaces afectadas; las acciones previstas del socio; Los Deedlines; personas de contacto.

12) Registro de incidentes (mínimo de campos)

ID· Tiempo de detección/confirmación· Gravedad· Fuente· Sistemas/datos· Volumen/categoría· Geografía· Vendedores involucrados· Medidas adoptadas (en tiempo)· Notificaciones (en coma/cuando)· Responsables (RACI)· Referencias a artefactos· SARA/Plazos· Estado.

13) Métricas y puntos de referencia de objetivos

MTTD/MTTC/MTTR (detección/contención/recuperación).
% de notificaciones a 72 h - 100%.
La proporción de incidentes con causa de origen establecida ≥ del 90%.
CAPA cerrado a tiempo ≥ 95%.
Incidentes repetidos por una sola razón ≤ 5%.
Porcentaje de incidentes cerrados en SLA (Medium/High/Critical): 90/95/99%.

14) Hojas de cheques

14. 1 Inicio (primeros 60 minutos)

• IC asignado y war-room abierto
• Medidas de estabilización (desconexiones/límites/rotación de claves)
• Recopilación de datos mínimos y capturas de pantalla/registros
• Notificado por DPO/Legal, clase predeterminada definida
• Congelación de lanzamientos y protocolos de limpieza de registros

14. 2 Hasta 24 horas

• Forenzika: volumen/categorías/geografía (draft)
• Decisión sobre notificaciones, preparación de textos
• Plan de recovery/verificación de integridad
• Paquete de evidencia en WORM, eventos en línea

14. 3 Hasta 72 horas

• Envío de notificaciones de DPA/reguladores/PSP (si es necesario)
• Comm a los usuarios (con alto riesgo)
• Plan actualizado de CAPA, propietarios y plazos

15) Escenarios y medidas modelo

A) Exportar la base de chat de sapport a un segmento de almacenamiento abierto

Medidas: cerrar el acceso, inventariar descargas, notificar a los afectados, reforzar las políticas de S3/ACL, reglas DLP para la exportación.

B) Compromiso de tokens de acceso a API

Medidas: rotación inmediata, revocación de tokens refresh, verificación del registro de llamadas, re-firma de webhooks, segmentación del tráfico.

C) Filtración de escáneres KYC a través del vendedor

Medidas: aislamiento de integración, confirmación de eliminación, verificación manual de clientes de alto riesgo, revisión de DPA/retenciones.

D) Publicar un volcado en un público

Medidas: fijación de artefactos (hashes), retirada legal de enlaces (takedown), notificaciones, seguimiento de nuevas publicaciones.

16) Integración con cumplimiento y privacidad

Ligamento con procesos GDPR: DSAR, RoPA, DPIA/DTIA; Actualización de las Políticas y Cookies/CMR en los cambios de proveedores/objetivos.
Incluir el incidente en la matriz de riesgo y revisar los umbrales/controles.

17) CAPA y post mortem (≤ 72 horas después de la estabilización)

Estructura del informe: hechos/tiempo en línea· impacto· causa raíz· que funcionó/no· lista CAPA (propietario, plazo, criterio de éxito)· fecha de prueba de eficacia (30-60 días).

18) Hoja de ruta para la madurez del proceso

Mes 1: actualizar el playbook, contactos, plantillas, archivo WORM, prueba de notificaciones.
Mes 2: ejercicio tabletop (fuga de PII/vendedor/tokens), SOAR playbooks.
Mes 3 +: retrospectivas trimestrales, auditoría de vendedores, pruebas bias de modelos antifraude/detección, revisión regular de umbrales.

TL; DR

En caso de fuga: estabilizamos (containment) rápidamente, confirmamos (forenzika) con precisión, notificamos a tiempo (DPA/usuarios/socios), documentamos con transparencia (registro, línea de tiempo, evidencia) y corregimos la causa raíz (CAPA). El resultado es menos daño, cumplimiento y confianza restaurada de los jugadores y socios.