🔒 Resposta a Incidentes de Segurança - CSuite
Versão: 1.0
Última Atualização: 2025-01-02
Classificação: CONFIDENCIAL
📋 Índice
- Visão Geral
- Classificação de Incidentes
- Procedimentos de Resposta
- Contenção e Isolamento
- Investigação
- Recuperação
- Pós-Incidente
- Contatos de Emergência
🎯 Visão Geral
Este documento define os procedimentos para resposta a incidentes de segurança no ecossistema CSuite, incluindo detecção, contenção, investigação e recuperação.
Princípios
- Segurança primeiro: Isolar imediatamente para prevenir propagação
- Preservar evidências: Não apagar logs ou dados antes da investigação
- Comunicação clara: Notificar stakeholders apropriados
- Documentação completa: Registrar todas as ações tomadas
Escopo
- Ataques externos (DDoS, SQL Injection, XSS)
- Comprometimento de credenciais
- Acesso não autorizado
- Vazamento de dados
- Malware/ransomware
- Vulnerabilidades críticas exploradas
🚨 Classificação de Incidentes
Severidade Crítica (P1)
Critérios:
- Ataque ativo em produção
- Dados sensíveis comprometidos
- Múltiplos serviços afetados
- Acesso root/admin comprometido
Tempo de Resposta: Imediato (< 15 min)
Escalation: CTO/CIO imediato
Exemplos:
- SQL Injection resultando em acesso a dados
- Credenciais de admin vazadas e usadas
- Ransomware detectado
- Backdoor instalado
Severidade Alta (P2)
Critérios:
- Ataque detectado mas contido
- Dados não-sensíveis comprometidos
- Serviço único afetado
- Vulnerabilidade crítica explorada
Tempo de Resposta: < 1 hora
Escalation: DevOps Lead + Security Team
Exemplos:
- Tentativa de acesso não autorizado bem-sucedida
- Vulnerabilidade conhecida explorada
- DDoS afetando disponibilidade
- Credenciais comprometidas (não usadas)
Severidade Média (P3)
Critérios:
- Tentativa de ataque bloqueada
- Vulnerabilidade detectada (não explorada)
- Anomalia de segurança
Tempo de Resposta: < 4 horas
Escalation: On-Call + Security Team
Exemplos:
- Múltiplas tentativas de login falhadas
- Scan de portas detectado
- Anomalia em logs de acesso
- Vulnerabilidade reportada (não explorada)
Severidade Baixa (P4)
Critérios:
- Alertas de segurança não críticos
- Falsos positivos
- Informações de segurança
Tempo de Resposta: < 24 horas
Escalation: Ticket normal
Exemplos:
- Alertas de WAF (falsos positivos)
- Tentativas de brute force bloqueadas
- Informações de segurança gerais
🔧 Procedimentos de Resposta
Fase 1: Detecção e Triagem
Sinais de Comprometimento
Indicadores Comuns:
- Logins de IPs não reconhecidos
- Acesso a horários não usuais
- Comandos suspeitos em logs
- Alterações não autorizadas em dados
- Performance degradada sem causa aparente
- Tráfego de rede anômalo
- Alertas de segurança (WAF, IDS)
Verificação Inicial
# 1. Verificar logs de autenticação
grep "FAILED" /var/log/auth.log
grep "authentication failure" /var/log/messages
# 2. Verificar conexões ativas suspeitas
netstat -an | grep ESTABLISHED
ss -tulpn | grep LISTEN
# 3. Verificar processos suspeitos
ps aux | grep -E "(python|bash|sh)" | grep -v grep
top -b -n 1
# 4. Verificar alterações recentes em arquivos críticos
find /etc -type f -mtime -1
find /var/www -type f -mtime -1
# 5. Verificar espaço em disco (possível ransomware)
df -h
Classificação
- Confirmar se é incidente real:
- Falso positivo?
- Teste autorizado?
-
Manutenção planejada?
-
Classificar severidade: Ver Seção 2
-
Notificar equipe: Ver Seção 8
Fase 2: Contenção Imediata
Isolamento de Rede
Para Serviço Comprometido:
# 1. Parar serviço imediatamente
docker service scale csuite-affected-service_csuite-affected-service=0
# 2. Bloquear tráfego de rede (se necessário)
# Via firewall
sudo iptables -A INPUT -s <ATTACKER_IP> -j DROP
# 3. Isolar container (se ainda rodando)
docker network disconnect csuite_default <container_id>
Para Servidor Comprometido:
# 1. Desconectar da rede (se possível)
sudo ifdown eth0
# 2. Ou bloquear tráfego externo
sudo iptables -A INPUT -j DROP
sudo iptables -A OUTPUT -j DROP
Preservação de Evidências
⚠️ IMPORTANTE: Não apagar nada antes da investigação!
# 1. Criar snapshot de logs
mkdir -p /evidence/$(date +%Y%m%d_%H%M%S)
cp -r /var/log/* /evidence/$(date +%Y%m%d_%H%M%S)/
# 2. Snapshot de processos
ps aux > /evidence/$(date +%Y%m%d_%H%M%S)/processes.txt
netstat -an > /evidence/$(date +%Y%m%d_%H%M%S)/network.txt
# 3. Snapshot de containers Docker
docker ps -a > /evidence/$(date +%Y%m%d_%H%M%S)/containers.txt
docker service ls > /evidence/$(date +%Y%m%d_%H%M%S)/services.txt
# 4. Backup de configurações
cp -r /etc/docker /evidence/$(date +%Y%m%d_%H%M%S)/docker_config
cp docker-stack.yml /evidence/$(date +%Y%m%d_%H%M%S)/
Revogação de Credenciais
# 1. Revogar tokens JWT (se possível)
# Atualizar JWT_SECRET no Docker Swarm
echo "NEW_SECRET" | docker secret rm jwt_secret
echo "NEW_SECRET" | docker secret create jwt_secret -
# 2. Forçar re-autenticação de usuários
# (depende da implementação)
# 3. Rotacionar senhas de banco de dados
# Atualizar mysql_password secret
echo "NEW_PASSWORD" | docker secret rm mysql_password
echo "NEW_PASSWORD" | docker secret create mysql_password -
Fase 3: Investigação
Coleta de Evidências
Logs de Aplicação:
# Logs do Gateway
docker service logs --tail 1000 csuite-gateway_csuite-gateway > gateway_logs.txt
# Logs do serviço afetado
docker service logs --tail 1000 csuite-affected-service_csuite-affected-service > service_logs.txt
# Logs do Traefik
docker service logs --tail 1000 traefik_traefik > traefik_logs.txt
Logs de Banco de Dados:
-- Verificar acessos recentes
SELECT * FROM mysql.general_log
WHERE event_time > DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY event_time DESC;
-- Verificar alterações em tabelas críticas (se audit log existe)
SELECT * FROM audit_log
WHERE table_name = 'users'
AND action = 'UPDATE'
AND timestamp > DATE_SUB(NOW(), INTERVAL 24 HOUR);
Logs do Sistema:
# Logs de autenticação
grep -i "fail\|denied\|unauthorized" /var/log/auth.log
# Logs de acesso web (se disponível)
tail -1000 /var/log/nginx/access.log | grep -E "(POST|PUT|DELETE)"
# Logs do Docker
journalctl -u docker.service --since "24 hours ago"
Análise de Timeline
Criar timeline do incidente:
1. T0: Primeira detecção
2. T-1h: O que aconteceu 1 hora antes?
3. T-24h: O que aconteceu 24 horas antes?
4. T-7d: Mudanças recentes (deploys, configurações)
Comandos úteis:
# Verificar quando arquivos foram modificados
find /path -type f -mtime -7 -exec ls -lh {} \;
# Verificar histórico Git (se aplicável)
git log --since="7 days ago" --oneline
# Verificar cron jobs recentes
grep CRON /var/log/syslog | tail -100
Identificação do Vetor de Ataque
Vetores Comuns:
- SQL Injection: Verificar queries com parâmetros não sanitizados
- XSS: Verificar inputs de usuário não sanitizados
- Credenciais comprometidas: Verificar vazamentos conhecidos
- Vulnerabilidade explorada: Verificar CVE conhecidos
- Acesso não autorizado: Verificar falhas de autenticação/autorização
Fase 4: Recuperação
Limpeza e Remediação
Para Serviço Comprometido:
# 1. Remover container comprometido
docker service rm csuite-affected-service_csuite-affected-service
# 2. Limpar volumes (se necessário)
docker volume rm csuite-affected-service_data
# 3. Verificar e corrigir código (se vulnerabilidade)
git checkout <commit_anterior_seguro>
# Ou aplicar patch de segurança
# 4. Re-deploy do serviço
docker stack deploy -c docker-stack.yml csuite
Para Banco de Dados Comprometido:
-- 1. Verificar integridade dos dados
CHECK TABLE critical_table;
-- 2. Identificar dados alterados (se audit log existe)
SELECT * FROM audit_log
WHERE action IN ('INSERT', 'UPDATE', 'DELETE')
AND timestamp > '<incident_time>';
-- 3. Restaurar dados comprometidos (se backup disponível)
-- Ver DISASTER_RECOVERY.md - Seção 5.2
Hardening Pós-Incidente
Aplicar correções:
1. Atualizar dependências vulneráveis:
pip list --outdated
pip install --upgrade <package>
- Aplicar patches de segurança:
sudo yum update --security
- Rever configurações de segurança:
- Firewall rules
- Security groups
- WAF rules
-
Rate limiting
-
Implementar monitoramento adicional:
- Alertas para padrões similares
- Logs adicionais
- Análise comportamental
Fase 5: Pós-Incidente
Relatório de Incidente
Template:
# Relatório de Incidente de Segurança
**Data do Incidente:** YYYY-MM-DD HH:MM
**Severidade:** P1/P2/P3/P4
**Status:** Resolvido/Em Investigação
## Resumo Executivo
Breve descrição do incidente e impacto.
## Timeline
- T0: Detecção
- T+15min: Contenção
- T+1h: Investigação iniciada
- T+4h: Recuperação completa
## Causa Raiz
Descrição da causa raiz identificada.
## Impacto
- Serviços afetados: [lista]
- Dados comprometidos: [descrição]
- Tempo de indisponibilidade: [X horas]
- Usuários afetados: [número estimado]
## Ações Tomadas
1. [Ação 1]
2. [Ação 2]
...
## Lições Aprendidas
- O que funcionou bem
- O que pode ser melhorado
- Gaps identificados
## Ações Corretivas
- [ ] Ação 1 (responsável, prazo)
- [ ] Ação 2 (responsável, prazo)
...
Comunicação
Stakeholders a Notificar:
- P1: CTO, CIO, Legal, Compliance
- P2: DevOps Lead, Security Team, Product Owners
- P3: On-Call, Security Team
- P4: Ticket normal
Template de Comunicação:
Assunto: [SEVERIDADE] Incidente de Segurança - CSuite
Prezados,
Informamos que foi detectado um incidente de segurança no CSuite.
**Resumo:**
[Breve descrição]
**Impacto:**
[Serviços/dados afetados]
**Status:**
[Contido/Em investigação/Resolvido]
**Ações Tomadas:**
[Lista de ações]
**Próximos Passos:**
[O que será feito]
Mais informações serão compartilhadas conforme a investigação progride.
Equipe de Segurança CSuite
Melhorias Contínuas
Revisar e Atualizar:
1. Procedimentos de resposta
2. Monitoramento e alertas
3. Treinamento da equipe
4. Documentação
5. Testes de segurança
📞 Contatos de Emergência
Equipe de Segurança
| Função | Nome | Contato | Disponibilidade |
|---|---|---|---|
| Security Lead | - | - | 24/7 para P1 |
| On-Call Security | - | - | 24/7 |
| DevOps Lead | - | - | Horário comercial |
| CTO/CIO | - | - | Para P1 |
Escalation Path
- Nível 1: On-Call Security (15 min)
- Nível 2: Security Lead + DevOps Lead (30 min)
- Nível 3: CTO/CIO + Legal (1 hora)
Canais de Comunicação
- Slack: #csuite-security-incidents
- Email: security-incidents@internut.com.br
- Telefone: (verificar com equipe)
🔗 Documentos Relacionados
- DISASTER_RECOVERY.md - Plano de recuperação de desastres
- TROUBLESHOOTING.md - Guia de troubleshooting
- RUNBOOKS_OPERACIONAIS.md - Runbooks operacionais
Última Revisão: 2025-01-02
Próxima Revisão: 2025-04-02 (trimestral)
Classificação: CONFIDENCIAL