Engenharia de Deteção

Cada caminho de ataque encontrado na linha torna-se uma deteção. Descobertas de pentest e bounty tornam-se casos de uso do SOC para a sua stack.

Do caminho de ataque ao alerta

Uma descoberta de pentest, levada até ao ecrã de um analista.

Escolha um passo, ou deixe correr. Cada fala é o que alguém na sala diz de facto.

De pentests, relatórios de bounty e threat models.

ATALAIANove caminhos de ataque dos vossos pentests e bounty. São reais. Funcionaram.

OFENSIVAO IDOR em /redeem é o que voltaríamos a tentar.

Sai da sala9 caminhos de ataque de pentests e bounty

Que log, evento ou métrica mostraria cada um.

SOCComo é que isso apareceria nos nossos logs?

ATALAIAUm utilizador a pedir ofertas de muitos outros. Mas o /redeem não regista o dono.

DEV LEADAdicionamos o ID do dono ao access log neste sprint.

Sai da salaSinal: utilizador ≠ dono em /redeem

Regras, e depois simulações de ataque que provam que disparam.

ATALAIARegra: um utilizador, mais de cinco IDs de ofertas alheias em dez minutos.

OFENSIVAA correr o ataque em staging agora.

SOCAlerta disparou. Quarenta segundos.

Sai da salaRegra escrita, simulação disparada

Limiares e runbooks com que os analistas concordam.

SOCOs agentes de suporte vão dispará-lo. Consultam ofertas o dia todo.

ATALAIAEntão exclui-se a função de suporte e mantém-se para os restantes. Eis o runbook.

Sai da salaRunbook, limiar acordado

“Adicionamos o ID do dono ao access log neste sprint.”
DEV LEAD · passo 2, Encontrar o sinal

A maioria dos SOCs vigia sinais genéricos. Os ataques que importam são os que os seus próprios pentests já encontraram.

Formato típico: contínuo, um lote de casos de uso por ciclo.

Todas as estações reportam à mesma torre. Estas são as vizinhas.

Com âmbito, manual, retestado

Novas ameaças verificadas contra a sua stack

Âmbito, triagem, recompensas, correções

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.