Playbooks e cenários de incidentes
1) Atribuição de seção
Formar um conjunto único e versionável de playbooks (runbooks) para responder rapidamente e de forma coerente a incidentes no circuito de Operações e Complaens, desde detecção a recuperação, comunicações, notificações legais e melhorias.
2) Padrão de playbook (cartão de cenário)
Cada playbook do diretório é feito com um único modelo:
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 seriedade e triagem (currículos)
S1 (crítico): interrupções globais Core/carteira, vazamento de PII/find, indisponibilidade de pagamentos em massa, investigações regulatórias.
Apdate: ≤15 min 1; a cada 30 ou 60 minutos a seguir.
S2 (alta): interrupções regionais, queda na conversão de pagamentos> 10%, vulnerabilidade comprovada sem fuga.
S3 (média): Degradação de provedores/fic individuais, crescimento de CS acessos> 30% à base de dados.
S4 (baixo): defeitos locais, queixas individuais.
Triage (cheque rápido): fato? Escala? segurança de ferramentas/dados? prazo legal? rotas de reserva? O canal da primeira mensagem e a hora do próximo update?
4) Papéis e comunicações
IC - Proprietário de times/soluções.
Tech Lead (SRE/Plataforma): diagnóstico/fixação/caminhos de volta.
Segurança Lead (AppSec/Blue Team): forenseiro/contêiner/notificação dos órgãos de IB, se necessário.
Payments Lead: PSP/bancos, rotas multi, processamento manual.
Legal/Compliance: notificações regulatórias, formulações, prazos.
Comms Lead: página status, e-mail/SMS/push, afiliados, mídia.
CS/CRM Lead: macros, compensações, segmentos de metas.
Data/Analytics: avaliação de influência, relatórios, controle de MTT.
Uma só voz: qualquer mensagem externa através do Comms + Legal.
5) Folha de cheque universal
5. 1 Iniciar playbook (0-15 min)
- O IC foi atribuído, o war room foi aberto e um taquigrafista foi designado.
- Gravidade identificada (S1-S4), raio de influência.
- Medidas de proteção foram adotadas (fichiflags, limites, conclusões paradas para riscos).
- Preparado por holding statement e ETA do próximo update.
- Foram criados tíquetes de fixação de artefatos (logs/dampos/screenshots).
5. 2 Antes da primeira mensagem externa
- Confirmados os factos, excluídos os segredos/PII.
- Verificação legal da formulação.
- Instruções claras para os usuários sobre o que fazer agora.
- A hora do próximo update está claramente indicada.
5. 3 Encerramento do incidente
- A raiz foi eliminada/as medidas compensatórias foram implementadas.
- As compensações foram pagas e transações controversas foram processadas.
- Relatório final/status atualizado; O retro está marcado para ≤7 dias.
- Os pontos CAPA foram criados com proprietários e prazos.
6) Playbooks típicos (catálogo)
PB-SEC-01: Fuga de dados/comprometimento de contas (S1)
Detecção: anomalias de entrada, acionamento EDR/WAF, queixas de invasão de contas, vazamento no fórum.
0-15 min: isolamento dos sistemas afetados; rotação de segredos; desativar os tokens comprometidos; inclusão da campanha MFA.
15-60 min: notificações de destino aos afetados; a primeira mensagem pública; a fixação de artefactos forenseiros.
1-4 horas: auditoria do acesso ao PII; solicitação de provedores/nuvem; elaboração de notificações regulatórias.
Até 24 horas: relatório detalhado, mudança de chave, atualização de senhas, extensão de monitoramento.
Comunicações: página de status, e-mail afetado, parceiros, se necessário - mídia Q & A.
Legalmente: notificações de reguladores/bancos/PSP dentro do prazo previsto.
Critérios de saída: risco localizado; todos os tokens foram substituídos; instruções enviadas aos jogadores; confirmando danos ausentes/limitados.
Prevenção: bug bounty, hardening, DLP, gestão de segredo.
PB-PAY-02: Crise de pagamento (PSP/banco não disponível) (S1/S2)
Detecção: queda de auth-rate, aumento das falhas, fila de conclusões.
0-15 min: mudança para PSP/rotas de reserva; suspensão suave das conclusões automáticas; um banner na caixa «métodos alternativos».
15-60 min: primeira mensagem externa (caixa/status); prioridade manual de grupos VIP/vulneráveis; conexão com o PSP.
1-4 horas: reajuste dos limites; compensação por inconvenientes; Relatório aos parceiros.
Até 24 horas: relatório final; devoluções por SLA; atualização das regras de balanceamento de tráfego.
Prevenção: multi-equiring, health-checks, auto-revalance.
PB-NET-03: DDoS/degradação em massa da rede (S1)
0-15 min: incluir perfis anti-DDoS; rate-limits/capping; Regras de proteção CDN/WAF; desligar temporariamente os endpoints pesados.
15-60 min: geo-filtros/lista preta; comunicações com o provedor; primeira mensagem aos usuários com ETA.
1-4 horas: escala das frentes; verificação de canais; Analisar a telemetria do ataque.
Prevenção: exercícios DDoS regulares; perfis adaptativos; ASN/CDN de reserva.
PB-GAME-04: Falha no provedor de jogos (S2/S3)
Detecção: aumento dos erros de API do provedor, aumento das acessões de CS em timbres específicos.
Passos: ocultar temporariamente os jogos afetados; mostrar a dica/substituição; sincronização dos balanços; notificação do provedor e dos jogadores.
Prevenção: fail-open/close estratégias, catálogos de cachê, health-marca de jogos.
PB-REG-05: Incidente regulatório (S1/S2)
Malas: violação de bónus, falhas KYC/KYB, falhas de publicidade.
Passos: freeze controverso mecânico; consulta Legal/Compliance; termos neutros; relatórios de padrões.
Prevenção: promoção pré-clearance, auditorias regulares T & C.
PB-FRD-06: Anel/abuse fraudulento (S2)
Detecção: aumento de multiplacaunting, bónus-abuse, anomalias de arbitragem.
Passos: limites de tempo de depósito/conclusão; O alvo KYC; bloquear laços de device/pagamento/IP; Relatório de risco.
Comunicações: notificações individuais; evitar revelar a lógica antifrod publicamente.
Prevenção: modelos comportamentais, analista gráfico, filtros velocity.
PB-DATA-07: Integridade de dados/ressincronização de balanços (S1/S2)
Passos: transferência da carteira para «modo safe»; a proibição de operações perigosas; Restauração a partir de revistas/snapshots; O cruzamento das unidades; notificações pessoais.
Prevenção: comitas de duas fases/idempotidade, event-surcing, invariantes.
PB-AF-08: Queda do tracking de afiliados (S3)
Passos: conserto de pixel/pós-back; relatórios de compensação; notificações aos parceiros; coeficientes de atribuição temporários.
Prevenção: monitoramento de conversões, colbecs de reserva.
PB-PR-09: Tempestade de reputação (S2/S3)
Passos: posição unificada; faturamento; Q&A; evitar discussões nos comentários; Preparar um longo-ride com os factos.
Prevenção: mediatrações dos porta-vozes, «dark site» com factos.
PB-PHI-10: Phishing/sites falsos (S2)
Etapas: coleta de provas; notificação de recepcionistas/hospedeiros; aviso aos jogadores; atualização da página anti-fishing; DMARC/Brand Indicators.
Prevenção: monitoramento de domínios semelhantes, parceria com provedores anti-phishing.
7) Modelos de mensagem (inserções rápidas)
Holding statement (externo, ≤2 linhas):Associados/associados: Brefe breve «o que/como afeta o tracking/medidas temporárias/ETA».
Regulador/banco/PSP: notificação formal: factos, medidas, influência do cliente, plano de prevenção, data limite do relatório final.
8) Métricas e alvos
Detecção: MTTD, alertas de sinal-to-noise.
Resposta: MTTA, TTS (time-to-statement),% de updates em SLA.
Recuperação: MTTR, RTO/RPO para serviços afetados.
Impacto: Jogadores/transações afetados, GGR carente, grade.
Comunicações: open/click-rate, abrangência, proporção de acessos, CSAT/DSAT.
A abrangência das notificações obrigatórias, a totalidade dos artefactos.
9) Artefatos e base de provas
O conjunto mínimo é guardado em um tíquete/repositório de incidente:- timeline de decisões e ações (precisão de minutos);
- logi/dampas/screenshots/exportação de gráficos;
- versões de configurações/bilhetes;
- cópias das mensagens e listas de destinatários;
- listas de contas/transações afetadas;
- notificações legais (rascunhos/envios/respostas).
10) Ferramentas e integração
Incidente-bot: '/declare ', '/severity S1.. S4', '/update <texto> ', '/close'.
Página de status: fitas públicas; integração com os sensores de farmácia.
Compensações: calculadora de segmentos (tempo, geo, jogo, método de pagamento).
Security stack: EDR/WAF/SIEM/IDS; playbooks em SOAR.
Observabilidade: logs/métricas/trailers, error budgets, SLO-dashboard.
11) Gerenciamento de diretório de playbooks (governance)
Versioning: repositório git, processo PR, versões semânticas.
Responsabilidade: cada playbook tem dono e reserva.
Revisões: mínimo trimestral, após cada S1/S2 - não programado.
Treinos: mesa-top uma vez por trimestre, live-drill em cenários críticos a cada seis meses.
Compatibilidade: Links para BCP/DRP, Matriz de Escalagem, Jogo Responsável, Política de Notificação.
12) Início rápido da implementação (em 30 dias)
1. Formar uma lista de melhores 10 cenários de risco e designar proprietários.
2. Cada um tem um cartão padrão (secção 2) e o repositório.
3. Ligar playbooks a um incidente-bota (shortcods e modelos de mensagens).
4. Realizar 2 ensinamentos de mesa top (pagamentos + IB) e 1 live-drill (degradação do provedor de jogos).
5. Executar as métricas de dashboard (MTTD/MTTA/MTTR, TTS,% updates em SLA).
6. Obter um backlog CAPA, concordar prazos e RACI.
7. Revincular o envio «seco» dos modelos (jogadores/parceiros/reguladores) através do sandbox.
- Gestão de crise e comunicações
- Plano de Continuidade de Negócios (BCP)
- Disaster Recovery Plan (DRP)
- Matriz de escalações
- Sistema de notificações e alertas
- Jogo responsável e proteção de jogadores