Uso correcto del Sophos Firewall Health Check

El Sophos Firewall Health Check es una revisión integrada de la configuración del firewall. Muestra en el Control Center si configuraciones importantes cumplen con las recomendaciones de seguridad y mejores prácticas. Es especialmente útil para los administradores, ya que hace visibles configuraciones riesgosas antes de que se conviertan en un problema de seguridad u operativo.

Para el contexto general de hardening, sirve el hub Sophos Firewall Hardening: buenas prácticas para una configuración segura.

El Health Check fue introducido con Sophos Firewall v22. La función evalúa configuraciones en comparación con mejores prácticas y estándares como los CIS Benchmarks. Con SFOS 22.0 MR1 también se actualizó el contexto CIS subyacente.

Vídeo tutorial

Cómo utilizar esta guía

El Health Check ofrece una lista, pero no toma la decisión. Por eso, la guía añade una valoración de Avanet:

• Prioridad alta: controles básicos de seguridad u operación; resolver o justificar muy bien.
• Según el contexto: útiles, pero no para todas las reglas, rutas de tráfico o arquitecturas.
• Cubierto de otra forma: el objetivo ya se cumple mediante un control equivalente de otro fabricante o mediante otro proceso operativo. Un override documentado puede ser correcto.
• Opcional: funciones de cumplimiento o servicios Sophos adicionales; un estado rojo no implica automáticamente una configuración insegura.

Esta clasificación no sustituye un análisis de riesgos. Evita que una gravedad baja de Sophos reste importancia a un backup crítico o que una integración opcional termine prematuramente en un proyecto de compra.

Para qué está diseñado el Health Check

El Health Check no es un estado clásico del sistema ni un sensor de hardware. No verifica si una fuente de alimentación está defectuosa o si un SSD está a punto de fallar. Para eso, son adecuados otros chequeos operativos, como Verificar el estado de salud del SSD o el monitoreo de HA y hardware.

El Health Check responde más bien a estas preguntas:

• ¿Están los accesos administrativos demasiado abiertos?
• ¿Está activado el MFA para inicios de sesión críticos?
• ¿Están las reglas del firewall demasiado abiertas?
• ¿Están preparados correctamente los respaldos, hotfixes, registros o funciones de Central?
• ¿Se desvía la configuración de los estándares de seguridad recomendados?
• ¿Existen hallazgos que deban resolverse antes de una auditoría o puesta en marcha?

Es, por lo tanto, una buena herramienta para el endurecimiento, revisión y control de cambios. Sin embargo, no reemplaza una arquitectura limpia, documentación de reglas ni una evaluación manual.

⚠️ Un Health Check en verde no significa automáticamente que el firewall esté planificado de manera segura. Indica si ciertas configuraciones verificables son adecuadas. El diseño de la red, la lógica de negocio, las excepciones, los grupos de usuarios y los procesos operativos deben seguir siendo evaluados profesionalmente.

Evaluar correctamente el puntaje y el estado

El Health Check es útil, pero no es una auditoría neutral respecto al fabricante. También premia el uso de Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds y Synchronized Security. Desde la perspectiva de Avanet, esto contiene una clara parte de cross-selling: Noncompliant puede significar una brecha real, como WebAdmin expuesto sin MFA, o simplemente que no se utiliza un servicio Sophos opcional aunque Microsoft Defender, otro EDR/NDR, un SIEM o un filtro DNS ya cubra el objetivo.

Recomendación de Avanet: revisar cada finding, pero no implementar todos sin cuestionarlos. Un punto rojo sobre WebAdmin, MFA, autenticación sin cifrar, copias de seguridad o reglas abiertas merece mucha atención. Un punto rojo sobre un servicio Sophos sin licencia es inicialmente una decisión de arquitectura y producto, no una brecha de seguridad demostrada automáticamente. El objetivo de seguridad, las alternativas existentes y el proceso operativo determinan si corresponde activar, cubrir de otra forma o aplicar un override justificado.

Por lo tanto, no se debe activar cada recomendación solo para que la visualización se vuelva verde. Un ejemplo es el disclaimer de inicio de sesión: en entornos de auditoría o cumplimiento, puede ser necesario un aviso de inicio de sesión. Sin embargo, en muchos entornos operativos normales, solo genera un clic adicional en cada inicio de sesión y prácticamente no aporta un beneficio técnico de seguridad. Si solo aumenta el puntaje del Health Check, el valor agregado es limitado.

Para estas funciones conviene preguntar: ¿qué riesgo reducen?, ¿existe ya un control equivalente?, ¿qué licencia y transferencia de datos requieren?, ¿quién trata alertas, excepciones y falsos positivos? Sin respuestas claras, un override documentado suele ser más honesto que activar una función sin operarla.

No se deben confundir NDR Essentials y MDR. NDR Essentials analiza tráfico seleccionado del firewall y genera detecciones. Sophos MDR significa Managed Detection and Response y es un servicio adicional de pago con analistas y procesos de incidentes. Los MDR threat feeds solo tienen sentido cuando ese servicio está licenciado e integrado en la operación. Un finding de NDR no significa automáticamente que sea necesario comprar MDR.

Como regla general:

• Accesos de gestión expuestos a Internet, MFA, hotfixes, respaldos, reglas de contraseña, IPS Generalmente son fundamentos reales de seguridad u operación. Estos puntos deben tomarse muy en serio.
• Registros, informes, notificaciones, NTP Importante para la operación y trazabilidad. El camino concreto depende del modelo operativo.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central y Synchronized Security son soluciones posibles, no requisitos universales. Una alternativa eficaz importa más que el logotipo Sophos del control.
• Disclaimer de inicio de sesión Generalmente más una función de cumplimiento/aviso que una medida de protección técnica. Activar solo si realmente se requiere o desea.

Decisión rápida: ¿qué conviene implementar realmente?

Al abrir el Health Check por primera vez, se pueden clasificar los findings en cuatro grupos de trabajo:

• Revisar de inmediato y normalmente corregir: 8, 9, 11, 13 a 20, 22, 25, 28 y 31. Incluyen hotfixes, protección de login, contraseñas de administrador, MFA, autenticación cifrada, SSH, exposición WAN, pattern updates, IPS, reglas amplias y hora correcta.
• Muy importantes aunque Sophos los valore como Low o Medium: 16 y 21. Los backups necesitan un restore probado. Las alertas necesitan una vía funcional mediante correo, monitorización, Central o SIEM.
• Decidir según la ruta de tráfico y la arquitectura: 3, 5, 10 y 23 a 27. X-Ops, Heartbeat, reglas de contraseña de usuarios, Web Policy, Zero-Day Protection, Application Control y TLS Inspection no son igual de útiles en todas las reglas.
• Activar solo con el ecosistema Sophos adecuado o una decisión consciente sobre servicios cloud: 1, 2, 4, 6, 12, 29 y 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection y las funciones de Central no son un estándar mínimo universal. El punto 7, Login disclaimer, es principalmente una decisión de cumplimiento.

Esta clasificación es deliberadamente más directa que la gravedad de Sophos. Evalúa qué reduce primero el riesgo en el entorno real, no qué puede vender o integrar técnicamente Sophos.

Abrir el Health Check

El estado del Health Check aparece en el Control center. La vista detallada también se encuentra a través del menú principal:

Monitor & analyze > Firewall health check

Allí se puede ver el número de configuraciones revisadas, los puntos conformes y los no conformes. Sophos muestra las entradas no conformes según su gravedad. Los datos se actualizan cuando cambia una configuración monitoreada. Por lo tanto, el Health Check también es adecuado para un seguimiento directo después de los cambios.

Para la revisión, no solo se debe anotar el estado general. Son más importantes los hallazgos concretos, el contexto de riesgo y la medida planificada. Un hallazgo crítico único sobre la accesibilidad WAN de WebAdmin es más importante en la operación que varios hallazgos menores sin exposición a Internet.

Entender estado, gravedad y override

La vista detallada muestra para cada comprobación si la configuración es compliant, noncompliant o si se ha sobrescrito manualmente. Para la operación, estos tres estados son más importantes que el porcentaje por sí solo.

• Compliant: la configuración revisada cumple la policy correspondiente. Después de cambios importantes, aun así conviene validarla técnicamente.
• Noncompliant: la configuración revisada no cumple la policy. Hay que evaluar riesgo, exposición y viabilidad.
• Manual policy status override: la configuración no cumple la policy, pero se ha marcado manualmente como compliant. Este estado solo debería usarse con motivo, owner y fecha de revisión.

La gravedad ayuda a ordenar, pero no sustituye la evaluación técnica. Es una valoración Sophos estática y no conoce la exposición ni controles compensatorios. Un hallazgo Low por backups ausentes puede ser más urgente que un Medium por un servicio Sophos no utilizado.

Si un finding parece ilógico, también se deben comprobar la versión de firmware y los errores conocidos. SFOS 22.0 MR1 corrigió estados Doesn't comply incorrectos para reglas de firewall y para NDR Essentials en firewalls virtuales. Un estado claramente erróneo no justifica un cambio de configuración arriesgado ni un override precipitado.

Las funciones de búsqueda y ordenación de la tabla Health Check ayudan a agrupar hallazgos por policy, módulo, estándar o gravedad. En firewalls grandes es más práctico que mirar solo el widget del dashboard.

Evaluación individual de las revisiones del Health Check

La lista se basa en las 31 revisiones de la vista inglesa utilizadas para este análisis. Sophos puede cambiar la cantidad, el nombre, el estándar o la gravedad con una actualización de firmware. Si el firewall local muestra findings adicionales o con otro nombre, esa vista es la referencia. El estado no se muestra porque varía según el firewall. Lo importante es entender qué comprueba cada punto y cómo valorarlo.

Active Threat Response y Advanced Security

• 1. Synchronized Application Control debería estar activado. Estándar: Recommended, Gravedad: Medium. Identifica aplicaciones con mayor precisión mediante Sophos Endpoint y requiere Security Heartbeat; en el primer uso también debe activarse en Sophos Central. Valoración Avanet: opcional. Activar solo si hay endpoints Sophos compatibles y las aplicaciones detectadas se clasificarán y utilizarán después mediante Application Filter. Con Microsoft Defender u otro producto endpoint, un override justificado es más útil que una activación sin efecto.
• 2. NDR Essentials debería estar activado y monitorizar al menos una interfaz. Estándar: Recommended, Gravedad: Medium. El firewall analiza tráfico seleccionado mediante el servicio cloud Sophos NDR, detecta IoC y los registra, pero no los bloquea automáticamente. Admite determinadas interfaces en zonas LAN, DMZ y Custom; WAN, Wi-Fi y varios tipos de interfaz, como RED o XFRM, están excluidos. Active-Active HA no es compatible. También deben estar activos los logs de Active Threat Response y, según el tipo de IoC, las comprobaciones de firewall, DNS, IPS o decryption. Valoración Avanet: según el contexto u opcional. Activar solo cuando estén aclarados la licencia, el análisis cloud, la privacidad, las interfaces adecuadas y la responsabilidad sobre las alertas. No sustituir un NDR existente solo para que el Health Check aparezca verde.
• 3. Sophos X-Ops debería estar activado, acción Log and drop. Estándar: CIS, Gravedad: High. Relevante para la seguridad si los Threat Feeds se utilizan activamente. Se deben verificar los falsos positivos y el registro.
• 4. MDR threat feeds deberían estar activados, acción Log and drop. Estándar: Recommended, Gravedad: High. Requiere Sophos MDR, registro en Sophos Central y licencias adecuadas. Valoración Avanet: opcional. Sin contrato MDR no es una brecha de configuración, sino una recomendación de producto y servicio.
• 5. Una regla de firewall debería usar Synchronized Security Heartbeat. Estándar: CIS, Gravedad: Medium. Valoración Avanet: según el contexto. Aporta mucho valor con Sophos Endpoint, pero no corresponde con Microsoft Defender u otro EDR. Es imprescindible realizar un piloto: según la regla, los dispositivos que nunca han enviado un heartbeat pueden seguir teniendo acceso. Block clients with no heartbeat y Block request to destination with no heartbeat son las opciones que aplican el comportamiento deseado a esos dispositivos.
• 6. Security Heartbeat debería estar activado. Estándar: CIS, Gravedad: High. Importante si se utiliza Sophos Endpoint. De lo contrario, primero se debe aclarar el diseño del Endpoint.
• 12. DNS Protection debería configurarse y estar activa. Estándar: Recommended, Gravedad: Medium. El estado activo requiere la licencia correspondiente, los resolvers de DNS Protection en el firewall y la IP pública del firewall como Location en Sophos Central. Valoración Avanet: opcional. Activar solo si el servicio se utiliza conscientemente como capa de seguridad DNS y sus logs se revisan. Otros filtros DNS pueden cubrir el mismo objetivo sin que el Health Check de Sophos lo considere compliant.

Administración, autenticación y Device Access

• 7. Login disclaimer debería estar activado. Estándar: CIS, Gravedad: Medium. Tema de cumplimiento. Técnicamente tiene poco efecto de protección, pero genera un clic adicional al iniciar sesión.
• 8. La configuración de Hotfix debería estar activada. Estándar: CIS, Gravedad: High. Valoración Avanet: prioridad alta. En SFOS 22 actual ya no aparece un bloque Hotfix separado en Backup & firmware > Firmware. Sophos instala hotfixes automáticamente por defecto; el estado puede comprobarse con system hotfix show en Device Console. La ausencia de una casilla en la interfaz no es un hallazgo.
• 9. Las sesiones inactivas deberían cerrarse y los inicios de sesión bloquearse después de intentos fallidos. Estándar: CIS, Gravedad: High. Endurecimiento claro de inicio de sesión. Especialmente importante en portales expuestos y accesos administrativos.
• 10. La complejidad de la contraseña debería configurarse para los usuarios. Estándar: CIS, Gravedad: High. Útil, especialmente para usuarios locales y portales. Con un IdP externo, también se debe revisar su política de contraseñas y MFA.
• 11. La complejidad de la contraseña debería configurarse para los administradores. Estándar: CIS, Gravedad: High. Endurecimiento básico. Más importante aún son los administradores individuales, MFA y el acceso restringido.
• 13. MFA debería estar activo para los inicios de sesión de VPN de acceso remoto. Estándar: CIS, Gravedad: High. Muy importante para SSL VPN y acceso remoto IPsec. Planificar el despliegue con un administrador de respaldo y usuarios de prueba.
• 14. MFA debería estar activo para la WebAdmin Console y el VPN Portal. Estándar: CIS, Gravedad: High. Muy importante, especialmente si los portales son accesibles desde redes menos controladas.
• 15. Las conexiones a los servidores de autenticación deberían estar cifradas. Estándar: CIS, Gravedad: Medium. Importante en conexiones AD/LDAP/RADIUS. Evitar autenticación no cifrada.
• 17. La autenticación de clave pública debería estar activada para SSH. Estándar: Recommended, Gravedad: High. Muy útil. Además, permitir SSH solo desde redes de confianza.
• 18. El User Portal no debería ser accesible desde la zona WAN. Estándar: Recommended, Gravedad: High. Correcto en muchos entornos. Si se necesita acceso WAN, restringirlo fuertemente y usar MFA.
• 19. La WebAdmin Console no debería ser accesible desde la zona WAN. Estándar: CIS, Gravedad: High. Uno de los puntos más importantes. Nunca abrir ampliamente WebAdmin a Internet.
• 20. MFA debería configurarse para el administrador predeterminado. Estándar: CIS, Gravedad: High. Importante, pero mejor aún es un proceso administrativo limpio con cuentas de administrador personales.

Backups, actualizaciones, reglas e inspection

• 16. Los respaldos deberían planificarse en el firewall o en Sophos Central. Estándar: CIS, Gravedad: Low. Gravedad baja, pero extremadamente importante en caso de emergencia. También probar el proceso de restauración.
• 21. Los correos electrónicos de notificación deberían configurarse para eventos del sistema y de seguridad. Estándar: CIS, Gravedad: Low. Sophos Firewall puede enviar notificaciones por correo y SNMP; los eventos se seleccionan en System services > Notification list. Valoración Avanet: según el contexto. Lo decisivo es una vía de alerta fiable y probada. Si Syslog, SIEM, monitorización o Central Alerts funcionan correctamente, el correo no es obligatorio. Un servidor SMTP configurado sin eventos seleccionados ni prueba de entrega todavía no es un proceso de alertas.
• 22. Las actualizaciones automáticas de patrones deberían estar activadas. Estándar: CIS, Gravedad: High. Valoración Avanet: prioridad alta. Sin patrones actuales, varias funciones de protección pierden eficacia. Las actualizaciones están activadas automáticamente de forma predeterminada, pero aun así deben comprobarse el estado y la última actualización correcta. El firmware de Access Points y dispositivos RED solo se descarga y se instala por separado porque requiere un reinicio. En entornos Air-Gap se necesita un proceso manual de patrones y licencias.
• 23. Se debería seleccionar una política web en una regla de firewall. Estándar: Recommended, Gravedad: Medium. Útil para el tráfico web de usuarios. No aplicarlo ciegamente al tráfico de servidor a servidor o tráfico especializado.
• 24. La protección contra día cero debería seleccionarse en una regla de firewall. Estándar: CIS, Gravedad: High. Útil para rutas web y de descarga adecuadas. Considerar licencia, rendimiento y falsos positivos.
• 25. IPS debería estar activado y se debería seleccionar una política IPS en una regla de firewall. Estándar: CIS, Gravedad: High. Punto de protección muy importante. IPS debe elegirse adecuadamente por ruta de tráfico y registrarse.
• 26. Se debería seleccionar una política de control de aplicaciones en una regla de firewall. Estándar: CIS, Gravedad: Medium. Útil para reglas de Internet de clientes. Probar primero en tráfico crítico.
• 27. Una regla de inspección SSL/TLS debería usar la acción Decrypt. Estándar: CIS, Gravedad: High. No activar ciegamente. La inspección TLS requiere distribución de CA, excepciones, fase piloto y proceso de resolución de problemas.
• 28. Una regla de permiso no debería usar Any en los campos de red y servicio en todas partes. Estándar: CIS, Gravedad: Medium. Muy importante para la higiene de reglas. Any puede ser necesario conscientemente, pero debe justificarse y registrarse.

Sophos Central y hora

• 29. Sophos Central Reporting debería estar activado. Estándar: Recommended, Gravedad: Medium. Útil para informes y evaluaciones más largas. No es obligatorio si Syslog/SIEM se opera correctamente.
• 30. El firewall debería estar registrado para Sophos Central Management y Central Management debería estar activado. Estándar: Recommended, Gravedad: Medium. Práctico para gestión centralizada, respaldos e informes. No todos los entornos quieren o necesitan gestión en la nube.
• 31. Se debería configurar un servidor NTP. Estándar: CIS, Gravedad: Low. Requisito básico. Sin tiempo correcto, los registros, certificados, autenticación y resolución de problemas sufren.

Priorizar e implementar hallazgos

No todos los hallazgos tienen la misma importancia en cada entorno. Una buena revisión clasifica las entradas no solo por gravedad técnica, sino también por exposición y riesgo operativo.

Esta secuencia ha demostrado ser efectiva:

1. Revisar accesos de gestión y portales expuestos a Internet.
2. Revisar MFA y seguridad de inicio de sesión para administradores, VPN Portal, User Portal y acceso remoto.
3. Limpiar reglas de firewall con fuentes, destinos o servicios demasiado amplios.
4. Controlar registros, respaldos y hotfixes.
5. Revisar funciones de protección por regla, como IPS, política web, control de aplicaciones, inspección TLS o protección contra día cero.
6. Evaluar hallazgos de Central, Reporting o NDR según si la función realmente se utiliza y opera en el entorno.

La secuencia es pragmática: primero las cosas que son directamente visibles en Internet o permiten acceso al firewall. Luego, higiene de reglas y funciones de protección. Luego, temas operativos y de ecosistema.

Hallazgos típicos y medidas adecuadas

WebAdmin, User Portal o VPN Portal son demasiado accesibles

Si los portales administrativos o cercanos al usuario son accesibles desde demasiadas zonas, aumenta el riesgo de escaneos, intentos de fuerza bruta y relleno de credenciales. El artículo más importante sobre esto es Asegurar el acceso a Sophos Firewall: Configurar correctamente el Device Access.

Para entornos productivos, se debe verificar:

• ¿Es realmente necesario WebAdmin desde la zona WAN?
• ¿Existe una regla de excepción de Local Service ACL para la IP de gestión o la red de administración?
• ¿SSH solo está permitido desde redes de confianza?
• ¿Son User Portal y VPN Portal accesibles solo donde se necesitan?

Falta MFA o no está activado de manera consistente

MFA debe aplicarse al menos a accesos administrativos y acceso remoto. Si el Health Check muestra hallazgos de MFA, no se debe cambiar ciegamente para todos los usuarios al mismo tiempo. Es mejor un despliegue controlado con usuario de prueba, administrador de respaldo y proceso de token limpio.

La guía práctica está en Activar MFA para Sophos Firewall WebAdmin, VPN Portal y acceso remoto.

Las reglas de firewall son demasiado abiertas

Reglas muy amplias con Any en fuente, destino o servicio a menudo han crecido históricamente. No todas las reglas amplias son automáticamente incorrectas, pero cada una debe estar justificada.

Para la limpieza, estas preguntas son útiles:

• ¿Qué zona realmente puede acceder a qué zona?
• ¿Se pueden restringir las redes de destino o los servicios?
• ¿Está activo el registro para que los aciertos sean visibles?
• ¿Existen reglas de prueba antiguas o excepciones temporales?
• ¿Se puede dividir la regla en varias reglas más comprensibles?

Los fundamentos están en Entender y configurar correctamente las reglas de Sophos Firewall. Si no está claro qué regla se aplica, ayuda Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture.

Faltan respaldos, hotfixes y proceso de actualización

Un Health Check puede señalar la falta de respaldos o temas de actualización/hotfix. Estos puntos parecen menos espectaculares que la exposición de portales, pero son cruciales en caso de emergencia.

Antes de cambios mayores, se debe crear un respaldo y saber cómo funciona una restauración. El procedimiento está descrito en Crear o restaurar un respaldo de Sophos Firewall. Para temas de firmware, es adecuado Actualización de firmware de Sophos Firewall - Preparación y mejores prácticas.

Registros e informes son incompletos

Si faltan registros, la operación es ciega. El Health Check puede dar pistas sobre temas de registros o informes, pero la decisión real depende del modelo operativo.

Para análisis local, son relevantes Log Viewer, registros de servicios y Packet Capture. Para almacenamiento más prolongado, se necesita Central Firewall Reporting o Syslog/SIEM. Si no se investigan eventos de registro individuales, sino flujos de tráfico, picos de ancho de banda o relaciones de comunicación inusuales, también es adecuado Monitoreo sFlow. Los fundamentos locales están en Solución de problemas de Sophos Firewall: Servicios y registros.

Las funciones de protección no están activas en las reglas

Un punto frecuente son las reglas sin IPS, política web, control de aplicaciones, inspección TLS o protección contra día cero. Aquí no se debe activar todo de manera general, sino entender la ruta del tráfico.

Ejemplos:

• El tráfico web de usuarios necesita controles diferentes al tráfico de servidor a servidor.
• La inspección TLS debe implementarse planificadamente, ya que puede interferir con aplicaciones.
• IPS y control de aplicaciones necesitan registro y una rutina de revisión.
• Las funciones de NDR o Threat Feed solo ayudan si los hallazgos se evalúan posteriormente.

Para la inspección TLS, es adecuado Implementar correctamente la inspección TLS de Sophos Firewall. Para Threat Feeds, es adecuado Sophos Firewall Threat Feeds.

Documentar y volver a comprobar la revisión

Sophos Firewall permite anular manualmente el estado de revisiones individuales. Esto puede ser útil si una recomendación no se implementa conscientemente en el propio entorno.

Sin embargo, los overrides no deben malinterpretarse como una función de limpieza. Si se anula un punto, debe estar documentado:

• ¿Por qué no es adecuada la recomendación?
• ¿Quién aprobó la decisión?
• ¿La excepción es permanente o solo temporal?
• ¿Cuándo se revisará nuevamente?
• ¿Existe una medida compensatoria?

⚠️ Un override no es una solución. Es una aceptación consciente del riesgo o una excepción documentada. Sin justificación, el Health Check pierde valor.

Documentar correctamente el resultado

Una revisión del Health Check debe generar un resultado rastreable. De lo contrario, solo se ve brevemente un panel, pero más tarde no se sabe qué decisión se tomó y qué puntos aún están pendientes.

Para entornos pequeños, a menudo basta con una tabla simple:

• Fecha: ¿Cuándo se revisó el Health Check?
• Firmware: ¿En qué versión de SFOS se evaluó?
• Hallazgo: ¿Qué punto no conforme se reportó?
• Riesgo: ¿Por qué es relevante o menos relevante el punto en este entorno?
• Medida: ¿Qué se cambiará, probará o aceptará conscientemente?
• Responsable: ¿Quién aclarará el punto profesional o técnicamente?
• Fecha límite: ¿Para cuándo debe completarse la medida o reevaluarse?
• Evidencia: Captura de pantalla, ticket, ID de cambio o referencia de registro de auditoría

En firewalls productivos, la evidencia no debe consistir solo en una captura de pantalla. Si se cambió una configuración, deben estar juntos el ticket de cambio, el registro de auditoría, la regla de firewall afectada y el resultado del seguimiento. Para cambios en reglas, interfaces, hosts y servicios, es especialmente útil Revisar los registros de auditoría de Sophos Firewall.

Revisar nuevamente después de los cambios

Después de una corrección, se debe abrir nuevamente el Health Check y verificar si el hallazgo realmente ha desaparecido. Además, se necesita una prueba de funcionamiento técnico, ya que un estado verde por sí solo no prueba que el tráfico productivo siga funcionando correctamente.

Ejemplos:

• Después de un cambio en Device access, verificar si el acceso administrativo desde la red de gestión prevista aún funciona y ya no es accesible desde redes no deseadas.
• Después de cambios en MFA, iniciar sesión con un usuario de prueba y verificar por separado el administrador de respaldo.
• Después de cambios en el conjunto de reglas, probar Log Viewer, Policy Test y aplicaciones afectadas.
• Después de cambios en registros o informes, verificar si los nuevos eventos son realmente visibles localmente, en Sophos Central o en el Syslog.
• Después de un override, establecer un recordatorio para que la excepción no se olvide permanentemente.

Si se abordan varios hallazgos al mismo tiempo, se deben dividir los cambios en bloques pequeños. De lo contrario, en caso de un problema posterior, no está claro si el acceso al dispositivo, MFA, reglas de firewall, inspección TLS u otro cambio fue la causa.

Usar el Health Check como proceso operativo

El Health Check es más efectivo cuando se ejecuta regularmente y después de cambios importantes.

Momentos adecuados:

• después de la configuración inicial o una puesta en marcha,
• antes y después de cambios importantes en el conjunto de reglas,
• antes de actualizaciones de firmware,
• después de restauraciones o cambios de hardware,
• después de migraciones o cambios importantes en la arquitectura,
• antes de auditorías,
• trimestralmente como revisión de seguridad.

Para los cambios en sí, también se debe utilizar el registro de auditoría. El artículo Revisar los registros de auditoría de Sophos Firewall explica cómo evaluar configuration-audit.log y rastrear cambios de configuración.

Proceso práctico de revisión

Una revisión pragmática del Health Check se desarrolla así:

1. Abrir el Health Check en el Control Center.
2. Ordenar los hallazgos no conformes por gravedad.
3. Revisar primero los servicios y accesos administrativos expuestos a Internet.
4. Abordar temas de MFA, contraseñas y sesiones.
5. Identificar reglas de firewall amplias y validar con Log Viewer.
6. Revisar respaldos, hotfixes, registros e informes.
7. Evaluar funciones de protección por regla.
8. Documentar excepciones justificadas en lugar de anular sin comentarios.
9. Revisar nuevamente después de los cambios.
10. Documentar el resultado con fecha, responsable y puntos pendientes.

Para revisiones recurrentes, a menudo basta con una tabla simple con hallazgo, riesgo, medida, responsable, estado y recordatorio. Lo importante es que los hallazgos no solo se vean, sino que se aborden o se acepten conscientemente.

Límites

El Health Check es útil, pero tiene límites claros.

• No conoce toda la lógica de negocio del entorno.
• No evalúa si una regla es necesaria profesionalmente.
• No reemplaza la segmentación de red ni un modelo de zonas.
• No detecta automáticamente cada caso especial riesgoso.
• No reemplaza una auditoría externa ni una revisión manual de reglas.
• No indica si las alertas se abordarán posteriormente.

Por lo tanto, se debe ver el Health Check como un punto de partida. Hace que las desviaciones visibles sean tangibles, pero la verdadera calidad de seguridad surge de una buena arquitectura, procesos limpios y mantenimiento constante.

Lista de verificación operativa

• Ejecutar el Health Check después de la puesta en marcha y después de grandes cambios.
• Priorizar hallazgos por gravedad y exposición.
• Revisar la accesibilidad WAN de WebAdmin, SSH, User Portal y VPN Portal.
• Activar MFA para administradores, portales y acceso remoto.
• Limpiar o justificar reglas de firewall amplias.
• Activar registros en reglas importantes.
• Revisar respaldos y proceso de restauración.
• Documentar el proceso de hotfix y firmware.
• Establecer overrides solo con justificación.
• Documentar regularmente el resultado del Health Check.

FAQ