En esta segunda parte de la serie “Análisis de PCI DSS v4.0” se realizará una revisión a los requerimientos 1 y 2 del estándar, que hacen parte del grupo “Build and Maintain a Secure Network and Systems”, orientados al control del tráfico de red entrante y saliente del entorno y a la configuración segura de los componentes del sistema o hardening.

Como se indicaba en la primera parte de esta serie de artículos, es importante anotar que estos requerimientos se han renombrado en la versión 4.0 del estándar para adaptarse a los cambios tecnológicos en los controles de seguridad y para ampliar el alcance de su aplicabilidad.

Cambios en los nombres de los requerimientos 1 y 2 de PCI DSS

Requirimiento 1: Install and Maintain Network Security Controls

La masificación del uso de tecnologías de virtualización (incluyendo redes definidas por software – Software Defined Networks o SDN) y de contenedores, así como de infraestructuras de red provistas por proveedores de servicios en la nube (Cloud) han impactado notablemente en el primer requerimiento de PCI DSS. De hecho, dicho cambio se puede notar en el renombramiento del requerimiento y la remoción del término “firewall”, que ha estado presente desde la primera versión del estándar.

Sin embargo, estos cambios no fueron ninguna sorpresa, ya que el PCI SSC ya había adelantado algunos de ellos en el documento Information Supplement – Cloud Computing Guidelines, publicado en abril de 2018, en donde se analizaban una serie de consideraciones técnicas de seguridad en la implementación de entornos multiusuario en la nube (multi-tenant cloud environment) y arquitecturas emergentes como el Internet de las Cosas (Internet of Things – IoT) o Fog Computing, y tecnologías como Software Defined Networking (SND), contenedores y Virtual Desktop Infrastructure (VDI). Todos estos cambios tecnológicos vienen acompañados de nuevas amenazas y nuevos riesgos que no se estaban gestionando de forma correcta o que no terminaban de adaptarse a los criterios establecidos en la versión 3.2.1 de PCI DSS.

Es por ello por lo que en la versión 4.0 de PCI DSS se ha prescindido del concepto tradicional de “firewall” para remplazarlo por el de Network Security Controls (NSCs), concepto mucho más amplio que abarca no solo a los firewalls anteriormente nombrados, sino también a cualquier otra tecnología de red que permiten controlar el tráfico de red entre dos o más segmentos de red lógicos o físicos basados en reglas o políticas predefinidas.

Diferencia entre el concepto de «Firewall» y «Network Security Control»

En términos generales, este requerimiento conserva la misma organización de controles vista en PCI DSS v3.2.1 pero se han agregado o cambiado algunos de ellos para adaptarlos al concepto de NSCs. Algunos de los cambios más representativos son:

• Se requieren estándares de configuración para las reglas de filtrado de los NSCs (1.2.1)
• Los cambios en las conexiones de red y configuraciones de NSCs (1.2.2) deben ser implementados siguiendo la metodología de gestión de cambios de PCI DSS, especificada en el requerimiento 6.
• En el caso de los diagramas de red (1.2.3), se han agregado buenas prácticas entre las que se encuentran el etiquetado de los segmentos de red, la identificación de los controles de seguridad que proveen segmentación y sus detalles (nombre del control, modelo, versión, etc.), inclusión de todos los componentes en el alcance, etiquetado de áreas fuera del alcance e información de cambios del documento (fecha de la última actualización, responsable del cambio, aprobador del cambio y una leyenda explicativa del diagrama).
• En el caso de los diagramas de flujo (1.2.4), se indica que este diagrama complementa al diagrama de red y se recomienda incluir todos los procesos (autorización, captura, liquidación, devoluciones, reembolsos, etc.) y los flujos de datos de tarjetas, incluyendo aquellos que involucran medios físicos.
• Solo se permitirán servicios, protocolos y puertos identificados, aprobados y con una necesidad de negocio definida (1.2.5), incluyendo controles adicionales para puertos considerados como inseguros (1.2.6).
• Se debe efectuar una revisión semestral de la configuración de los NSC para confirmar que son relevantes y efectivos (1.2.7).
• Si el NSCs usa ficheros de configuración, estos deben ser protegidos contra acceso no autorizado y consistentes con la configuración de red activa (1.2.8).

Igualmente, la terminología de los segmentos de red a ser protegidos se ha aclarado, alineándola con los criterios descritos en el documento Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation. En ese sentido, la intención es que despliegue un control de seguridad de red (Network Security Control – NSC) entre entornos con diferentes niveles de confianza (incluyendo redes internas). Bajo esta óptica, se identifican dos bloques de redes principales:

• Redes confiables (trusted networks): Cualquier red que está bajo el control o gestión de la entidad y que cumple con los requisitos aplicables de PCI DSS. En esta categoría se incluyen el CDE y los sistemas conectados o que pueden impactar la seguridad del CDE.
• Redes no confiables (untrusted networks): Cualquier red fuera del control de la entidad, entre las que se encuentran Internet, canales de comunicación dedicados, redes inalámbricas, redes de proveedores de servicio de internet (ISP), incluyendo redes móviles y redes de terceros. También se aclara que, si una red está fuera del alcance de PCI DSS, dicha red debe ser considerada como una red no confiable.

Siendo así, las reglas de filtrado de tráfico que deben ser implementadas por los NSCs deben seguir los siguientes criterios:

Criterios para seguir en las políticas o reglas de los NSCs

Un tema interesante en esta versión del estándar es que la obligatoriedad de implementar una Red Desmilitarizada (DMZ) como segmento de red para limitar el acceso de tráfico entrante (1.3.1 en PCI DSS 3.2.1) ha desaparecido, aunque ahora se recomienda como una buena práctica. Sin embargo, si se implementa una DMZ y este segmento procesa o transmite datos de tarjetas de pago, debe ser considerado como parte del CDE.

Requirimiento 2: Apply Secure Configurations to All System Components

Al igual que con el requerimiento 1, este requerimiento fue renombrado para flexibilizar la aplicabilidad de los controles de configuración segura, haciendo énfasis en que no solo se tienen que cambiar los valores por defecto, sino que también se tiene que eliminar el software, las funciones y las cuentas innecesarias, y desactivar o eliminar los servicios innecesarios. También, se hace énfasis en que este requerimiento aplica no solo a sistemas “tradicionales” sino a cualquier otro sistema accedido a través de un servicio de suscripción en la nube (cloud).

Dentro de los cambios aplicados este requerimiento cabe destacar los siguientes:

• Se requiere el desarrollo de estándares de configuración segura para todos los componentes del sistema (2.2.1), incluyendo sistemas en la nube (cloud). De esta forma, como referencia, también se agrega al Cloud Security Alliance (CSA).
• Se permite el uso de cuentas por defecto de fabricantes (vendors), siempre y cuando se cambie su contraseña por defecto (2.2.2). De lo contrario, estas cuentas deben ser removidas o eliminadas. Esto es un cambio importante respecto a PCI DSS v3.2.1, ya que en esa versión del estándar simplemente estas cuentas por defecto debían ser eliminadas o removidas y cualquier excepción debía ser gestionada a través de controles compensatorios.
• Se aclara la aplicabilidad del concepto de “función primaria” (2.2.3), permitiendo la coexistencia de diferentes funciones principales con diferentes niveles de seguridad en un mismo sistema mientras que sean aisladas entre sí o mientras que todas sean aseguradas al mismo nivel de la que tenga mayor nivel de seguridad. Este concepto ya había sido analizado anteriormente en el documento Information Supplement – PCI DSS Virtualization Guidelines de junio de 2011, enfocado en tecnologías de virtualización, pero en la versión 4.0 de PCI DSS ya se ha incluido de forma explícita.
• Solamente se deben permitir servicios, protocolos, daemons y otras funciones que sean necesarios, removiendo o deshabilitando todos los demás (2.2.4), justificando y añadiendo controles adicionales a aquellos que sean considerados inseguros (2.2.5).
• Solamente se permitirá el acceso administrativo que no sea por consola (non-console) mientras que sea cifrado mediante criptografía robusta. Esto incluye no solo a interfaces administrativas tradicionales (basadas en browser) sino también a accesos a través de interfaces de programación de aplicaciones (Application Programming Interfaces – APIs).
• Se agregan controles adicionales en el proceso de configuración segura de entornos inalámbricos (2.3.1), incluyendo el cambio de claves de cifrado de redes inalámbricas que transmitan datos de tarjetas o conectados al CDE si cualquier personal con conocimiento de las mismas deja la empresa o si la clave es comprometida o se sospecha de ello.

Finalmente, el control del inventario de componentes (2.4 en PCI DSS v3.2.1) se ha movido al requerimiento 12, una ubicación más congruente con su objetivo.

En el siguiente artículo se analizarán los requerimientos 3 y 4 de PCI DSS, orientados a la seguridad de datos de tarjetas durante su almacenamiento y su transmisión.

Referencias

• • Information Supplement – Cloud Computing Guidelines https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf
  • Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
  • Information Supplement – PCI DSS Virtualization Guidelines https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf