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" de Internet de las cosas (IoT) tienen cada vez más lógica. Con él, un mayor riesgo de falla. Muchos de estos dispositivos se utilizan en áreas críticas para la seguridad, como la médica y la automotriz, donde pueden 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 los ingenieros de software del título, pero ese no es necesariamente el término adecuado para describir cómo están trabajando hoy. La evolución hacia una buena práctica de ingeniería de software da como resultado una disminución de los costos y un aumento de la calidad. Una parte clave de esto es la adopción de estándares, en particular, estándares de codificación.

La era del automóvil conectado, el IoT y los dispositivos conectados perpetuamente 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”, Por Edsger W Dijkstra. Todavía es muy relevante hoy.

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".

Figura 1: Calidad del software 2011: una encuesta sobre el estado del arte en software - Capers Jones

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 económico: unos minutos del tiempo del desarrollador, por ejemplo. 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 reparar defectos en cada etapa de desarrollo:

Figura 2: Fuentes: medición de software aplicada, Capers Jones, 1996, Building Security into The Software Life Cycle, Marco M. Morana, 2006

Reparar los defectos posteriores al lanzamiento cuesta alrededor de $ 16,000 (posiblemente mucho más) según la investigación de empresas reales que hacen software real, no un modelo teórico. Si nos fijamos en los esfuerzos de seguridad y calidad del ciclo tardío, 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 caro que encontrar vulnerabilidades a través de pruebas en comparación con auditorías de seguridad tempranas.

Un enfoque obsoleto y demostrablemente 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 sigo en lugar de comprender 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 las normas son la forma de construir un producto seguro a la primera. Un desarrollador de software piensa que los estándares son una restricción que los está ralentizando ... un "falso positivo".
• 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 probadas que conduzcan a un código seguro, confiable, comprobable y mantenible. Por lo general, esto significa evitar las prácticas de codificación inseguras conocidas o el código que puede 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, estos estándares están siendo adoptados en muchas industrias. Estos son algunos ejemplos de estándares de codificación establecidos para seguridad y protección.

• MISRA C / C ++: Desarrollado por la 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, su uso creció en otras aplicaciones críticas para la seguridad. “MISRA”, “MISRA C” y el logotipo del triángulo 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 MISRA C, que mencioné no solo para aplicaciones de automóviles. Sin embargo, es un estándar que se utiliza desde 1998 y está bien definido. Se actualiza cada dos 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 tecnología que puede detectar violaciones a 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 mediante herramientas) y cuáles no. Esto nos lleva al tema de la adopción y cumplimiento 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, tal vez con una herramienta de seguridad de aplicación dinámica (DAST). Este es un golpe de suerte ya que su prueba simplemente ejecutó 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 análisis de flujo también puede 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 a escribir código que no conducirá 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, medir el peso del último camión exitoso y construirlo nuevamente para soportar ese nuevo peso. Este enfoque sería tonto todavía, 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 ++, Java y C # y VB.NET con una rica biblioteca de verificadores para todos los estándares de seguridad integrados.