Premières étapes pour adopter des normes de codage sécurisé intégrées

Il y a tellement de pratiques et de normes de codage axées sur la sécurité (c'est-à-dire CERT, OWASP, CWE, MISRA, AUTOSAR et toute une famille de normes basées sur la CEI 61508). Comment déterminez-vous l'ensemble de normes de codage à appliquer à votre projet spécifique? Ce guide vous lancera sur votre chemin.

Les logiciels continuent de faire de plus en plus partie intégrante de notre vie quotidienne. Les appareils courants contiennent des logiciels, tels que des voitures, des téléphones, des réfrigérateurs, des montres, des appareils médicaux ou des avions. Et les organisations sur lesquelles nous comptons, d'une banque ou d'une compagnie d'assurance, à une centrale énergétique ou à un système de contrôle du trafic, dépendent toutes de logiciels fiables. L'existence de ce logiciel nous offre de nombreuses opportunités - vivre dans des maisons intelligentes, conduire des voitures intelligentes, et nos smartphones et montres intelligentes nous aidant avec tout ce dont nous avons besoin, et à mesure que de plus en plus de ces éléments se connectent les uns aux autres, nous pouvons ajouter des avantages supplémentaires. et efficacité, rendant nos vies beaucoup plus faciles.

Mais tout cela comporte un risque. Les failles de sécurité des logiciels peuvent être exploitées pour obtenir un accès sans privilège à n'importe quel système. Cela peut signifier de simples hacks comme éteindre nos lumières lorsque nous ne nous y attendons pas, ou des attaques plus alarmantes, comme nous espionner avec nos caméras, ou vider nos comptes bancaires à notre insu ou sans notre permission. Et les bogues logiciels qui entraînent un comportement indésirable d'une application peuvent également causer des problèmes similaires, même sans la participation d'un cybercriminel. Pour ces raisons, la sécurité des logiciels devient de plus en plus une priorité pour les citoyens du monde entier.

Codage sécurisé : du CVE au CWE Top 25

En 1999, MITRE Corporation (une organisation américaine à but non lucratif qui gère des centres de recherche et développement parrainés par le gouvernement fédéral) a commencé à documenter les vulnérabilités de sécurité logicielles connues sur la liste Common Vulnerabilities and Exposures (CVE). La liste initiale comprenait 321 entrées CVE, mais elle a augmenté rapidement, et actuellement (en septembre 2018), la liste CVE contient plus de 100,000 entrées et est maintenue par 92 autorités de numérotation CVE (CNA) - différentes organisations du monde entier ( chercheurs de vulnérabilités, vendeurs de produits et programmes de primes de bogues) qui sont autorisés à attribuer des ID CVE aux problèmes détectés. La liste est très largement utilisée et est recommandée par le National Institute of Standards and Technology (NIST), la US Defence Information Systems Agency (DISA) et bien d'autres.

La société MITRE souhaitait faciliter la compréhension des racines des problèmes les plus courants et prendre les mesures appropriées pour éviter des problèmes similaires à l'avenir.Elle a donc classé les entrées CVE en groupes en fonction du type de problème, qui s'est terminée par la publication de le document Liste préliminaire des exemples de vulnérabilité pour les chercheurs (PLOVER). La combinaison de ce travail avec d'autres recherches a abouti à la définition de la liste Common Weakness Enumeration (CWE), qui est une liste formelle des types de faiblesses logicielles. Actuellement, la CWE List Version 3.1 contient environ 800 types de faiblesses regroupées en 300 catégories et vues. Étant donné que ce nombre peut être écrasant, la liste des «25 erreurs logicielles les plus dangereuses» est maintenue par le CWE en collaboration avec le SANS Institute pour maintenir les erreurs les plus répandues et les plus critiques qui peuvent conduire à de graves vulnérabilités dans les logiciels. Le haut de la liste actuelle des «25 premiers», par exemple, comprend les injections SQL, les injections de commandes du système d'exploitation, les débordements de tampon et les scripts intersites.

Normes de sécurité fonctionnelle

Pour les industries dans lesquelles la sécurité est beaucoup plus importante que dans d'autres (c'est-à-dire les systèmes aéroportés, automobiles ou de santé par rapport à la télévision ou d'autres systèmes de divertissement), la Commission électrotechnique internationale (CEI) a développé le CEI 61508: Sécurité fonctionnelle des systèmes électriques / électroniques / électroniques programmables relatifs à la sécurité. La CEI 61508 est une norme à usage général utilisée dans une variété d'industries, mais voici également des normes dédiées à des industries spécifiques, par exemple:

• En vol: DO-178C / ED-12C
• Automobile: ISO 26262
• Chemin de fer: CEI 62279 / EN 50128
• Centrales nucléaires: CEI 61513

Ces normes considèrent les spécificités d'un domaine donné, mais leur idée générale - du moins du point de vue logiciel - est assez similaire. Tous nécessitent (entre autres techniques de vérification) une analyse statique du code développé et fournissent des directives de haut niveau sur ce qui doit être fait, tout en laissant beaucoup de place à l'interprétation. Ils ne mentionnent généralement pas de conventions de codage ou de normes de codage spécifiques à utiliser, mais par exemple, l'ISO 26262 mentionne MISRA C comme exemple de guide de codage pour le langage de programmation C.

Normes de codage (sécurisées)

Ecrire du code sécurisé signifie écrire du code qui ne sera pas vulnérable, c'est-à-dire du code qui ne contient pas de faiblesses potentiellement exploitables. Cela signifie écrire du code qui respecte certains modèles «sûrs» et le code qui évite les modèles «non sûrs». Et ces modèles seront différents pour différents langages de programmation. Bien entendu, il n'y a pas un ensemble unique de règles d'or qui pourraient être suivies pour garantir la sécurité du logiciel. Certaines des normes de codage largement utilisées qui tiennent compte de la sécurité sont:

• Pour le langage C: Norme de codage MISRA C, SEI CERT C
• Pour le langage C ++: MISRA C ++, norme de codage JSF AV C ++, norme de codage SEI CERT C ++, directives de codage AUTOSAR C ++

Les normes MISRA C et MISRA C ++ sont développées par la Motor Industry Software Reliability Association (MISRA). Les directives de codage AUTOSAR C ++ sont développées par le partenariat de développement AUTOSAR (AUTomotive Open System ARchitecture). La norme de codage JSF AV C ++ a été développée par Lockheed Martin Corporation. Les normes de codage SEI CERT C et C ++ contiennent des règles générales destinées à garantir la sûreté, la fiabilité et la sécurité des systèmes logiciels développés dans les langages de programmation C et C ++.

Les règles de ces normes sont généralement regroupées en plusieurs catégories pour permettre une navigation plus facile, car le nombre de règles dans une norme donnée peut être assez important, par exemple:

• MISRA C 2012 a 173 lignes directrices, avec 156 règles et 17 directives
• CERT C a 307 lignes directrices, avec 121 règles et 186 recommandations
• AUTOSAR a 344 lignes directrices, dont 319 obligatoires et 25 «consultatives»
• CERT C ++ a 163 directives, avec 83 règles C ++ et 80 règles C pertinentes

Compte tenu du nombre de normes de sécurité fonctionnelle, des normes de codage et du nombre de lignes directrices recommandées ou requises par chaque norme, il est important de faire de bons choix lors du lancement de l'initiative de sécurisation du code.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.

Comment choisir la bonne norme de codage

Si le logiciel doit être certifié selon une norme de sécurité fonctionnelle spécifique (par exemple ISO 26262 pour l'automobile ou DO-178C pour le transport aérien), la décision initiale est déjà prise. Quoi qu'il en soit, un choix doit être fait pour déterminer la ou les normes de codage, ou un sous-ensemble d'une norme à appliquer sur le logiciel développé. Il peut, mais ne doit pas être, l'une des normes mentionnées ci-dessus.

Ensuite, il faut choisir un outil d'analyse de code statique approprié, car il n'est pas possible de vérifier manuellement le respect de toutes ces règles. Il existe des outils d'analyse statique open source et commerciaux disponibles. Il est important d'en choisir un bon. Certains des facteurs qui doivent être pris en compte sont :

• L'outil prend-il en charge la ou les normes de codage choisies - entièrement / partiellement?
• Si la qualification de l'outil est exigée par la norme de sécurité fonctionnelle, l'outil est-il certifié? Fournit-il le kit de qualification?
• L'outil peut-il produire des rapports d'analyse sous la forme requise pour effectuer une analyse de conformité?
• L'outil peut-il produire des rapports d'analyse sous une forme facile à lire par les développeurs?
• L'outil s'intègre-t-il proprement aux IDE, aux systèmes de construction et d'IC ​​utilisés?
• L'outil permet-il l'analyse sélective du nouveau code, du code modifié ou du code hérité?
• L'outil prend-il en charge une configuration flexible de l'analyse?
• L'outil tire-t-il parti des algorithmes de notation des risques pour aider à hiérarchiser les défauts trouvés?

De plus, la communauté CWE dirige le programme de compatibilité et d'efficacité CWE, qui est un processus formel d'examen et d'évaluation d'un produit ou d'un service. La liste des produits et services «Officiellement compatibles CWE» contient actuellement 55 entrées. L'utilisation de l'outil de cette liste garantit qu'il a atteint la dernière étape du programme formel de compatibilité CWE de MITRE.

Lorsque la norme de codage et l'outil approprié sont choisis, pour les projets logiciels démarrés à partir de zéro, le travail supplémentaire devrait être facile - il suffit d'intégrer l'outil au système CI et de s'assurer qu'aucun défaut n'est laissé sans surveillance. Mais généralement, la norme de codage doit être appliquée au logiciel déjà en cours de développement.

Dans de tels cas, l'exécution aveugle de l'analyse sur l'ensemble de la base de code peut produire des centaines de défauts signalés, qui sont difficiles à gérer tous ensemble. Heureusement, plusieurs techniques peuvent être utilisées pour faciliter le processus. Par exemple, vous pouvez vous concentrer d'abord sur le code nouvellement écrit ou modifié, pour vous assurer qu'au moins aucun nouveau défaut n'est introduit à partir du moment où la norme de codage a été établie.

Une autre bonne pratique consiste à hiérarchiser les défauts signalés pour s'assurer que les plus graves sont traités en premier lieu. Par exemple, les règles CERT C et C ++ sont associées à une évaluation des risques, ce qui permet de hiérarchiser facilement les défauts trouvés.

Un outil d'analyse statique sophistiqué peut également vous aider à vous concentrer sur les règles les plus sévères en premier, en augmentant le nombre de règles auxquelles vous vous conformez à mesure que les défauts les plus graves sont corrigés.

Conclusion

La partie la plus importante est de s'assurer que l'analyse est suivie des actions appropriées prises par l'équipe de développement. Peu importe la qualité des rapports de l'analyse statique s'ils ne sont pas utilisés par les développeurs pour corriger le code, ce qui conduit à des produits logiciels plus sûrs et sécurisés. Prendre le temps de choisir la bonne solution d'analyse statique et les normes de codage vous mettra sur la voie du succès.

Par Michał Rozenau

Michał est un ingénieur chef de projet chez Parasoft, spécialisé dans l'application des produits Parasoft pour une utilisation dans des applications liées à la sécurité. Michał pilote le développement du moteur d'analyse statique utilisé par la solution de test de développement de Parasoft.