Cómo cumplir el requisito 6.6 de PCI DSS: una solución dos en uno de Threat Stack

F5

Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Empieza a utilizar Distributed Cloud AIP con tu equipo hoy.

La versión actual del PCI DSS es la 3.2.1, publicada en mayo de 2018. El requisito 6 establece que se deben «desarrollar y mantener sistemas y aplicaciones seguros». Claro, ningún problema. Es totalmente claro y sencillo, al menos para quien nunca haya intentado desarrollar y mantener sistemas y aplicaciones seguros. Para los demás, es una tarea muy exigente.

Sin embargo, el documento continúa enumerando una serie de requisitos bastante claros, aspectos que ya forman parte de la mayoría de los ciclos de vida de desarrollo de software seguro. Se debe establecer un proceso para identificar vulnerabilidades de seguridad, corregir las vulnerabilidades conocidas, aplicar buenas prácticas de programación, separar de forma segura los entornos y las cuentas de desarrollo y pruebas de los de producción, realizar revisiones de código, disponer de un proceso de control de cambios, formar a los desarrolladores en técnicas de programación segura, etc. Todo bastante razonable.

Profundizando un poco más en ese requisito de alto nivel —concretamente, en el requisito 6.5—, se enumeran varias vulnerabilidades específicas frente a las que deben protegerse las aplicaciones. Se trata de una especie de recopilación de los «grandes éxitos» de OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding, etc., e incluye lo que cabría esperar: inyección SQL, criptografía débil, XSS, desbordamientos de búfer y similares. De nuevo, algo razonable. Los atacantes suelen centrarse en este tipo de vulnerabilidades como punto de entrada inicial.

Después, en el requisito 6.6, llega lo más importante: «En el caso de las aplicaciones web de acceso público, abordar continuamente las nuevas amenazas y vulnerabilidades y garantizar que estas aplicaciones estén protegidas frente a ataques conocidos». ¿Qué ataques? La respuesta es: «Como mínimo, todas las vulnerabilidades del requisito 6.5». Piénselo por un momento. Este único requisito —el 6.6—, escondido en lo más profundo del documento, en la página 64, tiene un enorme impacto en la forma en que desarrollamos y operamos el software. ¿Cómo proponen cumplir este requisito? La respuesta consta de dos partes:

• Revisando las aplicaciones anualmente y después de cualquier cambio, utilizando «herramientas o métodos de evaluación de vulnerabilidades de seguridad, ya sean manuales o automatizados»
• Mediante el uso de «una solución técnica automatizada que detecte y evite los ataques basados en la web»

Por tanto, esto afecta tanto a la fase de compilación como al tiempo de ejecución de las aplicaciones web y, en realidad, implica dos actividades completamente distintas:

1. Revisar las aplicaciones para detectar de forma proactiva la presencia de vulnerabilidades (y asegurarse después de que se corrijan)

– Y –

2. Detectar y bloquear ataques en tiempo real

No es un mal requisito en absoluto. Como indica la guía, «las aplicaciones web de acceso público son objetivos prioritarios para los atacantes, y las aplicaciones web mal programadas les ofrecen una vía fácil para acceder a datos y sistemas confidenciales». No podría estar más de acuerdo. El reto reside en la aplicación práctica del requisito.

No se ofrecen muchas indicaciones sobre cómo llevar a cabo la primera parte: revisar las aplicaciones. Las aplicaciones deben revisarse «utilizando herramientas o métodos manuales o automatizados de evaluación de vulnerabilidades de seguridad». Es una indicación bastante amplia.

La segunda parte incluye una recomendación algo más específica. Se debe instalar «una solución técnica automatizada que detecte e impida los ataques a través de la web (por ejemplo, un cortafuegos de aplicaciones web) delante de las aplicaciones web de acceso público, para comprobar continuamente todo el tráfico». Esto supuso una gran oportunidad para los proveedores de WAF, que de repente vieron cómo sus productos se convertían en una compra destinada a «marcar una casilla» para los equipos que querían cumplir el requisito 6.6. Sin embargo, un WAF no ayuda con la primera parte del requisito. Un WAF no es una herramienta de evaluación de la seguridad: no sabe qué hace una aplicación ni cómo lo hace. Solo entiende lo que se envía a una aplicación, no lo que esta puede hacer (o no) con esa información.

Todo esto hace que muchos equipos tengan dificultades para abordar la totalidad del requisito 6.6. Este único y breve requisito engloba dos necesidades importantes y bastante diferentes. La mayoría intentará cumplir la segunda parte mediante un WAF y combinará otras técnicas para abordar la primera (revisiones manuales de código, análisis automatizado del código fuente, etc.).

Pero existe una alternativa que permite cumplir el Requisito 6.6 con una única solución. Observará que el estándar PCI incluye la expresión «por ejemplo» al mencionar los WAF. Esto es importante (y no se incluía en versiones anteriores del estándar), ya que reconoce que existen otras tecnologías capaces de proteger las aplicaciones siempre que estén «configuradas para bloquear ataques basados en la web o generar una alerta que se investigue de inmediato». Application Security Monitoring —la solución unificada de seguridad de aplicaciones que Threat Stack ha añadido sin coste adicional a su Cloud Security Platform®— aborda tanto los aspectos de la fase de compilación como los de la fase de ejecución del Requisito 6.6. Una única solución para estos dos grandes retos.

Durante la compilación, se añade el microagente de Threat Stack a las aplicaciones como cualquier otra biblioteca de código de terceros. Para los desarrolladores, el proceso es muy similar a instrumentar sus aplicaciones con una solución de APM. Una vez añadido el microagente, la aplicación se evalúa cada vez que se ejecuta, ya sea mediante pruebas manuales locales, pruebas automatizadas en una compilación nocturna, pruebas de aceptación de usuario, etc. PCI especifica que la aplicación debe revisarse «al menos una vez al año y después de cualquier cambio». Threat Stack va mucho más allá e identifica vulnerabilidades de seguridad de forma continua, sin que el desarrollador tenga que realizar ningún trabajo adicional. No hay que escribir pruebas ni administrar servidores.

Una vez identificada una vulnerabilidad, el Requisito 6.6 también establece que debe subsanarse. Debe asegurarse «de que se corrijan todas las vulnerabilidades y de que la aplicación vuelva a evaluarse después de las correcciones». Threat Stack AppSec Monitoring proporciona a los desarrolladores indicaciones prácticas sobre los riesgos detectados: explica el riesgo, ofrece código de ejemplo para corregirlo e indica el módulo y el nombre del método exactos, así como la ubicación del archivo y el número de línea donde se ha encontrado. Una vez que el desarrollador corrige la vulnerabilidad, no es necesario hacer nada especial para «volver a evaluar» la aplicación, ya que se evaluará automáticamente la próxima vez que se ejecute.

Durante la ejecución, el requisito es «comprobar continuamente todo el tráfico» para proteger la aplicación frente a ataques conocidos. El mismo microagente de Threat Stack también se encarga de ello. A medida que la aplicación se despliega desde el entorno de desarrollo hasta producción, el microagente la acompaña (está integrado en la aplicación como una dependencia). A partir de ahí, analiza todas las cargas útiles web que se envían a la aplicación para detectar indicios de ataque. Si se determina que una carga útil es maliciosa, la solicitud puede detenerse de inmediato. Los equipos reciben notificaciones sobre el ataque a través del portal de Threat Stack, de Slack o de otros canales de ChatOps. Esto cumple directamente el requisito de PCI de «bloquear los ataques basados en web o generar una alerta que se investigue de inmediato».

PCI 6.6 tiene un gran alcance. El mandato de «abordar de forma continua las nuevas amenazas y vulnerabilidades y garantizar que estas aplicaciones estén protegidas frente a ataques conocidos» abarca dos fases distintas del ciclo de vida del desarrollo de software (desarrollo y producción) e implica dos tareas diferentes (la evaluación proactiva de vulnerabilidades y la detección y prevención de ataques en tiempo real). Ambas son complejas y suelen involucrar a equipos diferentes. Pero no necesita dos herramientas distintas para abordarlas. Application Security Monitoring de Threat Stack cumple ambos requisitos con una única solución que no ralentizará a los desarrolladores. ¡Pruébela hoy mismo!

Si le interesa obtener más información o quiere probar Application Security Monitoring, solicite una demostración de Threat Stack Cloud Security Platform. Nuestros expertos en cumplimiento normativo y seguridad estarán encantados de analizar sus requisitos específicos.

Referencia

Requisito 6.6 de PCI DSS de Requisitos y procedimientos de evaluación de seguridad, versión 3.2.1, mayo de 2018

6.6 En el caso de las aplicaciones web de acceso público, aborde de forma continua las nuevas amenazas y vulnerabilidades, y asegúrese de que estas aplicaciones estén protegidas contra ataques conocidos mediante uno de los siguientes métodos:

• Revisar las aplicaciones web de acceso público mediante herramientas o métodos manuales o automatizados de evaluación de la seguridad y detección de vulnerabilidades, al menos una vez al año y después de cualquier cambio
• Instalar una solución técnica automatizada que detecte y evite ataques basados en la web (por ejemplo, un cortafuegos de aplicaciones web) delante de las aplicaciones web de acceso público, para supervisar continuamente todo el tráfico.

Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Empieza a utilizar Distributed Cloud AIP con tu equipo hoy.

Sobre el autor

F5

Más artículos de F5