1 feb. 2018

Requisitos de PCI DSS v3.2 que entran en vigencia en el 2018

El 30 de abril de 2016 se publicó la versión 3.2 del estándar PCI DSS. Esta versión y sus revisiones posteriores incluían una serie de requisitos identificados temporalmente como “buenas prácticas” y se estipularon unas fechas límite a lo largo del año 2018 para su entrada en vigencia como requisitos obligatorios. Esto implica que a partir del día siguiente a la fecha límite, el requisito deberá contar con evidencia verificable de su ejecución.

A continuación se encuentran identificados todos los controles que se convertirán en obligatorios durante el año 2018:
Fecha de entrada en vigenciaRequisito de PCI DSS v3.2Aplicable a
01 de febrero de 2018 3.5.1. Mantenga una descripción documentada de la arquitectura criptográfica que incluye:
- Detalles de todos los algoritmos, protocolos y claves utilizados para la protección de los datos del titular de la tarjeta, incluidas la complejidad de la clave y la fecha de caducidad
- Descripción del uso de la clave para cada tecla
- Inventario de un HSM SMS y otros SCD utilizados para la gestión de claves
Proveedores de servicios
01 de febrero de 2018 6.4.6. Al término de un cambio significativo, deben implementarse todos los requisitos pertinentes de la PCI DSS en todos los sistemas y redes nuevos o modificados, y la documentación actualizada según sea el caso. Comercios y proveedores de servicios
01 de febrero de 2018 8.3.1. Incorporar la autenticación de múltiples factores para todo acceso que no sea de consola en el CDE para el personal con acceso administrativo. Comercios y proveedores de servicios
01 de febrero de 2018 10.8. Implementar un proceso para la detección oportuna y la presentación de informes de fallas de los sistemas críticos de control de seguridad, incluido pero no limitado a la falla de:
- Firewalls
- IDS/IPS
- FIM
- Antivirus
- Controles de acceso físicos
- Controles de acceso lógico
- Mecanismos de registro de auditoría
- Controles de segmentación (si se utilizan)
Proveedores de servicios
01 de febrero de 2018 10.8.1. Responder a las fallas de los controles de seguridad críticos en el momento oportuno. Los procesos para responder en caso de fallas en el control de seguridad son los siguientes:
- Restaurar las funciones de seguridad
- Identificar y documentar la duración (fecha y hora de inicio a fin) de la falla de seguridad
- Identificar y documentar las causas de la falla, incluida la causa raíz, y documentar la remediación requerida para abordar la causa raíz
- Identificar y abordar cualquier problema de seguridad que surja durante la falla del control de seguridad.
- Realizar una evaluación de riesgos para determinar si se requieren más acciones como resultado de la falla de seguridad
- Implementar controles para prevenir que se vuelva a producir la causa de la falla
- Reanudar la supervisión de los controles de seguridad
Proveedores de servicios
01 de febrero de 2018 11.3.4.1. Si se utiliza la segmentación, confirme el alcance de la PCI DSS al realizar pruebas de penetración en los controles de segmentación al menos cada seis meses, y después de cualquier cambio a los controles/métodos de segmentación. Proveedores de servicios
01 de febrero de 2018 12.4.1. La gerencia ejecutiva deberá establecer la responsabilidad de la protección de los datos del titular de la tarjeta y un programa de cumplimiento de la PCI DSS para incluir:
- Responsabilidad general de mantener el cumplimiento de la PCI DSS
- Definir un estatuto para el programa de cumplimiento de la PCI DSS y la comunicación a la gerencia ejecutiva
Proveedores de servicios
01 de febrero de 2018 12.11. Realizar revisiones al menos trimestralmente para confirmar que el personal sigue las políticas de seguridad y los procedimientos operativos. Las revisiones deben cubrir los siguientes procesos:
- Revisiones del registro diario
- Revisiones del conjunto de reglas de firewall
- La aplicación de las normas de configuración a los nuevos sistemas
- Respuesta a las alertas de seguridad
- Procesos de gestión del cambio
Proveedores de servicios
01 de febrero de 2018 12.11.1. Mantener la documentación del proceso de revisión trimestral para incluir:
- Documentar los resultados de las revisiones
- Revisión y cierre de los resultados por el personal asignado a la responsabilidad del programa de cumplimiento de la PCI DSS
Proveedores de servicios
01 de julio de 2018 Todas las entidades deberán haber dejado de usar la SSL/TLS temprana como un control de seguridad, y usar solo las versiones seguras del protocolo. Comercios y proveedores de servicios

Si tienes preguntas, no olvides dejar tu comentario o ingresar al foro de PCI Hispano.

OWASP Top Ten y PCI DSS

Desde sus primeras versiones, PCI DSS siempre citado a la OWASP como referente para la definición de directrices de codificación segura. Por ello, en el requisito 6.5 "Aborde las vulnerabilidades de codificación comunes en los procesos de desarrollo de software" se citan las guías de la OWASP como mejores prácticas de la industria a ser empleadas para estas acciones, en conjunción con las guías del CERT (https://www.cert.org/secure-coding/publications/index.cfm) y del SANS CWE Top 25 (http://cwe.mitre.org/top25/).

Teniendo en cuenta la dinámica en términos de riesgos en las aplicaciones web, el PCI SSC fue bastante precavido y por ello dejó en claro que, en el caso de actualización de las mejores prácticas de la industria para la gestión de las vulnerabilidades, éstas deberían primar sobre las identificadas por el propio estándar.
Figura 3. Requisito 6.5 de PCI DSS

Por otro lado, también se deja en claro lo siguiente:
"A medida que cambian las prácticas de codificación segura aceptadas por la industria, las prácticas de codificación de las organizaciones y la capacitación de los desarrolladores se deben actualizar para abordar nuevas amenazas, por ejemplo, ataques para extraer la memoria." 

"Las vulnerabilidades identificadas en los Requisitos 6.5.1 al 6.5.10 proporcionan un punto de partida mínimo."

"Es responsabilidad de la organización informarse sobre las últimas tendencias en vulnerabilidades e incorporar las medidas apropiadas en cuanto a las prácticas de codificación segura"

Las vulnerabilidades descritas en los requisitos 6.5.1 al 6.5.10 de PCI DSS hacen referencia a los controles mínimos que se deben implementar y que las organizaciones deben incorporar dentro de sus prácticas de codificación segura correspondientes a la tecnología particular de su entorno.
A continuación, se relacionan dichos requisitos de PCI DSS y su correspondencia con los Top Ten de la OWASP de los años 2013 y 2017:
Req.
Descripción
Referencia en OWASP Top Ten 2013
Referencia en OWASP Top Ten 2017
6.5.1
Errores de inyección, en especial, errores de inyección SQL. También considere los errores de inyección de comandos de OS, LDAP y Xpath, así como otros errores de inyección.
A1:2013
A1:2017
6.5.2
Desbordamiento de buffer
-        
-        
6.5.3
Almacenamiento cifrado inseguro
A6:2013
A3:2017
6.5.4
Comunicaciones inseguras
A6:2013
A3:2017
6.5.5
Manejo inadecuado de errores
A5:2013
A6:2013
A3:2017
A6:2017
6.5.6
Todas las vulnerabilidades de "alto riesgo" detectadas en el proceso de identificación de vulnerabilidades
A9:2013
A9:2017
6.5.7
Lenguaje de comandos entre distintos sitios (XSS)
A3:2013
A7:2017
6.5.8
Control de acceso inapropiado
A4:2013
A7:2013
A10:2013
A5:2017
6.5.9
Falsificación de solicitudes entre distintos sitios (CSRF)
A8:2013
-        
6.5.10
Autenticación y administración de sesión interrumpidas
A2:2013
A2:2017

Como se puede observar, ninguno de los nuevos riesgos incluidos en la versión 2017 del Top Ten de la OWASP es contemplado por PCI DSS v3.2:
  • A4:2017 – XML External Entities (XXE)
  • A8:2017 – Insecure Deserialization
  • A10:2017 – Insufficient Logging & Monitoring

¿Qué implican estos cambios en el cumplimiento de PCI DSS y cómo se debe proceder?

La priorización de nuevos riesgos a nivel de aplicación previamente no cubiertos por PCI DSS, pero identificados actualmente en la última versión del Top Ten de la OWASP, implica que todas las organizaciones que desarrollen aplicaciones de pago para entornos PCI DSS deben proceder de la siguiente manera:
  • Actualizar la documentación vinculada con el SSDLC (Secure Software Development Life Cycle) para que contemplen la totalidad de los riesgos del Top Ten de la OWASP 2017 – Req. 6.3
  • Actualizar los criterios empleados en la revisión de código (ya sea si se realiza manualmente o empleando herramientas automatizadas) antes de enviarlo a Producción para que cubran estos nuevos riesgos – Req. 6.3.2
  • Actualizar el material de formación en desarrollo seguro incluyendo estos nuevos riesgos y describir sus contramedidas – Req. 6.5
  • Proceder a capacitar a los desarrolladores dentro de los ciclos formativos anuales – Req. 6.5
  • Si se cuenta con aplicaciones web públicas y dependiendo de la opción empleada para protegerlas contra ataques conocidos, actualizar dichos métodos para que contemplen los riesgos de la OWASP Top Ten 2017:
    • Si se emplean herramientas o métodos de evaluación de vulnerabilidades de aplicación  automáticos o manuales, éstos deben permitir la identificación de los nuevos riesgos.
    • Si se emplea un WAF (Web Application Firewall), esta solución debe ser configurada para que detecte y/o bloquee aquellos ataques vinculados con estos nuevos riesgos. 
Fuente: IsecAuditors

0 comentarios:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info
Si vas a dejar una consulta, procura tener habilitado tu perfil en Blogger o deja una forma de contacto.

Gracias por comentar!