Una regla de firewall escrita por dirección IP y puerto no dice qué aplicación protege ni quién responde por ella. Tres pasos para llevar Zero Trust a las reglas y al tráfico entre aplicaciones, con lo que piden NIST, CISA y el NSTAC.
¿Cuántas reglas de tu firewall dejan pasar tráfico que ninguna aplicación usa? Si para responder hay que abrir una planilla vieja o preguntarle a alguien que ya no está en el equipo, tu firewall protege direcciones, no aplicaciones.
Cuando se habla de Zero Trust, casi siempre se piensa en el acceso remoto de los usuarios, lo que se conoce como ZTNA. Este artículo trata otra parte del modelo, menos visible: las reglas que deciden qué aplicación puede hablar con cuál dentro de tu propia red.
Por qué las reglas por IP y puerto envejecen mal
Durante años, el firewall se configuró por dirección IP y por puerto. El problema es que una dirección IP no dice qué aplicación hay detrás ni quién es su dueño.
El ciclo es conocido. Alguien abre un rango para que una aplicación funcione. Meses después la aplicación se muda a otro servidor, o se da de baja, y la regla sigue ahí. Si nadie sabe qué depende de ella, nadie se anima a borrarla, y así se acumulan permisos que ya no responden a ninguna necesidad del negocio.
El principio para evitarlo existe desde hace tiempo. La guía de firewalls de NIST de 2009 (SP 800-41 Rev. 1) ya pedía bloquear todo el tráfico entrante y saliente que no esté permitido de forma expresa, y escribir reglas tan específicas como sea posible. Lo que suele faltar es el dato que permite cumplirlo: a qué aplicación pertenece cada regla.
Movimiento lateral: lo que cuesta una regla amplia
Una regla demasiado amplia no molesta en el día a día. El problema aparece cuando un atacante ya entró a un servidor: desde ahí, esa regla le abre camino hacia el resto.
NIST lo describe en su arquitectura Zero Trust (SP 800-207, 2020): la seguridad basada solo en el perímetro resultó insuficiente, porque una vez que el atacante lo cruza, su movimiento lateral no encuentra freno. Por eso el modelo no da confianza implícita a un activo o a una cuenta solo por su ubicación en la red.
Para el tráfico entre aplicaciones, eso cambia la pregunta. Además de saber desde dónde viene una conexión, importa qué aplicación la necesita. CISA, en la versión 2.0 de su modelo de madurez Zero Trust (2023), lo plantea como un recorrido: en la etapa tradicional hay grandes segmentos de red con pocas restricciones de alcance; en la óptima, microsegmentación extensa basada en los perfiles de cada aplicación.
El camino tiene tres pasos, y el primero parte de los firewalls que ya tienes.
Paso 1: visibilidad sobre lo que ya tienes
Tus firewalls, perimetrales e internos, ya guardan la configuración y los logs. Un análisis de esas políticas, cruzado con el tráfico real, permite reconocer las aplicaciones de negocio que están detrás de cada flujo. Hoy existen plataformas de gestión de políticas que hacen este trabajo con ayuda de inteligencia artificial y proponen las aplicaciones para que el equipo las confirme.
El resultado es concreto. Donde antes veías direcciones IP, ahora ves pagos, portal web o ERP. Y las reglas que no corresponden a ninguna aplicación quedan a la vista: es la respuesta a la pregunta del comienzo.
Paso 2: superficie protegida y mapa de flujos
En 2022, el NSTAC, un comité asesor del presidente de Estados Unidos, recomendó un proceso de cinco pasos para implementar Zero Trust. Los dos primeros coinciden con este trabajo: definir la superficie protegida y mapear los flujos de transacciones.
La superficie protegida la define tu equipo: elige las aplicaciones críticas y les asigna un dueño que pueda decir qué flujos necesita su aplicación.
Después viene el mapa: quién habla con quién. La web con la aplicación, la aplicación con la base de datos. Con ese mapa se estima el riesgo de cada aplicación a partir de dos cosas: las reglas demasiado amplias que la exponen y las vulnerabilidades de sus servidores, que pueden llegar por API desde tu herramienta de gestión de vulnerabilidades.
Paso 3: mínimo privilegio sin cortar el servicio
Solo entonces se cierran los accesos que sobran. Una regla que abría todo a todo se reduce a lo que la aplicación usa: de la web a la aplicación, por el puerto que necesita. Es la aplicación directa de otro principio de NIST SP 800-207: cada acceso se concede con los mínimos privilegios que necesita la tarea.
Cerrar a ciegas también es un riesgo: un corte mal calculado puede dejar sin servicio a una aplicación crítica. Por eso la guía SP 800-41 de NIST pide que las reglas y políticas de firewall pasen por un control formal de cambios, dado su impacto posible en la seguridad y en la operación.
En la práctica, antes de cada cambio va un análisis de impacto. Si la regla nueva corta un flujo que el ERP necesita, lo ves antes de aplicarla. Ajustas la regla, la validas y la aplicas sin interrumpir el servicio.
Cómo queda el firewall al terminar
Al cerrar los tres pasos, cada regla queda ligada a su aplicación y a su dueño. Solo pasan los flujos que cada aplicación necesita, y las vulnerabilidades se atienden por criticidad, empezando por las aplicaciones que más importan.
Hay además una ventaja práctica: cuando alguien pregunta por qué existe una regla, en una auditoría o antes de un cambio, la respuesta está escrita y tiene nombre y apellido.
¿Quieres llevar Zero Trust al tráfico de tus aplicaciones?
En Assertiva acompañamos este recorrido, desde la visibilidad de las reglas actuales hasta los cambios con análisis de impacto. Escríbenos a contacto@assertiva.biz y revisemos juntos por dónde empezar en tu red.
Fuentes
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, septiembre de 2009, resumen ejecutivo (bloqueo de todo tráfico no permitido de forma expresa, reglas tan específicas como sea posible, control formal de cambios): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf
- NIST SP 800-207, Zero Trust Architecture, agosto de 2020, resumen y secciones 1 y 2.1 (movimiento lateral, sin confianza implícita por ubicación, mínimo privilegio): https://csrc.nist.gov/pubs/sp/800/207/final
- CISA, Zero Trust Maturity Model, versión 2.0, abril de 2023, pilar Redes, función "Network Segmentation": https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
- NSTAC, Report to the President on Zero Trust and Trusted Identity Management, 2022 (proceso de cinco pasos). Ficha en Cloud Security Alliance: https://cloudsecurityalliance.org/artifacts/report-to-the-president-on-zero-trust-and-trusted-identity-management/
Zero Trust para el tráfico de aplicaciones: de la regla por IP al mínimo privilegio