El objetivo del requerimiento 1 de PCI DSS (“Instale y mantenga una configuración de firewall para proteger los datos del titular de la tarjeta”) es el de garantizar la existencia de controles de acceso a nivel de red entre los diferentes componentes del entorno de cumplimiento y redes no confiables. Estos controles se deben desplegar siguiendo el concepto de defensa en profundidad (“defense in depth”), necesidad de saber (“need to know”) y menor privilegio (“least privilege”), permitiendo que solamente aquellos servicios, puertos y protocolos de red estrictamente necesarios sean accedidos a nivel de tráfico entrante y saliente y bloqueando todo el otro tráfico.

El modelo de defensa en profundidad y su comparación con el plano de una ciudad amurallada (Fuente: ISACA JOnline)

De acuerdo con ello, el principal componente de esta estrategia de control es la figura de un cortafuegos (“firewall”). Un cortafuegos es una tecnología que permite el filtrado de tráfico entre dos redes o entre un equipo y una red, aceptándolo o denegándolo en función de una serie de reglas definidas. No obstante, si esas reglas de filtrado no se revisan de forma periódica y se actualizar conforme con los cambios del entorno, entonces el nivel de protección perimetral puede verse afectado.

¿Qué es una regla de filtrado?

Una regla de filtrado por defición cuenta con 5 partes principales (5-tupla):

  • Dirección IP origen.
  • Puerto y protocolo origen.
  • Dirección IP destino.
  • Puerto y protocolo destino.
  • Acción (“Aceptar” o “Denegar”).

Dependiendo de la solución de filtrado implementada, se pueden encontrar otros campos adicionales:

  • Identificador de regla.
  • Nombre de la regla.
  • Contador de paquetes que han coincidido con esta regla, con el fin de validar si existe tráfico que está siendo controlado.
  • Registro (log) de la acción.
  • Calendario de aplicación de la regla, para definir periodos en los cuales el filtro estará activo. Ejemplo: solamente entre semana, solamente los fines de semana, en las noches, etc.
  • Interacción del tráfico que coincide con la regla con módulos adicionales de antimalware, filtrado de URL, DLP, VPN, etc.

¿En qué consiste la revisión semestral de reglas de filtrado?

Para verificar que las reglas de filtrado implementadas en el firewall (“rule sets”) son congruentes con el entorno que están protegiendo, el requisito 1.1.7 de PCI DSS exige la realización de una revisión de estas reglas por lo menos de forma semestral (revisión periódica). Es importante tener presente que cualquier dispositivo que permita implementar estas reglas  y que soporte inspección de estados (“stateful inspection”) es susceptible de esta revisión al margen del uso de IPv4 o IPv6:

  • Enrutadores con listas de control de acceso (“Access Control List” – ACL) extendidas.
  • Conmutadores (“switches”) de capa 3 (administrables) que permitan la implementación de ACLs.
  • Cortafuegos tradicionales (soluciones en appliances, software independiente o en módulos/aplicaciones de sistemas operativos).
  • Tecnologías de filtrado de paquetes de plataformas en cloud:
    • Security Groups en AWS,
    • Network Security Groups en Microsoft Azure,
    • Firewall rules en Google Cloud Platform (GCP).

Adicionalmente, se recomienda extender estas pruebas a otras plataformas o tecnologías que implementen otros tipos de filtrado de paquetes (ACL tradicionales, Network ACL en AWS, soluciones de cortafuegos personales (“personal firewalls”), etc.)

Por otro lado, es indispensable que esta revisión la ejecute una persona o área diferente a la que administra, opera y/o configura la solución de filtrado de paquetes para evitar problemas de conflicto de interés. De hecho, esta tarea deberá estar asignada explícitamente en la definición de roles y responsabilidades en la administración de componentes de red del requisito 1.1.5 de PCI DSS.

A continuación se enumeran las tareas a ejecutar en esta revisión:

Prerrequisitos

Antes de proceder con la revisión de reglas de filtrado, se debe validar lo siguiente:

  • El diagrama de red (req. 1.1.2) y el diagrama de flujo del entorno (req. 1.1.3) deben estar actualizados.
  • Identificar los rangos de direccionamiento IP existentes dentro del entorno.
  • Identificar los controles de segmentación implementados en el entorno.
  • El inventario de activos de la organización debe estar actualizado (req. 2.4).
  • El inventario de servicios, protocolos y puertos y sus justificaciones se encuentra actualizado (req. 1.1.6).
  • Identificar el ámbito de cumplimiento (“scope”) de PCI DSS.
  • Si se han realizado revisiones de reglas de filtrado anteriormente, se debe tener disponibles dichos informes y resultados para validar si los hallazgos identificados en dichos informes han sido gestionados o no.
  • Se debe contar con acceso a las plataformas de filtrado o – en su defecto – tener disponible una copia de las reglas de firewall (exportación).
  • Identificar en la topología de las interfaces del firewall cuáles están conectadas a redes internas (“trust”), cuáles están conectadas a redes no confiables (“untrust”) y cuáles a la DMZ.

Fuente: https://iproot.wordpress.com

Acciones a realizar

A continuación se enumeran algunas acciones generales a realizar durante la verificación de las reglas de filtrado:

  • Validar que las configuraciones de inspección completa (“stateful inspection” – req. 1.3.5) y anti-suplantación (“antispoofing” – req. 1.3.3) se encuentre siempre activadas.
  • Validar que la regla o reglas de filtrado implementadas permiten únicamente servicios, protocolos y puertos dentro de la lista documentada y justificada en el Req.1.1.5.
  • Validar que la regla o reglas implementadas tienen limitado su campo de acción a hosts y/o rangos específicos de direcciones IP. Si la regla cubre una red completa (ANY) o un grupo amplio de direcciones, revisar con el solicitante la necesidad y justificarla.
  • Validar que la regla o reglas implementadas tienen limitado su campo de acción a puertos, protocolos y servicios exclusivos. No deben existir reglas que permitan tráfico a todos los puertos, protocolos y/o servicios (ANY).
  • Validar que no se permite el tráfico a puertos inseguros.
  • Validar que el tráfico saliente solamente está autorizado a los rangos de direcciones IP del entorno.
  • Validar que no existen reglas de filtrado asociadas a servidores o aplicaciones que han sido retirados del entorno de Producción.
  • Validar que el tráfico entrante proveniente de internet no permite el acceso a los bloques de redes privadas (RFC 1918) para prevenir suplantación (“spoofing”). Se debería bloquear explícitamente cualquier tráfico desde internet con origen desde estos rangos:
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • Validar que las reglas están configuradas para registrar eventos (log).
  • Validar que la regla no entra en conflicto con reglas anteriores (esto debido a que el procesamiento de reglas de filtrado es de arriba a abajo y se aplica la de primera aparición).
  • Validar que la regla se encuentre documentada (comentarios). Idealmente, cada regla debería tener registrado el número de cambio o ticket de servicio con la que se dió de alta o se cambió, para poder realizar trazabilidad en caso de ser necesario.
  • Validar que al final del paquete de reglas existe una regla explícita que deniegue todo el tráfico restante. Esta regla recibe el nombre de “regla de limpieza” (“clean-up rule”).

Por otro lado, se debe hacer una revisión de las restricciones de tráfico inter-redes que requiere PCI DSS:

  • Validar la existencia de una zona de DMZ (1.3.1).
  • Validar la existencia de una zona interna en donde se ubican los sistemas que almacenan datos de tarjetas (req. 1.3.6).
  • Validar la existencia de reglas para aislar el entorno de redes inalámbricas (req. 1.2.3).

Estas revisiones deben ser implementadas tanto en las reglas explícitas (aquellas que el administrador puede configurar) como en las reglas implícitas (aquellas que el propio sistema de filtrado genera automáticamente y no son visualizadas por defecto).

Herramientas

La ejecución de estas tareas de revisión se pueden ejecutar de forma manual o se pueden complementar con el uso de herramientas automáticas, como por ejemplo:

Soluciones comerciales:

Freeware:

Open Source:

Herramientas online (estas herramientas permiten ejecutar escaneos de puertos contra recursos publicados en redes públicas abiertas únicamente):

Resultados e informes

Al finalizar esta labor, se debería contar con la siguiente evidencia, con el objetivo de confirmar la ejecución de esta tarea periódica de PCI DSS:

  • Informe de hallazgos de la revisión.
  • Informe de recomendaciones de mejora de las reglas de filtrado.
  • Evidencia de las acciones correctivas realizadas con base en los hallazgos reportados (tickets de soporte, formularios de gestión de cambios, etc.)

A continuación se puede descargar una hoja de cálculo de MS Excel que puede servir como lista de verificación (“checklist”) para la ejecución de esta tarea:

Revisión semestral de reglas de filtrado

Como soporte a estas acciones, se recomienda consultar los siguientes documentos:

Si hay alguna duda, el foro y los comentarios están disponibles.