Operacionalización de Zero Trust: Paso 4: Prescribir qué datos se necesitan

Esta serie de blogs amplía las ideas introducidas en mi publicación de marzo,”La confianza cero no es difícil... Si eres pragmático.”

En ese post, describo 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 apoyar la implementación de un marco sólido que puede ser utilizado por cualquier profesional de seguridad para que sus proyectos sean más exitosos, independientemente del tamaño de la organización.

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

Paso 4: Prescribir qué datos se necesitan

En el ultimo mensaje de esta serie, miré “Determinar en qué pilar Zero Trust centrarme” y “Especificar el control exacto”. La evaluación de esos pasos dio como resultado las siguientes entradas para ayudarle a avanzar en la operacionalización de Zero Trust:

• Determine en qué pilar de Confianza Cero debe centrarse: Seguridad y visibilidad de la carga de trabajo debido a Evaluación de Madurez de Confianza Cero usted 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 enfocará es la microsegmentación.

Una vez que se haya puesto a punto exactamente para qué desea mejorar la protección y qué controles 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 deben permitir únicamente el acceso dentro y fuera de sus cargas de trabajo que se necesitan para realizar su función de negocio.

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 de campo rodado, que ya ha estado 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 de campo desprotegido: Obtenga registros de tráfico para ayudarle a identificar los flujos que pueden ser relevantes

¿Alguna vez ha pasado muchas horas y días mirando los registros de tráfico de los firewalls tratando de averiguar qué está haciendo una conexión en particular? ¿Y se ha visto obligado a buscar información o personas que puedan proporcionar un contexto valioso a un flujo para que su propósito pueda ser entendido adecuadamente? ¿Ha repetido esto para la siguiente línea en los registros, y la siguiente, y la siguiente...? Ahora imagínese tener que hacer esto para todas las aplicaciones en el ámbito de la segmentación, no es mi idea de diversión. Suena como tocar 'encuentra la aguja en el pajar' repetidamente.

Ahora, imagina un universo alternativo donde todos estos grandes 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, pudieras reunir el contexto de una conexión de inmediato, sin tener que hacer esta búsqueda, para que puedas entender 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 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: nombrado
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Como propietario de una aplicación o operaciones de seguridad miembro del equipo, una versión del evento es claramente superior. La versión con contexto proporciona una imagen completa del flujo: puede ver que el Servidor Web de Pagos de Producción tiene una dependencia del Respondedor DNS de Producción, que tiene el proceso nombrado que recibe conexiones en 53/udp. Como revisor, puede decidir rápidamente si se trata de un flujo que le interesa, si se trata de tráfico normal o si justifica una investigación adicional. Puede clasificarlo fácilmente (o incluso construir 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 obtiene tanta cobertura como debería, es que la implementación efectiva de Zero Trust se basa en el acceso a la 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 las cargas de trabajo, los metadatos mínimos fuera de un informe 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.

Núcleo de Illumio utiliza estos metadatos recolectados de la CMDB de una organización u otra fuente dorada (o autorizada) para rellenar 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 una solución rica mapa de dependencia de aplicaciones que identifica claramente las dependencias ascendentes y descendentes para cada aplicación. Y esto nos pone en una gran posición para revisar los flujos y diseñar la política.

En mi próximo post, voy a discutir cómo diseñar una política de confianza cero.

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