← SecurityX/CASP+: arquitetura e operação segura
17 / 17 · 70 MIN

Hipóteses, deteção e qualidade da decisão

Transforma uma hipótese em critérios testáveis e mede as consequências de alterar uma regra de deteção.

Da suspeita à hipótese testável

A hipótese do exercício é que uma sequência de falhas seguida de sucesso pode justificar investigar uma conta. Define população, fontes, janela temporal, unidade de análise e explicações alternativas antes de executar a pesquisa. A regra escolhida procura pelo menos três eventos distintos de falha para o mesmo tenant e utilizador nos 300 segundos inclusivos anteriores ao sucesso. Não prova roubo de credenciais: um utilizador legítimo pode esquecer a password. Um atacante também pode usar credenciais válidas sem falhas anteriores. A investigação precisa de contexto adicional autorizado, como dispositivo, ações posteriores e alteração de privilégios. Mantém uma conclusão limitada à hipótese e aos dados disponíveis; um resultado negativo não exclui todos os comportamentos que ficaram fora do predicado.

O denominador faz parte da evidência

O laboratório tem seis casos com classificação sintética conhecida. Alpha, gamma e late representam atividade maliciosa no enunciado; beta, delta e shared em funds-b representam atividade benigna. Esta verdade foi definida para o exercício, não inferida da própria regra. Depois do replay completo, alpha e late alertam: são dois verdadeiros positivos. Beta também alerta: é um falso positivo. Gamma não alerta porque só tem duas falhas: é um falso negativo. Delta e shared não alertam corretamente: são dois verdadeiros negativos. Os casos de fronteira temporal, relógio e ausência de telemetria servem outros testes e não entram nesta matriz. Misturar casos sem rótulo no denominador criaria uma precisão aparente sem fundamento. Em produção, documenta como a classificação foi obtida e quais os casos ainda desconhecidos.

Precisão e recall respondem a perguntas distintas

Precisão é TP/(TP+FP): neste conjunto, dois dos três alertas classificados correspondem à atividade maliciosa definida. Recall é TP/(TP+FN): dois dos três casos maliciosos conhecidos foram encontrados. Ambos dão 2/3, mas essa coincidência não torna as métricas equivalentes. Se não houver alertas, o denominador da precisão é zero; o script devolve null em vez de declarar 100%. Se não houver casos positivos classificados, o recall também fica indefinido. Acrescentar muitos casos benignos sem alerta pode elevar a accuracy sem encontrar o ataque que falta. Por isso, conserva as contagens absolutas, a composição da amostra e o período analisado. Os seis casos didáticos não suportam uma previsão estatística da eficácia real nem da capacidade da equipa SOC.

Ajustar uma regra altera o compromisso

Baixar o limiar de três para dois encontra gamma neste conjunto. Isso não demonstra que o novo limiar será melhor em todas as populações; outras contas podem produzir mais ruído. Num segundo ensaio, a equipa suprime alpha e beta para reduzir volume. O único alerta classificado restante é late: a precisão sobe para 1, mas o recall cai para 1/3. A melhoria do dashboard escondeu a remoção de um caso malicioso. Uma exceção operacional deve ter motivo, âmbito, responsável, validade e teste de regressão. Antes de promover uma alteração, compara casos positivos, negativos e de fronteira, além de custo de execução e atraso até à análise. Uma regra que deteta corretamente num replay pode chegar demasiado tarde para a decisão operacional pretendida.

Transforma a investigação num controlo sustentável

O resultado da pesquisa deve permitir outra pessoa reproduzir a decisão: conserva versão da query, parâmetros, fontes, período, relógio escolhido, casos classificados e limitações. Para o handover, associa a regra a um responsável e a um procedimento de triagem. Se a fonte deixar de reportar, a cobertura deve degradar de forma visível. Se um replay voltar a encontrar a mesma conta, define se atualiza uma investigação ou abre um novo alerta; DISTINCT sobre contas no script não resolve o ciclo de vida de incidentes. Um projeto fictício de pagamentos só deve aceitar o controlo depois de provar o percurso no ambiente autorizado e de combinar resposta, acesso e retenção. O laboratório executa SQL real sobre dados inventados, sem SIEM ou ataque real, e é preparação para esses ensaios.

# Six explicitly labeled synthetic cases only:
TP, FP, FN, TN = 2, 1, 1, 2
precision = TP / (TP + FP) if TP + FP else None
recall = TP / (TP + FN) if TP + FN else None
# Suppressing alpha and beta: TP=1, FP=0, FN=2, TN=3.
# More precise alerts can coexist with more missed malicious cases.
NA PRÁTICA

Suprimir duas contas melhora a precisão de 2/3 para 1, mas reduz o recall para 1/3 porque uma das contas correspondia a um caso malicioso.

Armadilhas comuns

Usar a regra para criar os próprios rótulos; excluir falsos negativos; celebrar menos alertas sem cobertura; confundir replay com resposta em tempo útil.

Tópicos relacionados: Qualidade da telemetria · Governance e risco residual

Leva esta ideia contigo

Uma boa alteração melhora a decisão com evidência explícita sobre o que encontra, o que perde e o que custa.

Criar conta

Referência: SecurityX CAS-005 objectives · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17

CompTIA® e CASP+ são marcas comerciais ou marcas registadas de CompTIA, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por CompTIA. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.