Código: POL-CYBER-004/2026
Versão: 2.0
Versão: 2.0
Data de Aprovação: Fevereiro/2026
Vigência: Indeterminada (Revisão Semestral)
Aprovadores:
Conselho de Administração
Chief Executive Officer (CEO)
Chief Information Security Officer (CISO)
Chief Technology Officer (CTO)
Diretoria Jurídica
MENSAGEM DO CISO
“No Banco JC Digital, a segurança cibernética não é apenas um requisito técnico, é a base da confiança dos nossos clientes. Como um banco 100% digital, nossa infraestrutura é nosso maior ativo e nosso maior alvo.
Esta política define a postura de ‘guerra’ que adotamos contra ameaças: detecção rápida, resposta implacável e recuperação resiliente.
Nossa prioridade #1 é proteger os dados e o patrimônio de nossos clientes contra qualquer adversário, seja um hacker isolado ou grupos de crime organizado.”
OBJETIVO
Estabelecer um framework estruturado para detectar, conter, erradicar e recuperar de incidentes de segurança cibernética, minimizando danos operacionais, financeiros e reputacionais, garantindo a continuidade dos negócios e a conformidade regulatória.
CAPÍTULO I – OBJETIVO E ESCOPO
1.1 Finalidade
■ Padronizar a resposta a incidentes de segurança.
■ Definir papéis e responsabilidades claros (RACI).
■ Assegurar a comunicação tempestiva com stakeholders (BCB, Clientes, Imprensa).
■ Garantir a preservação de evidências para fins forenses e legais.
1.2 Escopo de Aplicação
Esta política aplica-se a:
■ Todos os sistemas, redes, aplicações (App, Internet Banking, APIs) e dados.
■ Infraestrutura Multi-Cloud (AWS e Google Cloud) e On-Premise.
■ Dispositivos móveis corporativos e endpoints.
■ Parceiros críticos conectados à rede (Correspondentes, Fornecedores de TI).
1.3 Definições Críticas
■ Evento de Segurança: Qualquer ocorrência observável em um sistema ou rede (ex: falha de login, scan de porta).
■ Incidente Cibernético: Um evento adverso confirmado que compromete a Confidencialidade, Integridade ou Disponibilidade de um ativo de informação (ex: ransomware, vazamento de dados, DDoS).
CAPÍTULO II – BASE LEGAL E NORMATIVA
Esta política está em estrita conformidade com:
■ Resolução BCB 4.893/2021: Política de Segurança Cibernética.
■ Lei 13.709/2018 (LGPD): Obrigação de notificar incidentes com dados pessoais.
■ ISO/IEC 27001:2022 & 27035: Gestão de Segurança e Incidentes.
■ NIST Cybersecurity Framework (CSF): Identificar, Proteger, Detectar, Responder, Recuperar.
■ NIST SP 800-61 r2: Computer Security Incident Handling Guide.
CAPÍTULO III – TAXONOMIA DE INCIDENTES
3.1 Categorias de Incidentes
3.2 Níveis de Severidade (Criticidade)
CAPÍTULO IV – CSIRT (COMPUTER SECURITY INCIDENT RESPONSE TEAM)
4.1 Estrutura do CSIRT
A) CORE TEAM (Permanente 24/7):
■ CISO (Líder)
■ SOC Manager
■ Incident Responders (L1, L2, L3)
■ Threat Hunters
■ Digital Forensics Analyst
B) EXTENDED TEAM (Acionado conforme necessidade):
■ CTO / DevOps Lead
■ DPO (Data Protection Officer)
■ Jurídico
■ Comunicação / PR
■ Recursos Humanos
4.2 Papéis e Responsabilidades (RACI)
4.3 Gatilhos de Acionamento Automático
■ Alerta de DDoS com volume > 10 Gbps.
■ Detecção de assinatura de Ransomware pelo EDR.
■ Alerta de Vazamento de Dados (DLP) do SIEM.
■ Tentativas de acesso não autorizado > 100 falhas em 5 min (Brute Force).
■ Queda de sistema crítico (PIX/App) por > 5 minutos sem causa infraestrutural óbvia.
CAPÍTULO V – FASE 1: PREPARAÇÃO
A melhor defesa é estar preparado antes do ataque.
■ Treinamentos: Simulações trimestrais de ataque (Red Team) para o CSIRT.
■ Ferramentas: Manutenção e tuning de SIEM (Splunk), EDR (CrowdStrike), SOAR e Firewall WAF.
■ Playbooks: Atualização constante dos guias passo-a-passo (Anexos).
■ Backups: Testes de restauração semanais (Regra 3-2-1).
■ War Room: Sala virtual de crise pré-configurada (Slack/Teams seguro).
CAPÍTULO VI – FASE 2: DETECÇÃO E ANÁLISE
6.1 Fontes de Detecção
Monitoramento 24/7 via SOC (Security Operations Center):
■ Logs de SIEM (correlação de eventos).
■ Alertas de EDR em todos os endpoints.
■ Threat Intelligence Feeds (IOCs externos).
■ Denúncias de usuários (phishing button).
6.2 Triagem e Análise
Ao detectar um alerta, o analista deve responder em até 15 minutos (P1):
■ É um falso positivo?
■ Qual a categoria e severidade?
■ Quais sistemas/dados estão afetados?
■ Há risco de propagação lateral?
Ação Técnica: Coletar evidências voláteis (RAM dump, conexões de rede ativas) ANTES de qualquer reboot.
CAPÍTULO VII – FASE 3: CONTENÇÃO
O objetivo é estancar o sangramento e impedir que o ataque se espalhe.
■ Ransomware: Isolar hosts infectados da rede (quarentena via EDR). Desconectar cabos se físico.
■ DDoS: Ativar mitigação em nuvem (Cloudflare/Akamai) e bloqueio de IPs geográficos.
■ Vazamento: Revogar credenciais comprometidas, derrubar API vulnerável, bloquear S3 bucket.
■ Insider: Bloquear conta do AD e acesso VPN imediatamente.
7.2 Preservação de Evidências
Para fins forenses, NUNCA desligue ou reinicie um servidor comprometido sem antes:
■ Fazer um dump de memória RAM.
■ Criar uma imagem forense do disco (bit-a-bit).
■ Salvar logs de firewall e rede.
CAPÍTULO VIII – FASE 4: ERRADICAÇÃO
Remover a causa raiz e os artefatos maliciosos.
■ Rodar scan completo de malware em todos os sistemas.
■ Identificar e fechar a vulnerabilidade explorada (patching).
■ Remover backdoors, contas criadas pelo atacante e scripts agendados (cron jobs).
■ Trocar todas as senhas administrativas e chaves de API.
CAPÍTULO IX – FASE 5: RECUPERAÇÃO
Restaurar as operações para a normalidade.
■ Restaurar sistemas a partir de backups limpos e validados (pré-incidente).
■ Reconstruir servidores a partir de imagens “gold” (se necessário).
■ Validar integridade dos dados restaurados.
■ Monitorar intensivamente os sistemas recuperados (risco de reinfecção).
■ Comunicar stakeholders sobre a normalização.
CAPÍTULO X – FASE 6: LIÇÕES APRENDIDAS (POST-MORTEM)
Obrigatório para todo incidente P1 e P2, em até 72h após a resolução:
■ O que aconteceu? (Timeline detalhado).
■ O que funcionou? (Detecção foi rápida? Backups funcionaram?).
■ O que falhou? (Por que a defesa não parou o ataque?).
■ Plano de Ação: Melhorias em processos, ferramentas e treinamentos.
CAPÍTULO XI – PLANO DE COMUNICAÇÃO
11.1 Comunicação Interna (Escalonamento)
■ P1 (Crítico): Notificar CEO e Board imediatamente (< 1h). Sala de Guerra aberta.
■ P2 (Alto): Notificar Diretoria Executiva em até 4h.
11.2 Comunicação Externa (Regulatória e Clientes)
CAPÍTULO XII – INVESTIGAÇÃO
■ Cadeia de Custódia: Documentar cada pessoa que teve acesso às evidências digitais.
■ Análise de Malware: Realizada apenas em ambiente de Sandbox isolado (sem rede).
■ Coordenação Legal: O departamento Jurídico deve validar todas as comunicações externas.
■ Polícia/MP: Acionamento de autoridades policiais apenas com aprovação do CEO e Jurídico.
CAPÍTULO XIII – PREPARAÇÃO CONTÍNUA
Red Team vs Blue Team: Anualmente, contratamos uma empresa externa para realizar um
ataque simulado realista (Red Team) para testar a capacidade de detecção e resposta
do nosso time (Blue Team).
CAPÍTULO XIV – GOVERNANÇA DA POLÍTICA
■ Responsável: CISO (Chief Information Security Officer).
■ Revisão: Semestral ou após incidente crítico.
■ Aprovação: Conselho de Administração.
LISTA DE ANEXOS (DOCUMENTOS OPERACIONAIS)
Os documentos abaixo são de uso restrito do CSIRT e estão disponíveis no cofre de senhas/documentação segura:
■ ANEXO I: Playbook de Resposta a RANSOMWARE.
■ ANEXO II: Playbook de Resposta a DDoS.
■ ANEXO III: Playbook de Resposta a VAZAMENTO DE DADOS (DLP).
■ ANEXO IV: Matriz de Contatos de Emergência (On-Call List).
■ ANEXO V: Templates de Comunicação (Clientes, BCB, Imprensa).
■ ANEXO VI: Formulário de Cadeia de Custódia.
■ ANEXO VII: Checklist de Hardening Pós-Incidente.
