CSIRT: O Time Que Transforma Incidente Em Controle

Um CSIRT não é “o time que resolve alerta”. Também não é um grupo heroico que aparece quando tudo já está pegando fogo. Um CSIRT maduro é uma função operacional: recebe sinais, confirma incidentes, coordena resposta, preserva evidência, reduz impacto e força a organização a aprender com a própria falha.

A diferença entre uma empresa com CSIRT e uma empresa sem CSIRT aparece no primeiro incidente sério. Sem CSIRT, todo mundo pergunta “quem decide?”. Com CSIRT, já existe dono, severidade, canal, plano, evidência, contenção e comunicação.

O Que Um CSIRT Realmente Faz

O trabalho central de um CSIRT é reduzir quatro tempos:

• Tempo até detectar
• Tempo até entender
• Tempo até conter
• Tempo até recuperar

Um CSIRT não é “o time que resolve alerta”. Também não é um grupo heroico que aparece quando tudo já está pegando fogo. Um CSIRT maduro é uma função operacional: recebe sinais, confirma incidentes, coordena resposta, preserva evidência, reduz impacto e força a organização a aprender com a própria falha.

A diferença entre uma empresa com CSIRT e uma empresa sem CSIRT aparece no primeiro incidente sério. Sem CSIRT, todo mundo pergunta “quem decide?”. Com CSIRT, já existe dono, severidade, canal, plano, evidência, contenção e comunicação.

O Que Um CSIRT Realmente Faz
O trabalho central de um CSIRT é reduzir quatro tempos:

Tempo até detectar
Tempo até entender
Tempo até conter
Tempo até recuperar

O resto é suporte a isso: playbooks, automação, forense, threat intel, comunicação, métricas, tabletop exercises e melhoria contínua.

Um CSIRT bom não tenta centralizar tudo. Ele coordena. Infra executa mudança. Jurídico avalia exposição. Comunicação fala com clientes. Engenharia corrige causa raiz. Liderança aceita risco. O CSIRT mantém o incidente coerente.

Incidente Não É Alerta

Alerta é sinal. Incidente é violação confirmada ou ameaça iminente contra política, sistema, dado ou operação.

Essa distinção importa porque tratar todo alerta como incidente destrói o time. E tratar incidente como “só mais um alerta” destrói a empresa.

Um fluxo saudável:

Signal -> Triage -> Investigation -> Incident Declaration -> Containment -> Eradication -> Recovery -> Lessons Learned

Nem tudo passa para incidente. Mas tudo que passa precisa ter severidade, owner e registro.

Modelo De Severidade

Um CSIRT precisa de severidade operacional, não estética.

Exemplo direto:

Severidade	Critério
SEV-1	Comprometimento ativo, impacto em produção, exfiltração provável, ransomware, acesso privilegiado confirmado
SEV-2	Comprometimento limitado, credencial sensível vazada, exploração provável, movimento lateral possível
SEV-3	Tentativa bloqueada, exposição pontual, vulnerabilidade explorável sem evidência de abuso
SEV-4	Ruído investigativo, falso positivo provável, melhoria preventiva

A severidade inicial pode mudar. O erro é fingir certeza cedo demais. Incidente começa com hipótese, não com conclusão.

Evidência Antes De Ego

Em resposta a incidente, opinião sem evidência atrapalha.

O CSIRT precisa preservar:

• logs de autenticação;
• logs de rede;
• eventos EDR;
• histórico de comandos;
• artefatos de disco;
• imagem ou snapshot quando necessário;
• hash de arquivos suspeitos;
• timeline de ações;
• quem fez o quê e quando.

Toda ação de contenção pode destruir evidência. Às vezes isolar uma máquina é correto. Às vezes desligar é ruim. Às vezes rotacionar segredo rápido salva o ambiente. Às vezes denuncia ao atacante que você percebeu.

Resposta boa é técnica e contextual.

Contenção Não É Correção

Contenção é parar sangramento. Correção é remover causa raiz.

Exemplos:

• Bloquear IP não corrige credencial vazada.
• Reiniciar servidor não corrige webshell.
• Remover malware não corrige vetor inicial.
• Trocar senha não corrige máquina comprometida.
• Aplicar patch não responde se já houve exfiltração.

Um CSIRT maduro separa:

Containment: limitar dano agora.
Eradication: remover persistência e vetor.
Recovery: voltar com segurança.
Post-incident: impedir repetição.

Comunicação É Controle Técnico

Durante incidente, silêncio cria caos. Comunicação ruim cria pânico.

O CSIRT deve ter canais definidos:

• canal interno do incidente;
• bridge de decisão;
• registro central de timeline;
• atualizações executivas;
• comunicação legal/compliance;
• comunicação externa, se necessária.

A regra é simples: uma fonte de verdade.

Sem isso, engenharia diz uma coisa, suporte diz outra, liderança decide com dado velho e o time técnico perde tempo explicando o mesmo fato dez vezes.

Playbooks Que Prestam

Playbook bom não é documento bonito. É decisão pronta.

Playbooks essenciais:

• credencial vazada;
• host Linux comprometido;
• ransomware;
• phishing com conta comprometida;
• vazamento de segredo em GitHub;
• exploração de CVE crítica;
• abuso de cloud IAM;
• container comprometido;
• incidente em Kubernetes;
• exfiltração suspeita;
• DDoS;
• comprometimento de CI/CD.

Cada playbook precisa conter:

• sinais de entrada;
• dados mínimos para triagem;
• severidade provável;
• ações de contenção;
• evidências a preservar;
• responsáveis;
• critérios de recuperação;
• comunicação necessária;
• checklist pós-incidente.

Métricas Que Importam

Métrica ruim incentiva comportamento ruim. “Número de alertas fechados” só mede fábrica de clique.

Métricas melhores:

• MTTD: tempo médio até detectar;
• MTTA: tempo médio até assumir;
• MTTC: tempo médio até conter;
• MTTR: tempo médio até recuperar;
• porcentagem de incidentes com causa raiz identificada;
• porcentagem de playbooks exercitados;
• tempo para revogar credencial crítica;
• cobertura de logs por sistema crítico;
• reincidência por mesma causa.

O objetivo não é parecer rápido. É ficar melhor.

O Erro Mais Comum

O erro mais comum é montar CSIRT só com ferramenta.

SIEM não é CSIRT. EDR não é CSIRT. SOAR não é CSIRT. Threat intel feed não é CSIRT.

Ferramenta amplia capacidade. Mas quem decide severidade, preserva evidência, coordena contenção, entende negócio e conduz recuperação é processo humano com apoio técnico.

CSIRT é disciplina operacional.

Checklist Final

Um CSIRT minimamente sério precisa responder “sim” para:

• Existe política clara de incidente?
• Existe canal oficial de acionamento?
• Existe escala de severidade?
• Existe plantão ou responsável?
• Existem playbooks testados?
• Logs críticos estão disponíveis?
• Evidência pode ser preservada?
• Segredos podem ser rotacionados rápido?
• Backup foi testado?
• Jurídico/compliance sabe quando entrar?
• Liderança sabe quem decide?
• Pós-incidente vira melhoria real?

Se não, você não tem CSIRT. Você tem boa vontade em horário comercial.

Conclusão

CSIRT não é sobre evitar todo incidente. É sobre impedir que um incidente vire colapso.

Infraestrutura falha. Credenciais vazam. CVEs aparecem. Pessoas clicam. Deploy quebra. Atacantes insistem.

A maturidade está em detectar cedo, decidir rápido, conter com precisão, recuperar com evidência e aprender sem teatro.

Referências úteis: NIST SP 800-61 Rev. 3, FIRST CSIRT Services Framework, CISA Incident Response Plan Basics.