Las renovadas directrices del PCI Security Standards Council: ¿se desplazan lo suficiente hacia la izquierda?

Una versión de este artículo se publicó originalmente en Digital Transactions Magazine.

Este año, el PCI Security Standards Council publicó un conjunto totalmente nuevo de directrices de seguridad de software como parte de su PCI Software Security Framework. Esta actualización tiene como objetivo alinear las mejores prácticas de seguridad de software con el desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo ha cambiado este proceso con el tiempo, lo que requiere replantear los estándares de seguridad establecidos mucho antes de que la mayor parte de nuestras vidas se digitalizara rápidamente.

Esta es una prueba clara de que nuestra industria se está involucrando más estrechamente con la idea de directrices adaptables —aquellas que evolucionan con nuestras necesidades cambiantes—, así como con las demandas de un panorama de ciberseguridad que podría descontrolarse rápidamente si seguimos siendo laxos en nuestros procesos de desarrollo seguro. Naturalmente, dado que el PCI Security Standards Council actúa como organismo rector dentro de la industria bancaria y financiera (es decir, estableciendo los estándares de seguridad para el software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y puntos de venta), asumen muchos riesgos y tienen una gran motivación para reducirlos.

Si bien estos estándares ciertamente mejoran la versión anterior y ayudan a cubrir el vacío que tenemos en el desarrollo rápido e innovador de funciones que también prioriza la seguridad como parte de su evaluación de calidad general, resulta algo decepcionante descubrir que todavía nos queda un largo camino por recorrer.

No, no estoy siendo un aguafiestas con esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos mueven lo suficiente hacia la izquierda.

Seguimos obsesionados con las pruebas (y estamos probando demasiado tarde).

Un problema evidente que encontré en el PCI Security Standards Framework es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.

¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.

¿Quién tiene la envidiable posición de probar este código, ya sea con herramientas de escaneo o mediante revisión manual? Los especialistas en seguridad de aplicaciones (AppSec).

¿Qué siguen descubriendo estos especialistas? Los mismos errores que nos han plagado durante décadas. Cosas simples que sabemos cómo solucionar desde hace años: inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el Día de la Marmota para ellos. Pasan su tiempo encontrando y corrigiendo violaciones de código que los propios desarrolladores han tenido el poder de solucionar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso, especialmente ahora, en la era del desarrollo ágil donde la entrega de funciones es lo más importante y la seguridad es el Grinch que roba el proceso creativo y el triunfo de completar un proyecto.

Esta no es una evaluación negativa de ninguno de los equipos; tanto los desarrolladores como los profesionales de AppSec tienen trabajos extremadamente importantes que realizar, pero siguen estorbándose mutuamente. Esta situación solo perpetúa un ciclo de vida de desarrollo de software (SDLC) defectuoso, donde los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro que luego debe ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. AppSec apenas tiene tiempo para solucionar los problemas verdaderamente complejos porque están demasiado atrapados con los pequeños problemas recurrentes que aún podrían significar un desastre para una empresa si no se controlan.

Estamos desperdiciando tiempo, dinero y recursos al permitir que las pruebas sean la solución general para las debilidades de seguridad en el código. Y con filtraciones de datos masivas cada dos días, este método obviamente no está funcionando de manera óptima, si es que funciona. Estos nuevos estándares siguen evaluando un estado de producto final (quizás bajo la suposición de que todos los desarrolladores son conscientes de la seguridad, lo cual no es el caso): es decir, uno que ya está construido. Esta es la etapa más costosa y difícil para corregir fallas; es como construir una casa nueva y elegante, solo para traer a un equipo de seguridad a verificar si hay peligros el mismo día que te mudas. Si algo anda mal con los cimientos, imagina el tiempo, el costo y el dolor de cabeza absoluto que supone llegar a esa área para siquiera comenzar a abordar los problemas. A menudo es más fácil y barato simplemente empezar de nuevo (y qué proceso tan poco satisfactorio es ese para todos los que construyeron la primera versión).

Debemos trabajar absolutamente desde cero: involucrando al equipo de desarrollo con las mejores prácticas de seguridad, capacitándolos con el conocimiento para programar de forma segura y eficiente, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.

¿Es una curva de aprendizaje? Vaya que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser una tarea aburrida. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un éxito inmenso en el sector bancario y financiero, si la experiencia de Russ Wolfe en Capital One sirve de indicación.

Seguimos buscando el "estado final" perfecto.

Si observas los estándares de seguridad PCI actualizados en el contexto para el que están destinados, es decir, que tu producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para una seguridad y protección óptimas, entonces están perfectamente bien. Sin embargo, en mi opinión, todas las empresas, financieras o de otro tipo, tendrían la mejor oportunidad de alcanzar un estado final de software que represente tanto la calidad de las funciones como un alto estándar de seguridad si tan solo dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.

¿Ese estado final perfecto? Ya sabes, ¿el que ocurre cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.

¿Por qué es tan difícil de alcanzar? Hay varios factores:

• Las herramientas de escaneo son muy utilizadas, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y una pérdida de tiempo, al igual que el hecho de que, incluso combinados, los escaneos DAST/SAST/PCI no pueden identificar ni revelar todas las vulnerabilidades posibles en el código base.Quizás te den luz verde, pero ¿realmente están buscando todo? A un atacante solo le basta una vulnerabilidad para acceder a algo que crees protegido.
• Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos sobre seguridad entre ellos ni existen "recetas de código seguro" (patrones de código buenos y seguros) que sean bien conocidas y estén documentadas.
• No se pone énfasis en construir una cultura de seguridad colaborativa y positiva.
• Es necesario dotar a los desarrolladores de las herramientas adecuadas para integrar la seguridad en los productos que crean, sin interrumpir sus procesos creativos ni sus metodologías de desarrollo ágil.

Estas directrices son una lista de verificación eficaz para los estándares de seguridad que el software debería cumplir, pero el mejor proceso para lograr que el software alcance ese estado sigue siendo objeto de debate.

El software no es inseguro por falta de escáneres, sino porque los desarrolladores no cuentan con herramientas de seguridad fáciles de usar y entender que los guíen.

Estamos en una época de evolución. Durante muchos años, la seguridad del software fue opcional. Hoy en día, es prácticamente obligatoria, especialmente para quienes custodian información sensible (finanzas, salud, seguridad social... ya entiendes la idea).

El PCI Security Standards Council ayuda a establecer el estándar, pero me encantaría ver que, con todo su prestigio e influencia en la industria, trabajen para incluir directrices prácticas para desarrolladores, haciendo hincapié en una formación y herramientas adecuadas y positivas. Actualmente, no hay presión para que las organizaciones aseguren que sus equipos de desarrollo sean conscientes de la seguridad y cumplan con las normas, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de corregir, cuando son explotados por quienes buscan hacer daño.

Como ocurre con todo lo que vale la pena en la vida, hace falta toda una comunidad para lograr un cambio real. Y el cambio que se respira en el ambiente (con suerte) nos llevará a todos más hacia la izquierda.