Sophos NDR: escolher a plataforma e dimensionar corretamente o sensor

O Sophos NDR pode ser executado como appliance virtual em VMware ESXi, Microsoft Hyper-V, AWS ou Nutanix, bem como em hardware certificado da Dell, NUC e OnLogic. A escolha é feita antes da implementação: os sensores virtuais e na cloud são dimensionados com base na largura de banda, nos pacotes e nos fluxos; no caso do hardware, aplicam-se exclusivamente os modelos certificados e os respetivos níveis de capacidade.

Decisão rápida: até 500 Mbit/s, 70'000 pacotes por segundo e 1'200 fluxos por segundo, a configuração padrão é suficiente para um sensor NDR virtual dedicado. Até 1 Gbit/s, 300'000 pacotes por segundo e 4'500 fluxos por segundo, estão previstas 8 vCPUs. Se qualquer uma das métricas ultrapassar o respetivo valor, são necessárias várias appliances virtuais na rede. Para larguras de banda superiores ou para um sensor físico, escolha hardware certificado com base na carga contínua e de pico efetivamente medida.

Licença e fundamentos do planeamento

A integração requer o Sophos Network Detection and Response integration license pack. A Sophos calcula a licença NDR com base no número total de utilizadores e servidores da organização. O software para appliances virtuais está incluído; podem ser implementados tantos sensores NDR quantos forem necessários ao abrigo da licença. Isto é importante quando um ambiente de maior dimensão tem de ser distribuído por vários sensores devido aos limites documentados das VMs.

Antes de escolher a plataforma, recolha os seguintes valores:

• largura de banda máxima e contínua do tráfego que será efetivamente espelhado,
• pacotes por segundo e fluxos por segundo durante o mesmo período,
• capacidade do switch ou da porta de espelhamento a partir da qual o sensor recebe o tráfego,
• número e localização previstos dos sensores,
• outras integrações de Log Collector que devam ser executadas na mesma appliance,
• microarquitetura da CPU, flags da CPU, memória e armazenamento disponíveis,
• plataforma de virtualização suportada ou modelo exato de hardware certificado.

Uma ligação à Internet, por si só, não constitui uma base de dimensionamento suficiente. O sensor processa o tráfego que lhe é espelhado. Por isso, os valores devem ser medidos no ponto de espelhamento previsto e documentados como carga contínua e de pico.

Escolher a plataforma

Appliance virtual ou cloud

Uma appliance virtual é adequada quando já existe uma das plataformas testadas, a carga se mantém dentro dos limites da VM ou pode ser distribuída de forma adequada por vários sensores. São suportados:

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

Para a AWS, a especificação técnica do Sophos NDR indica o tipo de instância c5n.2xlarge. Os mecanismos de implementação concretos, as interfaces de rede e as definições de Traffic Mirroring constam das respetivas instruções de implementação e não são determinados pela decisão de dimensionamento.

O VMware Cloud não é suportado. Para ESXi e Hyper-V, aplicam-se também os requisitos de versão e de CPU descritos abaixo. Os requisitos disponíveis, por outro lado, não incluem uma matriz de versões comum para AWS e Nutanix; os pré-requisitos de implementação devem, por isso, ser verificados na documentação da respetiva plataforma.

Hardware certificado

O hardware é uma opção quando é necessário um sensor físico dedicado ou quando um nível de capacidade certificado corresponde à carga medida. A Sophos apenas suporta o NDR em hardware com sistemas certificados. Daqui não se pode concluir que servidores x86 genéricos, variantes de modelos semelhantes ou sistemas montados pelo próprio cliente sejam suportados.

Estão certificados sistemas destas famílias:

• Dell,
• NUC,
• OnLogic.

Não basta considerar o nome do fabricante. Antes da aquisição, o modelo exato deve ser comparado com as especificações atuais em Certified hardware specifications for NDR. A instalação, a imagem de disco e os passos específicos do fabricante só são definidos depois desta decisão sobre o modelo.

Dimensionar sensores virtuais e na cloud

Recursos mínimos

Para ESXi e Hyper-V, aplicam-se os seguintes recursos mínimos:

• 4 CPUs,
• 16 GB RAM,
• 160 GB de armazenamento.

A OVA do VMware já vem pré-configurada com estes valores mínimos para o Sophos NDR e as integrações de Log Collector. A AWS utiliza o tipo de instância indicado acima. Para o Nutanix, a fonte de requisitos utilizada não especifica aqui recursos mínimos separados. No entanto, os recursos mínimos ainda não constituem uma garantia de capacidade. Para escolher entre a configuração padrão, 8 vCPUs e várias appliances, é necessário considerar as três métricas de tráfego.

Os valores-limite definem em conjunto uma classe de carga. Um sensor com 400 Mbit/s, mas 100'000 pacotes por segundo, já não se enquadra integralmente na classe Média. Se os valores forem superiores aos da classe Alta, a Sophos prevê várias appliances virtuais distribuídas pela rede; as fontes não permitem concluir que seja possível utilizar uma única VM maior acima deste limite.

A especificação técnica limita um sensor NDR virtual a um máximo de 1 Gbit/s. Este valor não anula os limites mais restritivos relativos a pacotes e fluxos.

Verificar a CPU e o hipervisor

Os requisitos de microarquitetura e de flags que se seguem aplicam-se ao sistema em que a VM é executada. No ESXi, Hyper-V e noutros hosts de VM autogeridos, as flags de CPU pdpe1gb e avx2 têm de estar disponíveis na VM. pdpe1gb é necessária para a captura de pacotes e avx2 para as funções de Machine Learning. Um número superior de vCPUs não compensa a ausência destas flags.

Para a AWS, verifique antes o tipo de instância suportado e os requisitos de implementação da AWS; as appliances físicas são validadas através do modelo certificado exato e da respetiva configuração aprovada. Daqui não se pode deduzir a necessidade de uma verificação manual adicional das flags para a AWS ou para hardware certificado.

A Sophos documenta as seguintes microarquiteturas de CPU:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh e Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 e Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples e Great Horned Owl com Zen 1, Rome com Zen 2, Milan com Zen 3 e Genoa com Zen 4.

Também podem ser utilizadas CPUs mais recentes, desde que ambas as flags necessárias estejam disponíveis. A Sophos indica que as CPUs lançadas desde o primeiro trimestre de 2015 deverão funcionar; para a aprovação, continua a ser necessária a confirmação concreta das duas flags na VM prevista.

Aplicam-se aos hipervisores as seguintes versões mínimas e limitações:

• VMware ESXi: versão 6.7 Update 3 ou posterior e VM Hardware Version 11 ou superior. Num cluster EVC, deve estar selecionado Skylake generation or later. O VMware Cloud não é suportado.
• Microsoft Hyper-V: versão 6.0.6001.18016 no Windows Server 2016 ou posterior. O Processor Compatibility Mode não é suportado.

Appliance partilhada com Log Collectors

Os valores de VM para as classes Média e Alta aplicam-se a uma appliance que execute apenas o Sophos NDR. Se também forem alojadas integrações de Log Collector, o planeamento começa pelo dimensionamento do NDR e acrescenta depois a respetiva carga. Estão documentados os seguintes limites e efeitos:

• Todas as integrações de Log Collector de uma VM, em conjunto, podem aceitar no máximo 8'000 eventos por segundo.
• Uma integração de Log Collector necessita de aproximadamente 400 MB RAM sob carga elevada.
• Com 4 CPUs, o NDR utiliza 2 CPUs; com 8 CPUs, utiliza 3 CPUs. Outras integrações podem, ainda assim, utilizar estas CPUs e afetar o volume de tráfego que o NDR consegue processar.
• Com 16 GB RAM, as integrações de Log Collector podem utilizar, em conjunto, no máximo 2 GB, para que o NDR conserve memória suficiente.
• Um Log Collector no limite máximo da taxa de eventos requer, numa VM com as 4 CPUs padrão, aproximadamente a mesma capacidade de processamento que o NDR sob carga média-alta.

Não existe uma dimensão única e universal para cargas mistas. Se for provável que os limites do NDR ou os recursos disponíveis sejam ultrapassados, devem ser planeadas appliances adicionais. Se várias integrações de Log Collector ultrapassarem, em conjunto, 8'000 eventos por segundo, devem ser utilizadas várias VMs. Se, pelo contrário, uma única integração ultrapassar este limite, tente primeiro reduzir o volume de eventos através das definições de Syslog do sistema de origem. Os valores aproximados documentados não justificam uma sobrealocação arbitrária.

Dimensionar hardware certificado

A Sophos determina o nível de hardware com base na capacidade do switch que efetua o espelhamento e na carga contínua e de pico. O sensor NDR deve ter a mesma capacidade que o switch do qual provém o tráfego espelhado. As recomendações seguintes baseiam-se numa organização típica com 20 por cento de Power Users, 60 por cento de utilizadores típicos e 20 por cento de Light Users. Pressupõem ainda VoIP, algum streaming de vídeo, uploads e downloads de grande dimensão, bem como servidores de aplicações e Web.

Estes nomes e níveis de desempenho servem apenas para uma pré-seleção. A aquisição só é aprovada quando o modelo exato e a configuração exata constarem das atuais Certified hardware specifications for NDR.

Para cada linha, a Sophos documenta uma possível carga de pico duas a três vezes superior à carga típica. Esta indicação de pico não substitui uma medição e não deve ser confundida com o nível de capacidade. Se houver utilização intensa adicional de streaming de vídeo e música, poderá ser necessário o nível seguinte; a decisão baseia-se na carga contínua e de pico medida e nos limites certificados atuais. Se predominar a utilização de correio eletrónico, poderá ser adequado um nível inferior, desde que a carga contínua e de pico medida e o número de utilizadores se mantenham dentro dos respetivos valores.

A largura de banda e o número de utilizadores, por si só, não são suficientes para escolher o hardware. Na certificação atual, também é necessário verificar o número máximo de ligações por segundo e a configuração aprovada de CPU, RAM e, se aplicável, sockets. Isto é particularmente importante para tráfego com muitas ligações. Por exemplo, a ficha técnica do Sophos NDR de 19 de dezembro de 2024 indica, para duas configurações R660, o mesmo débito nominal, mas limites diferentes de ligações e recursos:

As configurações da ficha técnica com data de 19.12.2024 em detalhe:

Dell R660, 2 sockets

• Débito máx.: 40 Gbit/s
• Ligações máx./s: 120'000
• CPUs: 64
• RAM: 128 GB

Dell R660, 1 socket

• Débito máx.: 40 Gbit/s
• Ligações máx./s: 80'000
• CPUs: 32
• RAM: 64 GB

Dell R650

• Débito máx.: 20 Gbit/s
• Ligações máx./s: 40'000
• CPUs: 24
• RAM: 64 GB

Dell R450

• Débito máx.: 10 Gbit/s
• Ligações máx./s: 20'000
• CPUs: 16
• RAM: 32 GB

Dell R350

• Débito máx.: 4 Gbit/s
• Ligações máx./s: 8'000
• CPUs: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Débito máx.: 2,5 Gbit/s
• Ligações máx./s: 4'000
• CPUs: 12
• RAM: 32 GB

Estes valores datados apresentam todas as dimensões técnicas do dimensionamento e a importância da configuração exata, mas não constituem uma matriz atual de aquisição ou certificação. Para R360, R660xs, OnLogic e qualquer variante diferente, os valores em falta não devem ser inferidos a partir de modelos semelhantes, mas obtidos exclusivamente na especificação de certificação atual.

As recomendações de hardware são um modelo de carga, não uma garantia para todas as distribuições de tráfego. O streaming e os fluxos de backup de grande dimensão geram muito volume; o Sophos NDR está otimizado para este tipo de streaming e tráfego de «Elephant Flow», ao passo que muitas ameaças são detetadas no tráfego normal de navegação e de aplicações. Por isso, o perfil dos utilizadores e os valores reais da rede são avaliados em conjunto.

Pré-requisitos de rede antes da implementação

A appliance necessita de ligações de saída para arrancar e receber atualizações. Se a firewall suportar wildcards, a Sophos documenta as seguintes permissões:

yum.oracle.com é opcional; sem acesso, a appliance utiliza o mirror do repositório Sophos JFrog. Se a firewall não suportar wildcards, esta tabela resumida não deve ser convertida numa lista de hosts presumidos. Nesse caso, utilize a lista regional atual na página da Sophos Appliance requirements.

Não instale um Sophos Agent nem qualquer outro agente antimalware na Integration Appliance. As atualizações do sistema operativo e de segurança também não devem ser instaladas manualmente; a Sophos gere estas atualizações.

Validar e transmitir a decisão

Antes da implementação, um registo de planeamento deve incluir, no mínimo, os seguintes pontos:

1. Plataforma: ESXi, Hyper-V, AWS, Nutanix ou modelo exato de hardware certificado.
2. Período de medição: data, hora e duração da medição, bem como valores contínuos e de pico para largura de banda, pacotes e fluxos no ponto de espelhamento previsto.
3. Dimensionamento: classe de carga ou nível de hardware selecionado e o respetivo valor-limite mais restritivo; para hardware, comparar adicionalmente o número máximo de ligações por segundo medido com o limite certificado atual.
4. Recursos por plataforma:
   • ESXi, Hyper-V e outros hosts de VM autogeridos: vCPUs, RAM, armazenamento, modelo da CPU e as flags pdpe1gb e avx2 visíveis na VM.
   • AWS: tipo de instância suportado c5n.2xlarge e requisitos do ramo de implementação da AWS.
   • Hardware certificado: modelo certificado exato e configuração aprovada de CPU, RAM e sockets.
5. Carga adicional: nomes e número previsto de eventos por segundo de todas as integrações de Log Collector alojadas em conjunto.
6. Rede: ligações previstas de gestão e espelhamento, bem como confirmação das permissões de portas e domínios de saída.
7. Escalabilidade: número e localização de sensores adicionais, caso um sensor virtual ultrapasse os limites da classe Alta.

A decisão é sólida quando cada valor medido se encontra dentro do nível escolhido e os pré-requisitos específicos da plataforma estão cumpridos. Nos hosts de VM autogeridos, estes incluem o hipervisor, a CPU e as flags visíveis na VM. Na AWS, conta o tipo de instância suportado em conjunto com os requisitos de implementação. No hardware, o modelo exato, a configuração de CPU/RAM/sockets, o débito e o número máximo de ligações por segundo têm de corresponder à certificação atual. Numa appliance partilhada, é também necessário considerar a taxa de eventos, a RAM e o impacto dos Log Collectors na CPU.

A criação da imagem, a instalação, o registo, o Traffic Mirroring e a primeira Detection pertencem às etapas seguintes de implementação e validação. Um estado posterior Connected ou um estado verde da appliance apenas confirma o estado da integração; não comprova uma cobertura completa do espelhamento nem uma deteção de ponta a ponta funcional.

Limites do planeamento documentado

As fontes não fornecem uma fórmula que permita calcular uma configuração individual arbitrária de CPU e RAM acima dos níveis de VM indicados com base no número de utilizadores, na largura de banda ou nos eventos. Acima dos limites da classe Alta, a decisão documentada é, por isso, várias appliances virtuais, e não uma única VM especulativamente maior.

Da mesma forma, as tabelas de hardware não substituem a especificação de certificação atual. Indicam valores de pré-seleção ou valores datados de fichas técnicas, mas não aprovam servidores com nomes semelhantes, componentes diferentes ou sistemas x86 próprios. Se, para hardware, faltar o modelo exato e a configuração aprovada, ou se não existirem valores fiáveis de tráfego e ligações, a plataforma ainda não deve ser autorizada para implementação. O mesmo se aplica a um host de VM autogerido se as flags de CPU necessárias não estiverem disponíveis na VM.