Una de las principales ventajas de la migración a un modelo basado en la nube (“cloud”) es el de la delegación de responsabilidades de gestión de infraestructura de TI en un proveedor especializado. Dependiendo de las necesidades de la organización, esta delegación se puede enmarcar en cualquiera de los tres modelos principales: IaaS (“Infrastructure as a Service”), PaaS (“Platform as a Service”) o SaaS (“Software as a Service”).

No obstante, el hecho de delegar la totalidad o parte de la gestión de TI en un proveedor de servicios en la nube implica que la organización pierde cierto control y autonomía sobre esos servicios y queda supeditada a las restricciones que le sean impuestas en términos de infraestructura, tecnología, topología o integración.  Este problema suele salir a flote cuando se requiere asumir el cumplimiento de estándares o de controles específicos en los que el proveedor puede tener limitaciones que impactarán ese proceso de despliegue y alineación.

En este articulo se analizará uno de esos casos excepcionales en los que una organización que ha desplegado su entorno PCI DSS empleando la infraestructura de un proveedor en la nube bajo un modelo IaaS requiere demostrar el cumplimiento del requerimiento 11.4 del estándar, relacionado con el uso de sistemas de detección y/o prevención de intrusiones a nivel de red para monitorizar el perímetro y los puntos críticos en el entorno de datos de tarjetas de pago.

El problema: pérdida de control sobre la visibilidad de los incidentes a nivel de red

Para introducir este escenario, primero se debe analizar en detalle lo que se exige en el requerimiento 11.4 de PCI DSS:

Use técnicas de detección de intrusiones y/o prevención de intrusiones para detectar y/o prevenir intrusiones en la red. Monitorice todo el tráfico en el perímetro y los puntos críticos del entorno de datos de tarjetas de pago (CDE) y alerte al personal ante la sospecha de compromisos.

Como se puede observar, se hace referencia explícita a la implementación de una solución de detección y/o prevención de intrusiones a nivel de red. No obstante, en un modelo IaaS la gestión de la red se encuentra enteramente del lado del proveedor de servicios:

En cierta forma, se podría pensar que como la infraestructura de red (tanto física como virtual) se encuentra bajo la responsabilidad del proveedor de servicios en la nube, entonces las soluciones de IDS/IPS y la monitorización de incidentes a nivel de red también estarán bajo su responsabilidad. Pero, si se revisan las matrices de responsabilidad de estos proveedores, la cosa cambia:

Amazon Web Services (descargado a través de AWS Artifact):

Microsoft Azure (descargado desde Microsoft Trust Center):

Google Cloud Platform (descargado desde GCP):

Todo esto lleva a la siguiente conclusión: El proveedor de servicios en la nube se hace responsable de la monitorización de intrusiones en su infraestructura, pero el cliente también debe incorporar otras soluciones para cubrir con la parte del entorno bajo su cargo. Es decir: la responsabilidad del control 11.4 relacionado con IDS/IPS es MIXTA por más que la responsabilidad de la infraestructura de red sea exclusiva del proveedor.

Análisis de despliegue de soluciones de IDS/IPS a nivel de red

Para que un sistema de IDS/IPS de red (Network IDS/IPS) sea funcional se requiere:

  1. Centralizar todo el tráfico a ser analizado, o
  2. Tener acceso a la totalidad del tráfico a nivel de red empleando un un puerto “mirror”, un TAP de red (“Network Tap”) o una interfaz de red configurada en modo “promiscuo“.

La opción 1 (centralizar todo el tráfico a ser analizado) se puede lograr configurando que todas las instancias virtualizadas del entorno envíen su tráfico a un punto en común, el cual realizará una inspección del tráfico en búsqueda de patrones maliciosos. Sin embargo, este escenario requiere del despliegue de un nuevo equipo en el entorno y de cambios radicales a nivel de enrutamiento en la zona de red. Algunos ejemplos se pueden encontrar en los “marketplaces” de cada uno de los proveedores con soluciones como PaloAlto, Alertlogic, Checkpoint, Cisco, etc.

En el caso de la opción 2 (realizar captura de tráfico), en los tres proveedores anteriores (AWS, Azure y GCP) no está permitido activar una interfaz en modo promiscuo o emplear herramientas para captura de tráfico (“sniffing”) directamente en la red debido a sus propias políticas de seguridad, por lo cual esta opción no puede ser implementada de forma nativa y hay que analizar un control compensatorio.

Análisis de controles compensatorios

Este caso es un ejemplo clásico de un escenario en el que se puede aplicar un control compensatorio. Un “control compensatorio” es un control alternativo que se puede implementar cuando existe una limitación en términos técnicos o administrativos que impidan la correcta implementación del control original que exige el estándar PCI DSS. En este escenario, se encuentra una limitación técnica causada por la imposibilidad de desplegar un sistema de detección y/o prevención de intrusiones en un entorno en la nube (“cloud”) conforme lo requiere PCI DSS, debido a las restricciones del proveedor para la captura de tráfico a nivel de red:

Para perfilar la solución, hay que tener presente que en un modelo IaaS el cliente tiene el control absoluto sobre el sistema operativo y las instancias virtualizadas (AWS EC2, Azure VM y GCP Compute Engine), de lo cual se desprende que en los sistemas operativos instalados en estos servicios es posible tener acceso a todo el tráfico destinado a cada interfaz de red conectada. Siendo así, se puede instalar un sistema de detección y/o prevención de intrusiones basado en host (host IDS/IPS) como un control compensatorio, en vez de un IDS/IPS de red (network IDS/IPS) como lo especifica el estándar PCI DSS en el requisito 11.4. Esta solución analizará el tráfico entrante y saliente de cada interfaz de red, complementando estas tareas con la monitorización del comportamiento de las aplicaciones y del sistema operativo en búsqueda de patrones maliciosos.

Bajo este modelo, se requiere el despliegue de un agente de detección y/o prevención de intrusiones basado en host (HIDS/HIPS) en cada una de las instancias virtualizadas y una consola que se encargará de la centralización de alertas y despliegue de políticas. Al igual que con los sistemas de IDS/IPS de red, aquí también se requiere mantener actualizados los motores y las firmas de la solución (si aplica).

Para este tipo de despliegues se puede hacer uso de soluciones basadas en software libre (Wazuh, OSSEC y Tripwire incorporan funcionalidades de HIDS/HIPS) o soluciones comerciales (Trend Micro Deep Security, CarbonBlack, Crowdstrike, Cylance, SentinelOne, etc.) casi todas categorizadas como “endpoint protection” (incluyen otras funcionalidades de seguridad adicionales como firewall personal, antimalware, control de aplicaciones, etc.).

Es importante recordar que si se hace uso de una solución de HIDS/HIPS en vez de un NIDS/NIPS en un entorno PCI DSS es indispensable rellenar el “Anexo C: Hoja de trabajo de controles de compensación” ya sea si se presenta un cuestionario de autoevaluación (SAQ) o un reporte de cumplimiento (Report on Compliance).