Capítulo 18 — Arquitetura de segurança
Mapa da aula
Aula 18 publicada. Mapa, exemplo, EX052.
flowchart TD
N0["18.1 O que significa arquitetura"]
N1["18.2 Zonas e fronteiras"]
N2["18.3 Posicionamento de sensores"]
N3["18.4 Protegendo o SOC"]
N4["18.5 Mapeamento às ameaças"]
N5["18.6 Simplicidade"]
N6["18.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX052"]
Desenho lógico
flowchart LR
N0["18.1 O que significa arquitetura"]
N1["18.2 Zonas e fronteiras"]
N2["18.3 Posicionamento de sensores"]
N3["18.4 Protegendo o SOC"]
N4["18.5 Mapeamento às ameaças"]
N5["18.6 Simplicidade"]
N6["18.7 Caso"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[18.1 O que significa arquitetura]
|
v
[18.2 Zonas e fronteiras]
|
v
[18.3 Posicionamento de sensores]
|
v
[18.4 Protegendo o SOC]
|
v
[18.5 Mapeamento às ameaças]
|
v
[18.6 Simplicidade]
|
v
[18.7 Caso]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX052]
Objetivos de aprendizagem
Você vai (1) descrever a arquitetura de segurança como o posicionamento estruturado de controles; (2) projetar zonas de rede e fronteiras de confiança; (3) posicionar sensores onde eles veem a atividade mais relevante; (4) avaliar a arquitetura em relação às ameaças.
18.1 O que significa arquitetura
A arquitetura de segurança decide onde ficam os controles e como os componentes confiam uns nos outros. É a estrutura que faz os controles individuais trabalharem juntos, em vez de formarem uma pilha de produtos. Produtos comprados separadamente podem se sobrepor em algumas áreas e deixar lacunas em outras. A arquitetura parte dos sistemas e dados a proteger, decide de que controles cada um precisa e então escolhe produtos para cumprir esses papéis. Ela também define como as partes confiam umas nas outras, como quais sistemas podem enviar logs ao SIEM e como provam quem são.
18.2 Zonas e fronteiras
A Lindqvist separa o portal voltado para a internet, os sistemas internos de negócio, as redes dos depósitos que operam os leitores portáteis e os próprios sistemas do SOC. Cada fronteira tem regras sobre o que pode atravessá-la. As fronteiras são onde o monitoramento é mais informativo, porque o tráfego legítimo que as atravessa é limitado e conhecido. Dentro de uma zona, muitos sistemas conversam livremente e o tráfego é difícil de julgar. Numa fronteira, só fluxos específicos devem passar: o portal pode chamar o sistema de pedidos numa porta, os depósitos podem enviar dados de leitura a um servidor. Qualquer outra coisa que atravesse é suspeita por definição, o que dá ao monitoramento uma linha de base clara para comparação.
18.3 Posicionamento de sensores
Os sensores devem ficar onde veem a atividade relevante com pouco ruído: na camada web, para o portal; nos controladores de domínio, para a autenticação; na fronteira entre as redes de negócio e dos depósitos. Pôr um único sensor grande na borda da internet vê muito tráfego, mas pouco contexto. Um sensor de borda vê cada pacote vindo da internet, a maior parte dele ruído de varredura, sem saber a que conta de cliente uma requisição se referia. Um sensor na camada web vê a requisição decifrada e o nome de usuário. Posicionar sensores onde o significado está disponível, e não onde o volume é maior, dá aos analistas eventos em menor número e mais ricos para trabalhar.
18.4 Protegendo o SOC
O SIEM e o sistema de casos são alvos valiosos: mostram o que os defensores conseguem ver. Ficam em sua própria zona, com contas de administrador separadas e autenticação multifator. Um atacante que controle o SIEM pode ver quais alertas existem, descobrir quais ações estão sendo detectadas ou apagar evidências. Contas de administrador separadas fazem com que uma conta de funcionário comprometida na zona de negócio não consiga alcançar os sistemas do SOC. O SOC também monitora os próprios sistemas, com alertas sobre mudanças de configuração e sobre logins vindos de fora da zona do SOC.
18.5 Mapeamento às ameaças
Os arquitetos conferem cada técnica importante do ATT&CK contra a arquitetura: que controle a previne, que sensor a veria e que equipe responderia. As lacunas viram itens do backlog. O D3FEND ajuda a nomear a técnica defensiva que cada controle oferece. O exercício produz uma tabela: cada técnica numa linha, com colunas para prevenção, detecção e responsável pela resposta. As células vazias são lacunas. Nem toda lacuna precisa ser fechada; algumas técnicas são improváveis contra a Lindqvist, e a discussão de risco decide as prioridades. Os nomes do D3FEND, como credential hardening, facilitam comparar controles entre produtos.
18.6 Simplicidade
Arquiteturas complexas escondem lacunas. Menos fronteiras, e bem compreendidas, são mais fáceis de monitorar. Cada fronteira extra precisa de suas próprias regras, sensores e manutenção, e as exceções se acumulam com o tempo até que ninguém lembre por que um fluxo é permitido. Fundir zonas que servem ao mesmo propósito pode tornar o monitoramento mais claro. Amara observa que a Lindqvist tem três projetos de rede de depósito ligeiramente diferentes, o que multiplica o trabalho de definir o tráfego normal de cada um. Ela propõe um projeto padrão de depósito, implantado à medida que o equipamento de cada local for substituído, para que a linha de base só precise ser definida uma vez.
18.7 Caso
Amara revisa onde os logs do portal são produzidos e descobre que o balanceador de carga, que vê os endereços reais dos clientes, não estava encaminhando seus logs; os servidores web viam apenas o endereço do balanceador em algumas requisições. Como o balanceador substituía os endereços dos clientes pelo seu próprio em algumas requisições, os logs dos servidores web mostravam muitas tentativas vindas de um único endereço interno. Agregar por rede então agrupava clientes sem relação entre si e escondia as fontes reais. Encaminhar os logs do balanceador, e configurá-lo para repassar o endereço original num cabeçalho, corrige tanto os dados quanto a precisão da regra.
Exemplo resolvido
Antes que essa mudança entre em produção, Paolo só a aprova depois de verificar que o cabeçalho não pode ser forjado de fora: o balanceador sobrescreve qualquer cabeçalho que um cliente envie, então o endereço registrado é confiável.
Caso sintético. A arquitetura e as zonas são inventadas.
Erros e limites
Os diagramas de arquitetura se afastam da realidade; verifique com o tráfego e a configuração, não apenas com os desenhos.
Exercícios
- EX052 — Monitoramento de fronteiras. Por que o monitoramento é mais informativo nas fronteiras de confiança? Rubrica: 3 = o tráfego legítimo que atravessa é limitado e conhecido; 2 = parcial; 1 = vago; 0 = nada.
- EX053 — Lacuna do balanceador de carga. Que lacuna Amara encontrou, e como foi fechada com segurança? Rubrica: 3 = logs do balanceador não encaminhados; cabeçalho do cliente acrescentado, o balanceador sobrescreve o cabeçalho enviado pelo cliente; 2 = parcial; 1 = ignorada; 0 = nada.
- EX054 — Proteção do SOC. Como os próprios sistemas do SOC são protegidos? Rubrica: 3 = zona própria, contas de administrador separadas, MFA; 2 = duas; 1 = uma; 0 = nada.
Síntese
Uma boa arquitetura posiciona controles e sensores nas fronteiras, protege o próprio SOC e é conferida em relação às ameaças.
Continue estudando — capítulo 18 de 50
← Capítulo 17 (rascunho) · Índice de capítulos do curso · Capítulo 19 (rascunho) →