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 aplicações seguros”. Claro, no hay problema. Esto es totalmente claro y sencillo, ¡al menos para cualquiera que nunca haya intentado desarrollar y mantener sistemas y aplicações 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 aplicações . 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 aplicações web públicas, aborde las nuevas amenazas y vulnerabilidades de forma continua y asegúrese de que estas aplicações 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 aplicações web y realmente involucra dos actividades completamente diferentes:
1.Revisar aplicações 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 aplicações web públicas son los principales objetivos de los atacantes, y las aplicações 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 aplicações 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 aplicação ni cómo. Solo entiende lo que se envía a una aplicação , no lo que la aplicação 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 aplicações 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 aplicação , la solución de seguridad de aplicação 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 aplicações como cualquier otra biblioteca de código de terceros. A los desarrolladores les resulta muy similar instrumentar sus aplicações con una solución APM. Una vez que se agrega el microagente, la aplicação 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 aplicação 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 aplicação 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 aplicação contra ataques conocidos. El mismo microagente Threat Stack también hace esto. A medida que la aplicação se implementa desde desarrollo a producción, el microagente la acompaña (está integrado a la aplicação como una dependencia). Desde allí, analiza todas las cargas web que se envían a la aplicação 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 aplicações 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 aplicação 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 aplicação , 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 aplicações web públicas, abordar nuevas amenazas y vulnerabilidades de forma continua y garantizar que estas aplicações 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 .