Revisión de reglas de cortafuegos para ISO 27001, NIS2, DORA y GDPR
Son las 07:42 de un lunes por la mañana. El CISO de un proveedor SaaS y FinTech en crecimiento revisa tres mensajes distintos.
El primero llega del SOC. Una estación de trabajo de un desarrollador comprometida intentó conectarse durante la noche a una subred interna de bases de datos. El tráfico fue bloqueado, pero el analista quiere confirmar que la regla de cortafuegos es intencional, está vigente y está aprobada.
El segundo procede de un gran cliente corporativo. Solicita evidencias de que los entornos de producción, desarrollo, corporativo y soporte están segmentados, de que las reglas de cortafuegos se revisan y de que las excepciones caducan.
El tercero es del responsable de cumplimiento normativo. La organización está sujeta a NIS2 como proveedor digital importante, tiene responsabilidades GDPR como encargado del tratamiento y cuenta con clientes de servicios financieros que solicitan evidencias de gestión del riesgo relacionado con las TIC al estilo DORA. El consejo de administración quiere saber si las mismas evidencias ISO/IEC 27001:2022 pueden responder a los tres frentes.
Entonces llega la revisión posterior al incidente. Un servidor de desarrollo estuvo a punto de quedar expuesto a internet durante un cambio nocturno. No se perdió información de clientes, pero el equipo forense descubrió algo peor que el error inicial: una regla de cortafuegos de “prueba temporal” de hacía cinco años seguía permitiendo un movimiento amplio entre desarrollo y producción. Si un atacante hubiera obtenido acceso, la red habría ofrecido muy poca resistencia.
Ese es el momento en que muchas organizaciones descubren una verdad incómoda. Pueden tener cortafuegos, VLAN, grupos de seguridad en la nube y diagramas, pero no tienen gobernanza sobre zonas de segmentación, titularidad de reglas, acceso temporal, aprobaciones de cambios, recertificación y evidencias de auditoría.
En 2026, “tenemos un cortafuegos” no es una respuesta defendible. Auditores, reguladores, clientes y aseguradoras quieren pruebas de que las redes están separadas de forma intencional, de que el tráfico se controla por necesidad de negocio, de que las excepciones de riesgo están gobernadas y de que los registros demuestran que los controles funcionan.
Por qué la gobernanza de cortafuegos es ahora un asunto del consejo de administración
La segmentación de red solía tratarse como un asunto técnico de ingeniería. Los equipos de infraestructura eran responsables de las VLAN, los administradores de cortafuegos mantenían los conjuntos de reglas, los equipos de nube gestionaban los grupos de seguridad y cumplimiento solo veía un diagrama durante las auditorías.
Ese modelo operativo ya no funciona.
La Directiva NIS2 exige que las entidades esenciales e importantes implanten medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de los sistemas de redes y de información. El artículo 21 incluye políticas sobre análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, seguridad en la adquisición y el mantenimiento, evaluación de la eficacia, ciberhigiene básica, control de acceso y gestión de activos. Los órganos de dirección deben aprobar y supervisar esas medidas de gestión de riesgos de ciberseguridad.
DORA es aplicable desde el 17 de enero de 2025 a muchas entidades financieras y convierte la gestión del riesgo relacionado con las TIC en una disciplina gobernada y documentada. Los artículos 5, 6 y 8 exigen gobernanza, un marco de gestión del riesgo relacionado con las TIC y la identificación de funciones de negocio respaldadas por TIC, activos de información, activos TIC, dependencias, activos críticos e interconexiones. Los artículos 9, 10 y 11 abordan protección, prevención, detección, respuesta y recuperación. Los artículos 24 a 27 exigen pruebas de resiliencia operativa digital, incluidas pruebas avanzadas para determinadas entidades. Esto convierte la segmentación en un asunto de resiliencia, no solo de cortafuegos.
GDPR añade la capa de responsabilidad proactiva en privacidad. El artículo 32 exige medidas técnicas y organizativas adecuadas para garantizar un nivel de seguridad adecuado al riesgo, incluida la confidencialidad, integridad y disponibilidad, así como la resiliencia. El artículo 5(1)(f) exige integridad y confidencialidad, y el artículo 5(2) exige responsabilidad proactiva. Si los sistemas con datos personales son accesibles desde equipos comprometidos, redes de invitados o rutas de terceros no gestionadas, una autoridad de control puede preguntar por qué existían esas rutas.
ISO/IEC 27001:2022 proporciona la base del sistema de gestión que conecta estas obligaciones. Exige alcance, requisitos de las partes interesadas, evaluación de riesgos, tratamiento de riesgos, una Declaración de Aplicabilidad, planificación y control operacional, responsabilidad de la dirección, objetivos medibles, información documentada y mejora continua. El Anexo A, respaldado por la guía ISO/IEC 27002:2022, incluye las áreas de control necesarias para riesgo de proveedores, servicios en la nube, registro de eventos, supervisión, arquitectura segura, separación de entornos y gestión de cambios.
La conclusión es sencilla: la segmentación de red y la revisión de reglas de cortafuegos son ahora evidencias de gobernanza.
El patrón operativo de Clarysec: 8.20, 8.22 y 8.32
Clarysec trata la segmentación y la revisión de cortafuegos como un único patrón operativo dentro de los controles ISO/IEC 27002:2022, no como tareas técnicas aisladas.
Los tres controles principales son:
| Área ISO/IEC 27002:2022 | Pregunta de gobernanza | Evidencias que esperan los auditores |
|---|---|---|
| 8.20 Seguridad de redes | ¿Las redes se diseñan, gestionan, supervisan y protegen en función del riesgo? | Diagramas de arquitectura, estándares de cortafuegos, procedimientos de red segura, registros de supervisión, evidencias de IDS/IPS, muestras de configuración de VPN y red en la nube |
| 8.22 Segregación de redes | ¿Las zonas están separadas por sensibilidad, función y nivel de confianza? | Modelo de zonificación, matriz de flujos de datos, diseño de VLAN y subredes, límites de DMZ, reglas de cortafuegos entre zonas, resultados de pruebas de segmentación |
| 8.32 Gestión de cambios | ¿Los cambios de reglas se evalúan, aprueban, prueban, registran y revisan? | Tickets de cambio, evaluaciones de riesgos, aprobaciones, planes de reversión, revisiones posteriores a la implementación, registros de cambios de emergencia |
En Zenith Blueprint: hoja de ruta de 30 pasos para auditores [ZB], Clarysec sitúa la seguridad de redes en la fase Controles en acción, paso 20: controles 8.18 a 8.26. La guía formula con claridad la pregunta central de auditoría:
“En esencia, este control exige que las organizaciones garanticen que las redes sean seguras por arquitectura, no solo mediante la incorporación posterior de cortafuegos o antivirus. Esto implica pensar estratégicamente en la segmentación de red, el control de acceso, el cifrado en tránsito, la supervisión y la defensa en profundidad. Empieza con una pregunta sencilla: ¿quién y qué se está comunicando, y debería hacerlo?”
Esa pregunta, “¿quién y qué se está comunicando, y debería hacerlo?”, es el mejor punto de partida práctico para la revisión de reglas de cortafuegos. Aleja la conversación de miles de entradas ACL crípticas y la centra en flujos justificados por el negocio.
El mismo Zenith Blueprint indica a los equipos que evalúen la arquitectura de red verificando que las reglas de cortafuegos, las configuraciones IPS/IDS y las configuraciones de acceso remoto estén actualizadas y reforzadas, y que confirmen que los grupos de seguridad en la nube, el enrutamiento y las reglas de VPC o subred coinciden con la arquitectura prevista. También indica a los auditores que esperen un documento de arquitectura de seguridad de red que muestre cortafuegos, pasarelas VPN, zonas DMZ, separación de VLAN y límites de confianza.
Para gestión de cambios, Zenith Blueprint sitúa el control ISO/IEC 27002:2022 8.32 en la fase Controles en acción, paso 21: controles 8.27 a 8.34, y destaca por qué la gobernanza de cortafuegos falla cuando el control de cambios es débil:
“Este control reconoce una realidad difícil en TI: muchos incidentes no son causados por ataques, sino por cambios mal gestionados. Una regla de cortafuegos abierta con demasiado alcance. Un ajuste de depuración que queda habilitado. Una dependencia olvidada tras una migración.”
Así es exactamente como las aperturas temporales de cortafuegos se convierten en rutas de ataque permanentes.
Cómo es una buena segmentación de red
Un programa maduro de segmentación tiene cuatro capas.
Primero, cuenta con un modelo de zonificación. Las zonas no son subredes arbitrarias. Son límites de confianza alineados con la función de negocio y la sensibilidad de los datos, como DMZ expuesta a internet, capa de aplicación de producción, capa de base de datos de producción, red de usuarios corporativos, red de gestión privilegiada, entorno de desarrollo, entorno de prueba, red de copias de seguridad, Wi-Fi de invitados, zona OT o IoT y zona de acceso de terceros.
Segundo, dispone de una matriz de flujos. Para cada par de zonas, la organización documenta origen, destino, protocolo, puerto, aplicación, propietario de negocio, propietario del sistema, tipo de datos, justificación y requisito de registro de eventos permitidos.
Tercero, establece la titularidad de las reglas. Cada regla de cortafuegos, regla de grupo de seguridad en la nube o política de perímetro definido por software tiene un propietario, una fecha de caducidad o recertificación, un ticket de cambio vinculado y una justificación de negocio. “Any to any” debe tratarse como un hallazgo salvo que esté aceptado formalmente como riesgo, limitado en el tiempo y respaldado por controles compensatorios.
Cuarto, incorpora una revisión recurrente. Revisar significa mucho más que exportar una base de reglas de cortafuegos una vez al año. Incluye recertificación por el propietario, comparación con el tráfico observado, detección de reglas no utilizadas, validación de excepciones temporales, revisión de exposición a internet, pruebas de segmentación y conciliación con el inventario de activos.
La Política de Seguridad de Redes [P-NS] de Clarysec establece claramente la expectativa empresarial:
“Todo el tráfico entre zonas debe estar controlado por cortafuegos o soluciones de perímetro definido por software, con configuraciones explícitas de denegación por defecto.”
De la política empresarial, Política de Seguridad de Redes, sección “Requisitos de gobernanza”, cláusula 5.2.
La misma política conecta directamente los cambios de cortafuegos con la gestión de cambios:
“Cualquier cambio en conjuntos de reglas de cortafuegos, tablas de enrutamiento o configuraciones de grupos de seguridad debe seguir la Política de gestión de cambios (P5) de la organización, incluidos los planes de reversión y el registro de auditoría.”
De la política empresarial, Política de Seguridad de Redes, sección “Requisitos de gobernanza”, cláusula 5.4.
Para pymes, la Política de Seguridad de Redes para pymes [P-NS-SME] de Clarysec proporciona el mismo principio en términos operativos:
“Las reglas de denegación por defecto deben aplicarse para todas las conexiones entrantes salvo que sean expresamente necesarias y estén aprobadas”
De la política para pymes, Política de Seguridad de Redes para pymes, sección “Requisitos de implementación de la política”, cláusula 6.1.2.
Y, específicamente para segmentación:
“El tráfico entre segmentos debe filtrarse, y el acceso entre segmentos debe seguir el principio de mínimo privilegio”
De la política para pymes, Política de Seguridad de Redes para pymes, sección “Requisitos de implementación de la política”, cláusula 6.2.3.
Estas cláusulas de política permiten a un auditor trazar desde el riesgo hasta el control, desde el control hasta la regla, desde la regla hasta la aprobación y desde la aprobación hasta los registros.
Un único paquete de evidencias para ISO 27001, NIS2, DORA y GDPR
El error que cometen muchos equipos es crear paquetes de evidencias separados: uno para ISO/IEC 27001:2022, otro para NIS2, otro para GDPR, otro para clientes DORA y otro para el ciberseguro.
Un enfoque mejor consiste en construir un único paquete de evidencias de gobernanza de segmentación y cortafuegos que se mapee transversalmente entre marcos.
Zenith Controls: guía de cumplimiento cruzado [ZC] mapea el control ISO/IEC 27002:2022 8.22 Segregación de redes como un control preventivo que respalda la confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad Proteger y con la capacidad operativa de seguridad de sistemas y redes. Vincula 8.22 con 8.20 Seguridad de redes, 8.21 Seguridad de los servicios de red, 8.7 Protección contra el software malicioso, 8.27 Arquitectura segura de sistemas y principios de ingeniería, y 8.31 Separación de entornos de desarrollo, prueba y producción.
La guía explica así la relevancia de la segmentación para NIS2:
“La segregación de redes es una respuesta directa a estas obligaciones, al reducir las superficies de ataque e impedir el movimiento lateral entre sistemas conectados en red.”
Esa frase explica por qué los programas de ciberhigiene de NIS2 no deben tratar la segmentación como opcional. La contención del ransomware no depende únicamente de la protección de endpoints. Consiste en limitar el movimiento lateral cuando falla la prevención.
Para GDPR, Zenith Controls mapea 8.22 con el artículo 32 y el considerando 49, señalando que los diagramas de red y las políticas de zonificación se convierten en evidencias clave de cumplimiento. Para DORA, Zenith Controls mapea la seguridad y segregación de redes con la gestión del riesgo relacionado con las TIC y la contención de incidentes. Las pruebas de segmentación pueden respaldar evidencias de resiliencia TIC, especialmente cuando demuestran que un compromiso en una zona no puede moverse libremente hacia servicios financieros críticos, repositorios de datos personales o sistemas de gestión privilegiada.
| Artefacto de evidencia | Uso en ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Uso en NIS2 | Uso en DORA | Uso en GDPR |
|---|---|---|---|---|
| Documento de arquitectura de seguridad de red | Respaldar el alcance del SGSI, el control operacional, 8.20 y 8.22 | Muestra medidas técnicas para la seguridad de redes y sistemas de información | Muestra interconexiones TIC y dependencias de servicios críticos | Muestra límites de protección alrededor de sistemas con datos personales |
| Matriz de zonas y flujos | Demuestra segregación basada en riesgos y mínimo privilegio | Respalda la ciberhigiene y la evaluación de eficacia | Respalda la clasificación de activos TIC y dependencias | Respalda las medidas técnicas del artículo 32 y la responsabilidad proactiva |
| Registros de revisión de reglas de cortafuegos | Evidencia de supervisión de controles y mejora continua | Muestra que las medidas se revisan y no son estáticas | Respalda la revisión del riesgo TIC y las pruebas de resiliencia | Demuestra la seguridad continua del tratamiento |
| Tickets de cambio para reglas de cortafuegos | Respalda la gestión de cambios 8.32 | Respalda el mantenimiento seguro y la trazabilidad | Respalda cambios TIC controlados y resiliencia | Muestra que los cambios que afectan a sistemas con datos personales se evalúan en función del riesgo |
| Registro de excepciones | Respalda el tratamiento de riesgos y la aceptación del riesgo residual | Muestra la supervisión de la dirección sobre desviaciones | Respalda la tolerancia al riesgo y la gobernanza | Muestra responsabilidad proactiva sobre exposiciones temporales |
| Registros de tráfico entre zonas bloqueado y permitido | Respaldan el registro de eventos, la supervisión y la eficacia del control | Respaldan la detección y la respuesta a incidentes | Respaldan la categorización de incidentes y la notificación | Respaldan la evaluación de brechas y la preservación de evidencias |
Esta tabla no es solo una correspondencia de cumplimiento. Es una hoja de ruta para la recopilación de evidencias.
La revisión de reglas de cortafuegos que realmente funciona
Una revisión de reglas de cortafuegos fracasa cuando solo pregunta: “¿Sigue siendo necesaria esta regla?” Los propietarios de reglas suelen responder que sí porque temen romper algo.
Una revisión más eficaz plantea seis preguntas:
- ¿Qué servicio de negocio respalda esta regla?
- ¿Qué propietario del activo y propietario de la información aprobaron el flujo?
- ¿Está el destino en la zona correcta para los datos y la función?
- ¿La regla es más permisiva de lo que requiere el tráfico observado?
- ¿Está habilitado el registro de eventos para los flujos de alto riesgo?
- ¿Tiene la regla una fecha de revisión, fecha de caducidad o registro de excepción?
La Política de Seguridad de Redes para pymes exige una revisión periódica:
“El proveedor de soporte de TI debe realizar una revisión anual de las reglas de cortafuegos, la arquitectura de red y las configuraciones inalámbricas”
De la política para pymes, Política de Seguridad de Redes para pymes, sección “Requisitos de gobernanza”, cláusula 5.6.1.
La revisión anual es la base, no el límite máximo. Las reglas de alto riesgo necesitan recertificación con mayor frecuencia.
| Categoría de regla | Ejemplo | Frecuencia de revisión | Expectativa de aprobación |
|---|---|---|---|
| Entrada desde internet a producción | API pública hacia pasarela de aplicación | Trimestral o tras una versión mayor | Propietario del servicio, seguridad, aprobador del cambio |
| Acceso entre zonas a base de datos de producción | Capa de aplicación hacia capa de base de datos | Trimestral | Propietario de la aplicación y propietario de la información |
| Acceso administrativo | Bastión de acceso hacia puertos de administración de servidores | Mensual o trimestral | Propietario de infraestructura y delegado del CISO |
| Acceso de terceros | VPN de proveedor hacia subred de soporte | Mensual o hito contractual | Propietario del proveedor y seguridad |
| Excepción temporal | Acceso de emergencia durante una migración | Antes de la caducidad, máximo 90 días | Responsable del SGSI o CISO |
| Regla interna estándar de bajo riesgo | Servidor de supervisión hacia endpoints gestionados | Anual | Propietario del servicio |
La Política de Seguridad de Redes es explícita sobre las excepciones:
“La solicitud debe ser revisada y aprobada por el Responsable del SGSI o el CISO y registrada en el Registro de excepciones del SGSI, con un período máximo de aprobación de 90 días, renovable previa reevaluación.”
De la política empresarial, Política de Seguridad de Redes, sección “Tratamiento de riesgos y excepciones”, cláusula 7.3.
Para pymes, la Política de Seguridad de Redes para pymes exige que las solicitudes de excepción incluyan los datos mínimos adecuados:
“La solicitud debe incluir la justificación, el alcance, la duración y los controles compensatorios (por ejemplo, lista de permitidos de IP, registro de eventos)”
De la política para pymes, Política de Seguridad de Redes para pymes, sección “Tratamiento de riesgos y excepciones”, cláusula 7.3.3.
Esa cláusula convierte la gestión de excepciones, de una conversación informal, en tratamiento de riesgos auditable.
Ejemplo práctico: eliminar una regla de base de datos de producción de riesgo
Supongamos que una empresa encuentra la siguiente regla durante la revisión:
| Campo | Valor actual |
|---|---|
| Origen | VLAN de usuarios corporativos |
| Destino | Subred de base de datos de producción |
| Puerto | TCP 5432 |
| Acción | Permitir |
| Comentario | Acceso temporal para migración de informes |
| Creada | Hace 14 meses |
| Propietario | Desconocido |
| Registro de eventos | Deshabilitado |
Este es un hallazgo de auditoría clásico. Incumple el mínimo privilegio, no tiene propietario claro, no tiene caducidad, no tiene justificación vigente y no registra eventos. También crea una exposición frente al artículo 32 de GDPR si la base de datos de producción contiene datos personales de clientes.
El proceso de remediación debe crear evidencias, no solo eliminar una regla deficiente.
| Paso | Acción | Referencia de Clarysec | Evidencia de auditoría creada |
|---|---|---|---|
| 1. Mapear la regla con el modelo de zonas | Confirmar si los usuarios corporativos deberían acceder alguna vez a la subred de base de datos de producción | Zenith Blueprint, Controles en acción, paso 20 | Notas actualizadas de revisión de arquitectura y clasificación de zonas |
| 2. Crear o actualizar el registro de flujo | Documentar origen, destino, puerto, tipo de datos, propietario, justificación y riesgo | Zenith Controls, mapeo 8.22 | Entrada de la matriz de zonas y flujos |
| 3. Abrir un ticket de cambio | Proponer la eliminación o sustitución por una ruta controlada de servicio de informes | Política de Seguridad de Redes, cláusula 5.4 | Registro de cambio con análisis de riesgos, plan de pruebas y plan de reversión |
| 4. Decidir el tratamiento | Eliminar la regla amplia o sustituirla por una réplica de solo lectura, bastión, lista de permitidos de IP y registro de eventos | Política de Seguridad de Redes, cláusula 7.3 | Decisión de tratamiento de riesgos o excepción limitada en el tiempo |
| 5. Habilitar el registro de eventos para flujos aprobados | Enviar eventos de cortafuegos entre zonas de alto riesgo a la supervisión | Política de registro y supervisión, cláusula 6.1.1.6 | Registros SIEM, reglas de alerta y capturas de pantalla de supervisión |
| 6. Validar la segmentación | Probar que la subred de base de datos no es alcanzable salvo por rutas aprobadas | Zenith Blueprint, paso 20 | Resultado de prueba de segmentación y cierre de remediación |
La Política de registro y supervisión [P-LM] de Clarysec incluye comunicaciones externas y activadores de reglas de cortafuegos como eventos relevantes para registro:
“Comunicaciones externas y activadores de reglas de cortafuegos”
De la política empresarial, Política de registro y supervisión, sección “Requisitos de implementación de la política”, cláusula 6.1.1.6.
Para reglas entre zonas de alto riesgo, los activadores de cortafuegos deben alimentar el SIEM o la plataforma de supervisión, con alertas por hosts de origen, volúmenes o ventanas horarias inusuales.
La política para pymes también exige disciplina de cambios:
“Todos los cambios en configuraciones de red (reglas de cortafuegos, ACL de switches, tablas de enrutamiento) deben seguir un proceso documentado de Gestión de cambios”
De la política para pymes, Política de Seguridad de Redes para pymes, sección “Requisitos de implementación de la política”, cláusula 6.9.1.
Una sola limpieza de esta regla genera evidencias para el control operacional ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 y 8.32, la ciberhigiene de NIS2, el artículo 32 de GDPR y la gestión del riesgo relacionado con las TIC al estilo DORA.
Deben incluirse las redes en la nube, SaaS e híbridas
La segmentación moderna no se limita a VLAN y cortafuegos físicos. Incluye grupos de seguridad de AWS, grupos de seguridad de red de Azure, políticas de red de Kubernetes, tablas de enrutamiento en la nube, listas de permitidos de administración SaaS, endpoints privados, VPN, SD-WAN, proxies con control de identidad y controles de perímetro definido por software.
Para un proveedor SaaS o un servicio digital regulado, la revisión de reglas de cortafuegos debe incluir, como mínimo:
- Balanceadores de carga y pasarelas de aplicación expuestos a internet
- Grupos de seguridad en la nube y ACL de red
- Tablas de enrutamiento de subredes privadas
- Rutas de interconexión y Transit Gateway
- Rutas de VPN y administración remota
- Interfaces de administración y planos de gestión
- Ingress de Kubernetes y políticas de red
- Acceso de ejecutores de CI/CD a producción
- Cobertura de registro de eventos para flujos denegados y permitidos de alto riesgo
- Acceso de soporte de terceros y rutas de acceso de emergencia
Si un grupo de seguridad en la nube permite tráfico entrante de base de datos desde un rango amplio de IP corporativas, debe tratarse como una regla de cortafuegos. Necesita propietario, justificación, aprobación, revisión, registro de eventos y caducidad.
Aquí es también donde las normas ISO de apoyo refuerzan la narrativa. ISO/IEC 27017 aporta claridad sobre responsabilidades de seguridad en la nube. ISO/IEC 27033 proporciona orientación más detallada sobre arquitectura de seguridad de red, DMZ, zonas de segmentación, filtrado de tráfico y comunicaciones seguras entre redes. ISO/IEC 27701 refuerza la gobernanza de la privacidad cuando información de identificación personal (PII) se mueve a través de redes. ISO/IEC 27035 respalda la contención de incidentes, e ISO/IEC 27005 apoya la selección de la segmentación como tratamiento de riesgos frente al acceso no autorizado, la propagación de malware y el movimiento lateral.
Cómo prueban los auditores el mismo control de formas distintas
Una de las fortalezas de Zenith Controls es que explica cómo distintas metodologías de auditoría examinan el mismo control. Las evidencias pueden reutilizarse, pero las preguntas cambian.
| Enfoque de auditoría | Pregunta probable | Mejor evidencia |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿La segmentación se selecciona, implementa y revisa en función del riesgo? | Evaluación de riesgos, SoA, política de red, diagramas, registros de revisión |
| Auditor con enfoque ISO/IEC 27007 | ¿Las reglas de cortafuegos y los esquemas VLAN implementados coinciden con la política documentada? | Muestras de reglas de cortafuegos, ACL de routers, diseño de VLAN, entrevistas con administradores |
| Enfoque de auditoría de certificación ISO/IEC 27006-1:2024 | ¿Los límites críticos de red se auditan con competencia adecuada y planificación basada en riesgos? | Plan de auditoría, muestreo técnico, evidencias de grupos de seguridad en la nube, resultados de pruebas |
| Auditor orientado a NIST | ¿Los límites y los flujos de información se aplican y supervisan? | Reglas de cortafuegos, ACL, pruebas de segmentación, registros de supervisión |
| Auditor COBIT 2019 | ¿La seguridad de redes está gobernada, supervisada y reportada? | Matriz de propiedad, KPI, informes a la dirección, registro de riesgos |
| Auditor ISACA ITAF | ¿Los controles generales de TI operan de forma consistente? | Tickets de cambio, aprobaciones de excepciones, registros, muestras de recertificación de reglas |
| Autoridad de control GDPR | ¿Los sistemas con datos personales estaban protegidos por medidas técnicas adecuadas? | Mapas de flujo de datos, aislamiento de zonas PII, rutas de acceso, registros de cortafuegos |
| Evaluador centrado en DORA | ¿La segmentación respalda la resiliencia TIC y la contención de incidentes? | Mapa de dependencias de activos TIC, flujos de funciones críticas, playbooks de incidentes, registros de prueba |
Un evaluador centrado en DORA puede preguntar si un compromiso en una pasarela de pagos puede pivotar hacia bases de datos de clientes. Una autoridad competente NIS2 puede preguntar si ransomware en una estación de trabajo administrativa puede alcanzar sistemas esenciales de prestación del servicio. Una autoridad GDPR puede preguntar qué restricciones a nivel de red protegían los sistemas que trataban datos personales. Un auditor ISO puede pedir simplemente la evaluación de riesgos, la SoA, la política, el procedimiento y las evidencias de que las revisiones se realizaron.
Los mejores programas responden a todo esto con los mismos artefactos.
Métricas que hacen visible la segmentación para la alta dirección
NIS2 y DORA impulsan la responsabilidad proactiva de la dirección. ISO/IEC 27001:2022 exige liderazgo, objetivos, roles, recursos, informes y mejora continua. Esto significa que la segmentación necesita métricas que la dirección pueda entender.
Entre las métricas de gestión útiles se incluyen:
- Porcentaje de reglas de cortafuegos con propietario asignado
- Porcentaje de reglas con justificación de negocio documentada
- Número de reglas temporales caducadas
- Número de reglas con origen, destino o servicio “any”
- Número de servicios expuestos a internet por criticidad
- Porcentaje de flujos entre zonas de alto riesgo con registro de eventos habilitado
- Número de cambios de emergencia en cortafuegos por trimestre
- Porcentaje de reglas muestreadas vinculadas a tickets de cambio aprobados
- Número de fallos en pruebas de segmentación
- Tiempo medio para remediar reglas de riesgo o no utilizadas
- Número de excepciones con más de 90 días de antigüedad
- Número de reglas de acceso de terceros revisadas y recertificadas
La Política de Seguridad de Redes identifica la “eficacia de las reglas de cortafuegos” como una consideración de cumplimiento y aplicación en la sección “Aplicación y cumplimiento”, cláusula 8.2.2. Esa frase importa porque la mera existencia de reglas no basta. Las reglas deben ser eficaces, revisarse y estar alineadas con el riesgo actual.
Construir el paquete de evidencias de segmentación para 2026
Un paquete práctico de evidencias de segmentación y revisión de reglas de cortafuegos debe estar listo antes de que el auditor lo solicite.
Como mínimo, mantén:
- Diagrama actual de arquitectura de red, incluidas zonas en la nube e híbridas
- Estándar de clasificación de zonas, incluida sensibilidad y nivel de confianza
- Matriz de flujos para servicios críticos y sistemas con datos personales
- Exportación de reglas de cortafuegos y grupos de seguridad en la nube
- Registro de propietarios de reglas y recertificación
- Procedimiento de revisión de cortafuegos y calendario de revisión
- Registros de cambio para modificaciones de cortafuegos muestreadas
- Registro de excepciones con aprobaciones, caducidad y controles compensatorios
- Resultados de pruebas de segmentación y registros de remediación
- Evidencias de registro de eventos y supervisión para flujos de alto riesgo
- Playbooks de incidentes que demuestren contención por zona
- Métricas de reporte a la dirección y actas de reunión
Mapea estas evidencias con las cláusulas ISO/IEC 27001:2022 y las áreas de control del Anexo A. Después, cruza la referencia con el artículo 21 de NIS2, el artículo 32 de GDPR, los requisitos de gestión del riesgo relacionado con las TIC y pruebas de DORA, resultados de NIST CSF 2.0 como GOVERN, PROTECT, DETECT y RESPOND, y prácticas de gobernanza COBIT.
NIST CSF 2.0 es especialmente útil como capa de comunicación con el consejo de administración. Su función GOVERN se centra en requisitos legales, regulatorios y contractuales, apetito de riesgo, roles, políticas y supervisión. Sus resultados operativos abordan gestión de configuraciones, registro de eventos, supervisión, protección de datos, respuesta a incidentes y recuperación. Esto ayuda a la dirección a comprender el riesgo sin leer ACL de cortafuegos.
Hallazgos comunes que Clarysec observa en auditorías de segmentación
En proveedores SaaS, fintech, proveedores de servicios gestionados y pymes reguladas, los mismos hallazgos aparecen repetidamente:
- Red plana entre endpoints de usuario y servicios de producción
- Bases de datos de producción alcanzables desde redes de desarrollo o corporativas
- Grupos de seguridad en la nube amplios copiados de plantillas antiguas
- Reglas temporales de proveedores sin caducidad
- Cambios de cortafuegos realizados fuera del proceso de cambios
- Reglas sin propietario ni justificación de negocio
- Registro de eventos deshabilitado en reglas permisivas de alto riesgo
- Wi-Fi de invitados no completamente aislado
- Interfaces de administración alcanzables desde redes generales
- Diagramas que no coinciden con el enrutamiento real
- Ausencia de evidencias de que las revisiones de reglas se completaron
- Ausencia de pruebas de segmentación tras cambios importantes de arquitectura
- Ausencia de mapeo entre sistemas con datos personales y zonas de red
- Ausencia de informes a la dirección sobre exposición de red
Estos hallazgos no son solo debilidades técnicas. Debilitan la capacidad de la organización para demostrar la ciberhigiene de NIS2, la resiliencia operativa de DORA y la responsabilidad proactiva del artículo 32 de GDPR.
De la limpieza reactiva al control defendible
La segmentación de red y la revisión de reglas de cortafuegos son el punto donde la arquitectura de seguridad se encuentra con la realidad de auditoría. Si puedes demostrar un modelo de zonificación basado en riesgos, flujos entre zonas controlados, cambios de cortafuegos aprobados, excepciones limitadas en el tiempo, evidencias de registro de eventos y validación periódica, puedes responder a una amplia variedad de preguntas ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST y COBIT con una narrativa coherente.
Clarysec puede ayudarte a construir esa narrativa.
Usa Zenith Blueprint: hoja de ruta de 30 pasos para auditores para estructurar el recorrido de implementación, especialmente Controles en acción, paso 20 para seguridad y segmentación de redes, y paso 21 para gestión de cambios. Usa Zenith Controls: guía de cumplimiento cruzado para mapear los controles ISO/IEC 27002:2022 8.20, 8.22 y 8.32 con las expectativas de auditoría de NIS2, DORA, GDPR, NIST y COBIT. Ancla tus reglas operativas en la Política de Seguridad de Redes, la Política de Seguridad de Redes para pymes y la Política de registro y supervisión de Clarysec.
Tu siguiente paso es sencillo y de alto valor: selecciona un servicio crítico, como producción de clientes, procesamiento de pagos o gestión de identidades, y realiza esta semana una revisión de muestra de 10 reglas. Para cada regla, confirma propietario, justificación, origen, destino, puerto, registro de eventos, ticket de cambio y caducidad. Si no puedes demostrar esos siete datos, ya tienes el inicio de tu plan de mejora de segmentación para 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
