Capítulo 26 — Operações de segurança e blue team: alternativas de arquitetura
Mapa da aula
Aula 26 publicada. Mapa, exemplo, EX076.
flowchart TD
N0["26.1 Modelos de SOC"]
N1["26.2 Opções de plataforma de dados"]
N2["26.3 Serviços gerenciados"]
N3["26.4 Construir ou comprar"]
N4["26.5 Registros de decisão"]
N5["26.6 Reversibilidade"]
N6["26.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX076"]
Desenho lógico
flowchart LR
N0["26.1 Modelos de SOC"]
N1["26.2 Opções de plataforma de dados"]
N2["26.3 Serviços gerenciados"]
N3["26.4 Construir ou comprar"]
N4["26.5 Registros de decisão"]
N5["26.6 Reversibilidade"]
N6["26.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[26.1 Modelos de SOC]
|
v
[26.2 Opções de plataforma de dados]
|
v
[26.3 Serviços gerenciados]
|
v
[26.4 Construir ou comprar]
|
v
[26.5 Registros de decisão]
|
v
[26.6 Reversibilidade]
|
v
[26.7 Caso]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX076]
Objetivos de aprendizagem
Você vai (1) comparar modelos de arquitetura de SOC, como centralizado, distribuído e híbrido; (2) avaliar opções de SIEM, de data lake e de serviço gerenciado; (3) pesar decisões de construir ou comprar; (4) documentar as decisões de arquitetura com seus motivos.
26.1 Modelos de SOC
Zimmerman (2014) e Knerler, Parker e Zimmerman (2022) descrevem estruturas de SOC que vão de pequenas equipes centralizadas a modelos em níveis, distribuídos e federados. A Lindqvist, com uma sede e quarenta depósitos, mantém um pequeno SOC central, com a equipe de TI dos depósitos como contatos locais. A estrutura acompanha o tamanho e a dispersão. Um modelo em níveis com muitos especialistas convém a uma organização grande; um modelo federado convém a uma com unidades de negócio independentes. Os quarenta depósitos da Lindqvist são numerosos demais para a equipe central visitá-los, mas pequenos demais para terem os próprios analistas, então os contatos de TI dos depósitos atuam como olhos e mãos no local quando necessário.
26.2 Opções de plataforma de dados
Um SIEM tradicional indexa eventos para busca rápida e regras embutidas. Uma abordagem de data lake armazena barato e consulta com flexibilidade, mas exige mais engenharia. Muitos SOCs combinam os dois: SIEM quente para dados recentes e de alto valor e um lake para dados volumosos e de longo prazo. A indexação de um SIEM torna as buscas rápidas, mas custa armazenamento e licenças cobradas por volume. Um lake guarda dados brutos com baixo custo, mas busca mais devagar e exige engenheiros para construir consultas e pipelines. Combinar os dois põe os dados onde seu uso justifica o custo: logs de autenticação recentes no SIEM, meses de logs de firewall no lake.
26.3 Serviços gerenciados
Um provedor de detecção gerenciada pode vigiar à noite e trazer um conhecimento de ameaças mais amplo, mas conhece menos o contexto local e exige acordos de escalonamento claros. A Lindqvist considera usar um para a cobertura noturna. A cobertura noturna por um provedor pode sair mais barata do que um turno da noite interno completo. Os riscos são o provedor escalonar demais ou de menos, ou não ter contexto para julgar os alertas. Acordos claros declaram quais alertas o provedor trata, o que ele pode fazer por conta própria e com que rapidez precisa chamar o engenheiro de plantão da Lindqvist.
26.4 Construir ou comprar
Construir dá controle e aderência; comprar dá rapidez e suporte. Os engenheiros estimam o custo total ao longo de vários anos, incluindo o tempo da equipe, e não apenas o preço da licença. Uma ferramenta construída se encaixa exatamente, mas precisa de pessoas para mantê-la depois que seus autores seguem adiante. Uma ferramenta comprada vem com atualizações e suporte, mas pode obrigar os processos a se ajustarem ao seu desenho. Comparar os custos em cinco anos, incluindo as horas da equipe para integração e manutenção, muitas vezes muda o quadro em relação ao preço da licença sozinho. A comparação da Lindqvist para seu sistema de casos mostra que uma licença mais barata custaria mais em trabalho de integração em dois anos, o que decide a escolha.
26.5 Registros de decisão
Cada escolha importante é escrita como um registro de decisão de arquitetura: contexto, opções, decisão, consequências. Futuros engenheiros conseguem ver por que as coisas são como são. Os registros são curtos, muitas vezes de uma página, e escritos no momento da decisão. As consequências incluem benefícios e custos, como a dependência de um formato do fornecedor. Quando uma equipe posterior se perguntar por que o lake usa um formato específico, o registro explica o raciocínio e as opções rejeitadas, poupando-a de repetir a análise. A Lindqvist os guarda junto do código.
26.6 Reversibilidade
Prefira escolhas que possam ser desfeitas. Manter os logs brutos num formato aberto torna possível trocar de plataforma mais tarde. Algumas escolhas são difíceis de reverter: dados guardados apenas num formato proprietário podem exigir uma conversão cara para serem movidos. Manter os logs brutos em formatos abertos, como linhas JSON, ao lado da cópia da própria plataforma preserva as opções. Escolhas reversíveis permitem a uma equipe andar mais depressa, já que um erro pode ser corrigido sem um grande projeto. Os termos do contrato também contam: um prazo inicial curto com um fornecedor é mais fácil de deixar do que um compromisso de cinco anos assinado em troca de desconto.
26.7 Caso
Com o armazenamento crescendo (capítulo 6), a Lindqvist precisa decidir se expande o SIEM ou acrescenta um lake para os logs de firewall e de DNS. Expandir o SIEM mantém tudo num só lugar, mas custa mais à medida que o volume cresce. Acrescentar um lake para os logs de firewall e de DNS, que são volumosos, mas pesquisados com menos frequência, mantém o SIEM para os dados de alto valor. Amara prepara a comparação com estimativas de custo em cinco anos e o efeito sobre a velocidade de investigação para cada tipo de log. A decisão vai ao CISO com uma recomendação e é registrada como registro de decisão.
Exemplo resolvido
O registro de decisão de Amara recomenda manter os dados do portal, de identidade e de endpoint no SIEM por 90 dias e enviar os logs de firewall e de DNS para um lake depois de 14 dias, com buscas no lake para as investigações. Consequência anotada: as consultas ao lake levam minutos, não segundos, então os playbooks de caça precisam levar isso em conta.
Caso sintético. As opções e as decisões são inventadas.
Erros e limites
As alegações dos fornecedores sobre escala e custo precisam ser testadas com seus próprios dados.
Exercícios
- EX076 — Plataforma híbrida. Explique a abordagem híbrida de SIEM mais lake. Rubrica: 3 = SIEM quente para dados recentes de alto valor, lake para volume/longo prazo; 2 = parcial; 1 = só um; 0 = nada.
- EX077 — Cobertura noturna gerenciada. Cite um benefício e um risco de um provedor gerenciado para as noites. Rubrica: 3 = cobertura e conhecimento mais amplo vs menos contexto local, acordos de escalonamento; 2 = um lado; 1 = vago; 0 = nada.
- EX078 — Registro de decisão. Que seções compõem um registro de decisão de arquitetura? Rubrica: 3 = contexto, opções, decisão, consequências; 2 = três; 1 = uma; 0 = nada.
Síntese
Compare estruturas de SOC e plataformas de dados pelo custo total, pela aderência e pela reversibilidade, e registre por que as decisões foram tomadas.
Continue estudando — capítulo 26 de 50
← Capítulo 25 (rascunho) · Índice de capítulos do curso · Capítulo 27 (rascunho) →