GH GambleHub

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):
💡 Nós registramos interrupções no [serviço]. O comando já está restabelecendo a disponibilidade. A próxima atualização é daqui a 30 minutos. Ferramentas e dados dos usuários sob proteção.
Update detalhado (após a estabilização):
💡 Razão: [componente/provedor]. Impacto: [porcentagem/geografia/período]. Medidas tomadas [reserva/reversão/validação]. Compensações: [tipo/critério]. Os seguintes passos são [prevenção/prazo].

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.

Seções relacionadas:
  • 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
Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.