Reglas estáticas en un mundo dinámico: el caso de la seguridad basada en activos

Se supone que Zero Trust nos ayuda a adaptarnos a las amenazas, al cambio, a lo impredecible. Pero aquí está el detalle: la mayoría de nuestras políticas no se crearon para nada de eso. Son estáticas. Están codificadas de forma rígida. Son glaciales. Y en ningún lugar es esto más cierto que en la manera en que seguimos dependiendo de construcciones de red heredadas, como zonas estáticas, IP fijas y reglas de acceso permanentes. Todo esto para tomar decisiones de confianza en un mundo donde las cargas de trabajo se crean, migran y desaparecen más rápido de lo que se tarda en decir "escalamiento de tickets". Es momento de hablar de por qué la base de Zero Trust necesita un cambio fundamental y de por qué la seguridad basada en activos es el puente entre la parálisis de las políticas heredadas y la verdadera agilidad de Zero Trust.

Anclajes heredados: zonas, redes y la ilusión de control

Las direcciones IP, las zonas y los segmentos de red nunca tuvieron como propósito ser anclajes de políticas en entornos modernos. Se inventaron para un mundo en el que las redes eran estáticas, las aplicaciones permanecían en su sitio y el cloud era un fenómeno meteorológico. Las redes de hoy son elásticas. Los contenedores viven horas. Las instancias en el cloud aparecen y desaparecen. Los componentes de las aplicaciones se extienden por geografías, proveedores de cloud y zonas de confianza. Mientras tanto, ¿sus políticas de seguridad? Siguen asignando el acceso a zonas fijas y bloques de IP. Incluso con superposiciones SDN y herramientas nativas del cloud, la mayoría de las políticas en la capa de ejecución siguen ancladas en construcciones que no reflejan cómo opera el negocio. ¿El resultado? Un desajuste entre la intención y la ejecución que ralentiza el cambio y lo expone al riesgo.

El desajuste de velocidad: los activos cambian, las políticas no

Las zonas destacan en el nivel macro, pero las arquitecturas de seguridad basadas en zonas no pueden adaptarse con rapidez a los cambios en los activos y sus interacciones. Y no es porque el equipo de red sea lento, sino porque las reglas están codificadas de forma rígida, las aprobaciones son inflexibles y cada cambio se siente como abrir la caja de Pandora de las consecuencias imprevistas. En contraste, los activos en sí mismos (los servidores, las aplicaciones y los servicios) y sus atributos se mueven rápido. Los activos cambian constantemente:

• Un equipo de desarrollo crea un nuevo servicio en contenedores para pruebas.
• Una VM se parcha y se reubica entre regiones.
• Una integración SaaS modifica cómo fluyen los datos entre las aplicaciones.

Cada uno de estos eventos tiene implicaciones de seguridad. Pero las políticas subyacentes no pueden seguir el ritmo. Los cambios en el firewall se encolan, las aprobaciones se retrasan y las iniciativas de negocio se ven obligadas a esperar a la seguridad, no porque esté equivocada, sino porque el proceso es frágil. Aquí es donde Zero Trust suele estancarse, no en el principio, sino en la práctica. No se puede aplicar confianza adaptativa con controles fijos.

Por qué la seguridad basada en activos es el punto de inflexión

La seguridad basada en activos invierte el modelo. En lugar de anclar las decisiones de acceso a la infraestructura (como zonas o IP), las ancla a los activos en términos de quiénes son, qué hacen y qué tan riesgosos son. Los activos se convierten en el contexto. Y el contexto lo es todo en Zero Trust. Un modelo de políticas basado en activos se apoya en elementos como:

• Etiquetas: metadatos del cloud, CMDB o sistemas de inventario
• Roles: función de negocio o agrupaciones de aplicaciones
• Postura: indicadores de riesgo, estado de cumplimiento o información sobre vulnerabilidades

Esto permite que los equipos de seguridad definan políticas como:

• "Permitir tráfico de base de datos únicamente desde cargas de trabajo etiquetadas como PCI con postura saludable".
• "Bloquear todo el acceso saliente a internet desde activos críticos marcados con severidad de vulnerabilidad alta".
• "Permitir acceso justo a tiempo para roles de administrador durante ventanas de mantenimiento aprobadas".

A estas políticas no les importa dónde reside el activo. Cloud, on-premise, híbrido. No importa. Lo que importa es la identidad, el propósito y el estado del activo. Así es como empezamos a pasar de una ejecución estática a barreras de protección adaptativas.

Cerrar la brecha: por qué los firewalls necesitan aprender el lenguaje de los activos y los atributos

Seamos claros: no se trata de reemplazar sus firewalls. Se trata de enseñarles un nuevo lenguaje. Uno que se alinee más estrechamente con la lógica de negocio y la intención de seguridad. Hoy, los equipos de seguridad de red suelen tener la tarea de traducir solicitudes como: "Permitir que la nueva aplicación de analítica se conecte a las bases de datos de producción". En algo como: "Permitir tráfico desde 10.42.0.0/16 hacia 172.19.8.0/24 en el puerto TCP 5432". Esa traducción es propensa a errores, lenta y está completamente desconectada de la intención de negocio original. Y peor aún, cuando la aplicación de analítica se traslada a una subred distinta, o se activa una nueva región, la política se rompe o, peor todavía, permanece abierta y genera exposición. Las políticas basadas en activos eliminan esa brecha de traducción. Describen el acceso en términos de negocio, y los sistemas de ejecución los resuelven de forma dinámica según el estado y el inventario de activos en tiempo real. Es como darles a sus firewalls un anillo decodificador para la infraestructura moderna.

De cuellos de botella en las políticas a habilitadores del negocio

Cuando las políticas de red se vuelven dinámicas y conscientes de los activos, ocurre algo profundo. La seguridad deja de ser un cuello de botella y comienza a ser un habilitador del negocio.

• La agilidad aumenta, ya que los desarrolladores no quedan bloqueados esperando cambios manuales en las reglas del firewall.
• El riesgo disminuye, ya que se minimiza el acceso permanente; las políticas se adaptan a medida que cambia la postura de los activos.
• El cumplimiento mejora, ya que los controles se alinean directamente con los sistemas y los datos que deben proteger.

Lo más importante: la seguridad puede moverse a la velocidad del negocio. No dos trimestres por detrás.

La perspectiva de FireMon: políticas que piensan en términos de negocio

En FireMon hemos dedicado dos décadas a ayudar a las organizaciones a poner orden en el caos de las políticas de seguridad. Y algo ha quedado claro: si quiere que Zero Trust funcione en el mundo real, sus políticas no pueden basarse en infraestructura fija, tienen que reflejar un contexto dinámico. Eso significa:

• Gestionar el acceso en torno a los activos, no a las direcciones
• Definir las políticas con lógica de negocio, no con subredes
• Aplicar controles según el riesgo y la postura, no según supuestos estáticos

Al adoptar esta mentalidad, los equipos de seguridad pueden obtener control real, no restringiendo las cosas con más rigidez, sino tomando decisiones de confianza más inteligentes.

Es momento de abandonar las reglas estáticas

Las reglas estáticas tenían sentido cuando la infraestructura era estática. Pero ese mundo ya no existe. Hoy, la seguridad debe reflejar el movimiento constante de usuarios, cargas de trabajo, amenazas y riesgos. Y eso significa que las políticas deben evolucionar de rígidas y reactivas a dinámicas y descriptivas. La seguridad basada en activos no es una palabra de moda, es el puente entre cómo pensamos la seguridad y cómo la operacionalizamos. Así que si su iniciativa de Zero Trust se siente estancada, pregúntese: ¿está aplicando políticas basadas en lo que el activo era o en lo que es en este momento? La respuesta puede ser la clave para desbloquearse. ¿Quiere modernizarse sin reemplazar su infraestructura? Permita que FireMon le muestre cómo una política dinámica y consciente de los activos puede liberar una verdadera agilidad de Zero Trust. Agende un demo hoy mismo.