No todas las empresas cuentan con la misma operativa, ni con la misma tecnología o personal y mucho menos con las mismas necesidades de negocio, con lo cual tratar de generalizar y definir una “red ideal” es muy complicado. En función de los flujos de datos, requerimientos legales y contractuales, interconexiones entre sistemas y redes, conocimiento del personal administrativo y operativo,  tecnologías implementadas, servicios ofrecidos o recibidos, outsourcing, servicios de Cloud Computing, virtualización, etc. cada organización debe definir (con el apoyo de un QSA) su “red ideal” que cumpla con los requisitos de PCI DSS.

No obstante, lo que se describirá a continuación es simplemente un ejemplo “ideal” en el cual se presentará una red en la cual se aplican todos los controles requeridos por el estándar y que cuenta con una topología que permite un flujo seguro de datos de tarjetas entre los diferentes activos conectados, la cual puede dar una visión inicial acerca de cómo y dónde se tienen que ubicar los diferentes componentes y los filtrados que se deben aplicar entre los diferentes segmentos.  Hay que recordar que en este caso es importante tener presente que la segmentación de red a nivel interno es una recomendación y no un requisito (ver artículo “El PCI SSC publica una guía para la determinación del alcance y segmentación de red para PCI DSS“).

Definición de controles y ubicaciones lógicas

Durante el proceso de definición de la topología de red, ubicación de activos, zonas de seguridad y despliegue de cualquier solución de filtrado de paquetes en el entorno de red PCI DSS se deben tener en cuenta como mínimo los siguientes criterios:

  • Se debe realizar un análisis detallado de los flujos de datos de tarjetas de pago en la red (entradas, salidas y procesamiento/almacenamiento) y se deben identificar los activos involucrados y sus funciones dentro del alcance. El uso de una CardHolder Data Matrix (req. 2.4), los diagramas de red (req. 1.1.2) y los diagramas de flujos (req. 1.1.3) facilitarán bastante este proceso.
  • Se deben identificar como mínimo dos zonas de seguridad: una zona “confiable” o “trust” (la red que se encuentra dentro del alcance de certificación PCI DSS y que contiene activos que transmiten, procesan y/o almacenan datos de tarjetas y activos que soportan dicha operativa) y una zona “no confiable” o “untrust” (cualquier red externa al entorno PCI DSS y/o que se encuentre fuera del alcance de gestión o control de la organización).
  • Se debe restringir el tráfico entrante y saliente de estas zonas al mínimo imprescindible.
  • Se debe prohibir cualquier acceso público entre Internet y la red de PCI DSS. En caso que dicho acceso sea necesario, se debe definir un segmento independiente y aislado denominado “zona desmilitarizada” (DMZ).
  • Es obligatorio instalar una solución de filtrado de paquetes entre la red del ámbito PCI DSS y cualquier red inalámbrica existente.
  • Se puede definir de forma opcional una red de gestión. En esta red de gestión se deben ubicar aquellos equipos cuya función será la administración de activos (consolas) y soporte de operativas dentro del entorno PCI DSS. Si se requiere administración remota, el acceso debe tener como destino este segmento posterior a una autenticación de dos factores (req. 8.3)
  • Siempre se debe activar la funcionalidad de inspección completa de paquetes (“Stateful Inspection”) en el firewall (req. 1.3.5)
  • Tener presente que el firewall se convierte en un único punto de fallo en la red, con lo cual se recomienda la implementación de controles de alta disponibilidad (HA) y balanceo de carga (LB). Ver el artículo “PCI DSS y Disponibilidad“.

Diagrama de red

Con base en los requerimientos de PCI DSS, el diagrama de referencia de una red “ideal” sería el siguiente:

De acuerdo con la descripción anterior, se deberá  contar con los siguientes segmentos de red aislados entre sí por un equipo de filtrado de paquetes que soporte inspección completa (“stateful inspection”):

Conexión con redes publicas abiertas

Esta zona es el área límite del entorno de tarjetas de pago (Cardholder Data Environment) y en donde se pueden ubicar los equipos de seguridad perimetral, enrutamiento y conexión con terceros.

  • Contempla la conexión con los canales de ISP y/o  conexiones con terceros. Cuando estos canales sean públicos (Internet, redes inalámbricas, GSM, GPRS) deben estar cifrados (HTTPS, VPN IPSEC, VPN SSL, SSH, etc.) cuando se transmitan datos de tarjetas de pago (Req. 4.1)
  • Contempla los equipos de enrutamiento perimetral gestionados por la empresa.
  • Contempla los equipos de balanceo de carga frontales (en caso que se implemente esta funcionalidad)
  • Contempla el equipo de filtrado (Firewall) Stateful Inspection, que separa las diferentes zonas y enruta el tráfico.
  • Puede contemplar el sistema VPN para gestión de conexiones remotas que puede estar o no integrado en el Firewall.
  • Puede contemplar el sistema de IDS/IPS que puede estar o no está integrado en el Firewall.
  • Puede contemplar el sistema de WAF (Web Application Firewall) que puede estar o no integrado en el firewall.

Es importante hacer una aclaración en este punto: Muchas soluciones de filtrado de paquetes suelen venir acompañadas por uno o varios módulos de seguridad adicionales (VPN IPSEC, VPN SSL, Filtrado de URL, AntiSpam, IDS, IPS, WAF, etc.) lo que se conoce como Unified Threat Management (UTM). Este tipo de configuraciones debe ser analizado por un QSA para garantizar el cumplimiento del req. 2.2.1.

DMZ PCI DSS

En esta zona se pueden ubicar aquellos equipos que por consideraciones operativas requieren tráfico de entrada y salida con redes externas (req. 1.3.1).  El tráfico tiene que ser  restringido al estrictamente necesario.

  • Compuesta por los servidores web o cualquier otro servidor/servicio que reciba/envíe datos de tarjetas de pago a redes públicas abiertas o redes externas.
  • Servidores de salto (“jump servers”) o servidores bastión. Se trata de servidores que permitirán la recepción de tráfico administrativo desde redes públicas abiertas empleando SSH, servicios de terminal (Terminal Services), etc. Cualquier conexión a estos servicios requiere de autenticación multifactor (req. 8.3).
  • Servidor de NTP para sincronización con servidores NTP externos (req. 10.4.3). Los demás servidores del entorno se deben sincronizar con este servidor (req. 10.4.1).
  • Servidor de DNS. Al igual que con el servicio de NTP, todos los demás servidores del entorno deben usar este servidor de DNS para enviarle sus consultas de resolución de nombres.
  • Servidores de descarga de actualizaciones de seguridad y actualizaciones de firmas de antivirus/IDS/IPS.
  • De forma opcional, en esta red se puede ubicar un servidor proxy, el cual puede actuar como intermediario entre cualquier equipo del entorno que por razones justificadas necesite acceso de salida a Internet (req. 1.3.7).

En este segmento se deben aplicar controles de limitación de tráfico de entrada desde internet (req. 1.3.2), implementación de controles de suplantación (anti-spoofing) y protección del direccionamiento interno (req. 1.3.7).

Red Interna PCI DSS

Esta zona es la más crítica del entorno de tarjetas de pago (CardHolder Data Matrix) según el requerimiento 1.3.6  y se deben ubicar:

  • Componentes que almacenen datos de tarjetas de pago (por ejemplo servidores de base de datos)
  • Repositorios de claves de cifrado (HSM)

Este segmento no debe tener tráfico directo entrante o saliente con redes públicas abiertas (req. 1.3 y 1.3.4).

En el caso del HSM, internamente se podría pensar en microsegmentación para aislar aún más este equipo, dada su criticidad.

Red de Gestión PCI DSS

En esta zona se pueden ubicar:

  • Todas las consolas de gestión de los servicios de seguridad asociados al entorno: Antivirus, Firewall, IDS/IPS, FIM, WAF, VPN, etc.
  • Servidor centralizado de logs (SYSLOG).
  • Software de análisis de vulnerabilidades interno.
  • Consola de backup/restauración.
  • Servidor controlador de dominio/LDAP/RADIUS/TACACS (servicios de autenticación).

Entre otros.

Cualquier conexión administrativa debe dirigirse a esta zona.  Si el acceso a esta zona se realiza desde una red externa, se requiere que una autenticación de dos factores (req. 8.3)  y uso de firewall personal en el equipo remoto que se conecta (Req. 1.4).

Red Inalámbrica

En el caso que en la organización existan componentes inalámbricos que interactúen con el entorno de tarjetas de pago, se deben implementar los requerimientos 1.2.3, 2.1.1 y 4.1.1.

A continuación  y a manera de referencia se describen las políticas generales de implementación de filtrado de tráfico que aplicaría entre cada una de estas redes (Req. 1.2 y 1.2.1). Los puertos autorizados deben estar registrados conforme con lo descrito en el Req. 1.1.6. Cualquier otro tráfico debe ser denegado (Req. 1.2.1.c):

Con base en este trabajo, se puede perfilar de una forma bastante fácil el listado de protocolos, puertos y servicios del entorno de cumplimiento (req. 1.1.6), la ubicación de cada activo en función de su operación y definir las reglas de filtrado asociadas dependiendo del direccionamiento y hosts en cada segmento. Adicionalmente, de forma semestral se requiere una revisión de las reglas de filtrado (req. 1.1.7) para garantizar que el nivel de seguridad provisto no se ha degradado con el tiempo.

Sobra decir que esto es un ejemplo de referencia y que dependiendo de la estructura y topología de su red estos conceptos pueden variar.

Conclusión

Un buen ejercicio previo a la definición final de la topología de red del entorno de cumplimiento PCI DSS de la organización se puede basar en el trabajo con una “red ideal”, en donde se cumplen con todos los requerimientos, como si de una plantilla se tratase. Partiendo de esta referencia, se pueden empezar a identificar flujos y necesidades propias de la organización y planificar filtros y ubicaciones lógicas para que se siga cumpliendo con los controles del estándar.