Playbook e script di incidenti
1) Assegnazione sezione
Formare un unico set di playbook (runbooks) versionabile per rispondere rapidamente e coerentemente agli incidenti del tracciato delle Operazioni e della Complaens, dal rilevamento al ripristino, alle comunicazioni, alle notifiche legali e ai miglioramenti.
2) Standard di playbook (scheda script)
Ogni playbook della directory viene visualizzato con un unico modello:
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) Matrice di serietà e triaggio (curriculum)
S1 (critico): interruzioni globali Core/portafoglio, perdita di dati PII/find, totale indisponibilità dei pagamenti, indagini regolatorie.
Apdate: 1 min. Ogni 30-60 minuti.
S2 (alto): interruzioni regionali, riduzione della conversione dei pagamenti> 10%, vulnerabilità confermata senza perdita.
S3 (media): degrado dei singoli provider/fich, crescita CS> 30% alla base.
S4 (basso): difetti locali, lamentele singole.
Triage (assegno rapido) è un fatto? Scala? Sicurezza degli strumenti/dati? I tempi legali? rotte di riserva? Il canale del primo messaggio e l'ora del prossimo update?
4) Ruoli e comunicazioni
IC - Proprietario della timeline/soluzioni.
Tech Lead (SRE/Platform) - Diagnostica/fissa/percorso di bypass.
Sicurezza Lead (AppSec/Blue Team): forensica/contenitore/notifica degli organi IB, se necessario.
Payments Lead: PSP/banche, multi-rotte, lavorazione manuale.
Legale/Compliance: notifiche regolatorie, formulazioni, scadenze.
Comms Lead: pagina di stato, e-mail/SMS/push, affiliati, media.
CS/CRM Lead: macro, compensi, segmenti target.
Data/Analytics: valutazione dell'impatto, report, controllo MTT.
Voce unica: tutti i messaggi esterni tramite Comms + Legale.
5) Fogli di assegno universali
5. 1 Avvio playbook (0-15 min)
- Assegnato IC, aperto war room, assegnato stenografo.
- Gravità identificata (S1-S4), raggio di influenza.
- Sono state adottate misure di protezione (phicheflagi, limiti, conclusioni stop ai rischi).
- Elaborato da holding statement e ETA del prossimo update.
- Sono stati creati tickets per fissare gli artefatti (loghi/dampi/screenshot).
5. 2 Prima del primo messaggio esterno
- Fatti confermati, esclusi i segreti/PII.
- Verifica legale della formulazione.
- Istruzioni chiare agli utenti «cosa fare adesso».
- L'ora del prossimo update è chiaramente indicata.
5. 3 Chiusura dell'incidente
- Radice eliminata/misure di compensazione implementate.
- Rimborsi accreditati, transazioni controverse elaborate.
- Rapporto finale/stato aggiornato; Sono stati fissati 12 giorni.
- CAPE sono creati con proprietari e scadenze.
6) Playbook tipici (directory)
PB-SEC-01: perdita di dati/compromissione di account (S1)
Rilevamento: anomalie degli ingressi, attivazioni EDR/WAF, lamentele per violazione di account, fuga di notizie sul forum.
0-15 min: isolamento dei sistemi interessati rotazione dei segreti; disattivare i token compromessi attivazione della campagna MFA.
15-60 min: notifiche di destinazione per i soggetti interessati il primo messaggio pubblico; Fissazione degli artefatti forensi.
1-4 ore: controllo dell'accesso al PII; Richieste di provider/cloud preparazione di notifiche regolatorie.
Fino a 24 ore: report dettagliato, cambio delle chiavi, aggiornamento delle password, estensione del monitoraggio.
Comunicazione: pagina di stato, e-mail, partner, se necessario - Media Q & A.
Legalmente: notifiche regolatorie/banche/PSP entro i tempi previsti.
Criteri di uscita: rischio localizzato; Tutti i token sostituiti istruzioni ai giocatori; sono stati confermati danni mancanti o limitati.
Prevenzione: bug bounty, hardening, DLP, gestione segreto.
PB-PAY-02: Crisi dei pagamenti (PSP/banca non disponibile) (S1/S2)
Rilevamento: calo auth-rate, aumento dei guasti, coda delle conclusioni.
0-15 min: failover PSP/percorsi ridondanti Sospensione morbida delle conclusioni automatiche uno striscione nella cassetta dei metodi alternativi.
15-60 min: primo messaggio esterno (cassa/stato) priorità manuale dei gruppi VIP/vulnerabili; collegamento con PSP.
1-4 ore: ricalcolamento dei limiti risarcimenti per disagi; Report ai partner.
Fino a 24 ore: rapporto finale; rimborsi SLA; aggiornamento delle regole di bilanciamento del traffico.
Prevenzione: multi-equairing, health-checks sui metodi, auto-rebalance.
PB-NET-03: degrado di rete di massa/ DDoS (S1)
0-15 min: abilita profili anti-DDoS rate-limits/capping; Regole di protezione CDN/WAF; Spegnere temporaneamente gli endpoint pesanti.
15-60 min: geo-filtri/black list; comunicazioni con il provider; il primo messaggio agli utenti con ETA.
1-4 ore: scalabilità dei fronti Controlli canari; analizzare la telemetria dell'attacco.
Prevenzione: esercitazioni DDoS regolari; profili adattivi ASN/CDN di riserva.
PB-GAME-04: errore del provider di giochi (S2/S3)
Rilevamento: aumento degli errori dell'API del provider, aumento degli accessi CS per timeline specifiche.
I passaggi nascondono temporaneamente i giochi interessati; Mostra suggerimento/sostituzione sincronizzazione dei bilanci notifica al provider e ai giocatori.
Prevenzione: strategie fail-open/close, catalogo della cache, etichettatura dei giochi.
PB-REG-05: Incidente regolatorio (S1/S2)
Valigetta: violazione dei termini di bonus, errore KYC/KYB, violazione della pubblicità.
Passi: freeze controverso meccanico; consulenza Legale/Compliance; termini neutrali; Report sui modelli.
Prevenzione: promo pre-clearance, controlli regolari T & C.
PB-FRD-06 Anello/Abuse fraudolento (S2)
Rilevamento: aumento del multi-acunting, bonus-abuse, anomalie arbitrali.
Passaggi: limiti temporali di depositi/conclusioni; KYC di destinazione blocco dei collegamenti device/pagamento/IP; Un rapporto sui rischi.
Comunicazioni: notifiche individuali; evitare di rivelare la logica antifrode in pubblico.
Prevenzione: modelli comportamentali, grafica, filtri velocity.
PB-DATA-07 Integrità dati/resincronizzazione bilanci (S1/S2)
Passaggi: trasferire il portafoglio in «safe-mode»; Divieto di operazioni pericolose; Ripristino da registri/snapshot comprimere le unità notifiche personali.
Prevenzione: commiti bifase/idampotenza, event-source, invarianti.
PB-AFFF-08: calo del tracking degli affiliati (S3)
Passaggi: riparazione pixel/postbeek; Rapporti di compensazione; notifiche ai partner coefficienti temporali di attribuzione.
Prevenzione: monitoraggio delle conversioni, colleback di riserva.
PB-PR-09 Tempesta di reputazione (S2/S3)
Passaggi: posizione unica; fattura; Q&A; evitare polemiche nei commenti; Preparare il Long Reed con i fatti.
Prevenzione: i media dei portavoce, «dark site» con i fatti.
PB-PHI-10: phishing/siti falsi (S2)
Passaggi: raccolta delle prove; notifica registratori/host; Avviso ai giocatori; Aggiornamento della pagina anti-fishing DMARC/Brand Indicators.
Prevenzione: monitoraggio dei domini simili, partnership con provider anti-phishing.
7) Modelli di messaggio (inserimento rapido)
Holding statement (esterno, ≤2 righe):Partner/affiliati: briefing breve «che/come influisce su tracking/misure temporanee/ETA».
Regolatore/banche/PSP: notifica formale: fatti, misure, impatto dei clienti, piano di prevenzione, termine del rapporto finale.
8) Metriche e obiettivi
Rilevamento: MTTD, segnale-to-noise alert.
Risposta: MTTA, TTS (time-to-statement),% update in SLA.
Ripristino: MTTR, RTO/RPO per i servizi interessati.
Impatto: giocatori/transazioni influenzati, GGR mancante, proveback-rit.
Comunicazioni: open/click-rate, copertura, percentuale di ripetizioni, CSAT/DSAT.
Completamento delle notifiche obbligatorie, completezza degli artefatti.
9) Manufatti e base di prova
Il set minimo viene salvato nel ticket/repository dell'incidente:- timeline di soluzioni e azioni (precisione di minuti)
- logi/dampi/schermate/esportazione di grafici
- versioni di configurazioni/bilanci
- Copie dei messaggi e elenchi dei destinatari
- Elenco degli account/transazioni interessati
- notifiche legali (bozze/invio/risposta).
10) Strumenti e integrazioni
Incidente-bot: '/declare ', '/severity S1.. S4', '/update <testo> ', '/close'.
Pagina di stato - nastri pubblici integrazione con i sensori di farmacia.
Compensi: calcolatore di segmenti (tempo, geo, gioco, metodo di pagamento).
Security stack: EDR/WAF/SIEM/IDS; playbook in SOAR.
Osservabilità: loghi/metriche/roulotte, error budget, SLO-dashboard.
11) Gestione directory playbook (governance)
Versioning: repository git, processo PR, versioni semantiche.
Responsabilità: ogni playbook ha il proprietario e la riserva.
Revisione: minimo trimestrale, dopo ogni S1/S2 è fuori programma.
Allenamenti: la tabella top una volta al trimestre, live-drill in scenari critici ogni sei mesi.
Compatibilità: collegamenti a BCP/DRP, Matrice di scalate, Gioco responsabile, Criteri di notifica.
12) Avvio rapido dell'implementazione (in 30 giorni)
1. Formare un elenco dei migliori 10 script di rischio e assegnare i proprietari.
2. Per ciascun utente è necessario compilare una carta standard (paragrafo 2) e installarla nel repository.
3. Collega le playbook a un incidente-bot (shortcode e modelli di messaggio).
4. Eseguire 2 tute top (pagamenti + IB) e 1 live-drill (degrado del provider di giochi).
5. Esegui dashboard metriche (MTTD/MTTA/MTTR, TTS,% update in SLA).
6. Avvia il backlog CAPA, fissa i tempi e il RACI.
7. Ripristina la distribuzione secca dei modelli (giocatori/partner/regolatori) tramite sandbox.
- Gestione delle crisi e comunicazione
- Piano di business continuity (BCP)
- Disaster Recovery Plan (DRP)
- Matrice di escalation
- Sistema di notifiche e alert
- Gioco responsabile e protezione dei giocatori