Cómo mejorar la seguridad de las aplicaciones mediante ciclos de retroalimentación

Mejorar la seguridad de las aplicaciones para la mayoría de las organizaciones significa implementar más del ciclo de vida de desarrollo de software seguro (SDLC seguro). ¿Qué puede hacer una vez que haya implementado todo? ¿O qué puede hacer para mejorar lo que ya tiene? Una forma sería medir cómo está funcionando todo actualmente y luego hacer cambios, medir y continuar.

El problema con este método es que las métricas de seguridad de la aplicación pueden ser difíciles por varias razones. El uso de la cantidad de vulnerabilidades encontradas y reparadas no tiene en cuenta la gravedad de cada vulnerabilidad. Incluso si tiene en cuenta la gravedad, ¿por qué está disminuyendo la cantidad de vulnerabilidades? ¿Está empeorando en encontrarlos o está mejor previniéndolos? Es muy difícil saber qué está sucediendo mediante el seguimiento de métricas básicas en la seguridad de las aplicaciones.

¿Qué son los bucles de retroalimentación en AppSec?

Una forma de mejorar la seguridad de las aplicaciones (AppSec) sin tener métricas perfectas es crear un ciclo de retroalimentación. Los ciclos de retroalimentación son simples: brinde a las personas acceso a la información en tiempo real y bríndeles la oportunidad de cambiar. Se han realizado muchos estudios que muestran la efectividad de los circuitos de retroalimentación y cómo ayudan a cambiar el comportamiento humano. Los bucles de retroalimentación se pueden utilizar en la seguridad de las aplicaciones para ayudar a mejorar el código cambiando el comportamiento del desarrollador.

Los bucles de retroalimentación tienen cuatro etapas:

1. Evidencia: un comportamiento se mide y se captura
2. Relevancia: el comportamiento se le da a la persona en un contexto que lo hace resonar
3. Consecuencias: la persona comprende cómo el comportamiento puede conducir a resultados negativos.
4. Acción: la persona debe tomar una acción clara basada en los datos.

Después de la acción, se recopilan más datos y el ciclo de retroalimentación comienza de nuevo.

Cómo usar los bucles de retroalimentación de manera efectiva

Un ejemplo de un circuito de retroalimentación es cuando se agrega una pantalla de velocidad dinámica junto a las señales de límite de velocidad. La velocidad de un automóvil se le da al usuario (evidencia) justo al lado del límite de velocidad legal (relevancia). A las personas se les recuerdan las desventajas del exceso de velocidad, como multas o accidentes (consecuencias), y la mayoría de los conductores reducen la velocidad (acción) debido a esto. No solo eso, sino que los conductores reducen la velocidad en promedio un 10% durante varias millas más allá de la señal. Este circuito de retroalimentación es efectivo para obtener el resultado deseado y hacer que las personas cambien su comportamiento.

Los bucles de retroalimentación se pueden aprovechar en la seguridad de las aplicaciones para ayudar a obtener el resultado deseado de un código más seguro y menos vulnerabilidades. Una forma de hacerlo es aprovechando una herramienta de prueba de seguridad de aplicaciones estáticas (SAST), como Parasoft, tomando los datos de vulnerabilidad de la herramienta y proporcionándolos al desarrollador que escribió el código junto con la gravedad y el impacto potencial de la vulnerabilidad. Los desarrolladores ven los errores de seguridad que han cometido en contexto y se dan cuenta del impacto potencial de las vulnerabilidades. A continuación, los desarrolladores corrigen los errores relevantes y toman la capacitación de codificación segura relevante basada en las vulnerabilidades que se han encontrado utilizando una plataforma como HackEDU para asegurarse de corregir la vulnerabilidad correctamente. Los desarrolladores mejoran en la escritura de código seguro porque están aprendiendo acerca de los errores que han cometido después de ver las consecuencias. El ciclo de retroalimentación continúa junto con el ciclo de vida del desarrollo de software seguro y el resultado es un código más seguro.

El ciclo de retroalimentación que esto crea es:

1. Evidencia: los desarrolladores reciben los problemas de seguridad que crearon
2. Relevancia: los desarrolladores ven la gravedad de las vulnerabilidades que se encuentran en el código que escribieron
3. Consecuencias: los desarrolladores se dan cuenta de los posibles riesgos y el impacto en función de las vulnerabilidades y la gravedad
4. Acción: los desarrolladores solucionan los problemas y reciben capacitación en función de los problemas de seguridad específicos que han realizado.

Este circuito de retroalimentación ayuda a cambiar el comportamiento de los desarrolladores y comienza a reducir el riesgo de vulnerabilidades en el software. Los desarrolladores mejoran su capacidad para escribir código seguro, se vuelven más conscientes de los problemas potenciales en el código y comprenden las consecuencias de no escribir código seguro.

Uso de bucles de retroalimentación con SCA y estándares de codificación

Hay otras áreas de la seguridad de las aplicaciones que también pueden usar bucles de retroalimentación. Todos ellos están destinados a ayudar a informar y mejorar el comportamiento de los desarrolladores de software. Por ejemplo, un área incluye proporcionar información sobre vulnerabilidades de bibliotecas de terceros a los desarrolladores con una herramienta de análisis de composición de software (SCA) como OWASP Dependency Check y responsabilizar a los desarrolladores de actualizar las bibliotecas. Los desarrolladores serán mucho más deliberados en cuanto a los paquetes de terceros que usan si incluso eligen usarlos, el costo-beneficio se traslada a los desarrolladores.

Otra área en la que se pueden utilizar circuitos de retroalimentación es en la actualización de estándares de codificación segura basados ​​en escaneos de software o revisiones de código. Un desarrollador recibe vulnerabilidades junto con la gravedad y el impacto. Si corresponde, la acción que toma el desarrollador es implementar un estándar de codificación basado en el problema encontrado. Si ya existe un estándar para el problema, o si el problema no se presta a un estándar, es posible que el desarrollador deba practicar la codificación segura en una plataforma de revisión de código como HackEDU.

Sin métricas perfectas, la seguridad de las aplicaciones aún se puede mejorar. Dado que el desarrollo de software es una actividad humana (por ahora), cambiar el comportamiento de los desarrolladores y aprovechar los ciclos de retroalimentación puede tener un efecto tremendo en la mejora de la seguridad de las aplicaciones.

Por Jared Ablón

Jared Ablon es el CEO de HackEDU, una plataforma de formación interactiva para la formación de codificación segura, probada para formar desarrolladores. Anteriormente, fue Director de Seguridad de la Información en AirMap, donde recibió el premio al Director de Seguridad de la Información (CISO) del año otorgado por LA Business Journal.