Primeros pasos para adoptar estándares de codificación segura integrados

Existen muchas prácticas y estándares de codificación centrados en la seguridad (es decir, CERT, OWASP, CWE, MISRA, AUTOSAR y toda una familia de estándares basados ​​en IEC 61508). ¿Cómo determina el conjunto de estándares de codificación que se aplicarán a su proyecto específico? Esta guía lo iniciará en su camino.

El software sigue siendo cada vez más integral en nuestra vida diaria. Los dispositivos cotidianos tienen software, como automóviles, teléfonos, refrigeradores, relojes, dispositivos médicos o aviones. Y las organizaciones en las que confiamos, desde un banco o una compañía de seguros hasta una planta de energía o un sistema de control de tráfico, dependen de un software confiable. La existencia de este software nos brinda muchas oportunidades: vivir en hogares inteligentes, conducir automóviles inteligentes y nuestros teléfonos inteligentes y relojes inteligentes nos ayudan con todo lo que necesitamos, y a medida que más y más de estos elementos se conectan entre sí, podemos agregar beneficios adicionales. y eficiencias, haciendo nuestras vidas mucho más fáciles.

Pero todo esto conlleva un riesgo. Los agujeros de seguridad del software se pueden aprovechar para obtener acceso sin privilegios a cualquier sistema. Esto puede significar trucos simples como apagar nuestras luces cuando no lo esperamos, o ataques más alarmantes, como espiarnos con nuestras cámaras o vaciar nuestras cuentas bancarias sin nuestro conocimiento o permiso. Y los errores de software que dan como resultado un comportamiento no deseado de una aplicación también pueden causar problemas similares, incluso sin la participación de un ciberdelincuente. Por estas razones, la seguridad del software se está convirtiendo cada vez más en una prioridad para los ciudadanos de todo el mundo.

Codificación segura: de CVE a CWE Top 25

En 1999, MITRE Corporation (una organización estadounidense sin fines de lucro que opera centros de investigación y desarrollo patrocinados por el gobierno federal) comenzó a documentar vulnerabilidades de seguridad de software conocidas en la lista Common Vulnerabilities and Exposures (CVE). La lista inicial constaba de 321 entradas CVE, pero creció rápidamente, y actualmente (a septiembre de 2018), la lista CVE contiene más de 100,000 entradas y es mantenida por 92 Autoridades de Numeración CVE (CNA), diferentes organizaciones de todo el mundo ( investigadores de vulnerabilidades, proveedores de productos y programas de recompensas por errores) que están autorizados para asignar ID de CVE a los problemas detectados. La lista es muy utilizada y recomendada por el Instituto Nacional de Estándares y Tecnología (NIST), la Agencia de Sistemas de Información de Defensa de los Estados Unidos (DISA) y muchos más.

La Corporación MITRE quería facilitar la comprensión de las raíces de los problemas más comunes y tomar las acciones adecuadas para evitar problemas similares en el futuro, por lo que categorizaron las entradas de CVE en grupos según el tipo de problema, lo que terminó con la publicación de el documento Lista preliminar de ejemplos de vulnerabilidad para investigadores (PLOVER). La combinación de este trabajo con otras investigaciones dio como resultado la definición de la lista Common Weakness Enumeration (CWE), que es una lista formal de tipos de debilidades de software. Actualmente, la versión 3.1 de la lista CWE contiene alrededor de 800 tipos de debilidades agrupadas en 300 categorías y vistas. Dado que este número puede ser abrumador, el CWE, junto con el Instituto SANS, mantiene la lista de los "25 errores de software más peligrosos" para mantener los errores más extendidos y críticos que pueden conducir a vulnerabilidades graves en el software. La parte superior de la lista actual de los "25 principales", por ejemplo, incluye inyecciones de SQL, inyecciones de comandos del sistema operativo, desbordamientos de búfer y secuencias de comandos entre sitios.

Estándares de seguridad funcional

Para las industrias en las que la seguridad es mucho más importante que en otras (es decir, sistemas aerotransportados, automotrices o de salud frente a la televisión u otros sistemas de entretenimiento), la Comisión Electrotécnica Internacional (IEC) desarrolló el IEC 61508: Seguridad funcional de sistemas eléctricos / electrónicos / electrónicos programables relacionados con la seguridad. IEC 61508 es un estándar de uso general utilizado en una variedad de industrias, pero aquí también hay estándares dedicados para industrias específicas, por ejemplo:

• Aerotransportado: DO-178C / ED-12C
• Automotriz: ISO 26262
• Ferrocarril: IEC 62279 / EN 50128
• Plantas de energía nuclear: IEC 61513

Estos estándares consideran aspectos específicos de un dominio dado, pero su idea general, al menos desde el punto de vista del software, es bastante similar. Todos ellos requieren (entre otras técnicas de verificación) que se realice un análisis estático en el código desarrollado y proporcionan algunas pautas de alto nivel sobre lo que se debe hacer, dejando mucho espacio para la interpretación. Por lo general, no mencionan convenciones de codificación específicas o estándares de codificación que se utilizarán, pero, por ejemplo, ISO 26262 menciona MISRA C como un ejemplo de una guía de codificación para el lenguaje de programación C.

Estándares de codificación (seguros)

Escribir código seguro significa escribir código que no será vulnerable, es decir, código que no contenga debilidades que puedan potencialmente ser explotadas. Significa escribir código que cumpla con algunos patrones "seguros" y el código que evita patrones "inseguros". Y estos patrones serán diferentes para diferentes lenguajes de programación. Por supuesto, no existe un único conjunto de reglas de oro que puedan seguirse para garantizar la seguridad del software. Algunos de los estándares de codificación más utilizados que consideran la seguridad son:

• Para lenguaje C: Estándar de codificación MISRA C, SEI CERT C
• Para lenguaje C ++: MISRA C ++, Estándar de codificación JSF AV C ++, Estándar de codificación SEI CERT C ++, Directrices de codificación AUTOSAR C ++

Los estándares MISRA C y MISRA C ++ son desarrollados por Motor Industry Software Reliability Association (MISRA). Las pautas de codificación AUTOSAR C ++ son desarrolladas por la asociación de desarrollo AUTOSAR (AUTomotive Open System ARchitecture). El estándar de codificación JSF AV C ++ fue desarrollado por Lockheed Martin Corporation. Los estándares de codificación SEI CERT C y C ++ contienen reglas generales destinadas a garantizar la seguridad, confiabilidad y seguridad de los sistemas de software desarrollados en los lenguajes de programación C y C ++.

Las reglas en estos estándares generalmente se agrupan en varias categorías para permitir una navegación más fácil, ya que el número de reglas en un estándar dado puede ser bastante grande, por ejemplo:

• MISRA C 2012 tiene 173 pautas, con 156 reglas y 17 directivas
• CERT C tiene 307 pautas, con 121 reglas y 186 recomendaciones
• AUTOSAR tiene 344 pautas, de las cuales 319 son obligatorias y 25 de "asesoramiento"
• CERT C ++ tiene 163 pautas, con 83 reglas C ++ y 80 reglas C relevantes

Teniendo en cuenta el número de diferentes estándares de seguridad funcional, estándares de codificación y el número de pautas recomendadas o requeridas por cada estándar, es importante tomar buenas decisiones al iniciar la iniciativa de hacer que el código sea seguro.

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

Cómo elegir el estándar de codificación correcto

Si el software necesita ser certificado de acuerdo con un estándar de seguridad funcional específico (por ejemplo, ISO 26262 para automoción o DO-178C para aerotransportado), la decisión inicial ya está tomada. Pero independientemente, se debe hacer una elección para determinar el estándar de codificación, los estándares o un subconjunto de un estándar que se aplicará al software desarrollado. Puede, pero no tiene que ser uno de los estándares mencionados anteriormente.

A continuación, se debe elegir una herramienta de análisis de código estático adecuada, ya que no es posible verificar manualmente el cumplimiento de todas estas reglas. Existen herramientas de análisis estático comerciales y de código abierto disponibles. Es importante elegir uno bueno. Algunos de los factores que se deben considerar son:

• ¿La herramienta es compatible con los estándares de codificación elegidos, total o parcialmente?
• Si la calificación de la herramienta es requerida por la norma de seguridad funcional, ¿está certificada la herramienta? ¿Proporciona el kit de calificación?
• ¿Puede la herramienta producir informes de análisis en la forma requerida para realizar análisis de cumplimiento?
• ¿Puede la herramienta producir informes de análisis en un formato fácil de leer para los desarrolladores?
• ¿La herramienta se integra limpiamente con los IDE usados, los sistemas de construcción y CI?
• ¿La herramienta permite el análisis selectivo del código nuevo, el código modificado o el código heredado?
• ¿La herramienta admite una configuración flexible del análisis?
• ¿La herramienta aprovecha los algoritmos de puntuación de riesgo para ayudar a priorizar los defectos encontrados?

Además, la Comunidad CWE impulsa el Programa de Compatibilidad y Efectividad de CWE, que es un proceso formal de revisión y evaluación de un producto o servicio. La lista de productos y servicios “oficialmente compatibles con CWE” contiene actualmente 55 entradas. El uso de la herramienta de esta lista asegura que ha alcanzado la etapa final del Programa de compatibilidad CWE formal de MITRE.

Cuando se eligen el estándar de codificación y la herramienta adecuada, para los proyectos de software que se inician desde cero, el trabajo adicional debería ser fácil: simplemente integre la herramienta con el sistema CI y asegúrese de que no quede ningún defecto desatendido. Pero por lo general, el estándar de codificación debe aplicarse en el software que ya está en desarrollo.

En tales casos, la ejecución ciega del análisis en toda la base del código puede producir cientos de defectos que son difíciles de manejar todos juntos. Afortunadamente, existen múltiples técnicas que se pueden utilizar para facilitar el proceso. Por ejemplo, puede centrarse primero en el código recién escrito o modificado, para asegurarse de que al menos no se introduzcan nuevos defectos desde el momento en que se ha establecido el estándar de codificación.

Otra buena práctica es priorizar los defectos notificados para asegurarse de que los más graves se manejen en primer lugar. Por ejemplo, las reglas CERT C y C ++ tienen una evaluación de riesgos asociada, lo que permite priorizar fácilmente los defectos encontrados.

Una herramienta sofisticada de análisis estático también puede ayudarlo a concentrarse primero en las reglas con la mayor gravedad, aumentando la cantidad de reglas a las que está atendiendo a medida que se solucionan los defectos más graves.

Conclusión

La parte más importante es asegurarse de que el análisis sea seguido por las acciones apropiadas tomadas por el equipo de desarrollo. No importa qué tan buenos sean los informes del análisis estático si los desarrolladores no los utilizan para corregir el código, lo que genera productos de software más seguros. Tomarse el tiempo para elegir la solución de análisis estática y los estándares de codificación correctos lo iniciará en el camino hacia el éxito.

Por Michał Rozenau

Michał es un ingeniero jefe de proyectos en Parasoft, especializado en aplicar los productos de Parasoft para su uso en aplicaciones relacionadas con la seguridad. Michał impulsa el desarrollo del motor de análisis estático utilizado por la solución de pruebas de desarrollo de Parasoft.