Capítulo 2 — Operações de segurança e blue team: seminário avançado

Mapa da aula

Aula 02 publicada. Mapa, exemplo, EX008.

flowchart TD
  N0["2.1 O que um SOC faz"]
  N1["2.2 Engenharia de detecção"]
  N2["2.3 Monitoramento contínuo"]
  N3["2.4 Métricas e efeitos colaterais"]
  N4["2.5 Modelos de maturidade"]
  N5["2.6 Formato do seminário"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX008"]

Desenho lógico

flowchart LR
  N0["2.1 O que um SOC faz"]
  N1["2.2 Engenharia de detecção"]
  N2["2.3 Monitoramento contínuo"]
  N3["2.4 Métricas e efeitos colaterais"]
  N4["2.5 Modelos de maturidade"]
  N5["2.6 Formato do seminário"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX008"]

[2.1 O que um SOC faz]
    |
    v
[2.2 Engenharia de detecção]
    |
    v
[2.3 Monitoramento contínuo]
    |
    v
[2.4 Métricas e efeitos colaterais]
    |
    v
[2.5 Modelos de maturidade]
    |
    v
[2.6 Formato do seminário]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX008]

Objetivos de aprendizagem

Você vai (1) discutir criticamente modelos e funções de SOC; (2) relacionar a engenharia de detecção a frameworks; (3) debater métricas e seus efeitos colaterais; (4) apresentar um argumento de seminário com fontes.

2.1 O que um SOC faz

Knerler, Parker e Zimmerman (2022) descrevem as funções de um SOC, do monitoramento e da análise à resposta a incidentes, à inteligência de ameaças e a serviços ampliados como a caça a ameaças. Sua primeira estratégia, "saiba o que você está protegendo e por quê", ancora as decisões de ajuste: uma regra importa conforme os ativos que ela guarda. Para a Pelham, saber o que está protegido significa saber que uma regra que guarda os servidores de gestão de patches importa mais do que uma que guarda os monitores das salas de reunião. Essa ordem afeta o ajuste: uma lista de permissão numa regra que vigia a conta de aplicação de patches traz mais risco se estiver errada, e é exatamente aí que o estudo de Tariq depois encontra um problema.

2.2 Engenharia de detecção

As detecções são escritas, testadas, implantadas e mantidas como software. O MITRE ATT&CK (Strom et al., 2018) oferece um vocabulário comum do comportamento adversário para que a cobertura possa ser mapeada; o Sigma oferece um formato de regra portátil. O D3FEND (Kaloroumakis e Smith, 2021) mapeia técnicas defensivas, ajudando as equipes a ver a que contramedida uma detecção pertence. Tratar as regras como software é o que torna o estudo de Tariq possível: as regras da Pelham são guardadas em formato Sigma, e as entradas das listas de permissão ficam sob controle de versão com seus motivos, de modo que o ajuste pode ser descrito, comparado e revisado. Mapear cada uma das vinte regras para uma tática do ATT&CK também lhe permitiu parear regras ajustadas e de controle pela tática.

2.3 Monitoramento contínuo

A NIST SP 800-137 enquadra o monitoramento como um programa contínuo ligado ao risco, com frequências e métricas definidas, e não como um conjunto de ferramentas. Para Tariq, isso significa que o ajuste não é um projeto que termina na semana 8. As listas de permissão mudam o que o SOC monitora, inclusive na regra que vigia a conta de aplicação de patches, então pertencem ao programa de monitoramento, com sua própria frequência de revisão e sua métrica. As recomendações dele depois tornam isso concreto: reprodução trimestral das entradas das listas de permissão contra eventos de purple team, e testes de ataques suprimidos acompanhados ao lado do volume.

2.4 Métricas e efeitos colaterais

Contar alertas fechados recompensa a velocidade em vez da profundidade; o tempo médio de resolução pode levar os analistas a fechar casos incertos. Kokulu et al. (2019) constataram que esses desencontros de métricas são um problema frequente. O seminário de Tariq argumenta que os estudos de ajuste precisam medir os ataques suprimidos junto com o volume, ou recompensarão o silêncio. A pergunta de Tariq no seminário afia o argumento: que taxa de ataques suprimidos um analista aceitaria por um corte de 30% no volume? Fazê-la obriga uma equipe a declarar o custo-benefício antes do ajuste, em vez de descobri-lo depois. Sem uma medida de ataques suprimidos, um projeto de ajuste só consegue relatar sucesso.

2.5 Modelos de maturidade

O SOC-CMM (van Os, 2016) avalia os domínios de negócio, pessoas, processo, tecnologia e serviços. Ele ajuda a situar o ajuste dentro da maturidade de processo, em vez de tratá-lo como uma limpeza pontual. Para a Pelham, o enquadramento do SOC-CMM situa o trabalho de Tariq no domínio de processo: as entradas das listas de permissão precisam da mesma revisão, do mesmo controle de versão e dos mesmos testes periódicos que as regras. O comentário posterior do revisor externo, de que o processo de revisão dele pressupõe um processo de mudanças maduro, é uma questão de maturidade exatamente nesse sentido. O modelo também dá à Pelham uma forma de mostrar progresso depois do estudo, reavaliando o domínio de processo assim que a reprodução trimestral estiver funcionando.

2.6 Formato do seminário

Cada estudante apresenta uma afirmação, evidências, contraevidências e uma pergunta para discussão. A pergunta é a parte que a maioria dos estudantes negligencia. A pergunta de Tariq, citada no exemplo resolvido abaixo, obrigou o seminário a discutir um custo-benefício em vez de concordar que ruído é ruim. Apresentar contraevidências ao lado da própria afirmação também mostrou depois aos examinadores que ele havia enfrentado a objeção mais forte a ela. O slide de Tariq citava Axelsson e Kokulu et al. como evidência e Alahmadi et al. como contraevidência, e a Dra. Solberg usou a pergunta para abrir a discussão.

Exemplo resolvido

Afirmação de Tariq no seminário: "A redução do volume de alertas, sozinha, é uma métrica de sucesso enganosa." Evidência: o argumento da taxa de base de Axelsson e Kokulu et al. sobre métricas. Contraevidência: Alahmadi et al. relatam que o próprio volume causa esgotamento, então a redução tem valor. Pergunta: "Que taxa de ataques suprimidos você aceitaria por um corte de 30% no volume?"

Caso sintético. O seminário é inventado.

Erros e limites

Os frameworks mudam de versão; cite a versão usada.

Exercícios

• EX008 — Estratégia um. Como "saiba o que você está protegendo e por quê" orienta o ajuste?
  Mostrar critérios de avaliação

  Rubrica: 3 = o valor da regra depende dos ativos guardados; 2 = parcial; 1 = vago; 0 = nada.
• EX009 — Uso do ATT&CK. O que o ATT&CK oferece à engenharia de detecção?
  Mostrar critérios de avaliação

  Rubrica: 3 = vocabulário comum de comportamentos para mapear a cobertura; 2 = parcial; 1 = exploits; 0 = nada.
• EX010 — Uso do D3FEND. O que o D3FEND acrescenta?
  Mostrar critérios de avaliação

  Rubrica: 3 = mapa de técnicas defensivas/contramedidas; 2 = parcial; 1 = o mesmo que o ATT&CK; 0 = nada.
• EX011 — Programa de monitoramento. Como a SP 800-137 enquadra o monitoramento?
  Mostrar critérios de avaliação

  Rubrica: 3 = programa contínuo ligado ao risco, com frequências e métricas; 2 = parcial; 1 = ferramentas; 0 = nada.
• EX012 — Efeito colateral de métrica. Dê um efeito colateral de métrica.
  Mostrar critérios de avaliação

  Rubrica: 3 = p. ex., a contagem de fechados recompensa velocidade em vez de profundidade; 2 = parcial; 1 = vago; 0 = nada.
• EX013 — Contraevidência. Que contraevidência Tariq apresentou?
  Mostrar critérios de avaliação

  Rubrica: 3 = Alahmadi et al.: o volume causa esgotamento, então a redução tem valor; 2 = parcial; 1 = vago; 0 = nada.
• EX014 — Enquadramento de maturidade. Como o SOC-CMM muda a visão do ajuste?
  Mostrar critérios de avaliação

  Rubrica: 3 = parte da maturidade de processo, não limpeza pontual; 2 = parcial; 1 = vago; 0 = nada.

Síntese

A prática avançada de SOC liga as detecções a frameworks, ativos e maturidade, e julga as métricas por seus efeitos colaterais.

Continue estudando — capítulo 02 de 08

← Capítulo 01 (rascunho) · Índice de capítulos do curso · Capítulo 03 (rascunho) →