Capítulo 20 — Operações de segurança e blue team: contexto de engenharia
Mapa da aula
Aula 20 publicada. Mapa, exemplo, EX058.
flowchart TD
N0["20.1 Missão primeiro"]
N1["20.2 Serviços do SOC"]
N2["20.3 Restrições"]
N3["20.4 Partes interessadas"]
N4["20.5 Problemas de engenharia pela frente"]
N5["20.6 Maturidade"]
N6["20.7 Medidas de sucesso"]
N7["Financiamento do SOC"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX058"]
Desenho lógico
flowchart LR
N0["20.1 Missão primeiro"]
N1["20.2 Serviços do SOC"]
N2["20.3 Restrições"]
N3["20.4 Partes interessadas"]
N4["20.5 Problemas de engenharia pela frente"]
N5["20.6 Maturidade"]
N6["20.7 Medidas de sucesso"]
N7["Financiamento do SOC"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[20.1 Missão primeiro]
|
v
[20.2 Serviços do SOC]
|
v
[20.3 Restrições]
|
v
[20.4 Partes interessadas]
|
v
[20.5 Problemas de engenharia pela frente]
|
v
[20.6 Maturidade]
|
v
[20.7 Medidas de sucesso]
|
v
[Financiamento do SOC]
|
v
[Exemplo resolvido] --> [Exercício EX058]
Objetivos de aprendizagem
Você vai (1) descrever a missão e os serviços do SOC em termos de engenharia; (2) relacionar as funções do SOC ao risco da organização; (3) identificar partes interessadas e restrições; (4) enquadrar os problemas de engenharia de SOC para o restante do curso.
20.1 Missão primeiro
Knerler, Parker e Zimmerman (2022) começam com "saiba o que você está protegendo e por quê". A Lindqvist protege dados de clientes, operações de entrega e fluxos de pagamento. As escolhas de engenharia decorrem dessa missão, e não dos recursos das ferramentas. Começar pelas ferramentas leva a coletar tudo o que a ferramenta suporta. Começar pela missão leva a perguntar que dano importaria mais: dados de clientes roubados, entregas paradas ou pagamentos desviados. Essas respostas decidem quais sistemas precisam da melhor cobertura e quais alertas merecem acionar alguém à noite, de modo que o esforço de engenharia segue o impacto no negócio.
20.2 Serviços do SOC
O SOC da Lindqvist oferece monitoramento e triagem, coordenação da resposta a incidentes, engenharia de detecção, recebimento de vulnerabilidades e consumo de inteligência de ameaças. Cada serviço tem clientes dentro da empresa e saídas mensuráveis. Tratar cada um como serviço esclarece a quem ele atende e como medi-lo. O monitoramento atende à empresa inteira e é medido pelos tempos de detecção e de resposta; a engenharia de detecção atende aos analistas e é medida pela qualidade das regras; o recebimento de vulnerabilidades atende às equipes de TI e é medido pela rapidez com que os relatos chegam aos responsáveis. Serviços pouco claros tendem a escorregar para trabalho não planejado.
20.3 Restrições
Orçamento, tamanho da equipe, regulação e sistemas legados restringem o projeto. Os leitores dos depósitos rodam software antigo que não comporta agentes, então o monitoramento de rede precisa cobri-los. As restrições são insumos do projeto, não desculpas. O software antigo dos leitores, que não consegue rodar um agente, exclui a telemetria de endpoint, então o projeto passa a observar o tráfego dos leitores na rede do depósito. O orçamento pode limitar os sensores, primeiro, aos depósitos mais movimentados. A regulação pode exigir que certos logs sejam guardados por períodos definidos. Cada restrição é registrada por escrito, para que leitores posteriores entendam o projeto.
20.4 Partes interessadas
O CISO define as prioridades; as operações de TI são donas dos sistemas; as equipes jurídica e de privacidade definem limites; as unidades de negócio sentem o impacto das ações de resposta. Os engenheiros de SOC precisam trabalhar com todos eles. As operações de TI podem resistir a um sensor que possa deixar seus sistemas lentos; a equipe jurídica pode limitar o conteúdo que pode ser coletado; as unidades de negócio podem se opor ao bloqueio de uma conta no horário de pico das entregas. Engenheiros que os envolvem cedo ouvem essas preocupações enquanto o projeto ainda é flexível. Amara mantém uma lista de partes interessadas com o que mais importa para cada grupo.
20.5 Problemas de engenharia pela frente
O curso acompanha quatro problemas na Lindqvist: detectar a tomada de contas no portal; monitorar as redes dos depósitos sem agentes; manter o SIEM dentro da capacidade; e provar, por meio da verificação, que o SOC funciona. Cada problema recorre a habilidades diferentes: a tomada de contas, a dados de identidade e estatística; o monitoramento dos depósitos, a redes e arquitetura; a capacidade do SIEM, a sistemas de dados e matemática; e a verificação, a testes e medição. Acompanhar a mesma empresa nos quatro permite ao curso mostrar como decisões numa área, como as camadas de armazenamento, restringem as opções em outra.
20.6 Maturidade
O SOC-CMM (van Os, 2016) avalia negócio, pessoas, processos, tecnologia e serviços. A autoavaliação da Lindqvist mostra tecnologia forte, mas documentação de processos fraca, o que orienta as prioridades. Um modelo de maturidade oferece um modo estruturado de ver forças e fraquezas no SOC inteiro. Tecnologia forte com documentação de processos fraca significa que as ferramentas funcionam, mas os resultados dependem de qual analista está no turno. A autoavaliação sugere escrever playbooks antes de comprar mais ferramentas e dá uma linha de base para repetir depois e mostrar o progresso. A avaliação é repetida a cada ano, pelo mesmo método.
20.7 Medidas de sucesso
O sucesso não é "nenhum incidente", e sim detecção mais rápida, decisões melhores e menos dano. Um ano tranquilo pode significar que nada aconteceu, ou que nada foi detectado; os dois parecem iguais numa contagem de incidentes. Medidas melhores incluem o tempo entre a primeira evidência e a detecção, o tempo até a contenção e com que frequência as decisões de resposta foram depois julgadas corretas. O SOC da Lindqvist relata essas medidas mensalmente, junto com notas honestas sobre qualquer detecção perdida. Cada medida tem uma meta declarada, e as tendências ao longo de vários meses importam mais do que o número de um único mês, que pode oscilar com um único incidente grande.
Financiamento do SOC
O orçamento do SOC compete com outros trabalhos de TI. Engenheiros que conseguem mostrar como uma mudança reduz o risco ou o tempo dos analistas obtêm apoio com mais facilidade do que os que pedem ferramentas.
Exemplo resolvido
Amara escreve um resumo de contexto de uma página: missão, serviços, restrições, partes interessadas e os quatro problemas de engenharia. Paolo acrescenta uma restrição que ela deixou passar — o SOC tem apenas dois analistas no turno da noite —, o que molda todas as decisões de alerta.
Caso sintético. O SOC da Lindqvist e sua avaliação são inventados.
Erros e limites
O contexto muda com o negócio; revise o resumo quando a empresa mudar.
Exercícios
- EX058 — Vínculo com a missão. Como a missão orienta as escolhas de engenharia? Rubrica: 3 = o que é protegido define as prioridades, não os recursos das ferramentas; 2 = parcial; 1 = vago; 0 = nada.
- EX059 — Restrição dos depósitos. Por que os leitores dos depósitos precisam ser monitorados pela rede? Rubrica: 3 = o software antigo não comporta agentes; 2 = parcial; 1 = nenhum motivo; 0 = nada.
- EX060 — Turno da noite. Por que importa o turno da noite com dois analistas? Rubrica: 3 = limita o volume de alertas que eles conseguem tratar; molda os alertas; 2 = parcial; 1 = irrelevante; 0 = nada.
Síntese
A engenharia de SOC parte da missão, dos serviços, das restrições e das partes interessadas; o restante do curso resolve problemas dentro desses limites.
Continue estudando — capítulo 20 de 50
← Capítulo 19 (rascunho) · Índice de capítulos do curso · Capítulo 21 (rascunho) →