En Abril de 2015 el PCI SSC publicó la versión 1.0 del suplemento informativo de guía para las pruebas de penetración (Information Supplement: Penetration Testing Guidance). En septiembre de 2017 este documento fue actualizado a la versión 1.1 para incluir referencias adicionales a pruebas de ingeniería social y aclaraciones menores.

En este artículo se resaltarán los 10 aspectos principales de este nuevo documento, que detalla las acciones requeridas para el cumplimiento del requerimiento 11.3 de PCI DSS, incluyendo los cambios adicionados en la versión 3.1 del estándar, la definición de una metodología, la validación del alcance de cumplimiento (scope), la gestión de vulnerabilidades y la revisión de los controles de segmentación, entre otros.

1. Diferencia entre análisis de vulnerabilidades y pruebas de penetración

Debido a que aún persisten dudas respecto a las diferencias entre un análisis de vulnerabilidades (vulnerability scans – req. 11.2) y las pruebas de penetración (penetration testing – req. 11.3), se ha diseñado una tabla que describe las diferencias entre estos dos conceptos:

 Análisis de vulnerabilidadesPruebas de penetración
PropósitoIdentificar, clasificar y reportar vulnerabilidades que - si son explotadas - pueden resultar en el compromiso intencional o no de un sistema.Identificar formas para explotar vulnerabilidades para esquivar o anular características de seguridad de los componentes del sistema.
CuándoAl menos trimestralmente o después de un cambio significativo.Por lo menos anualmente y después de un cambio significativo.
CómoTípicamente empleando herramienta automatizadas combinadas con verificación manual de problemas identificados.Un proceso manual que puede incluir el uso de analizadores de vulnerabilidades u otras herramientas automatizadas, cuyo resultado será un informe exhaustivo.
ReportesRiesgos potenciales de vulnerabilidades conocidas, catálogadas de acuerdo con la puntuación asignada por NVD (National Vulnerability Database) / CVSS (Common Vulnerability Scoring System).
Los análisis de vulnerabilidades externos deben ser ejecutados por un Criterios para escoger un Proveedor Aprobado de Escaneo (ASV)proveedor ASV y los riesgos catalogados de acuerdo con CVSS.
Los análisis de vulnerabilidades internos pueden ser ejecutados por personal cualificado (no requiere ser ASV) y los riesgos deben ser catálogados de acuerdo con proceso de catálogo de riesgos establecido por la organización, conforme con el requerimiento 6.1 de PCI DSS.
Un análisis de vulnerabilidades externo debe ser ejecutado desde fuera de la organización objetivo. Un análisis de vulnerabilidades interno debe ser ejecutado desde dentro de la organización objetivo.
Descripción de cada vulnerabilidad identificada o problema potencial descubierto, incluyendo riesgos específicos que dicha vulnerabilidad pueda poseer, así como métodos específicos de cómo y en qué medida puede ser explotada.
Ejemplos de vulnerabilidades incluye pero no se limita a inyección de SQL, escalamiento de privilegios, Cross-site scripting (XSS) y uso de protocolos obsoletos.
DuraciónRelativamente corto, variando entre algunos segundos a minutos por dispositivo analizado.Las pruebas pueden durar días o semanas, dependiendo del alcance de la prueba y el tamaño del entorno a ser analizado.
Las pruebas pueden crecer en tiempo y complejidad si la prueba descubre alcance adicional.

2. Tipos de pruebas de penetración

Dentro de la nueva guía se distinguen tres tipos de pruebas de penetración:

  • Caja negra: En este tipo de pruebas no se provee al pentester (persona interna o externa que realiza las pruebas de penetración) ningún tipo de información respecto al entorno que estará sujeto a las pruebas.
  • Caja blanca: En las pruebas de caja blanca, se suele entregar al pentester información completa y detallada de las redes y aplicaciones y se ejecuta con conocimiento del diseño e implementación de la estructura interna del entorno.
  • Caja gris: En este tipo de pruebas, se facilita al pentester información parcial del entorno.

Las pruebas de penetración relacionadas con PCI DSS por lo general son de caja blanca o de caja gris, ya que proporcionan resultados más precisos y pruebas más exhaustivas de la postura de seguridad del entorno, a diferencia de una prueba de caja negra que – debido a que no se entrega información del entorno antes de las pruebas – puede requerir más tiempo, dinero y recursos para su ejecución.

3. Pruebas de penetración en capa de red y de aplicación

Dentro de las pruebas de penetración se distinguen dos tipos de revisión:

  • Pruebas a nivel de capa de red, que incluyen pruebas internas y externas de redes (LAN/VLAN) entre sistemas interconectados, redes inalámbricas e ingeniería social. Las vulnerabilidades detectadas en estas pruebas pueden incluir reconfiguración o actualización de software o el despliegue de una alternativa segura a software inseguro.
  • Pruebas a nivel de capa de aplicación, que incluyen sitios web, aplicaciones web u otras aplicaciones. Las correcciones de las vulnerabilidades detectadas en este tipo de pruebas pueden incluir el rediseño o re-escritura del código inseguro.

Cualquier software desarrollado por o específicamente para la organización es parte del alcance de las pruebas y debe contemplar ambos escenarios (a nivel de red y a nivel de aplicación), tratando de identificar cualquier defecto de seguridad causado por diseño inseguro de la aplicación o configuración, empleo de prácticas de desarrollo inseguras o cualquier otro defecto de seguridad.

4. Alcance: Cardholder Data Environment (CDE)

El PCI SSC define el entorno de titular de tarjetas de pago (Cardholder Data Environment) como “las personas, procesos y tecnologías que almacenan, procesan o transmiten datos de tarjetas de pago o datos sensibles de autenticación (banda magnética completa, CID/CAV2/CVC2/CVV2 y PIN/PIN Block)”.

Bajo este escenario, se deben contemplar las siguientes áreas de la red de datos para que sean probadas:

  • Las pruebas de penetración externas deben cubrir el perímetro externo del CDE y los sistemas críticos conectados o accesibles a través de redes públicas abiertas, incluyendo cualquier servicio que tenga acceso restringido a direcciones IP externas y cualquier vector de acceso remoto como conexiones por VPN o por marcado (dial-up), ejecutando pruebas a nivel de capa de red y de aplicación.
  • Las pruebas de penetración interna deben cubrir el perímetro interno del CDE desde la perspectiva de cualquier segmento de red LAN que se encuentre fuera del entorno de cumplimiento. Los sistemas críticos y cualquier otro elemento que pueda afectar la seguridad del CDE deben ser tenidos en cuenta, incluyendo pruebas a nivel de capa de red y de aplicación.
  • Si se han implementado controles de segmentación, dichos controles deberán ser probados para validar la efectividad del aislamiento entre el CDE y cualquier otro segmento fuera del CDE.
  • Para garantizar que un sistema se encuentra fuera del alcance de cumplimiento, se debe incluir dentro de las pruebas de penetración sistemas que no procesen, transmitan o almacenen datos de tarjeta para comprobar que si dichos sistemas son comprometidos no afectarán la seguridad del entorno de cumplimiento.
  • No es un requerimiento realizar pruebas de penetración dentro del entorno de cumplimiento (CDE). No obstante, si las pruebas externas o internas logran acceso al entorno, el pentester puede elegir entre seguir haciendo pruebas dentro del entorno con el fin de validar los controles de exfiltración de datos o detener la prueba.

5. Uso de entornos de pruebas en vez de entornos de producción

Debido a la criticidad de los entornos de producción y a los potenciales problemas de desempeño, disponibilidad y seguridad que podrían presentarse durante la ejecución de las pruebas de penetración, se pueden usar entornos separados que sean idénticos al entorno de producción para la ejecución de las revisiones.  El pentester debe validar que los controles en el entorno de pruebas son iguales al entorno de producción. Cualquier vulnerabilidad identificada debe ser corregida en el entorno de producción y se deben repetir las pruebas hasta que todo se encuentre corregido.

6. Ingeniería social

La ingeniería social es el intento de obtener información, acceso o introducir software no autorizado dentro del entorno mediante la manipulación de los usuarios finales. Mediante este tipo de pruebas se pretende evaluar la formación y el conocimiento de las políticas y procedimientos de PCI DSS por parte de los usuarios y la efectividad de las formaciones periódicas en seguridad.  Dentro de las pruebas realizadas se puede intentar que un usuario mantenga una puerta abierta para permitir un acceso físico no autorizado, pedirle a alguien su contraseña de acceso o convencer a un usuario final de abrir un hipervínculo en un correo electrónico malicioso.

Las vulnerabilidades detectadas mediante este tipo de pruebas por lo general se pueden corregir con sesiones de formación y concienciación en seguridad a los usuarios.

7. Cambio significativo

El concepto de “cambio significativo” es muy importante en el cumplimiento de los requerimientos 11.3.1 y 11.3.2, ya que el estándar requiere que las pruebas de penetración se ejecuten de forma anual o cuando exista un “cambio significativo” en el entorno.

Siendo así, el PCI SSC define un cambio significativo como una modificación o actualización de infraestructura o de aplicación o la instalación de nuevos componentes del sistema. No obstante – y al ser una descripción tan general – es la propia organización la que debe definir qué es un “cambio significativo” para su entorno con base en el impacto a la seguridad de las tarjetas de pago que dicho cambio pueda agregar. El objetivo de las pruebas de penetración es validar que los controles desplegados siguen siendo efectivos posterior a la implementación del cambio.

8. Requerimientos necesarios de un pentester para poder ejecutar una prueba de penetración

A diferencia de los análisis de vulnerabilidades ASV (req. 11.2.2) que requieren ser ejecutados por una organización homologada por el PCI SSC (Proveedor Aprobado de Escaneos), las pruebas de penetración pueden ser ejecutadas por personal interno o por terceros contratados por la empresa.

Sin embargo, dicho personal requiere demostrar su experiencia y conocimiento para garantizar que el ejercicio obtendrá los resultados esperados:

  • Si las pruebas de penetración son realizadas por un tercero (proveedor), se debe validar que este proveedor sea independiente y no esté vinculado en tareas de instalación, mantenimiento y/o soporte de los sistemas en el entorno de cumplimiento.
  • Preferiblemente, el pentester deberá contar con alguna certificación que permita validar su conocimiento en el área. Por ejemplo Offensive Security Certified Professional (OSCP), Certified Ethical Hacker (CEH), Global Information Assurance Certification (GIAC) Certifications, CREST Penetration Testing Certifications, entre otras.
  • Como complemento a las certificaciones, se recomienda validar la experiencia del pentester en proyectos similares en términos de tiempo, complejidad de proyectos, tecnologías cubiertas, etc.

9. Metodología de las pruebas de penetración

Con el fin de establecer un marco común de trabajo, PCI DSS en su requerimiento 11.3 establece la necesidad de la definición de una metodología para la ejecución de las pruebas de penetración. Dicha metodología debe cubrir las tres fases de este tipo de proyectos: Pre-ejecución, ejecución y post-ejecución.

  • Pre-ejecución (pre-engagement): En esta fase se definen los roles y responsabilidades de los actores involucrados en la prueba, los tipos de pruebas a ejecutar, la definición del ámbito a ser cubierto, la documentación a ser provista al pentester (gráficos de red, diagramas de flujo de datos de tarjetas, etc.), políticas de la prueba (horarios de las pruebas, canales de comunicación entre las partes, acciones en el caso de identificación de datos sensibles, direcciones IP desde las cuales se realizarán las pruebas, etc.), coordinación, aprobaciones y responsabilidades en entornos en la nube (cloud) o en hosting, los criterios para establecer cuándo la prueba finaliza (cuando se compromete un sistema, cuando se inhabilita un control de seguridad, cuando se logran extraer datos confidenciales, etc.), la revisión de vulnerabilidades pasadas y la desactivación temporal de controles activos (WAF, IPS) que puedan afectar la ejecución de la prueba.
  • Ejecución (engagement): Esta fase involucra la ejecución de las pruebas de penetración a nivel de red, a nivel de aplicación, revisión de controles de segmentación, notificación en caso de acceso a datos de tarjetas de pago y acciones post-explotación (acciones tomadas después del compromiso del sistema).
  • Post-ejecución (post-engagement): En esta fase se definen las mejores prácticas en la remediación de las vulnerabilidades identificadas y explotadas, la re-ejecución de pruebas posterior a las correcciones para validar que el riesgo ha sido gestionado satisfactoriamente y la eliminación de cuentas/software usadas en las pruebas.

Como referencia para la redacción de esta metodología, el PCI SSC recomienda la alineación con los siguientes documentos (lista no exhaustiva):

10. Reportes y documentación

Finalmente, los resultados de la prueba de penetración deben ser estructurados en un documento que indique qué fue probado, cómo fue probado y los resultados obtenidos.

Cada una de las vulnerabilidades identificadas debe ser descrita y contener una puntuación de severidad (severity score) basada en las clasificaciones de NVD o CVSS (entre otros) u orientada a umbrales de nivel de riesgo (alto, medio, bajo).

El documento ofrece una lista de validación (Report Evaluation Checklist) con los apartados que debe contener el informe, con el fin que tanto el pentester como quien recibe el informe puedan validar que se han cubierto todas las áreas requeridas por la prueba así como tres casos de estudio que reflejan todos los apartados de la metodología.

Como siempre, les invitamos a participar en el foro o dejar un comentario en este artículo si se tiene alguna duda, comentario o sugerencia.