Una onza de prevención: seguridad y protección a través de estándares de codificación de software

El software pasó del escritorio a casi todo lo que tocamos. Desde termostatos inteligentes hasta bombas de infusión y automóviles, el software es omnipresente y está creciendo. Las llamadas “cosas” del Internet de las cosas (IoT) cada vez llevan más lógica. Con ello, un mayor riesgo de fracaso. Muchos de estos dispositivos se utilizan en áreas críticas para la seguridad, como la médica y la automotriz, donde tienen el potencial de causar daños corporales.

La mayoría de las empresas que fabrican dispositivos ven con razón el desarrollo de software actual como un grupo casi loco de vaqueros y caos. Pero hay esperanza. El software PUEDE y DEBE ser tratado como una práctica de ingeniería. Los estándares de codificación, que son parte integral de las buenas prácticas de ingeniería de software, nos mueven del ciclo de “construir, fallar, arreglar” a un ciclo de “diseñar, construir, entregar” con alta calidad, seguridad y protección.

Resulta que estos mismos estándares también brindan beneficios en las áreas de ciberseguridad, cumpliendo una doble función. Esta publicación analiza:

• Cómo estos estándares nos ayudan a pasar de encontrar defectos a desarrollar software más robusto.
• Cómo prevenir problemas en primer lugar con una codificación adecuada.
• Cómo aprovechar los esfuerzos de otros mediante el uso de estándares de la industria comúnmente aceptados, como MISRA, para lograr este objetivo.

Desde el desarrollo de software hasta la ingeniería de software

El impacto del software en el mundo real a menudo se descarta. Uno de mis temas principales que discuto continuamente como evangelista en Parasoft, es que el desarrollo de software realmente debería ser ingeniería.

Con frecuencia llamamos a los desarrolladores de software por el título de ingenieros de software, pero ese no es necesariamente el término adecuado para la forma en que trabajan hoy. Evolucionar hacia una buena práctica de ingeniería de software da como resultado que los costos bajen y la calidad aumente. Una parte clave de esto es la adopción de estándares, en particular, estándares de codificación.

La era de los vehículos definidos por software, el IoT médico e industrial y los dispositivos permanentemente conectados está aquí. El software se está infiltrando en productos, dispositivos y otros lugares en los que nunca pensamos. Ahora debemos pensar mucho en el software de estos productos y sus ramificaciones.

El costo de la mala calidad

Una de las cosas interesantes que trato de explicar es que construir un buen software es diferente a construir algo como un automóvil. Si estoy tratando de construir un automóvil de alta calidad, debo gastar más en materiales y más tiempo para construirlo. Resulta que en software, no se gasta más para crear software de alta calidad. Gasta más para crear software de baja calidad.

Debemos entender que en el software, la mayoría de los defectos provienen del programador, quien los coloca en el producto. Si podemos dejar de introducir defectos a medida que desarrollamos el software, podemos tener un software mucho mejor, a un precio más bajo.

Esta cita aquí es de una charla en 1972, llamada "El humilde programador”, escrito por Edsger W Dijkstra. Todavía es muy relevante hoy en día.

Es importante darse cuenta de cómo la calidad afecta los costos de desarrollo de software. Alcaparras jones, un investigador, ha estado siguiendo esto durante décadas y realiza una encuesta cada año sobre los costos de software. Los números no cambian mucho de un año a otro. Los datos muestran que el costo típico del software, desde los requisitos hasta la codificación y el mantenimiento, aumenta con cada fase. Sin embargo, la forma en que los equipos abordan la calidad determina si su proceso es saludable o "patológico".

Por qué necesitamos reparar los defectos de manera temprana

Tiene sentido que si encontramos un defecto justo cuando se escribe el código, el costo es relativamente bajo, por ejemplo, unos minutos del tiempo de un desarrollador. Si es posible eliminar el 85% de los defectos en la fase de desarrollo, hay un gran impacto en el costo. Considere el ahora famoso gráfico de Capers Jones que muestra el costo promedio de corregir defectos en cada etapa de desarrollo:

La reparación de defectos posteriores al lanzamiento cuesta alrededor de $ 16,000 (posiblemente mucho más) según la investigación de compañías reales que fabrican software real, no un modelo teórico. Si observamos los esfuerzos de calidad y seguridad del último ciclo, como las pruebas de penetración, los problemas de seguridad que se encuentran aquí se encuentran en el extremo costoso del ciclo. Probablemente sea 15 veces más costoso que encontrar vulnerabilidades a través de pruebas versus auditorías de seguridad tempranas.

Un enfoque obsoleto y probablemente falso es mejorar la calidad de su software probándolo al final del ciclo de vida, justo antes del lanzamiento. En el mundo de la fabricación, entienden que esto es imposible, pero por alguna razón, creemos que podemos probar la calidad y la seguridad "en" el software.

Las razones por las que digo que el desarrollo de software casi nunca es ingeniería son estas características comunes del desarrollo de software actual:

• Lo que hacen la mayoría de los desarrolladores no es repetible. Es decir, si le doy la misma tarea a dos personas diferentes, los resultados no serán los mismos.
• Falta de buenas prácticas bien ejercidas. Los desarrolladores de software ven los estándares de codificación como una palabra que tiene poco significado. Los estándares se consideran un conjunto de reglas que el líder del equipo insiste en que siga en lugar de entender que el estándar de codificación es la encarnación del conocimiento, la práctica y la experiencia. Un ingeniero eléctrico sabe que los estándares son la forma de construir un producto seguro la primera vez. Un desarrollador de software piensa que los estándares son una restricción que los está ralentizando… un “falsos positivos."
• La formación de los desarrolladores es desconocida e incoherente. La educación en desarrollo de software no está estandarizada como lo está con las disciplinas de ingeniería. Los estándares y las prácticas establecidas a menudo no forman parte del plan de estudios, sino que el énfasis está en los lenguajes de programación.

Los estándares de codificación mejoran la seguridad y la protección

El objetivo de los estándares de codificación de software es inculcar prácticas de programación comprobadas que conduzcan a un código seguro, confiable, comprobable y mantenible. Por lo general, esto significa evitar prácticas de codificación no seguras conocidas o código que pueda causar un comportamiento impredecible. Esto se vuelve crítico en lenguajes de programación como C y C++ donde el potencial para escribir código inseguro o inseguro es alto.

Sin embargo, creo que la industria ha perdido el rumbo con estos estándares de programación. En la última década, las herramientas (como las herramientas de análisis estático) han pasado de detectar código potencialmente problemático que es inseguro o una debilidad conocida del lenguaje a centrarse en buscar defectos como una forma de prueba temprana, también conocida como desplazamiento a la izquierda.

Aunque buscar defectos es importante, crear software de sonido es una actividad más productiva. Lo que deberíamos estar haciendo es construir y hacer cumplir los estándares para evitar la situación en la que se introducen defectos en primer lugar, desplazándose aún más hacia la izquierda.

Para respaldar esto, considere la la investigación realizado por el Instituto de Ingeniería de Software (SEI) donde encontraron, como era de esperar, que la seguridad y la confiabilidad van de la mano y que la seguridad del software se puede predecir por el número y los tipos de defectos de calidad encontrados. Además, los defectos críticos suelen ser errores de codificación que se pueden prevenir mediante inspecciones y herramientas como el análisis estático.

Estándares de la industria

Esta publicación no entra en detalles sobre cada uno de estos estándares de codificación, pero hay una cantidad considerable de trabajo en los siguientes estándares de la industria. Aunque su aplicación puede ser específica para un tipo específico, estas normas se están adoptando en muchas industrias. Estos son algunos ejemplos de estándares de codificación establecidos para la seguridad y la protección.

• MISRA C/C++. Desarrollado por Motor Industry Software Reliability Association, describe un subconjunto del lenguaje C o C++ y las pautas para su uso para mejorar la seguridad de la aplicación. Aunque originalmente estaba destinado a aplicaciones automotrices, se usa en todas las industrias, particularmente para aplicaciones críticas para la seguridad. “MISRA”, “MISRA C” y el logotipo triangular son marcas comerciales registradas de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Todos los derechos reservados.
• SEI / SANS CERT. El Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI) tiene un conjunto de pautas para ayudar a los desarrolladores a crear software más seguro y confiable. Las pautas se dividen en importancia por grupos de "reglas" y "recomendaciones" y son muy completas y amplias e incluyen metadatos de riesgo.
• OWASP Top 10. El Open Web Application Security Project (OWASP), como su nombre lo indica, es una organización que se compromete a mejorar la seguridad de las aplicaciones web. Como tal, su proyecto OWASP Top 10 proporciona una lista de las vulnerabilidades de seguridad de aplicaciones web más comunes y de mayor impacto. La última versión de OWASP Top 10 está directamente correlacionada con ID de CWE específicos e incluye metadatos de riesgo.
• Estándar de codificación C ++ de vehículos aéreos de combate de ataque conjunto (JSF AV). Un estándar basado en un subconjunto de MISRA C específicamente para el programa JSF.
• CWE - Top 25 de enumeración de debilidades comunes. CWE es una lista de debilidades de software descubiertas basada en el análisis de vulnerabilidades reportadas (CVE). El Top 25 enumera las debilidades de seguridad más comunes y peligrosas seleccionadas de la lista más grande de CWE, que son todos exploits que tienen una alta probabilidad de ocurrir y el impacto de explotar la debilidad es grande. CWE también incluye información sobre riesgos en forma de impacto técnico, lo que ayuda a comprender qué problemas son más importantes para su organización.

Consideremos MIRA C, que mencioné no es solo para aplicaciones de automóviles. Sin embargo, es un estándar que ha estado en uso desde 1998 y está bien definido. Se actualiza cada par de años que lo revisan. A medida que evolucionan los lenguajes C y C++, evolucionan los estándares a su alrededor. Es un estándar muy flexible que tiene en cuenta diferentes niveles de gravedad y existe una estrategia documentada para manejar y documentar las desviaciones.

Como la tecnología que puede detectar violaciones de las pautas estándar de codificación, como el análisis estático, las versiones recientes de MISRA tienen en cuenta qué pautas son decidibles (detectables con alta precisión por herramientas) y cuáles no. Esto nos lleva al tema de la adopción y aplicación y la importancia de las herramientas de análisis estático en los estándares de codificación.

Papel del análisis estático

Las investigaciones muestran que la eliminación inadecuada de defectos es la principal causa de la mala calidad del software. Los programadores son aproximadamente un 35% eficientes en encontrar defectos en su propio software. Más adelante en el ciclo de desarrollo, la mayoría de los defectos que podemos aspirar a eliminar después de todas las revisiones de diseño, revisiones por pares, pruebas unitarias y pruebas funcionales es de alrededor del 75 %.

El análisis estático, cuando se usa correctamente en un modo preventivo, puede aumentar la eliminación de defectos hasta aproximadamente un 85%. Sin embargo, el enfoque del uso del análisis estático para la mayoría de las organizaciones hoy en día es la detección y la solución rápida.

Son posibles más beneficios cuando se utilizan herramientas de análisis estático para prevenir prácticas de programación deficientes conocidas y características del lenguaje en primer lugar. Aquí es donde los estándares de codificación entran en juego como pautas y subconjuntos de lenguajes de programación que evitan que los defectos comunes como desbordamientos de búfer o falta de inicialización se escriban en el código.

Una onza de prevención

Considere un ejemplo en el que durante la prueba se detecta un error de desbordamiento de búfer bastante complejo, quizás con una herramienta de seguridad de aplicaciones dinámicas (DAST). Este es un golpe de suerte ya que su prueba acaba de ejecutar la ruta del código que contiene el error. Una vez detectado y depurado, debe volver a probarse, y así sucesivamente. El análisis estático mediante el análisis de flujo también podría haber encontrado este error, pero depende de la complejidad de la aplicación.

La detección de errores en tiempo de ejecución es precisa, pero solo verifica las líneas de código que ejecuta. Por lo tanto, es tan bueno como la cobertura de su código de prueba. Considere si un estándar de codificación había prohibido el código que habilitó este error en primer lugar.

Los estándares de codificación como MISRA C no describen cómo detectar la memoria no inicializada, por ejemplo, sino que guían a los programadores para escribir código que no conduzca a tal error en primer lugar. Creo que esto es mucho más un enfoque de ingeniería: programa de acuerdo con estándares bien conocidos y aceptados. Tomemos, por ejemplo, la ingeniería civil y la construcción de puentes.

No tomaríamos el enfoque de construir un puente y luego probarlo conduciendo camiones cada vez más grandes sobre él hasta que colapsara, midiendo el peso del último camión exitoso y construyéndolo de nuevo para soportar ese nuevo peso. Este enfoque sería una tontería aún, no es diferente a la forma en que abordamos el desarrollo de software.

Una vez que un equipo de software adopta un estándar de codificación y el análisis estático se aplica correctamente, puede detectar errores con anticipación y prevenirlos. En otras palabras, en lugar de encontrar un defecto temprano, lo cual es bueno, el equipo está cambiando la forma en que escriben el código, ¡lo cual es mejor!

Considere el gráfico heartbleed vulnerabilidad. Ahora hay detectores para esta instancia específica de vulnerabilidad, pero hay una forma de escribir código para que Heartbleed nunca haya sucedido en primer lugar. La prevención es un método mejor y más seguro.

Resumen

Dykstra dijo: "Aquellos que quieran un software realmente confiable descubrirán que deben encontrar la manera de evitar la mayoría de los errores para empezar". Tener una metodología de prevención sólida es menor que el costo de corregir estos errores.

Los estándares de codificación incorporan principios de ingeniería sólidos para la programación en sus respectivos lenguajes y forman la base de cualquier enfoque preventivo. El costo de un buen software es menor que el costo de un software malo. Si no está utilizando el análisis estático en la actualidad, o solo lo está utilizando para la detección temprana, eche un vistazo a las herramientas de análisis estático de Parasoft para C y C ++, Javay C # y VB.NET con una rica biblioteca de verificadores para todos los estándares de seguridad integrados.