Tiempo de leer: 8 minutosEl 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:
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.
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
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
La reparación de defectos después del 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:
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 de 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.
Esta publicación no entra en detalles sobre cada uno de estos estándares de codificación pero existe una considerable cantidad 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. A continuación, se muestran algunos ejemplos de estándares de codificación establecidos para la seguridad y la protecció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. Lo que 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.
Investigue muestra que la eliminación inadecuada de defectos es la principal causa de software de mala calidad. Los programadores son aproximadamente un 35% eficientes en la búsqueda de defectos en su propio software. Más adelante en el ciclo de desarrollo, la mayoría de los defectos que podemos esperar eliminar después de todas las revisiones de diseño, revisiones por pares, pruebas unitarias y pruebas funcionales es de aproximadamente el 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.
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.
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.
Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.
