Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

Utilisation de l'analyse statique pour atteindre la «sécurité dès la conception» pour le RGPD

Utilisation de l'analyse statique pour atteindre la «sécurité dès la conception» pour le RGPD Temps de lecture : 7 minutes

Une analyse statique correctement configurée avec le bon outil et les bonnes règles vous aidera à sécuriser votre logiciel, à prouver que vous faites ce qu'il faut pour les auditeurs et à montrer que vous suivez les principes de la sécurité dès la conception et de la confidentialité par -conception.

Le RGPD est grand et effrayant et se rapproche de jour en jour. Une partie de moi veut croire que nous serons tous prêts d'ici le 25 maith date limite, mais je suis plus nombreux à croire que la véritable poussée pour se conformer se produira APRÈS cette date. Si vous ne savez pas ce qu'est vraiment le RGPD ou si cela vous tient à cœur, jetez un œil à mon dernier blog pour un aperçu plus large. En un mot, cela signifie que vous devez informer les utilisateurs des données que vous collectez, comment vous les utiliserez, faire de votre mieux pour les protéger, être transparent lorsque des violations se produisent et supprimer complètement toutes les données utilisateur s'ils le demandent. Et oh oui, si vous ne vous conformez pas, il y a de grosses amendes.

En théorie, le RGPD ne s'applique qu'aux citoyens de l'UE, mais la portée mondiale de la plupart des échanges commerciaux exige de nos jours une diligence pour se conformer à la réglementation dans le monde entier. Cela laisse le choix entre traiter tous les utilisateurs de manière sécurisée et privée ou avoir un flux de données entièrement segmenté pour les clients européens et non européens, par exemple (probablement une proposition plus coûteuse). Dans ce blog, je vais vous expliquer comment vous pouvez tirer parti de l'analyse de code statique pour améliorer la protection et la confidentialité des données.

Sécurité dès la conception et confidentialité dès la conception

Lorsque vous pensez au RGPD, à la protection des données et à d'autres réglementations relatives aux données associées telles que PCI-DSS (Payment Card Industry-Data Security Standard) ou HIPAA (Health Insurance Portability and Accountability Act), la pensée immédiate est la nécessité d'augmenter les tests et l'analyse dynamique. et tests de pénétration. Bien que nécessaires et importantes, ces technologies de test réduisent le risque d'expédier des logiciels non sécurisés, sans pour autant rendre les logiciels plus sûrs ou garantir la confidentialité en premier lieu. Mais la sécurité et la confidentialité ne peuvent pas être «testées» dans les logiciels, pas plus que la qualité ou les performances. Le RGPD nécessite donc des concepts appelés «Security by Design» et «Privacy by Design» (PbD), ce qui signifie en premier lieu mieux construire un logiciel.

 «L'approche Privacy by Design se caractérise par des mesures proactives plutôt que réactives. Il anticipe et prévient les événements envahissants de la vie privée avant qu'ils ne se produisent. PbD n'attend pas que les risques liés à la confidentialité se matérialisent, et n'offre pas non plus de recours pour résoudre les infractions à la vie privée une fois qu'elles se sont produites - elle vise à les empêcher de se produire. En bref, la protection de la vie privée dès la conception vient avant les faits, pas après »

A. Cavoukian. Privacy by Design - The 7 Foundational Principles, janvier 2011.

J'évoque ces deux concepts car ils constituent la prochaine étape après les activités normales de sécurité des applications (pare-feu, tests de pénétration, équipes rouges, DAST, etc.). La partie «par conception» peut également être lue comme «à intégrer». C'est l'idée que plutôt que de pousser votre application et de fixer où se trouvent les trous, vous construisez une application sans les trous en premier lieu… par conception, pour ainsi dire. Par exemple, l'injection SQL (SQLi) continue d'être l'un des exploits les plus courants.

De nombreux outils existent pour essayer de forcer une injection via l'interface utilisateur (test de pénétration) ou de simuler le flux de données dans un programme sans l'exécuter pour voir si des données corrompues peuvent passer à une requête de base de données (analyse de flux). Une approche «par conception» signifie envelopper toute entrée (de la base de données, de l'utilisateur ou de n'importe quel endroit) à l'intérieur d'une fonction de validation au moment où l'entrée est acquise. Cela réduit les chemins possibles où les données peuvent contourner à zéro. Vous devez toujours exécuter les tests de pénétration pour vous assurer que vous avez bien construit votre logiciel, mais la différence est que si le pentest réussit, vous ne corrigez pas simplement la faiblesse que vous avez trouvée. Au lieu de cela, vous regardez en arrière et découvrez POURQUOI pentest a réussi et construisez votre logiciel pour qu'il ne réussisse pas.

Si pentest trouve de nombreuses failles de sécurité dans votre logiciel, vous ne créez pas de logiciel sécurisé «par conception». De même pour Privacy by Design, nous surveillons qui / quoi / où nous partageons, et nous présumons que toutes les données sont importantes, sauf indication contraire. Encore une fois, les programmeurs font généralement l'hypothèse que les données ne sont pas importantes à moins qu'elles ne soient spécialement signalées. Vous voyez cela dans des choses comme les décisions quant à savoir si les données sont stockées sous forme simple ou si les données sont cryptées. Tout chiffrer est un moyen de respecter la confidentialité dès la conception. L'un des nombreux accordés, mais c'est l'idée de base. Si vous cryptez tout, vous n'aurez jamais à vous soucier de ne pas crypter quelque chose que vous devriez avoir.

Quel rôle l'analyse statique joue-t-elle ici ?

Le rôle de l'analyse statique n'est pas de nous dire que notre logiciel est vulnérable (c'est le travail de tester). Le rôle de l'analyse statique est de contribuer à garantir la solidité du logiciel en premier lieu… de par sa conception. Bien que l'analyse de flux soit devenue populaire au cours des 10 dernières années en tant que technique de test de sécurité, c'est toujours un moyen de tester le logiciel plutôt qu'un moyen de renforcer le logiciel, ou d'intégrer la sécurité ou de le faire «par conception».

L'analyse statique peut être positionnée de manière unique pour agir comme une véritable technique préventive si elle est utilisée correctement. En plus des règles de sécurité d'analyse de flux, c'est-à-dire à la recherche de données corrompues, nous activons également des règles qui garantissent que le logiciel est construit de manière sécurisée. Compte tenu des deux cas ci-dessus, lorsque je fais de la confidentialité dès la conception, je peux avoir des règles d'analyse statique qui signalent lorsque les données sont stockées sans être cryptées au préalable, ou lorsqu'une ancienne méthode de cryptage incorrecte qui est piratable est utilisée à la place d'un cryptage fort, ou lorsque les utilisateurs sont essayant d'accéder à des données inappropriées pour leurs autorisations attendues.

Voici une brève description d'un exemple de règle qui applique la journalisation lorsque des méthodes sensibles sont appelées. Cette règle d'analyse statique ne trouvera pas de bogues, mais elle vous aidera à créer un logiciel qui enregistre ce qui se passe afin qu'il soit plus sûr en production. Cette règle convient parfaitement à PCI-DSS ainsi qu'au RGPD.

Assurez-vous que toutes les invocations de méthodes sensibles sont consignées [SECURITY.BV.ENFL] 

DESCRIPTION: Cette règle identifie le code qui n'enregistre pas les appels de méthodes sensibles. Une erreur est signalée si certaines invocations de méthodes sensibles - par exemple, «login» et «logout» depuis «javax.security.auth.login.LoginContext» - ne sont pas enregistrées lorsqu'elles sont utilisées.

Un autre exemple de confidentialité dès la conception est cette règle qui vous aide à vous empêcher de divulguer involontairement des informations personnelles ou importantes lorsqu'une erreur se produit dans votre logiciel:

Ne transmettez pas les messages d'exception en sortie afin d'empêcher l'application de divulguer des informations sensibles [SECURITY.ESD.PEO] 

DESCRIPTION: Cette règle identifie le code qui transmet les messages d'exception à la sortie. Une erreur est signalée lorsqu'une clause catch appelle une méthode de sortie et que l'exception interceptée dans la clause catch apparaît dans la liste des paramètres ou est utilisée comme objet appelant.

Cette règle couvre OWASP Top 10, CWE, PCI-DSS et GDPR - ce qui signifie que c'est une très bonne idée, peu importe la raison pour laquelle vous essayez de faire de la sécurité.

Commencer

Étant donné que le RGPD n'est pas une norme de codage, il n'y a pas de configuration d'analyse statique simple qui le couvrira. Souvent, le meilleur point de départ est de trouver des règles d'analyse statique qui se rapportent directement aux problèmes que vous rencontrez actuellement lors des tests, tels que les problèmes XSS ou SQLi. Ces problèmes ont généralement des règles d'analyse statiques qui agissent comme des localisateurs de bogues et fourniront une détection précoce de ces problèmes avant qu'ils ne soient testés. Plus important encore, il y aura également des règles associées, dans ce cas autour de la validation d'entrée, qui vous aident à vous assurer que SQLi ne peut tout simplement pas se produire comme je l'ai mentionné ci-dessus.

Chasser les données de l'entrée utilisateur via le stockage est difficile. La programmation pour que la validation se produise toujours est facile. La programmation pour que le cryptage se produise toujours est facile à faire et facile à tester. Pourquoi le faire à la dure?

Quelles sont les autres règles d'analyse statique ?

Une fois que vous avez trouvé et activé les règles pour les problèmes que vous rencontrez lors des tests, vous voudrez aller encore plus loin. Je suggérerais d'emprunter des idées à d'autres normes de codage qui couvrent déjà la confidentialité et la protection des données. Quelques bons choix sont OWASP, HIPAA et PCI-DSS. Si vous avez activé des règles dans votre outil d'analyse statique qui se rapportent à ces normes, vous allez faire du bon travail pour le RGPD. En fait, si vous êtes déjà conforme à la norme PCI-DSS, vous constaterez qu'au moins cette partie du RGPD devrait être relativement facile à préparer.

Si vous avez déjà d'autres exigences de sécurité telles que CWE ou CERT, vous pouvez vous assurer que vous les suivez également et étendre votre configuration pour couvrir la protection des données GDPR spécifique si nécessaire en recherchant tous les éléments de ces normes liés à la confidentialité des données, aux données. protection et cryptage.

Que peut faire Parasoft d'autre pour vous ?

Parasoft peut vous aider à sécuriser et à protéger votre code de plusieurs manières. Premièrement, tous nos moteurs d'analyse statique ont des configurations pour OWASP, CWE, CERT, PCI-DSS, HIPAA, etc. Vous pouvez activer l'ensemble exact de règles de sécurité qui conviennent à votre organisation, puis les appliquer automatiquement.

De plus, lorsque vous intégrez Parasoft DTP à l'analyse statique, vous disposez d'une capacité d'audit complète, automatisant le processus de documentation des règles exécutées sur quel code et à quel moment. Vous pouvez prouver que vous effectuez des tests ou même que vous sécurisez par conception en fonction des règles que vous avez sélectionnées.

Parasoft DTP a également des rapports très spéciaux, et si vous choisissez de baser vos efforts de sécurité sur CWE, le tableau de bord Parasoft CWE vous donne d'excellents rapports SAST, tels que les problèmes par gravité, emplacement, type, historique, etc. aller plus loin et implémenter les données d'impact technique dans CWE. L'impact technique (TI) est une recherche effectuée à Mitre dans le cadre du Cadre commun d'analyse des risques de faiblesse (CWRAF) et vous aide à classer les résultats du SAST en fonction du problème qu'ils peuvent causer. Ainsi, au lieu d'un message indiquant que vous avez un buffer overflow, que certains pourraient ne pas reconnaître comme un problème de sécurité, TI vous dit qu'un buffer overflow pourrait conduire à un déni de service.

Chaque résultat de CWE vous indique quels types de problèmes peuvent survenir, et il existe des graphiques spéciaux qui vous aident à naviguer dans vos problèmes d'analyse statique en fonction des problèmes les plus importants pour vous, et pas seulement des niveaux de gravité. Cette technique révolutionnaire vous aide à maîtriser ce qui peut souvent devenir un nombre écrasant de vulnérabilités, en particulier si vous travaillez sur une base de code héritée. Concentrez-vous d'abord sur les problèmes qui vous font le plus peur.

Et bien sûr, alors que je me concentrais aujourd'hui sur l'analyse statique comme moyen de sécuriser dès la conception, n'oubliez pas que Parasoft dispose également d'outils de test d'intrusion, de test d'API et de virtualisation de services, qui sont tous une partie importante de une stratégie globale de développement de logiciels sécurisés.

Résumé

Le RGPD semble effrayant et cela peut certainement l'être, mais une analyse statique correctement configurée avec le bon outil et les bonnes règles vous aidera à sécuriser votre logiciel, à prouver que vous faites ce qu'il faut pour les auditeurs et à montrer que vous suivez les principes de la sécurité dès la conception et de la confidentialité dès la conception. C'est quelque chose que les tests d'intrusion seuls ne peuvent pas faire. L'avantage supplémentaire est que vous constaterez que l'approche de la sécurité du point de vue «par conception» est bien plus efficace que d'essayer de tester votre façon de sécuriser le logiciel entre l'assurance qualité et la sortie. Pour approfondir, lisez le guide: Utilisation de l'analyse statique pour la sécurité et la confidentialité des données GDPR sécurisées dès la conception.

Nouvelle incitation à l'action

Écrit 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.