Como usar corretamente o Sophos Firewall Health Check

O Sophos Firewall Health Check é uma verificação integrada da configuração do firewall. Ele mostra no Control Center se configurações importantes estão de acordo com as recomendações de segurança e práticas recomendadas. Para os administradores, isso é especialmente útil, pois torna visíveis configurações arriscadas antes que se tornem um problema de segurança ou operacional.

Para o contexto geral de hardening, consultar o hub Sophos Firewall Hardening: melhores práticas para uma configuração segura.

O Health Check foi introduzido com a Sophos Firewall v22. A função avalia configurações, entre outras, contra práticas recomendadas e padrões como os benchmarks CIS. Com o SFOS 22.0 MR1, o contexto CIS subjacente também foi atualizado.

Guia em vídeo

O vídeo mostra o Health Check no Sophos Firewall e complementa a explicação dos findings no artigo.

Como usar este guia

O Health Check fornece uma lista, mas não toma a decisão. Por isso, o guia acrescenta uma avaliação Avanet:

Prioridade alta: controlo fundamental de segurança ou operação; corrigir ou justificar muito bem.
Dependente do contexto: útil, mas não para todas as regras, fluxos ou arquiteturas.
Coberto de outra forma: o objetivo de segurança já é cumprido por um controlo equivalente de outro fornecedor ou por outro processo operacional. Um override documentado pode ser adequado.
Opcional: função de conformidade ou serviço Sophos adicional; um estado vermelho não significa automaticamente uma configuração insegura.

Esta classificação não substitui uma análise de risco. Evita que uma severidade Sophos baixa minimize um backup importante ou que uma integração opcional se transforme demasiado cedo num projeto de compra.

Para que serve o Health Check

O Health Check não é um estado clássico do sistema nem um sensor de hardware. Não verifica se uma fonte de alimentação está avariada ou se um SSD está prestes a falhar. Para isso, são adequadas outras verificações operacionais, como verificar o estado de saúde do SSD ou a monitorização de HA e hardware.

Para a verificação recorrente do estado atual do sistema, dos serviços, da segurança e dos administradores, utiliza-se a checklist diária de administração da Sophos Firewall. Complementa o Health Check da configuração com Control Center, System graphs, relatórios e eventos.

O Health Check responde mais a estas perguntas:

Os acessos administrativos estão muito abertos?
O MFA está ativado para logins críticos?
As regras de firewall são muito abertas?
Backups, hotfixes, registros ou funções do Central estão bem preparados?
A configuração desvia dos padrões de segurança recomendados?
Existem descobertas que devem ser resolvidas antes de uma auditoria ou go-live?

Assim, é uma boa ferramenta para fortalecimento, revisão e controle de mudanças. No entanto, não substitui uma arquitetura limpa, documentação de regras ou avaliação manual.

⚠️ Um Health Check verde não significa automaticamente que o firewall está seguro. Ele mostra se certas configurações verificáveis estão corretas. Design de rede, lógica de negócios, exceções, grupos de usuários e processos operacionais ainda precisam ser avaliados tecnicamente.

Avaliar corretamente a pontuação e o estado

O Health Check é útil, mas não é uma auditoria de segurança independente do fornecedor. Também favorece Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds e Synchronized Security. Na perspetiva da Avanet, isto contém uma componente clara de cross-selling: Noncompliant pode indicar uma falha real, como WebAdmin exposto sem MFA, ou apenas a decisão de não usar um serviço Sophos opcional quando Microsoft Defender, outro EDR/NDR, SIEM ou filtro DNS já cobre o objetivo.

Recomendação da Avanet: analisar cada finding, mas não implementar todos sem avaliação. Um ponto vermelho relativo a WebAdmin, MFA, autenticação não cifrada, backups ou regras abertas merece muita atenção. Um ponto vermelho relativo a um serviço Sophos não licenciado é, antes de mais, uma decisão de arquitetura e produto, não uma falha de segurança automaticamente comprovada. O objetivo de segurança, as alternativas existentes e o processo operacional determinam se a resposta correta é ativar, cobrir de outra forma ou aplicar um override justificado.

Portanto, não se deve ativar cada recomendação apenas para que a exibição fique verde. Um exemplo é o aviso de login: em ambientes de auditoria ou conformidade, pode ser exigido um aviso de login. Em muitos ambientes operacionais normais, ele gera principalmente um clique adicional em cada login e não traz praticamente nenhum ganho técnico de segurança. Quando a função é necessária, Configurar o aviso de início de sessão e as mensagens na Sophos Firewall explica a gestão do texto, a pré-visualização, a validação e o rollback. Se isso apenas aumentar a pontuação do Health Check, o valor agregado é limitado.

Para estas funções, deve-se perguntar qual risco reduzem, se já existe um controlo equivalente, que licença e transferência de dados exigem e quem trata alertas, exceções e falsos positivos. Sem respostas claras, um override documentado é mais honesto do que uma função não operada ativada apenas para melhorar a pontuação.

Não se deve confundir NDR Essentials com MDR. NDR Essentials analisa tráfego selecionado do firewall e produz deteções. Sophos MDR significa Managed Detection and Response e é um serviço adicional pago com analistas e processos de incidentes. Os MDR threat feeds só fazem sentido quando esse serviço está realmente licenciado e integrado na operação. Um finding NDR não significa automaticamente que seja necessário comprar MDR.

Como regra geral:

Acessos de gerenciamento expostos à Internet, MFA, hotfixes, backups, regras de senha, IPS Normalmente, fundamentos reais de segurança ou operação. Esses pontos devem ser levados muito a sério.
Registros, relatórios, notificações, NTP Importante para operação e rastreabilidade. O caminho específico depende do modelo operacional.
DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central e Synchronized Security são soluções possíveis, não requisitos universais. Uma alternativa eficaz importa mais do que o logótipo Sophos no controlo.
Aviso de login Geralmente mais uma função de conformidade/aviso do que uma medida de proteção técnica. Ativar apenas se realmente exigido ou desejado.

Decisão rápida: o que deve ser realmente implementado?

Ao abrir o Health Check pela primeira vez, os findings podem ser separados em quatro grupos de trabalho:

Verificar imediatamente e normalmente corrigir: 8, 9, 11, 13-20, 22, 25, 28 e 31. Incluem hotfixes, proteção de login, passwords de administrador, MFA, autenticação cifrada, SSH, exposição WAN, pattern updates, IPS, regras amplas e hora correta.
Muito importantes, mesmo que a Sophos os classifique como Low ou Medium: 16 e 21. Backups exigem um restore testado. Alertas exigem um canal funcional por e-mail, monitoring, Central ou SIEM.
Decidir por fluxo de tráfego e arquitetura: 3, 5, 10 e 23-27. X-Ops, Heartbeat, regras de password de utilizadores, Web Policy, Zero-Day Protection, Application Control e TLS Inspection não são igualmente úteis em todas as regras.
Ativar apenas com o ecossistema Sophos adequado ou uma decisão consciente sobre o serviço cloud: 1, 2, 4, 6, 12, 29 e 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection e funções Central não são requisitos mínimos universais. O ponto 7, Login disclaimer, é sobretudo uma decisão de conformidade.

Esta classificação é deliberadamente mais direta do que a severidade Sophos. Avalia o que reduz primeiro o risco no ambiente real, não o que a Sophos pode vender ou integrar tecnicamente.

Abrir o Health Check

O status do Health Check aparece no Control center. A visão detalhada também pode ser encontrada através do menu principal:

Monitor & analyze > Firewall health check

Lá, você vê o número de configurações verificadas, os pontos conformes e os pontos não conformes. A Sophos mostra entradas não conformes por gravidade. Os dados são atualizados quando uma configuração monitorada é alterada. Isso torna o Health Check adequado também para uma revisão direta após alterações.

Para a revisão, não se deve apenas anotar o status geral. Mais importantes são as descobertas concretas, o contexto de risco e a medida planejada. Uma única descoberta crítica sobre a acessibilidade do WebAdmin pela WAN é mais importante na operação do que várias descobertas de baixa gravidade sem exposição à Internet.

Compreender estado, severidade e override

A vista detalhada mostra, para cada verificação, se a configuração está compliant, noncompliant ou foi substituída manualmente. Para a operação, estes três estados são mais importantes do que a percentagem isolada.

Compliant: a configuração verificada cumpre a policy correspondente. Após alterações maiores, deve ainda assim ser validada tecnicamente.
Noncompliant: a configuração verificada não cumpre a policy. É necessário avaliar risco, exposição e viabilidade.
Manual policy status override: a configuração não cumpre a policy, mas foi marcada manualmente como compliant. Este estado só deve ser usado com justificação, owner e data de revisão.

A severidade ajuda a ordenar, mas não substitui a avaliação técnica. É uma classificação Sophos estática e não conhece exposição nem controlos compensatórios. Um finding Low por backups ausentes pode ser mais urgente do que um Medium por um serviço Sophos não utilizado.

Se um finding parecer ilógico, também se deve verificar a versão de firmware e os problemas conhecidos. O SFOS 22.0 MR1 corrigiu estados Doesn't comply incorretos para regras de firewall e para NDR Essentials em firewalls virtuais. Um estado claramente incorreto não justifica uma alteração arriscada da configuração nem um override precipitado.

As funções de pesquisa e ordenação da tabela Health Check ajudam a agrupar findings por policy, módulo, standard ou severidade. Em firewalls maiores, isto é mais prático do que olhar apenas para o mosaico do dashboard.

Avaliação individual das verificações do Health Check

A lista baseia-se nas 31 verificações da vista inglesa usadas nesta análise. A Sophos pode alterar o número, o nome, o standard ou a severidade com uma atualização de firmware. Se o firewall local mostrar findings adicionais ou com nomes diferentes, essa vista é a referência. O status não é apresentado porque varia entre firewalls. O importante é compreender e avaliar corretamente cada verificação.

Active Threat Response e Advanced Security

1. Synchronized Application Control deve estar ativado. Standard: Recommended, Severidade: Medium. Identifica aplicações com maior precisão através do Sophos Endpoint e requer Security Heartbeat; na primeira utilização, também deve ser ativado no Sophos Central. Avaliação Avanet: opcional. Ativar apenas quando existem endpoints Sophos compatíveis e as aplicações detetadas serão depois classificadas e utilizadas através de Application Filter. Com Microsoft Defender ou outro produto endpoint, um override justificado é mais útil do que uma ativação sem efeito.
2. NDR Essentials deve estar ativado e monitorizar pelo menos uma interface. Standard: Recommended, Severidade: Medium. O firewall analisa tráfego selecionado através do serviço cloud Sophos NDR, deteta IoCs e regista-os, mas não os bloqueia automaticamente. São suportadas determinadas interfaces nas zonas LAN, DMZ e Custom; WAN, Wi-Fi e vários tipos de interface, como RED ou XFRM, estão excluídos. Active-Active HA não é suportado. Também devem estar ativos os logs de Active Threat Response e, conforme o tipo de IoC, as verificações de firewall, DNS, IPS ou decryption. Avaliação Avanet: dependente do contexto ou opcional. Ativar apenas quando licença, análise cloud, privacidade, interfaces adequadas e responsabilidade pelos alertas estiverem esclarecidas. Não substituir um NDR existente apenas para tornar o Health Check verde.
3. Sophos X-Ops deve estar ativado, Ação Log and drop. Standard: CIS, Severidade: High. Relevante para segurança se os Threat Feeds forem usados ativamente. Falsos positivos e registros devem ser verificados.
4. MDR threat feeds devem estar ativados, Ação Log and drop. Standard: Recommended, Severidade: High. Requer Sophos MDR, registo no Sophos Central e licenças adequadas. Avaliação Avanet: opcional. O guia ligado explica piloto, Audit ID, Task Queue e validação do incidente. Sem contrato MDR, não é uma falha de configuração, mas uma recomendação de produto e serviço.
5. Uma regra de firewall deve usar Synchronized Security Heartbeat. Standard: CIS, Severidade: Medium. Avaliação Avanet: dependente do contexto. Tem grande valor com Sophos Endpoint, mas não se aplica com Microsoft Defender ou outro EDR. É essencial um teste piloto: conforme a regra, os dispositivos que nunca enviaram um heartbeat podem continuar a ter acesso. As opções Block clients with no heartbeat e Block request to destination with no heartbeat aplicam o comportamento pretendido a esses dispositivos.
6. Security Heartbeat deve estar ativado. Standard: CIS, Severidade: High. Importante se o Sophos Endpoint for usado. Caso contrário, primeiro deve-se esclarecer o design do Endpoint.
12. DNS Protection deve ser configurado e ativo. Standard: Recommended, Severidade: Medium. O estado ativo requer a licença adequada, os resolvers de DNS Protection no firewall e o IP público do firewall como Location no Sophos Central. Avaliação Avanet: opcional. Ativar apenas quando o serviço é operado conscientemente como camada de segurança DNS e os respetivos logs são analisados. Outros filtros DNS podem cobrir o mesmo objetivo sem que o Sophos Health Check os marque como compliant.

Administração, autenticação e Device Access

7. Aviso de login deve estar ativado. Standard: CIS, Severidade: Medium. Tema de conformidade. Pouco efeito de proteção técnica, mas gera um clique adicional no login.
8. Configuração de hotfix deve estar ativada. Standard: CIS, Severidade: High. Avaliação Avanet: prioridade alta. No SFOS 22 atual, já não aparece um bloco Hotfix separado em Backup & firmware > Firmware. A Sophos instala hotfixes automaticamente por predefinição; o estado pode ser verificado com system hotfix show na Device Console. A ausência da caixa na interface não é um finding.
9. Sessões inativas devem ser encerradas e logins bloqueados após tentativas falhas. Standard: CIS, Severidade: High. Clareza na proteção de login. Especialmente importante em portais expostos e acessos administrativos.
10. A complexidade da senha deve ser configurada para usuários. Standard: CIS, Severidade: High. Útil, especialmente para usuários locais e portais. Com IdP externo, também verifique a política de senha e MFA deste.
11. A complexidade da senha deve ser configurada para administradores. Standard: CIS, Severidade: High. Fortalecimento básico. Mais importante ainda são administradores individuais, MFA e acesso restrito.
13. MFA deve estar ativo para logins de VPN de Acesso Remoto. Standard: CIS, Severidade: High. Muito importante para SSL VPN e IPsec Remote Access. Planeje o rollout com administrador de fallback e usuários de teste.
14. MFA deve estar ativo para WebAdmin Console e VPN Portal. Standard: CIS, Severidade: High. Muito importante, especialmente se os portais forem acessíveis a partir de redes menos controladas.
15. Conexões com servidores de autenticação devem ser criptografadas. Standard: CIS, Severidade: Medium. Importante em integrações AD/LDAP/RADIUS. Evite autenticação não criptografada.
17. Autenticação por chave pública deve estar ativada para SSH. Standard: Recommended, Severidade: High. Muito útil. Além disso, permita SSH apenas a partir de redes confiáveis.
18. User Portal não deve ser acessível a partir da zona WAN. Standard: Recommended, Severidade: High. Correto em muitos ambientes. Se o acesso WAN for necessário, restrinja fortemente e use MFA.
19. WebAdmin Console não deve ser acessível a partir da zona WAN. Standard: CIS, Severidade: High. Um dos pontos mais importantes. Nunca abra amplamente o WebAdmin para a Internet.
20. MFA deve ser configurado para o administrador padrão. Standard: CIS, Severidade: High. Importante, mas melhor ainda é um processo administrativo limpo com contas de administrador pessoais.

Backups, atualizações, regras e inspection

16. Backups devem ser planejados no firewall ou no Sophos Central. Standard: CIS, Severidade: Low. Baixa gravidade, mas extremamente importante em caso de emergência. Teste também o processo de restauração.
21. Emails de notificação devem ser configurados para eventos de sistema e segurança. Standard: CIS, Severidade: Low. O Sophos Firewall pode enviar notificações por email e SNMP; os eventos pretendidos são selecionados em System services > Notification list. Avaliação Avanet: dependente do contexto. O importante é um canal de alerta fiável e testado. Se Syslog, SIEM, monitorização ou Central Alerts forem operados de forma fiável, o email não é obrigatório. Um servidor SMTP configurado sem eventos selecionados e sem teste de entrega ainda não constitui um processo de alertas.
22. Atualizações automáticas de padrões devem estar ativadas. Standard: CIS, Severidade: High. Avaliação Avanet: prioridade alta. Sem padrões atuais, várias funções de proteção perdem eficácia. O procedimento para configurar e verificar as atualizações de padrões mostra a automação, os status e a instalação separada do firmware de APX e RED. Em ambientes Air-Gap, também é necessário um processo manual de padrões e licenciamento documentado.
23. Uma política da Web deve ser selecionada em uma regra de firewall. Standard: Recommended, Severidade: Medium. Útil para tráfego web de usuários. Não aplique cegamente a tráfego de servidor para servidor ou tráfego especial.
24. Proteção contra zero-day deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: High. Útil para caminhos web e de download apropriados. Considere licença, desempenho e falsos positivos.
25. IPS deve estar ativado e uma política de IPS deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: High. Ponto de proteção muito importante. IPS deve ser escolhido e registrado adequadamente por caminho de tráfego.
26. Uma política de controle de aplicativos deve ser selecionada em uma regra de firewall. Standard: CIS, Severidade: Medium. Útil para regras de internet de clientes. Teste primeiro em tráfego crítico.
27. Uma regra de inspeção SSL/TLS deve usar a ação Decrypt. Standard: CIS, Severidade: High. Não ative cegamente. TLS Inspection requer distribuição de CA, exceções, fase piloto e processo de solução de problemas.
28. Uma regra de permissão não deve usar Any em todos os campos de rede e serviço. Standard: CIS, Severidade: Medium. Muito importante para higiene de regras. Any pode ser necessário conscientemente, mas deve ser justificado e registrado.

Sophos Central e hora

29. Relatórios do Sophos Central devem estar ativados. Standard: Recommended, Severidade: Medium. Útil para relatórios e análises mais longas. Não é obrigatório se Syslog/SIEM for operado corretamente.
30. O firewall deve estar registrado para gerenciamento do Sophos Central e o gerenciamento do Central deve estar ativado. Standard: Recommended, Severidade: Medium. Prático para gerenciamento central, backups e relatórios. Nem todo ambiente quer ou precisa de gerenciamento em nuvem.
31. Um servidor NTP deve ser configurado. Standard: CIS, Severidade: Low. Requisito básico. Sem tempo correto, logs, certificados, autenticação e solução de problemas sofrem.

Priorizar e implementar descobertas

Nem toda descoberta tem a mesma importância em todos os ambientes. Uma boa revisão classifica as entradas não apenas pela gravidade técnica, mas também pela exposição e risco operacional.

Esta ordem tem se mostrado eficaz:

Verificar acessos de gerenciamento e portais expostos à Internet.
Verificar MFA e segurança de login para administradores, VPN Portal, User Portal e Acesso Remoto.
Limpar regras de firewall com fontes, destinos ou serviços muito amplos.
Controlar registros, backups e hotfixes.
Verificar funções de proteção por regra, como IPS, política da Web, controle de aplicativos, TLS Inspection ou Zero-Day Protection.
Avaliar descobertas do Central, relatórios ou NDR se a função é realmente utilizada e operada no ambiente.

A ordem é pragmática: primeiro as coisas que são diretamente visíveis na Internet ou permitem acesso ao firewall. Depois, higiene de regras e funções de proteção. Depois, questões operacionais e de ecossistema.

Descobertas típicas e medidas adequadas

WebAdmin, User Portal ou VPN Portal estão muito acessíveis

Se portais administrativos ou voltados para o usuário são acessíveis a partir de muitas zonas, o risco de varreduras, tentativas de força bruta e preenchimento de credenciais aumenta. O artigo mais importante sobre isso é Proteger o acesso ao Sophos Firewall: configurar corretamente o Device Access.

Para ambientes produtivos, deve-se verificar:

O WebAdmin é realmente necessário a partir da zona WAN?
Existe uma Local Service ACL Exception Rule para IP de gerenciamento ou rede de administradores?
O SSH é permitido apenas a partir de redes confiáveis?
Os User Portal e VPN Portal são acessíveis apenas onde são necessários?

MFA está ausente ou não está ativado consistentemente

O MFA deve estar presente, pelo menos, em acessos administrativos e Acesso Remoto. Se o Health Check mostrar descobertas de MFA, não se deve mudar cegamente para todos os usuários ao mesmo tempo. É melhor um rollout controlado com usuário de teste, administrador de fallback e processo de token limpo.

O guia prático está em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Acesso Remoto.

Regras de firewall são muito abertas

Regras muito amplas com Any em fonte, destino ou serviço são frequentemente históricas. Nem toda regra ampla está automaticamente errada, mas cada uma deve ser justificada.

Para a limpeza, estas perguntas são úteis:

Qual zona realmente pode acessar qual zona?
Os destinos ou serviços podem ser restringidos?
O registro está ativo para que os acertos sejam visíveis?
Existem regras de teste antigas ou exceções temporárias?
A regra pode ser dividida em várias regras mais compreensíveis?

Os fundamentos estão em Entender e configurar corretamente as regras do Sophos Firewall. Se não estiver claro qual regra está em vigor, Testar regra de firewall com Log Viewer, Policy Test e Packet Capture pode ajudar.

Backups, hotfixes e processo de atualização estão ausentes

Um Health Check pode apontar para a falta de backups ou questões de atualização/hotfix. Esses pontos parecem menos espetaculares do que a exposição de portais, mas são decisivos em caso de emergência.

Antes de grandes mudanças, deve-se criar um backup e saber como funciona uma restauração. O procedimento está em Criar ou restaurar backup do Sophos Firewall. Para questões de firmware, Atualização de firmware do Sophos Firewall - Preparação e Melhores Práticas é adequado.

Registros e relatórios estão incompletos

Se faltam logs, a operação fica cega. O Health Check pode dar dicas sobre questões de registro ou relatório, mas a decisão real depende do modelo operacional.

Para análise local, são relevantes Log Viewer, Service-Logs e Packet Capture. Para armazenamento mais longo, é necessário Central Firewall Reporting ou Syslog/SIEM. Se não forem eventos de log individuais, mas fluxos de tráfego, picos de largura de banda ou relações de comunicação notáveis que devem ser investigados, Monitoramento sFlow é adicionalmente adequado. Os fundamentos locais estão em Solução de problemas do Sophos Firewall: Serviços e Logs.

Funções de proteção não estão ativas em regras

Um ponto frequente são regras sem IPS, política da Web, controle de aplicativos, TLS Inspection ou Zero-Day Protection. Aqui, não se deve ativar tudo indiscriminadamente, mas entender o caminho do tráfego.

Exemplos:

O tráfego web de usuários precisa de controles diferentes do tráfego de servidor para servidor.
TLS Inspection deve ser introduzido de forma planejada, pois pode interferir em aplicativos.
IPS e controle de aplicativos precisam de registro e uma rotina de revisão.
Funções de NDR ou Threat-Feed só ajudam se as descobertas forem posteriormente avaliadas.

Para TLS Inspection, Introduzir corretamente o TLS Inspection do Sophos Firewall é adequado. Para Threat Feeds, Sophos Firewall Threat Feeds é adequado.

Documentar e rever a revisão

O Sophos Firewall permite substituir manualmente o status de verificações individuais. Isso pode ser útil se uma recomendação não for implementada conscientemente no próprio ambiente.

No entanto, as substituições não devem ser mal interpretadas como uma função de limpeza. Se um ponto for substituído, deve estar documentado:

Por que a recomendação não é adequada?
Quem aprovou a decisão?
A exceção é permanente ou apenas temporária?
Quando será revisada novamente?
Existe uma medida compensatória?

⚠️ Uma substituição não é uma correção. É uma aceitação consciente de risco ou uma exceção documentada. Sem justificativa, o Health Check se torna menos valioso.

Documentar corretamente o resultado

Uma revisão do Health Check deve gerar um resultado rastreável. Caso contrário, você pode ver brevemente um painel, mas não saberá mais tarde qual decisão foi tomada e quais pontos ainda estão pendentes.

Para ambientes pequenos, uma lista simples é muitas vezes suficiente:

Data: Quando foi verificado o Health Check?
Firmware: Em que versão do SFOS foi feita a avaliação?
Finding: Que ponto não conforme foi reportado?
Risco: Porque é que este ponto é relevante ou menos relevante neste ambiente?
Medida: O que será alterado, testado ou conscientemente aceite?
Responsável: Quem esclarece o ponto do ponto de vista técnico ou operacional?
Prazo: Até quando a medida deve ser concluída ou novamente avaliada?
Evidência: Screenshot, ticket, Change-ID ou indicação no Audit Log.

Para firewalls produtivos, a evidência não deve consistir apenas em uma captura de tela. Se uma configuração foi alterada, ticket de mudança, trilha de auditoria, regra de firewall afetada e resultado da revisão devem estar juntos. Para alterações em regras, interfaces, hosts e serviços, Verificar os logs de trilha de auditoria do Sophos Firewall é particularmente útil.

Verificar novamente após alterações

Após uma correção, deve-se abrir novamente o Health Check e verificar se a descoberta realmente desapareceu. Além disso, é necessária uma verificação técnica de funcionalidade, pois um status verde por si só não prova que o tráfego produtivo ainda está funcionando corretamente.

Exemplos:

Após uma alteração em Device access, verifique se o acesso administrativo a partir da rede de gerenciamento prevista ainda funciona e não é mais acessível a partir de redes indesejadas.
Após alterações de MFA, faça login com um usuário de teste e verifique separadamente o administrador de fallback.
Após alterações de regras, teste Log Viewer, Policy Test e aplicativos afetados.
Após alterações de registro ou relatório, verifique se novos eventos são realmente visíveis localmente, no Sophos Central ou no Syslog.
Após uma substituição, defina um lembrete para que a exceção não seja esquecida permanentemente.

Se várias descobertas forem tratadas ao mesmo tempo, as alterações devem ser divididas em blocos pequenos. Caso contrário, em um problema posterior, não está claro se o Device Access, MFA, regras de firewall, TLS Inspection ou outra alteração foi a causa.

Usar o Health Check como processo operacional

O Health Check é mais forte quando é executado regularmente e após mudanças importantes.

Momentos adequados:

após a configuração inicial ou um go-live,
antes e depois de grandes alterações de regras,
antes de atualizações de firmware,
após restauração ou troca de hardware,
após migrações ou grandes mudanças de arquitetura,
antes de auditorias,
trimestralmente como revisão de segurança.

Para as próprias alterações, a trilha de auditoria deve ser usada adicionalmente. O artigo Verificar os logs de trilha de auditoria do Sophos Firewall explica como avaliar o configuration-audit.log e rastrear alterações de configuração.

Processo prático de revisão

Uma revisão pragmática do Health Check segue assim:

Abra o Health Check no Control Center.
Classifique as descobertas não conformes por gravidade.
Verifique primeiro serviços e acessos administrativos expostos à Internet.
Trate temas de MFA, senha e sessão.
Identifique regras de firewall amplas e valide com Log Viewer.
Verifique backups, hotfixes, registros e relatórios.
Avalie funções de proteção por regra.
Documente exceções justificadas em vez de substituir sem comentários.
Verifique novamente após alterações.
Documente o resultado com data, responsável e pontos pendentes.

Para revisões recorrentes, muitas vezes uma tabela simples com descoberta, risco, medida, responsável, status e lembrete é suficiente. O importante é que as descobertas não sejam apenas vistas, mas tratadas ou conscientemente aceitas.

Limites

O Health Check é útil, mas tem limites claros.

Ele não conhece toda a lógica de negócios do ambiente.
Ele não avalia se uma regra é necessária tecnicamente.
Ele não substitui segmentação de rede e modelo de zonas.
Ele não reconhece automaticamente todos os casos especiais arriscados.
Ele não substitui uma auditoria externa e uma revisão manual de regras.
Ele não diz se os alertas serão tratados posteriormente.

Portanto, o Health Check deve ser visto como um ponto de partida. Ele torna visíveis desvios palpáveis, mas a verdadeira qualidade de segurança surge de uma boa arquitetura, processos limpos e manutenção consistente.

Lista de verificação operacional

Execute o Health Check após o go-live e após grandes mudanças.
Priorize descobertas por gravidade e exposição.
Verifique a acessibilidade WAN do WebAdmin, SSH, User Portal e VPN Portal.
Ative MFA para administradores, portais e Acesso Remoto.
Limpe ou justifique regras de firewall amplas.
Ative registros em regras importantes.
Verifique backups e processo de restauração.
Documente o processo de hotfix e firmware.
Defina substituições apenas com justificativa.
Documente regularmente o resultado do Health Check.

FAQ

O que o Sophos Firewall Health Check verifica?

O Health Check verifica configurações de firewall selecionadas contra configurações recomendadas, práticas recomendadas e padrões como benchmarks CIS. Isso inclui, entre outros, regras de firewall, MFA, complexidade de senha, acessos de gerenciamento e outras opções de segurança.

Um Health Check verde é uma prova completa de segurança?

Não. Um Health Check verde é um bom sinal, mas não substitui uma revisão de arquitetura, uma análise de regras, um conceito de backup e uma revisão de segurança manual.

Cada finding vermelho do Health Check é uma falha de segurança?

Não. Para acesso WAN, MFA, autenticação sem cifra, backups ausentes ou regras demasiado amplas, um estado vermelho indica normalmente um risco real. Para NDR, MDR threat feeds, DNS Protection, Sophos Central ou Synchronized Security, pode significar apenas que um serviço Sophos opcional não é usado. O objetivo de segurança, as alternativas existentes e uma decisão documentada são determinantes.

Com que frequência deve-se executar o Health Check?

Pelo menos após grandes mudanças, antes de auditorias e em um ritmo fixo, por exemplo, trimestralmente. Em ambientes críticos, uma revisão mensal pode ser útil.

Deve-se substituir descobertas do Health Check?

Apenas de forma deliberada e documentada. Um override é adequado quando existe um controlo equivalente ou um serviço Sophos opcional não é usado de propósito. Registar motivo, owner e data de revisão; caso contrário, o override enfraquece o Health Check.

O que deve ser corrigido primeiro?

Primeiro, devem ser verificadas descobertas com exposição à Internet, acesso administrativo, MFA, regras muito abertas, backups ausentes e registros ausentes. Depois, seguem-se otimizações em funções de proteção e integrações de ecossistema.