Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

La sécurité des applications est un problème de qualité: 6 conseils de test pour bénéficier à la fois de la qualité et de la sécurité

Par Arthur Hicken

5 octobre 2017

4  min lire

Récemment, je lisais un article sur LinkedIn dans lequel quelqu'un avait demandé la différence entre plusieurs fournisseurs de sécurité d'analyse statique. Une personne, sans surprise un fournisseur, a répondu que sa solution était meilleure parce que tandis que d'autres entreprises se concentraient sur la qualité et la sécurité, elles s'occupent strictement de la sécurité.

Bien sûr, c'était une déclaration ridicule. Et peut-être que ce genre de réflexion est révélateur du problème actuel de sécurité des applications dans l'industrie; par exemple, les organisations qui tentent d'exécuter leur groupe de sécurité complètement séparé du reste du SDLC (efforts de développement et de test). Dans ce modèle, l'équipe de sécurité exécute ses propres tests, essayant principalement de casser le logiciel, puis renvoie les bogues de sécurité à l'équipe de développement. En d'autres termes, essayer de tester la sécurité dans leur code. Je peux vous assurer que ce n'est pas plus efficace que tester la qualité dans votre code.

Bien sûr, ce type de test de sécurité est nécessaire, mais ce n'est tout simplement pas suffisant. S'il est en effet utile de casser le logiciel, le recours à celui-ci comme méthode d'amélioration de la sécurité conduit à la découverte d'erreurs à un moment trop tardif et finit par être supprimées. En particulier, les problèmes de cause profonde tels que les cadres et les algorithmes inappropriés sont balayés sous le tapis, car le calendrier gagne le conflit entre la réécriture du code et la sortie de la version.

Dans le commentaire Linkedin que j'ai mentionné ci-dessus, le fournisseur trompe dangereusement un client potentiel sans méfiance en affirmant que son logiciel est en quelque sorte meilleur, sans rien dire d'utile sur comment ou pourquoi il est meilleur. Je ne veux pas choisir un fournisseur d'outils en particulier, d'autant plus que je travaille pour un. Cependant, je suis frustré par de tels arguments d'homme de paille, qui donnent l'apparence de l'huile de serpent colporteur. Dans ce cas, le produit du fournisseur peut en effet avoir des fonctionnalités uniques intéressantes, mais nous avons l'impression que la sécurité est en quelque sorte comme par magie différente de la qualité, ce qui réduit notre compréhension de la sécurité des applications et nous rend tous un peu moins sûrs.

La sécurité doit être traitée comme de la qualité, et la qualité doit être basée sur des pratiques d'ingénierie matures, car la vérité est que si vous avez un problème de qualité, vous avez un problème de sécurité. Des études montrent que n'importe où 50 à 70% des défauts de sécurité sont des défauts de qualité. En d'autres termes, les bons vieux bogues de qualité se transforment en vulnérabilités que les intrus / hackers / mauvais acteurs utilisent pour pénétrer votre application (nous les appelons "zéro jour").

"Le consensus des chercheurs est qu'au moins la moitié, et peut-être jusqu'à 70% des vulnérabilités logicielles courantes sont des problèmes fondamentaux de qualité de code qui pourraient être évités en écrivant de meilleurs logiciels. Codage bâclé. »

- Jim Bird "Construire de vrais logiciels »

Si vous ne savez toujours pas comment la qualité et la sécurité se chevauchent, jetez un œil à quelques exemples tirés du Top 25 CWE. Les résultats de sécurité possibles suivants proviennent du Impact technique CWE travail:

  • #3 CWE 120 Copie de la mémoire tampon sans vérification de la taille de l'entrée («débordement de la mémoire tampon classique») - peut conduire à l'exécution de code ou de commandes non autorisés, possible accès non autorisé aux données, possible Déni de service (DoS)
  • #20 CWE 131 - Calcul incorrect de la taille de la mémoire tampon (entraînant un dépassement de la mémoire tampon) - DoS possible, exécution de code ou de commandes non autorisés, possibilité de lecture / modification de mémoire non autorisée
  • #25 CWE 190 - Débordement d'entier ou Wraparound (entraînant un comportement indéfini et donc des plantages) - DoS possible, modification possible de la mémoire, exécution possible de code ou de commandes non autorisés, exécution de code arbitraire possible

Si vous allez plus loin dans la liste complète de CWE (plus de 800 articles), vous en trouvez beaucoup d'autres, c'est-à-dire toutes les formes de débordement / sous-débordementinitialisationrécursion incontrôlée, etc. Ce sont toutes des attaques de sécurité courantes, ainsi que des problèmes de qualité évidents.

Construisez-le

La complexité des systèmes logiciels croît très rapidement. Essayer de tester toutes les variations possibles devient rapidement presque impossible. Comme Richard Bender le dit, «Le nombre de tests potentiels dépasse le nombre de molécules dans l'univers», ce qui est juste une façon plus amusante de dire que vous ne le ferez jamais. Ou de Jim Bird, "pour un gros système, vous auriez besoin d'un nombre infini de stylos testeurs sur un nombre infini de claviers fonctionnant pendant un nombre infini d'heures pour peut-être trouver tous les bogues."

La sécurité et la fiabilité doivent donc être conçues et intégrées. Vous ne pouvez pas les tester. Tant que la sécurité est quelque chose de «supplémentaire», elle en souffrira.

Ce qui peut être fait?

Voici quelques mesures à prendre pour commencer à améliorer la qualité de votre logiciel et un  sécurité en même temps.

  1. Former les développeurs au développement sécurisé. Une formation adéquate de vos développeurs aux pratiques de développement sécurisées signifie qu'ils peuvent prévenir - ou du moins trouver et résoudre - les problèmes de sécurité.
  2. Concevez et construisez votre système avec un accent délibéré sur la qualité et la sécurité. Évitez le code qui «fonctionne» mais qui n'est pas vraiment un bon choix car il présente des problèmes de sécurité potentiels. (Ou des problèmes de sécurité, d'ailleurs.) L'analyse statique vous aidera à le faire en vérifiant votre code non seulement pour les bogues, mais aussi pour la conformité avec les meilleures pratiques connues.
  3. Arrêtez de vous fier aux outils de bord. Reconnaissez votre exposition réelle et attaquez les surfaces. Le pare-feu et l'antivirus ne compenseront pas le code non sécurisé - vous devez renforcer votre application.
  4. Collectez / mesurez les données sur les défauts et utilisez-les pour évaluer et améliorer vos pratiques de développement. Quel code ou quels composants posent le plus de problèmes? Quel code est le meilleur? Comment ont-ils été testés? Répétez les bonnes idées et éliminez les mauvaises.
  5. Utilisez une analyse statique stricte. N'acceptez pas simplement l'évaluation de quelqu'un selon laquelle un défaut signalé n'est pas un problème important ou un faux positifs. Obtenez un bon ensemble de règles comprenant à la fois la détection et la prévention, et respectez-les. La meilleure façon d'y parvenir est d'une approche d'ingénierie autour des meilleures pratiques (le rôle des normes de codage comme CWECERTet OWASP). L'analyse statique est le moyen de s'assurer que les meilleures pratiques sont suivies.
  6. Utilisez l'analyse d'exécution. Il trouvera de vrais problèmes (en particulier des problèmes de mémoire désagréables), et il vous montre exactement où et ce qui n'a pas fonctionné sans faux positifs.

Nous devons donc commencer à intégrer la sécurité dans notre code. C'est le meilleur moyen de le durcir vraiment, plutôt que de simplement colmater les trous connus. L'intégration de tous vos résultats de développement logiciel, issus du codage, de la construction et des tests dans un référentiel central, offre un contrôle, une mesure et une traçabilité. C'est la base des améliorations futures.

Et rappelez-vous que le coût d'une prévention solide est inférieur au coût de gestion d'un logiciel défectueux ou non sécurisé. Il n'y a donc vraiment aucune excuse.

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.