Playbooks y scripts de incidentes

1) Asignación de partición

Forme un conjunto único y versionable de playbooks (runbooks) para responder de forma rápida y coherente a los incidentes en el circuito de Operaciones y Cumplimiento: desde la detección hasta la recuperación, comunicaciones, notificaciones legales y mejoras.

2) Estándar de juego (tarjeta de script)

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) Matriz de seriedad y triaje (currículum vitae)

S1 (crítico): downtime global Core/monedero, fuga de PII/findans, inaccesibilidad masiva de pagos, investigaciones regulatorias.
Apdates: ≤15 minas primero; cada 30-60 minutos más.
S2 (alto): tiempo de inactividad regional, caída de la conversión de pagos> 10%, vulnerabilidad confirmada sin fugas.
S3 (promedio): degradación de los proveedores individuales/fich, crecimiento de los accesos CS> 30% a la base.
S4 (bajo): defectos locales, quejas aisladas.

Triage (cheque rápido): ¿hecho? ¿escala? la seguridad de los medios/datos? ¿Plazos legales? ¿Rutas de reserva? ¿el canal del primer mensaje y la hora del próximo apdate?

4) Roles y comunicaciones

IC (Incident Commander): propietario de la línea de tiempo/soluciones.
Tech Lead (SRE/Platform): diagnóstico/fixes/solución de problemas.
Security Lead (AppSec/Blue Team): forensica/contenedor/notificaciones de autoridades de IB cuando sea necesario.
Payments Lead: PSP/bancos, múltiples rutas, manejo manual.
Cumplimiento legal: notificaciones regulatorias, formulaciones, plazos.
Comms Lead: status page, e-mail/SMS/push, afiliados, medios de comunicación.
CS/CRM Lead: macros, compensaciones, segmentos de destino.
Datos/Análisis: evaluación de impacto, informes, control MTT.

Voz única: cualquier mensaje externo - a través de Comms + Legal.

5) Hojas de cheques universales

5. 1 Lanzamiento de playbook (0-15 min)

• CI designado, sala de guerra abierta, taquígrafo asignado.
• Se identifica gravedad (S1-S4), radio de influencia.
• Se han adoptado medidas de protección (fichflags, límites, conclusiones de alto a riesgo).
• Estado holding preparado y ETA del próximo apdate.
• Se han creado tickets de fijación de artefactos (registros/volcado/capturas de pantalla).

5. 2 Antes del primer mensaje externo

• Hechos confirmados, secretos excluidos/PII.
• Verificación legal del lenguaje.
• Instrucciones claras a los usuarios «qué hacer ahora».
• La hora del próximo apdate se especifica explícitamente.

5. 3 Cierre del incidente

• Se ha eliminado la raíz/se han implementado medidas compensatorias.
• Las compensaciones se han acumulado, las transacciones en disputa se han procesado.
• Informe final/estado actualizado; retro asignado ≤7 días.
• Se han creado puntos CAPA con propietarios y plazos.

6) Reproductores típicos (catálogo)

PB-SEC-01: Filtración de datos/comprometimiento de cuentas (S1)

Detección: anomalías en las entradas, activación de EDR/WAF, quejas por hackeo de cuentas, filtración en el foro.
0-15 minas: aislamiento de los sistemas afectados; Rotación de secretos; desactivar los tokens comprometidos; la inclusión de una campaña de MFA.
15 a 60 minas: notificaciones específicas a las víctimas; la primera comunicación pública; fijación de artefactos para forenziki.
1-4 horas: auditoría del acceso a PII; Solicitudes a proveedores/nube; Preparación de notificaciones reglamentarias.
Hasta 24 horas: informe detallado, cambio de claves, actualización de contraseñas, ampliación de monitoreo.
Comunicaciones: status page, e-mail a los afectados, socios, si es necesario - medios Q & A.
Legalmente: notificaciones de reguladores/bancos/PSP dentro de los plazos establecidos.
Criterios de salida: el riesgo está localizado; todos los tokens han sido reemplazados; se han enviado instrucciones a los jugadores; Se ha confirmado el daño faltante/limitado.
Prevención: bug bounty, hardening, DLP, gestión secreta.

PB-PAY-02: Crisis de pagos (PSP/banco no disponible) (S1/S2)

Detección: caída de tasa automática, aumento de fallas, cola de salida.
0-15 min: conmutación por PSP/rutas de respaldo; suspensión suave de las salidas automáticas; una pancarta en la taquilla de «métodos alternativos».
15 a 60 minutos: primera comunicación externa (caja registradora/estado); la prioridad manual de los grupos VIP/vulnerables; comunicación con PSP.
1-4 horas: volver a calcular los límites; Compensación por inconvenientes; Informe a los asociados.
Hasta 24 horas: informe final; devoluciones por SLA; actualización de las reglas de equilibrio de tráfico.
Prevención: multi-equipaje, health-checks por métodos, auto-rebalance.

PB-NET-03: DDoS/degradación masiva de la red (S1)

0-15 min: incluir perfiles anti-DDoS; rate-limits/capping; reglas de protección CDN/WAF; apague temporalmente los endpoints pesados.
15-60 min: geo-filtros/listas negras; comunicaciones con el proveedor; primer mensaje a los usuarios con ETA.
1-4 horas: escala de frentes; Controles canarios; Análisis de telemetría de ataque.
Prevención: ejercicios regulares de DDoS; perfiles adaptativos; ASN/CDN de repuesto.

PB-GAME-04: Fallo del proveedor de juegos (S2/S3)

Detección: aumento de los errores de la API del proveedor, aumento de las llamadas CS a títulos específicos.
Pasos: ocultar temporalmente los juegos afectados; mostrar sugerencia/reemplazo; sincronización de balances; notificación al proveedor y a los jugadores.
Prevención: estrategias de fail-open/close, almacenamiento en caché del catálogo, etiquetado de juegos de salud.

PB-REG-05: Incidente regulatorio (S1/S2)

Casos: violación de las condiciones de bonificación, KYC/KYB fallas, infracción de publicidad.
Pasos: freeze mecánicos controvertidos; Consulta Legal/Compliance; formulaciones neutrales; informes por plantilla.
Prevención: pre-clearance promo, auditorías regulares de T & C.

PB-FRD-06: Anillo/abusivo fraudulento (S2)

Detección: estallido de multiacounting, bonus abuse, anomalías arbitrales.
Pasos: límites de tiempo para depósitos/retiros; KYC objetivo; bloqueo de ligamentos device/pago/IP; informe de riesgos.
Comunicaciones: notificaciones individuales; evitar revelar públicamente la lógica antifraude.
Prevención: modelos de comportamiento, gráficos analíticos, filtros velocity.

PB-DATA-07: Integridad de los datos/resincronización de balances (S1/S2)

Pasos: traducir la cartera en «modo seguro»; Prohibición de operaciones peligrosas; recuperación de registros/snapshots; Conciliación de unidades; notificaciones personales.
Prevención: commitas bifásicas/idempotencia, event-sourcing, invariantes.

PB-AFF-08: Caída del seguimiento de afiliados (S3)

Pasos: reparar píxeles/postbecs; Informes de indemnización; notificaciones a los socios; factores de atribución temporales.
Prevención: monitoreo de conversiones, collbacks de respaldo.

PB-PR-09: Tormenta de reputación (S2/S3)

Pasos: una posición única; Facturas; Q&A; evitar controversias en los comentarios; preparar un long reid con los hechos.
Prevención: mediatrenings de altavoces, «dark site» con hechos.

PB-PHI-10: Phishing/sitios falsos (S2)

Pasos: recolección de pruebas; Notificación a los registradores/hosters; advertencia a los jugadores; actualización de la página antifishing; DMARC/Brand Indicators.
Prevención: monitoreo de dominios similares, asociación con proveedores anti-phishing.

7) Plantillas de mensajes (inserciones rápidas)

Socios/afiliados: breve resumen «qué/cómo afecta el seguimiento/medidas temporales/ATA».

Regulador/bancos/PSP: notificación formal: hechos, medidas, influencia del cliente, plan de prevención, fecha límite del informe final.

8) Métricas y objetivos

Detección: MTTD, alertas señal-a-noise.
Reacción: MTTA, TTS (time-to-statement),% de los apdates en SLA.
Recuperación: MTTR, RTO/RPO sobre los servicios afectados.
Impacto: jugadores/transacciones afectadas, GGR perdido, chargeback-rate.
Comunicaciones: open/click-rate, cobertura, porcentaje de llamadas repetidas, CSAT/DSAT.
Cumplimiento: la puntualidad de las notificaciones obligatorias, la integridad de los artefactos.

9) Artefactos y base de pruebas

• la línea de tiempo de las decisiones y acciones (precisión minuciosa);
• logs/volcado/capturas de pantalla/exportación de gráficos;
• versiones de configuraciones/datos;
• copias de mensajes y listas de destinatarios;
• listas de cuentas/transacciones afectadas;
• avisos legales (borradores/envíos/respuestas).

10) Herramientas e integraciones

Incidente bot: '/declare ', '/severity S1.. S4', '/update <texto> ', '/close'.
Estado de la página: cintas públicas; integración con sensores de aptime.
Compensación: calculadora de segmentos (por tiempo, geo, juego, método de pago).
Titulity Stack: EDR/WAF/SIEM/IDS; playbucks en SOAR.
Observabilidad: registros/métricas/tracks, errores budgets, SLO-dashboards.

11) Gestión del catálogo de playbooks (governance)

Versioning: repositorio Git, proceso PR, versiones semánticas.
Responsabilidad: cada playbook tiene un propietario y una reserva.
Revisiones: mínimo trimestral, después de cada S1/S2 - no programado.
Entrenamiento: table-top una vez al trimestre, live-drill en escenarios críticos cada seis meses.
Compatibilidad: enlaces a BCP/DRP, Matriz de escalamiento, Juego responsable, Política de notificación.

12) Inicio rápido de la implementación (en 30 días)

1. Formar una lista de los 10 mejores escenarios de riesgo y asignar propietarios.
2. Para cada uno, formalice la tarjeta según el estándar (Sección 2) e inicie en el repositorio.
3. Conectar los playbooks al bot de incidentes (códigos cortos y plantillas de mensajes).
4. Realizar 2 ejercicios de mesa-top (pagos + IB) y 1 live-drill (degradación del proveedor de juegos).
5. Ejecutar métricas de dashboard (MTTD/MTTA/MTTR, TTS,% de los apdates en SLA).
6. Iniciar CAPA-backlog, acordar plazos y RACI.
7. Revertir el envío «seco» de plantillas (jugadores/socios/reguladores) a través de sandbox.

• Gestión de crisis y comunicaciones
• Plan de continuidad del negocio (BCP)
• Disaster Recovery Plan (DRP)
• Matriz de escalamiento
• Sistema de alertas y notificaciones
• Juego responsable y protección de los jugadores