Cuando un PCI QSA y la seguridad de la aplicación chocan

Si bien la seguridad de las aplicaciones y el cumplimiento de los datos de pago no suelen estar asociados, hay más enlaces de los que cabría esperar.
Hablando en la conferencia OWASP AppSec en Cambridge, Geraint Williams, consultor y QSA, dijo que al evaluar la certificación PCI, estará analizando la protección de los datos de los titulares de tarjetas dentro de las aplicaciones web, pero hay una serie de problemas comunes con los que se encuentra y que se puede quitar.
Dijo: “Lo que estoy buscando en una auditoría es si tienen políticas y procedimientos establecidos, y las personas están capacitadas. PCI DSS no es el mejor estándar para la seguridad de las aplicaciones web, pero es un estándar mínimo y espero que los procesadores estén asegurando el estándar mínimo «.
Resaltando algunas fallas comunes, Williams señaló el uso de un procesador o manejador de datos de terceros cuya «seguridad suele ser totalmente inútil» y cuyo sitio web puede ser fácilmente redirigido a un sitio web controlado por el atacante. “Se trata de escribir aplicaciones que aseguren que cualquier traspaso se realice correctamente, está dentro del alcance de PCI DSS”, dijo.
También señaló el uso de anuncios de terceros que pueden estar infectados y mostrados en el sitio web de comercio electrónico, posiblemente para capturar datos de titulares de tarjetas. «Queremos ver que todo se ha considerado dentro de una aplicación y también con el comercio electrónico y los comerciantes normales».
Sin embargo, la mayor preocupación es que si opera un sitio web y desarrolló el código, ¿puede demostrar que lo ha asegurado? Dijo: “Puede que seas un proveedor de servicios o un comerciante, pero estoy realmente preocupado por la forma en que los sitios web están configurados para realizar redireccionamientos. Depende de los comerciantes que escriban un código seguro para que no se roben los datos de su tarjeta de crédito, pero como desarrolladores, debe demostrar que está al día «.
Señalando los requisitos de PCI DSS, Williams señaló que hay cinco de los 12 requisitos que cubren el software, y con respecto a la versión tres, que presenta más énfasis en las pruebas, dijo que esto no se hace correctamente.
“Tengo más confianza en que los desarrolladores lo hagan correctamente que en que lo demuestren. El requisito 6.3 dice «Desarrollar aplicaciones de software de acuerdo con PCI DSS y basadas en las mejores prácticas de la industria e incorporar seguridad de la información durante todo el ciclo de vida del desarrollo de software», pero ¿por qué el ciclo de vida del desarrollo de software es tan bajo? ¿Qué es el cifrado fuerte? Si escribió una solicitud el año pasado, es probable que ahora esté desactualizada «.
También destacó el requisito 8, secciones 3, 4 y 5, y el requisito 10, secciones 2, 3 y 5, así como el requisito 6.4 sobre “procesos de cambio de componentes del sistema”. Williams dijo que los sitios web a menudo se construyen y prueban y, si fallan, lo arregla. “Se vuelve a probar un año después y los problemas vuelven, ya que las fallas están en el sistema de desarrollo y no en el código, por lo que con un sistema robusto para el control de cambios eso no debería ocurrir”, dijo.
“6.5 aborda las vulnerabilidades comunes de codificación y capacita a los desarrolladores en técnicas de codificación segura. ¿Puede demostrar que conoce la programación segura? ¿Desarrolla aplicaciones dentro de las pautas de codificación segura? «
Williams dijo que quienes lo hacían bien estaban incorporando la seguridad y preguntó cómo se está capacitando a los desarrolladores, y ¿podría demostrarle a un QSA que sus desarrolladores han sido capacitados? “El QSA debería querer estar convencido de que usted está haciendo las cosas bien y también buscarán competencia, como ¿hicieron los desarrolladores un curso? ¿Hiciste un ciclo de desarrollo continuo y mantuviste el conocimiento de la seguridad? A veces, los cambios deben ocurrir rápidamente, pero con procesos de diseño. También asegúrese de no sufrir vulnerabilidades conocidas
ities. «
En conclusión, Williams señaló que, en términos de aplicaciones seguras y una auditoría QSA, se trata de proporcionar documentación de que ha cumplido con ese requisito, que se siguen los procedimientos y políticas y que las personas que escriben las aplicaciones están informadas y actualizadas.
Dijo: «El problema surge en el lado de la evidencia, y si demuestra en una auditoría anual que se han realizado buenas prácticas durante todo el año, ¿puede o cómo demostrará que sus desarrolladores están siguiendo las mejores prácticas?»
Asistí a varias charlas este año en el día que pasé en AppSec Europa, y me alegra decir que no vi una charla decepcionante o mala. La razón para cubrir esto en profundidad es porque pensé que el área era bastante única y significativa, y espero que este consejo valga la pena para todos aquellos que tienen la suerte de enfrentarse a las auditorías de QSA.