No construyas herramientas de seguridad; construye herramientas para desarrolladores

Esta publicación apareció originalmente en CSO Online, el 3 de noviembre de 2017.

Desde hace mucho, los líderes y proveedores de seguridad de aplicaciones persiguen el esquivo objetivo de lograr que los desarrolladores adopten la seguridad. Este interés se debe en parte al valor de integrar la seguridad desde el principio, pero la causa principal es el enorme volumen de trabajo y el ritmo acelerado. Hay 100 desarrolladores por cada profesional de seguridad, y la velocidad del desarrollo moderno hace imposible que cualquier equipo externo mantenga el paso. Y, aun así, una y otra vez no logramos alcanzar este objetivo.

Las soluciones de seguridad se integran con las herramientas de desarrollo, los requisitos de seguridad se agregan al flujo habitual de requisitos y la capacitación en seguridad se repite cada trimestre; aun así, la seguridad se olvida en cuanto el equipo de seguridad deja de participar. ¿Cómo podemos romper este ciclo?

La clave del éxito es dejar de crear herramientas de seguridad que intentan adaptarse al desarrollo y empezar a crear herramientas de desarrollo que integran la seguridad. Puede parecer una diferencia semántica, pero en realidad transforma por completo nuestra forma de ver las herramientas y los programas de seguridad.

Prioriza las necesidades de los desarrolladores

Cuando un equipo de seguridad establece un proceso, normalmente empieza por sus propias necesidades. Necesita saber qué hacen los desarrolladores, asegurarse de que se apliquen ciertos controles y exigir que se ejecuten determinadas pruebas. Es comprensible que el proceso o las herramientas se enfoquen principalmente en satisfacer las necesidades de seguridad, cumplimiento o gobernanza, así como las del propio equipo de seguridad.

Para lograr una verdadera participación de los desarrolladores, debemos considerarlos los usuarios más importantes de nuestra solución y pensar en la seguridad y el cumplimiento como funciones de apoyo. ¿Cómo ayudaría esta práctica de seguridad a reducir la probabilidad de una interrupción del servicio? ¿Cómo mejoraría la comunicación y la colaboración en el equipo? ¿Cómo permitiría que los desarrolladores con menos experiencia asumieran tareas más complejas? Si replanteas las necesidades de seguridad teniendo en cuenta los objetivos de los desarrolladores, tendrás muchas más probabilidades de satisfacerlas.

Cambia el punto de partida.

Casi siempre intentamos adaptar las prácticas de seguridad al flujo de trabajo de desarrollo. Intentamos ejecutar análisis estáticos durante el proceso de compilación y descubrimos que tardan demasiado. Aplicamos este análisis en el IDE, pero no confiamos en que los desarrolladores descarten los falsos positivos de los resultados. Alertamos sobre una vulnerabilidad conocida a un desarrollador que no tiene las herramientas necesarias para evaluarla.

Las buenas herramientas para desarrolladores parten del otro lado. ¿Cómo funciona el proceso de desarrollo? ¿En qué momento este control de seguridad aportaría más valor o sería menos intrusivo? ¿Cuáles son los requisitos clave para integrarlo correctamente en ese momento? Con las respuestas a este tipo de preguntas, podrás crear tu solución de seguridad con las prioridades adecuadas.

Estas preguntas también pueden revelar herramientas que ya existen en el flujo de trabajo y que pueden usarse en el proceso de seguridad. Por ejemplo, en distintos episodios del pódcast The Secure Developer, el equipo de seguridad de PagerDuty habló sobre el uso de Splunk con fines de seguridad, y Chef Adam Jacobs describió cómo InSpec puede ayudar a mejorar tu postura de seguridad.

Cambia los productos con los que te comparas.

Las herramientas para desarrolladores han evolucionado drásticamente en la última década, impulsadas por la revolución de DevOps y el empoderamiento de los equipos de desarrollo. A partir de las herramientas más exitosas, surgieron buenas prácticas que abarcan desde la facilidad de uso hasta los precios y la importancia de la documentación.

Así que, en lugar de comparar tu firewall de aplicaciones web con tu firewall de red, compáralo con una herramienta exitosa de APM (monitoreo del rendimiento de aplicaciones). Compara tus herramientas de pruebas de seguridad de aplicaciones con los linters y las herramientas de revisión de código, no con los escáneres de seguridad de red. Estas herramientas lograron ganarse la confianza de los desarrolladores y formar parte de sus prácticas, hasta el punto de que ahora dependen de ellas con regularidad. Si imitas su funcionamiento, encajarás fácilmente con la forma en que los desarrolladores piensan y trabajan.

Aunque mis ejemplos se centran más en las herramientas que en los procesos, el principio se aplica a ambos. Las prácticas de desarrollo seguro también se beneficiarían de poner las necesidades de los desarrolladores en el centro, partir de las metodologías de desarrollo actuales y compararse con otras prácticas y procesos que utiliza el equipo de ingeniería. Una práctica de seguridad impuesta corre el riesgo constante de pasar desapercibida; en cambio, una práctica de desarrollo, incluso si aborda la seguridad, puede integrarse de forma mucho más natural y duradera.

Para lograr que los desarrolladores se comprometan con la seguridad, no construyas herramientas de seguridad. Crea herramientas para desarrolladores que faciliten la seguridad y verás la enorme diferencia que esto puede marcar en su adopción.