Fundamentos de arquitetura de rede

Todo alerta tem contexto de rede

Muito analista subestima o quanto arquitetura de rede pesa no SOC. Mas pense: todo alerta que você investiga tem um contexto de rede, e toda ameaça que você caça toca a rede de alguma forma. Se você não entende como a rede foi desenhada, não consegue descobrir como o atacante está se movendo dentro dela.

O modelo que morreu

Durante quase toda a história da segurança, o modelo era simples: firewall na borda, confia em tudo que está dentro, não confia em nada que está fora. É o modelo castelo e fosso, e as muralhas são o seu perímetro.

O problema é que esse modelo não descreve mais a realidade:

• os dados da organização estão na AWS, no Azure, em algum lugar da nuvem
• os usuários trabalham de casa
• os terceirizados entram de redes que não são suas
• as aplicações SaaS estão hospedadas em fornecedores que você não controla

Não existe mais muralha. Essa mudança se chama deperimetrização, e significa que o modelo dentro versus fora ruiu.

Os quatro fatores

A prova cobra os motivos, não só o nome.

1. Adoção de nuvem. A organização não roda mais tudo em hardware próprio. Um firewall de perímetro no escritório não protege dado que está na AWS.

2. Trabalho remoto. Funcionário conectando de casa, de cafeteria ou de wi-fi de hotel. O tráfego dele nunca toca a rede interna antes de já estar conectado aos seus sistemas.

3. Dispositivos móveis. Celular e tablet são aparelho de trabalho primário para muita gente. Acessam e-mail, arquivo e sistema corporativo de qualquer lugar, entrando e saindo de redes confiáveis e não confiáveis o tempo todo.

4. Terceirização e acesso de terceiros. Contratados, fornecedores e provedores de serviço gerenciado precisam de acesso remoto. As redes deles viram porta de entrada em potencial para a sua.

O que substituiu o perímetro

Quando o perímetro caiu, duas coisas viraram a nova base da segurança de rede: identidade e segmentação.

Em vez de perguntar "este tráfego vem de dentro da nossa rede?", você passa a perguntar: quem é este usuário? este dispositivo é confiável? esta requisição específica deve ser permitida?

Essa é a virada fundamental que você precisa entender — e ela é a raiz das quatro lições seguintes desta seção.

Software defined networking

Em paralelo à mudança arquitetural, uma tecnologia mudou como as redes são construídas e administradas: SDN, que separa o control plane do data plane.

Na rede tradicional, cada equipamento toma suas próprias decisões de encaminhamento. Em SDN, um controlador centralizado toma essas decisões por todos os equipamentos.

Isso importa para você por dois motivos:

Visibilidade. Controle centralizado significa log centralizado. Você enxerga os padrões de tráfego de toda a rede de um lugar só.

Velocidade de resposta. Se precisa isolar um segmento comprometido, faz pelo controlador, em vez de entrar em equipamento por equipamento.

Ao investigar suspeita de movimento lateral, os logs do controlador SDN e os dados de fluxo são dos primeiros lugares que você olha. Cisco DNA Center e VMware NSX dão visibilidade do tráfego east-west dentro da rede — o tráfego entre sistemas internos, que é exatamente onde o atacante adora se esconder.

Na nuvem, essa visibilidade east-west vem dos VPC Flow Logs (AWS) e dos NSG Flow Logs (Azure). Eles mostram o tráfego entre seus recursos de nuvem, não só o que entra da internet.

On-premise, nuvem e híbrido

On-premise puro. Sistemas, servidores e infraestrutura em data center próprio. Visibilidade e controle totais — e responsabilidade total por patching, hardening e monitoramento.

Nuvem. Cargas rodando na infraestrutura do provedor. Você ganha escala elástica e flexibilidade, mas a visibilidade funciona de outro jeito: depende de ferramenta nativa (CloudTrail para atividade de API, VPC Flow Logs para rede, GuardDuty para detecção). Sua ferramenta on-premise não enxerga o que acontece dentro da nuvem a menos que você a integre explicitamente.

Híbrido. A maioria das organizações hoje. Parte on-premise, parte na nuvem. É o modelo mais difícil de monitorar, porque exige visibilidade dos dois ambientes ao mesmo tempo.

Num ambiente híbrido, o SIEM precisa ingerir log dos dois mundos. Microsoft Sentinel ou Splunk Cloud puxam Windows Event Logs, logs de firewall e eventos do Active Directory on-premise junto com CloudTrail, dados do Azure Monitor e alertas de carga de nuvem. Sem essa visão unificada, você fica cego para ataques que atravessam os dois ambientes.

O primeiro passo do trabalho real

Entender a arquitetura da sua organização é o passo zero de qualquer estratégia de monitoramento. Antes de detectar ameaça, você precisa saber:

• onde estão os seus dados
• como o tráfego flui
• onde estão as suas lacunas de visibilidade