Como Implementar NAC Pós-Admissão para Monitorização Contínua de Confiança

Bem-vindo ao Purple Enterprise Architecture Briefing. Sou o vosso anfitrião e hoje vamos abordar uma mudança crítica na segurança de rede: a transição da autenticação estática para a Monitorização Contínua de Confiança utilizando o NAC Pós-Admissão. Junta-se a mim o nosso Arquiteto de Soluções Sénior. Obrigado por estar aqui. É um prazer estar aqui. Este é um tema que surge em quase todas as discussões de design empresarial neste momento. Vamos contextualizar. Durante anos, confiámos no 802.1X e em Captive Portals para proteger a periferia da rede. Porque é que isso já não é suficiente para ambientes como grandes cadeias de retalho ou espaços de hotelaria? Tudo se resume ao modelo de confiança. O NAC tradicional — o que chamamos de NAC Pré-Admissão — é como um segurança numa discoteca. Verifica a sua identificação à porta e, se estiver na lista, entra. Mas uma vez lá dentro, o segurança não está a vigiar o que faz. No contexto de rede, um dispositivo pode autenticar-se de forma perfeitamente limpa. Mas e se, dez minutos depois, esse dispositivo descarregar um payload malicioso e começar a fazer scan à sub-rede interna do ponto de venda? O NAC Pré-Admissão já fez o seu trabalho e retirou-se. O NAC Pós-Admissão é o segurança que patrulha o espaço. Monitoriza continuamente a sessão e pode intervir de forma dinâmica. Portanto, estamos a falar de análise comportamental em tempo real. Como é que isso funciona realmente nos bastidores? Exatamente. Requer dois componentes principais: a ingestão de telemetria e um motor de políticas dinâmico. Primeiro, precisamos de visibilidade. Os Dispositivos de Acesso à Rede — os controladores de LAN sem fios, os switches — precisam de transmitir telemetria de volta para o motor NAC. Estamos a falar de NetFlow, IPFIX, dados de contabilidade RADIUS. O motor NAC utiliza isto para estabelecer uma linha de base comportamental. Como é o tráfego normal de um dispositivo de convidado num hotel? Como é o tráfego normal de uma bomba de infusão médica? Assim que tiver essa linha de base, os desvios tornam-se detetáveis. E quando uma anomalia é detetada? É aí que entra a aplicação de políticas, normalmente utilizando a Alteração de Autorização RADIUS, ou CoA. Se um dispositivo de convidado começar subitamente a gerar volumes massivos de tráfego SMB — o tipo de tráfego que veria numa infeção por ransomware —, o motor NAC deteta a anomalia e envia um pedido de CoA para o controlador sem fios. O controlador pode então desligar o cliente, colocá-lo numa VLAN de quarentena ou aplicar uma lista de controlo de acesso restritiva — tudo a meio da sessão, sem qualquer intervenção manual da sua equipa de rede. Isso parece poderoso, mas também potencialmente disruptivo se não for implementado corretamente. Quais são os erros comuns que vê no terreno? O maior erro é ativar a aplicação ativa demasiado rápido. É necessário seguir uma abordagem faseada. A fase um é sempre Apenas Monitorizar. Precisa de deixar o sistema ingerir telemetria e criar linhas de base precisas. Se saltar diretamente para a aplicação, irá gerar falsos positivos e, num ambiente de hotelaria ou espaço público, desligar utilizadores legítimos é um pesadelo operacional. Digo sempre aos clientes: Monitorizar, Medir, Mitigar. Essa é a estrutura. A estrutura Monitorizar, Medir, Mitigar. Vamos analisar isso. Claro. Monitorizar significa implementar em modo passivo — toda a telemetria a fluir, sem ações de aplicação. Medir significa rever os dados, ajustar limites e testar o stress das suas políticas contra tráfego conhecido como bom. Mitigar é quando ativa a aplicação ativa, começando com uma resposta gradual — talvez uma ACL restritiva antes de uma desconexão total — e depois escalando a partir daí. Saltar diretamente para Mitigar é o erro mais comum que vejo. Qual é o segundo maior erro? Falhas de CoA. A Change of Authorization depende da porta UDP 3799. Frequentemente, as firewalls entre o motor NAC central e os routers das filiais bloqueiam este tráfego, ou os segredos partilhados RADIUS estão incorretos. Se o CoA falhar, não tem um NAC Pós-Admissão; tem apenas um sistema de alerta muito caro. Os seus registos mostrarão a anomalia, mas nada acontecerá na rede. Valide sempre o CoA num ambiente de laboratório antes do lançamento em produção. Vamos falar sobre IoT. Como é que isto se aplica a ambientes com muitos dispositivos sem ecrã (headless), como a saúde? É indiscutivelmente ainda mais crítico aí. Muitos dispositivos IoT médicos não suportam 802.1X, pelo que dependem de MAC Authentication Bypass, ou MAB. O MAB é incrivelmente vulnerável a MAC spoofing — um atacante pode clonar o endereço MAC de um dispositivo fidedigno e obter acesso à rede clínica. O NAC Pós-Admissão mitiga isto ao traçar o perfil de comportamento do dispositivo. Uma bomba de infusão tem um padrão de tráfego muito previsível — comunica com um servidor interno específico numa porta específica, a intervalos regulares. Se um dispositivo se autenticar com o endereço MAC da bomba mas começar a executar varrimentos de portas ou a comunicar com endereços IP externos, a monitorização contínua deteta-o instantaneamente e coloca a porta do switch em quarentena. Esse é um caso de utilização convincente. E quanto a grandes espaços públicos — estádios, centros de conferências? Ambientes de alta densidade são ideais para esta abordagem, mas trazem os seus próprios desafios. Está a lidar com milhares de sessões simultâneas, todas a gerar telemetria. O seu motor de políticas NAC e a sua infraestrutura de registos precisam de ser dimensionados para lidar com essa taxa de ingestão. Normalmente, recomendamos uma arquitetura distribuída — coletores de telemetria locais em cada espaço que alimentam um motor de políticas centralizado — em vez de tentar transportar toda a telemetria em bruto através de uma ligação WAN. A plataforma Purple WiFi Analytics integra-se bem aqui, fornecendo contexto ao nível da sessão que enriquece a tomada de decisões do motor NAC. Vamos fazer uma sessão rápida de perguntas e respostas com base nas dúvidas mais comuns dos clientes. Primeiro: O NAC Pós-Admissão substitui a minha firewall? Não. Complementa-a. As firewalls protegem o perímetro e as fronteiras entre segmentos de rede. O NAC protege a extremidade de acesso e impede o movimento lateral dentro do mesmo segmento. Precisa de ambos. Segundo: Isto pode integrar-se com o nosso SIEM existente? Absolutamente, e deve fazê-lo. O motor de NAC deve enviar eventos para o seu SIEM para correlação. Um evento de quarentena na rede combinado com um alerta correspondente no seu sistema de deteção de endpoints é um sinal muito mais forte do que qualquer um deles isoladamente. Terceiro: Qual é o ROI imediato para um CTO? Tempo Médio de Resposta drasticamente reduzido. Está a automatizar a quarentena de dispositivos comprometidos de horas — ou dias — para milissegundos. Isso protege a sua marca, reduz a carga operacional na sua equipa de rede e fornece o registo de auditoria de que a sua equipa de conformidade precisa para PCI DSS e GDPR. Excelente. Para concluir: as principais conclusões do briefing de hoje. O NAC Pós-Admissão muda o seu modelo de segurança de uma verificação de entrada estática para uma avaliação de confiança contínua e dinâmica. O mecanismo de aplicação é o RADIUS Change of Authorization — coloque-o a funcionar de forma fiável antes de qualquer outra coisa. Implemente sempre por fases: Monitorizar, Medir, Mitigar. A definição de perfis de comportamento é a sua base — invista o tempo necessário para a estruturar corretamente. E, finalmente, esta abordagem alinha-se diretamente com os princípios de arquitetura Zero Trust, que é para onde todas as redes empresariais se estão a dirigir. Obrigado pelas perspetivas, e obrigado a todos por ouvirem o Purple Enterprise Architecture Briefing. Se quiser explorar como a plataforma da Purple pode apoiar a sua implementação de NAC Pós-Admissão, visite purple dot ai para falar com a nossa equipa de soluções.