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

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 sécurité dès la conception et de confidentialité dès la conception.

GDPR est grand et effrayant. Pour résumer, le RGPD signifie que vous devez informer les utilisateurs :

• Quelles données vous collectez.
• Comment vous l'utiliserez.
• Faites de votre mieux pour le protéger.
• Soyez transparent lorsque des violations se produisent
• Supprimez complètement toutes les données utilisateur s'ils le demandent.

Et oh ouais, 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 de nos jours nécessite une diligence dans le respect de la réglementation à travers le monde. Cela laisse le choix entre traiter tous les utilisateurs de manière sécurisée et privée ou, par exemple, avoir un flux de données complètement segmenté pour les clients de l'UE et hors UE, ce qui est probablement une proposition plus coûteuse. Dans ce blog, j'expliquerai comment vous pouvez tirer parti de l'analyse de code statique pour améliorer la protection et la confidentialité des données.

Comprendre le RGPD et son impact sur le développement de logiciels

Principes clés du RGPD

Les objectifs généraux du RGPD sont de limiter et de protéger les informations des clients face à la collecte de données à grande échelle par les organisations, principalement sur Internet. Les lois sont mises en place pour les citoyens de l'UE, mais l'impact sera mondial puisque la plupart des organisations font des affaires dans les pays de l'UE et/ou avec des citoyens de l'UE.

Voici les principes clés.

• Légal et transparent. La collecte de données doit être effectuée légalement, ce qui implique le respect du RGPD et de toute autre législation sur la collecte de données dans la juridiction de l'utilisateur. L'utilisation des données doit être transparente pour l'utilisateur et obtenue légalement et avec une autorisation explicite.
• Minimiser le temps de stockage. Les données des utilisateurs ne peuvent être conservées que le temps nécessaire et pas plus. Les données des utilisateurs doivent être supprimées ou rendues anonymes lorsqu'elles ne sont plus nécessaires.
• Minimisez la quantité de données. La quantité de données collectées ne doit être que ce qui est nécessaire et soutenir l'intention initiale de la collecte de données.
• Précision des données. Les données des utilisateurs doivent être exactes et à jour. Les données inexactes doivent être corrigées ou supprimées.
• Objectif spécifique et limité. Les données de l'utilisateur ne peuvent être collectées que pour satisfaire l'objectif initial. Les données ne peuvent pas être conservées et réutilisées à d'autres fins.
• Garanties techniques et organisationnelles. La collecte de données implique que les organisations doivent protéger les données personnelles contre tout accès non autorisé par des moyens illégaux ou accidentels. Des solutions technologiques appropriées pour maintenir l'intégrité et la confidentialité sont nécessaires. Ce principe implique implicitement la responsabilité organisationnelle des mesures de sécurité appropriées pour protéger les données des utilisateurs.

Impact sur le développement logiciel

L'impact de la Conformité GDPR sur le développement de logiciels est importante, car elle a un certain nombre d'implications sur les pratiques de développement de logiciels. Les développeurs de logiciels se concentrent principalement sur les garanties techniques et organisationnelles nécessaires pour satisfaire aux principes clés et garantir l'intégrité et la confidentialité des données des utilisateurs.

• Assurer une collecte légale et transparente. Comme nous l'avons vu avec la pléthore de fenêtres contextuelles de sites Web, les organisations doivent s'assurer qu'elles collectent les données des utilisateurs de manière légale, décrire en détail comment elles sont utilisées et recueillir le consentement des utilisateurs avant de les collecter. Dans de nombreux cas, cela ajoute des exigences aux interfaces utilisateur et aux applications frontales.
• Mesures organisationnelles pour assurer la protection des données. Les données des utilisateurs doivent être considérées comme confidentielles et traitées comme telles tout au long de leur durée de vie au sein des systèmes d'une organisation. Cela s'aligne sur la triade de confidentialité, d'intégrité et d'accessibilité de l'ICA. La philosophie est fondamentale pour l'infosec et l'approche est désormais nécessaire pour les données clients dans les systèmes informatiques commerciaux. Dans le cadre du RGPD, les organisations doivent prendre des mesures à tous les niveaux pour protéger les données des clients, ce qui a des implications sur le développement de logiciels, les systèmes informatiques, le comportement organisationnel et la sécurité.
• Protection des données dès la conception et par défaut. L'intégration de la sécurité est nécessaire pour respecter les principes de protection des données du RGPD. Cela implique que la sécurité et la protection des données sont développées et testées dès les premières étapes du développement d'applications, par exemple. Tout comme la sécurité ne peut pas être testée plus tard dans le cycle de vie d'un produit, il en va de même pour la protection des données GDPR. De plus, la protection des données doit être la configuration par défaut des systèmes et applications informatiques et ne pas être supposée être « activée » ultérieurement avec des options de configuration, par exemple.
• Les données personnelles sont traitées de manière appropriée et transparente. Les données personnelles au sein des applications et des systèmes informatiques doivent être protégées en transit et au repos. Cela implique un cryptage approprié des données dans la plupart des cas et une utilisation en texte clair uniquement lorsque cela est absolument nécessaire. Comme la plupart des gens ont été confrontés à des violations de données très médiatisées, une technologie et des pratiques de stockage de données médiocres ont conduit à l'exposition de données utilisateur hautement sensibles.
• Limitez l'utilisation et le temps de stockage. Les développeurs de logiciels doivent s'assurer qu'il existe des limites de temps pour le stockage des données client et limiter le partage de ces données au-delà de son intention initiale. Par exemple, si les clients n'interagissent pas avec votre application pendant 30 jours, vous devez supprimer complètement leurs informations stockées, ce qui ajoute de nouvelles exigences importantes au stockage des données. De plus, il appartient à l'organisation de s'assurer que les données des clients ne sont pas utilisées en interne à d'autres fins. Par exemple, collecter les détails du support client, puis les partager avec les ventes ou le marketing. À moins qu'un consentement explicite ne soit donné pour ce partage, cela ne peut pas être fait

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 associées sur les données telles que PCI DSS (norme de sécurité des données de l'industrie des cartes de paiement) ou HIPAA (loi sur la portabilité et la responsabilité en matière d'assurance maladie), la pensée immédiate est la nécessité d'augmenter les tests, l'analyse dynamique et tests de pénétration.

Bien qu'elles soient nécessaires et importantes, ces technologies de test réduisent les risques d'envoi de logiciels non sécurisés, sans réellement rendre les logiciels plus sûrs ni garantir la confidentialité en premier lieu. Mais la sécurité et la confidentialité ne peuvent pas être « testées » dans un logiciel, pas plus que la qualité ou la performance. Le RGPD nécessite donc des concepts appelés « Security by Design » et « Privacy by Design » (PbD), ce qui signifie en premier lieu que la création de logiciels est meilleure.

« 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 portant atteinte à la vie privée avant qu'ils ne se produisent. PbD n'attend pas que les risques pour la vie privée 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 - il vise à les empêcher de se produire. En bref, la confidentialité dès la conception vient avant le fait, pas après. »

-UN. Cavoukian. Privacy by Design – Les 7 principes fondamentaux, janvier 2011.

J'aborde ces deux concepts car ils constituent la prochaine étape après les activités normales de sécurité des applications (pare-feu, tests d'intrusion, équipes rouges, DAST, etc.). La partie « by design » peut également être lue comme « build it in ». C'est l'idée qu'au lieu de fouiller dans votre application et de réparer 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 contaminées peuvent atteindre une requête de base de données (analyse de flux).

Une approche « par conception » signifie encapsuler toute entrée (provenant d'une base de données, d'un utilisateur ou de n'importe où) dans une fonction de validation au moment où l'entrée est acquise. Cela réduit à zéro les chemins possibles où les données peuvent être contournées. Vous devez toujours exécuter les tests d'intrusion pour vous assurer que vous avez bien conçu votre logiciel, mais la différence est que si un test d'intrusion réussit, vous ne corrigez pas simplement la seule faiblesse que vous avez trouvée. Au lieu de cela, vous regardez en arrière et découvrez POURQUOI le test d'intrusion a réussi et construisez votre logiciel pour qu'il ne réussisse pas.

Si un test d'intrusion trouve de nombreuses failles de sécurité dans votre logiciel, vous ne construisez pas de logiciel sécurisé "par conception". Semblable à Privacy by Design, nous surveillons qui/quoi/où nous partageons, et nous supposons que toutes les données sont importantes, sauf indication contraire. Encore une fois, les programmeurs supposent généralement 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 en clair ou si les données sont cryptées. Tout chiffrer est une façon de faire de la confidentialité dès la conception. L'un des nombreux accordé, mais c'est l'idée de base. Si vous cryptez tout, vous n'avez jamais à vous soucier de ne pas avoir crypté quelque chose que vous devriez avoir.

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

La rôle de l'analyse statique n'est pas de nous dire que notre logiciel est vulnérable. C'est le travail des tests. Le rôle de l'analyse statique est d'aider à s'assurer que le logiciel est solide en premier lieu… de par sa conception. Alors que l'analyse de flux est 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, par exemple, la recherche de données entachées, 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 quand :

Les données sont stockées sans être cryptées au préalable.

Une ancienne méthode de cryptage inappropriée et piratable est utilisée à la place d'un cryptage fort.

Les utilisateurs tentent 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écurisé en production. Cette règle est parfaitement adaptée à la norme 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 pourquoi vous essayez de faire de la sécurité.

Avantages de l'utilisation de l'analyse statique pour le RGPD

Outils d'analyse statique sont utiles pour répondre aux exigences de protection des données des utilisateurs à tous les niveaux en améliorant la qualité, la confidentialité et la sécurité des applications. Plus précisément, cela comprend :

• Détection précoce des vulnérabilités de sécurité. L'analyse statique aide à prévenir, via des normes de codage sécurisées, le développement de logiciels de mauvaise qualité qui conduisent à des vulnérabilités qui peuvent ensuite être exploitées. Ces outils détectent et identifient également les vulnérabilités de sécurité potentielles au début du cycle de vie du développement logiciel avant que le logiciel ne soit déployé en production. Cela permet aux développeurs de remédier à ces vulnérabilités avant qu'elles ne deviennent un problème de sécurité ou de confidentialité.
• Prévention des mauvaises pratiques de confidentialité et de sécurité. Les outils d'analyse statique peuvent être configurés pour rechercher des pratiques de sécurité et de confidentialité spécifiques qui sont courantes dans les violations de données. Par exemple, l'utilisation de techniques de cryptographie médiocres connues peut être signalée.
• Amélioration de la qualité du logiciel. Une amélioration globale de la qualité des logiciels est essentielle pour éliminer la possibilité de futures fuites de données et d'exploits de sécurité.

Problèmes courants de protection des données résolus par l'analyse statique

Les points forts des outils d'analyse statique résident dans deux domaines clés.

1. Prévention des mauvaises pratiques de codage via l'application des normes de codage.
2. Détection de bogues et de vulnérabilités dues à des erreurs de logique dans le code.

Le RGPD ne fournit pas de norme de codage, ni ne décrit explicitement les erreurs de sécurité et de confidentialité à détecter et à corriger. Cependant, si vous examinez la prise en charge d'autres normes connexes telles que PCI DSS, nous pouvons réutiliser les mêmes concepts. Par exemple, les types de problèmes de protection des données suivants peuvent être détectés :

• Failles d'injection, y compris les injections SQL, de commande, LDAP et Xpath
• Débordements de tampon
• Fonctions cryptographiques non sécurisées
• Communication de données non sécurisée
• Traitement incorrect des erreurs
• Contrôle d'accès inapproprié
• Script inter-site
• Falsification de requêtes inter-sites
• Authentification et gestion de session interrompues

De plus, Parasoft prend en charge les normes de codage sécurisé suivantes, dont les développeurs peuvent personnaliser un ensemble unique pour leur organisation :

• SEI CERT C et CERT C++
• CWE Top 25 des erreurs logicielles les plus dangereuses, CWE sur le point
• Top 10 OWASP, Top 10 de la sécurité des API OWASP

Pour commencer

Parce que GDPR 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 consiste à rechercher des règles d'analyse statique directement liées 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 statique qui agissent comme des détecteurs 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 des entrées, qui vous aideront à 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é des règles pour les problèmes rencontrés 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. Certains bons choix sont OWASP, HIPAA et PCI DSS.

Si vous activez des règles dans votre outil d'analyse statique qui se rapportent à ces normes, vous ferez 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 respectez également et étendre votre configuration pour couvrir la protection des données GDPR spécifique si nécessaire en trouvant tous les éléments de ces normes liés à la confidentialité des données, la protection des données , et chiffrement.

Que peut faire Parasoft d'autre pour vous ?

Parasoft peut vous aider à obtenir votre code sécurisé et privé par conception 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 testez ou même prouver la sécurité dès la conception en fonction des règles que vous avez sélectionnées.

Parasoft DTP a également des rapports très spéciaux. Si vous choisissez de baser vos efforts de sécurité sur CWE, le tableau de bord Parasoft CWE vous fournit d'excellents rapports SAST, tels que les problèmes par gravité, emplacement, type, historique, etc.

Nous sommes allés plus loin et avons implémenté 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 SAST en fonction du problème qu'ils peuvent causer. Ainsi, au lieu d'un message indiquant que vous avez un débordement de tampon, que certains pourraient ne pas reconnaître comme un problème de sécurité, TI vous indique que le débordement de tampon peut entraîner un déni de service.

Chaque découverte de CWE vous indique quels types de problèmes peuvent survenir. 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 faire de la sécurité dès la conception, n'oubliez pas que Parasoft dispose également d'outils de test d'intrusion, de tests d'API et de virtualisation de services, qui sont tous une partie importante d'un ensemble complet stratégie de développement logiciel sécurisé.

Résumé et principaux points à retenir

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écurisez votre logiciel.
• Prouvez que vous faites ce qu'il faut pour les auditeurs.
• Montrez que vous suivez les principes de sécurité dès la conception et de 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 qu'aborder la sécurité du point de vue « dès la conception » est beaucoup plus efficace que d'essayer de tester votre façon de sécuriser le logiciel entre l'AQ et la publication.