Como Escrever um Ticket de Investigação Profissional em SOC

Porquê o Ticket é um Produto de Investigação

Um bom Ticket serve vários públicos simultaneamente: o analista atual, o próximo turno, o Tier 2, a equipa de IR, o gestor de SOC e, por vezes, também o IT ou o proprietário do sistema. Cada um deles tem uma necessidade diferente, pelo que a documentação deve ser em camadas: um resumo rápido no início, detalhes técnicos no corpo e provas ou links no anexo.

A documentação também protege contra vieses de memória. Durante uma investigação, é fácil lembrar a conclusão e esquecer o caminho. Quando cada Query, descoberta e decisão são registadas em tempo real, é possível rever e verificar se a conclusão ainda é válida após o surgimento de novas informações.

Em caso de incidente confirmado, o NIST enfatiza a importância da documentação e coordenação como parte da capacidade de resposta. A documentação não é apenas "o que fizemos", mas também quando, quem aprovou, qual foi o resultado e quais limitações afetaram a decisão.

Estrutura Recomendada para um Ticket

Comece com um título descritivo e não apenas com o nome de uma regra. "Encoded PowerShell on DC01 after privileged login" é mais útil do que "Rule 4827". Na linha de resumo, escreva quem, o quê, quando e o estado atual. Depois, apresente o Scope, Timeline, Evidence, Analysis, Actions e Next Steps.

Use um modelo fixo, mas não o transforme num formulário preenchido com campos vazios. Se um campo não for relevante, indique "não relevante" ou remova-o de acordo com a política do sistema. Um campo vazio cria dúvidas sobre se foi esquecido ou não verificado.

Facto, Interpretação e Hipótese

Um facto é um dado observado na fonte: “Event ID 4688 registou powershell.exe às 10:14:22 UTC”. Uma interpretação é um significado profissional: “Parent de WINWORD.EXE e linha de comando codificada levantam suspeita de execução a partir de documento”. Uma hipótese é uma possibilidade ainda não verificada: “Pode ser que o utilizador tenha aberto um ficheiro de Phishing”.

Quando as três camadas são escritas na mesma frase, o leitor pode tratar a hipótese como um facto. Por isso, use etiquetas ou uma formulação clara: Observed, Assessment, Hypothesis. Adicione Confiança — alta, média ou baixa — e explique brevemente em que se baseia.

Mesmo ao fechar um incidente, documente a explicação alternativa. “Atividade legítima” não é suficiente; escreva quem aprovou, qual Change existe, quais detalhes corresponderam e o que foi incomum, mas explicável.

Como Citar Registos Sem Exagero

Não copie dezenas de linhas de Raw Log para o corpo do Ticket. Selecione os campos que provam a alegação: Timestamp, Host, User, Process, Parent, Command Line, Source/Destination, Result e Event ID. Guarde um link para a pesquisa ou para a evidência completa quando o sistema o permitir.

Ao citar uma Query, documente o ambiente de tempo, o Data Source e os filtros. “Nenhum evento encontrado” sem mencionar o intervalo de tempo e a tabela não é um achado reproduzível. Escreva, por exemplo: “A pesquisa de SecurityEvent para user1 nas 24 horas anteriores ao alerta não retornou Logon do tipo 10 de outros dispositivos”.

Não altere Raw Evidence para que seja legível. Pode apresentar uma versão resumida, mas guarde a fonte e o Hash conforme necessário. Informações sensíveis, segredos e PII devem ser armazenados no canal aprovado e de acordo com a política da organização.

Como Documentar Queries e Ações

Para cada Query significativa, registe o objetivo e o resultado: “Objetivo: Verificar Password Spray. Query: Falhas por Source IP e utilizador. Resultado: 37 utilizadores, sem sucesso”. Uma lista como esta evita repetições e mostra quais Hypotheses foram verificadas.

Numa ação de resposta, indique Actor, Time, Approval, Action e Outcome. Por exemplo: “10:32 UTC — o gestor de IT aprovou a Desativação da conta; 10:34 — a conta foi desativada; 10:36 — Refresh Tokens foram revogados; 10:40 — nenhuma nova Session observada”.

Se uma ação falhou, ainda faz parte da documentação. Escreva a mensagem de erro ou a razão e escale. Ocultar uma falha cria uma imagem errada da situação de contenção.

Ticket Fraco vs. Ticket Profissional

Exemplo Completo Abreviado

Título: “Successful external login followed by mailbox rule creation — user1”. Resumo: Às 07:11 UTC, registou-se um login bem-sucedido de um país não observado para o utilizador; quatro minutos depois, foi criada uma regra de Mailbox que encaminha mensagens com a palavra “invoice” para uma pasta oculta. O utilizador não reconhece a atividade. A conta foi temporariamente desativada e o incidente escalado para IR.

Factos: Entra Sign-in mostra um Dispositivo não gerido e MFA satisfied by claim; Audit Log mostra New-InboxRule; nenhuma Change encontrada. Análise: Não foi identificada uma explicação legítima, e a ação corresponde à persistência e acesso a e-mail. Confiança alta. Scope: conta user1; regras, concessões OAuth e Sessions adicionais estão a ser verificadas. Próximo passo: Revogar sessions, Reset credentials, Review mailbox access e notificação ao proprietário dos dados de acordo com o Playbook.

Lista de Verificação Prática

• ✓O título descreve o comportamento e a entidade, não apenas o nome da regra.
• ✓O resumo responde ao que aconteceu e qual é o estado atual.
• ✓O Scope e o Timeline são claros.
• ✓Separei facto, interpretação e hipótese.
• ✓Mencionei Queries, intervalos de tempo e resultados.
• ✓Documentei Ações, aprovação e resultado.
• ✓Adicionei Classificação e justificação.
• ✓Existe um Next Step com Owner e prazo.
• ✓Não há segredos ou informações sensíveis em canais não autorizados.

Erros Comuns

• Escrever “verifiquei e está tudo bem” sem evidências.
• Copiar Raw Logs longos em vez de campos relevantes.
• Não documentar Negative Findings e intervalos de pesquisa.
• Alterar a história retroativamente sem mencionar a atualização.
• Fechar o Ticket antes que a Ação seja verificada.
• Usar uma hipótese como título factual.

Resumo e CTA

Pegue um Ticket antigo ou um cenário de laboratório e reescreva-o de acordo com a estrutura do artigo. Peça a alguém que não participou na investigação para lê-lo e responder: o que aconteceu, quais são as evidências e qual é o próximo passo. No curso de Cybersecurity & AI da HPI, a investigação e a documentação são praticadas como parte do trabalho de SOC e não como um exercício separado.

Perguntas frequentes