Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .
La versión actual del PCI DSS es 3.2.1, publicada en mayo de 2018. El requisito 6 establece que usted debe “Desarrollar y mantener sistemas y aplicaciones seguros”. Claro, no hay problema. Esto es totalmente claro y sencillo, ¡al menos para cualquiera que nunca haya intentado desarrollar y mantener sistemas y aplicaciones seguros! Para el resto de nosotros, eso es una tarea difícil.
Pero el documento continúa enumerando una serie de requisitos bastante sencillos: cosas que ya son componentes de la mayoría de los ciclos de vida de desarrollo de software seguro. Debe establecer un proceso para identificar vulnerabilidades de seguridad, abordar vulnerabilidades conocidas, emplear las mejores prácticas en codificación, separar de forma segura los entornos y cuentas de desarrollo y prueba de la producción, realizar revisiones de código, tener un proceso de control de cambios, capacitar a los desarrolladores en técnicas de codificación segura, etc. Todo bastante razonable.
Un poco más a fondo, bajo ese requisito de nivel superior (en el Requisito 6.5), se enumeran una serie de vulnerabilidades específicas contra las que se deben proteger las aplicaciones . Estos son una especie de “grandes éxitos” de OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding, etc., y son lo que esperaría: inyección SQL, criptografía débil, XSS, desbordamientos de búfer y similares. Una vez más, razonable. Los atacantes suelen apuntar a este tipo de vulnerabilidades como punto inicial de ataque.
Luego, en el requisito 6.6, el más importante: “Para las aplicaciones web públicas, aborde las nuevas amenazas y vulnerabilidades de forma continua y asegúrese de que estas aplicaciones estén protegidas contra ataques conocidos”. ¿Qué ataques? Responde, “como mínimo, todas las vulnerabilidades del Requisito 6.5”. Piénsalo por un momento. ¡Este único requisito, el 6.6, enterrado en lo profundo del documento en la página 64, tiene un gran impacto en cómo creamos y operamos el software! ¿Cómo proponen cumplir con este requisito? La respuesta tiene dos partes:
Esto afecta tanto al tiempo de compilación como al tiempo de ejecución de las aplicaciones web y realmente involucra dos actividades completamente diferentes:
1.Revisar aplicaciones para detectar de forma proactiva la presencia de vulnerabilidades (y luego asegurarse 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 públicas son los principales objetivos de los atacantes, y las aplicaciones web mal codificadas proporcionan una vía fácil para que los atacantes accedan a datos y sistemas confidenciales”. No podría estar más de acuerdo. El desafío radica en la implementación práctica del requisito.
No se ofrecen muchas pautas sobre cómo realizar la primera parte: revisar las aplicaciones. Las aplicaciones deben revisarse “utilizando herramientas o métodos de evaluación de seguridad de vulnerabilidad, ya sean manuales o automatizados”. Eso es bastante amplio.
La segunda parte tiene una recomendación un poco más específica. Debe instalar “una solución técnica automatizada que detecte y prevenga ataques basados en la web (por ejemplo, un firewall de aplicaciones web) frente a las aplicaciones web públicas, para verificar continuamente todo el tráfico”. Esto fue una bendición para los proveedores de WAF, quienes de repente se encontraron en una situación de compra obligada para los equipos que buscaban satisfacer el Requisito 6.6. Pero un WAF no ayuda con la primera parte del requisito. Un WAF no es una herramienta de evaluación de seguridad: No tiene idea de qué hace una aplicación ni cómo. Solo entiende lo que se envía a una aplicación , no lo que la aplicación puede (o no) hacer con esa información.
Todo esto deja a muchos equipos luchando por abordar la totalidad del 6.6. En este pequeño requisito hay dos necesidades significativas y bastante diferentes. La mayoría intentará satisfacer la segunda parte con un WAF y reunirá una serie de otras técnicas para abordar la primera (revisiones manuales de código, análisis automatizado de código fuente , etc.).
Pero existe una alternativa que puede satisfacer el Requisito 6.6 con una única solución. Notarás que el estándar PCI incluye la frase "por ejemplo" cuando se menciona WAF. Esto es significativo (y no estaba incluido en versiones anteriores del estándar). Reconoce que existen otras tecnologías que pueden proteger las aplicaciones siempre que estén “configuradas para bloquear ataques basados en la web o generar una alerta que se investigue de inmediato”. Monitoreo de seguridad de aplicación , la solución de seguridad de aplicación unificada que Threat Stack ha agregado a su Cloud Security Platform® sin costo adicional, aborda los aspectos de tiempo de compilación y tiempo de ejecución del Requisito 6.6. Una solución a estos dos grandes desafíos.
En el momento de la compilación, agrega el microagente Threat Stack a tus aplicaciones como cualquier otra biblioteca de código de terceros. A los desarrolladores les resulta muy similar instrumentar sus aplicaciones con una solución APM. Una vez que se agrega el microagente, la aplicación se evalúa cada vez que se ejecuta, ya sea a través de pruebas manuales locales, pruebas automatizadas en una compilación nocturna, pruebas de aceptación del usuario, etc. PCI especifica que la aplicación debe revisarse “al menos anualmente y después de cualquier cambio”. Threat Stack va mucho más allá y permite identificar vulnerabilidades de seguridad de forma continua, todo ello sin que el desarrollador tenga que realizar ningún trabajo adicional. No hay pruebas que escribir ni servidores que administrar.
Una vez que se identifica una vulnerabilidad, el Requisito 6.6 también indica que debe abordarse. Debe asegurarse de “que se corrijan todas las vulnerabilidades y que la aplicación se vuelva a evaluar después de las correcciones”. Threat Stack AppSec Monitoring brinda a los desarrolladores orientación práctica sobre cualquier riesgo detectado: explica el riesgo, presenta un código de muestra sobre cómo solucionarlo y dirige al desarrollador al nombre exacto del módulo y método, la ubicación del archivo y el número de línea donde se encontró. Una vez que el desarrollador corrige la vulnerabilidad, no es necesario hacer nada especial para “reevaluar”: la aplicación se evaluará automáticamente la próxima vez que se ejecute.
En tiempo de ejecución, el requisito es “verificar continuamente todo el tráfico” para proteger la aplicación contra ataques conocidos. El mismo microagente Threat Stack también hace esto. A medida que la aplicación se implementa desde desarrollo a producción, el microagente la acompaña (está integrado a la aplicación como una dependencia). Desde allí, analiza todas las cargas web que se envían a la aplicación para detectar señales de ataque. Si se determina que una carga útil es maliciosa, la solicitud se puede detener de inmediato. Los equipos reciben una notificación sobre el ataque a través del portal Threat Stack o en Slack u otros canales de ChatOps. Esto aborda directamente el requisito de PCI de “bloquear ataques basados en la web o generar una alerta que se investigue de inmediato”.
PCI 6.6 es grande. El mandato de “abordar nuevas amenazas y vulnerabilidades de forma continua y garantizar que estas aplicaciones estén protegidas contra ataques conocidos” cubre dos fases separadas del ciclo de vida del desarrollo de software (desarrollo y producción) e involucra dos tareas separadas (evaluación proactiva de vulnerabilidades y detección y prevención de ataques en tiempo real). Ambos son complejos y generalmente involucran equipos diferentes. Pero no se necesitan dos herramientas separadas para abordarlos. El monitoreo de seguridad de aplicación de Threat Stack aborda ambos requisitos con una única solución que no ralentizará a los desarrolladores. ¡Pruébalo hoy!
Si está interesado en obtener más información o desea realizar una prueba de monitoreo de seguridad de aplicación , regístrese para obtener una demostración de la plataforma de seguridad en la nube Threat Stack. Nuestros expertos en cumplimiento y seguridad estarán encantados de analizar sus necesidades específicas.
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 Para las aplicaciones web públicas, abordar nuevas amenazas y vulnerabilidades de forma continua y garantizar que estas aplicaciones estén protegidas contra ataques conocidos mediante cualquiera de los siguientes métodos:
Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .