Puesta en práctica de Zero Trust – Paso 4: Prescribir qué datos se necesitan

Este serial de blogs amplía las ideas introducidas en mi publicación de marzo, "Zero Trust no es difícil... Si eres pragmático".

En esa publicación, describí seis pasos para lograr Zero Trust, y aquí me gustaría ampliar uno de esos pasos, a saber, prescribir qué datos se necesitan. Le mostraré cómo este paso puede respaldar la implementación de un marco estable que puede ser empleado por cualquier profesional de la seguridad para hacer que sus proyectos sean más exitosos, independientemente del tamaño de la organización.

Antes de comenzar, aquí hay un repaso de los seis pasos:

Paso 4: Prescriba qué datos se necesitan

En la última publicación de este serial, analicé "Determinar en qué pilar de Zero Trust enfocar" y "Especificar el control exacto". La evaluación de esos pasos dio como resultado las siguientes entradas para ayudarlo a avanzar en la puesta en marcha de Zero Trust:

• Determine en qué pilar de Confianza cero centrar: Seguridad y visibilidad de la carga de trabajo porque la evaluación de madurez de Zero Trust que realizó identificó estos como los pilares con las brechas más significativas.
• Especifique el control exacto: Dado que la evaluación identificó el acceso excesivo a la red como la brecha de seguridad más importante, el control en el que se centrará es la microsegmentación.

Una vez que se centró exactamente en lo que desea mejorar la protección y los controles que desea aprovechar, puede comenzar a reunir la información necesaria para implementar dichos controles de manera efectiva.

Comencemos con el estado final deseado:

• Desea crear una política de microsegmentación para proteger sus cargas de trabajo.
• Desea que esta política siga los principios de Confianza cero.
• Por lo tanto, las reglas que construya solo deben permitir el acceso dentro y fuera de las cargas de trabajo que sean necesarias para realizar su función empresarial.

Entonces, ¿qué necesitas para esto? Dependiendo de si tiene conocimientos preexistentes sobre los flujos necesarios, o si realmente está comenzando desde cero en un entorno brownfield, que ya estuvo operando durante muchos años, es posible que tenga dos respuestas ligeramente diferentes para esto.

• Si tiene conocimientos preexistentes: Especificar una regla de segmentación basada en IP de origen, IP de destino, puerto, protocolo
• Si se encuentra en un entorno brownfield: Obtenga registros de tráfico para ayudarlo a identificar flujos que pueden ser relevantes

¿Alguna vez pasó muchas horas y días mirando los registros de tráfico de los firewalls tratando de averiguar qué está haciendo una conexión en individua? ¿Y se vio obligado a buscar información o personas que puedan proporcionar un contexto valioso a un flujo para que su propósito pueda entender correctamente? ¿Repetiste esto para la siguiente línea en los registros, y la siguiente, y la siguiente...? Ahora imagina tener que hacer esto para todas las aplicaciones en el ámbito de la segmentación, no es mi idea de diversión. Suena como jugar a "encontrar la aguja en el pajar" repetidamente.

Ahora, imagine un universo alternativo donde todos estos excelentes datos de tráfico de repente proporcionan más que solo las 5 tuplas estándar de información. ¿Qué pasaría si, en cambio, pudiera recopilar el contexto de una conexión de inmediato, sin tener que hacer esta búsqueda, para que pueda comprender el contexto del evento de tráfico con solo mirarlo? Es como pasar de una película en blanco y negro sin audio a algo en 4K con sonido Dolby Atmos.

Para poner esto en contexto, usemos un ejemplo.

Registro de tráfico habitual:

• Fuente: 10.0.0.1
• Destino: 192.168.0.1
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Registro de tráfico con contexto:

• Fuente: 10.0.0.1
• Contexto de origen: Servidor sitio web, aplicación de pagos, producción, Reino Unido
• Destino: 192.168.0.1
• Destino: Contexto: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido
• Proceso de destino: denominado
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Como propietario de la aplicación o miembro del equipo de operaciones de seguridad , una versión del evento es claramente superior. La versión con contexto proporciona una imagen completa del flujo: puede ver que el servidor sitio web de pagos de producción tiene una dependencia del respondedor DNS de producción, que tiene el proceso con nombre que recibe conexiones en 53/udp. Como revisor, puede decidir rápidamente si es un flujo que le interesa, si es tráfico normal o si merece una mayor investigación. Puede clasificarlo fácilmente (o incluso crear algunas herramientas para clasificarlo automáticamente), y solo puede hacerlo debido al contexto adicional que tiene.

Uno de los aspectos más importantes de Zero Trust, y no recibe tanta cobertura como debería, es que la implementación efectiva de Zero Trust se basa en el acceso a información de contexto, o metadatos, para ayudar a formular políticas. Por lo tanto, cuando se habla de microsegmentación en el contexto de la protección de cargas de trabajo, los metadatos mínimos fuera de un reporte de tráfico estándar que necesita describen las cargas de trabajo en el contexto de las aplicaciones y entornos de su centro de datos.

Illumio Core emplea estos metadatos recopilados de la CMDB de una organización u otra fuente dorada (o autorizada) para completar las etiquetas asociadas con una carga de trabajo. Estas etiquetas asocian un rol, una aplicación, un entorno y una ubicación con cada carga de trabajo y nos ayudan a crear un mapa de dependencias de aplicaciones enriquecido que identifica claramente las dependencias ascendentes y descendentes de cada aplicación. Y esto nos coloca en una excelente posición para revisar los flujos y diseñar políticas.

En mi próxima publicación, discutiré cómo diseñar una política de Confianza cero.

¿Listo para dar el siguiente paso en su viaje hacia Zero Trust? Visita nuestra página sobre cómo poner en práctica su estrategia de Zero Trust con microsegmentación.