Las renovadas directrices del Consejo de Normas de Seguridad de la ICP: ¿Se desplazan lo suficientemente a la izquierda?

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

Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.

Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.

Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.

No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.

Seguían obsesionados con las pruebas (y las hacían demasiado tarde).

Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI 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 poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.

¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar 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 características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.

No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.

Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).

Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.

¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. 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 inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.

Todavía estamos buscando el "estado final" perfecto.

Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente 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 del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si 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 sabe, ¿el que se produce 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:

• Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
• Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
• No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
• Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.

Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.

No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.

Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).

El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.

Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.