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

Bien que le RGPD semble effrayant et ait sans aucun doute le potentiel de l'être, la mise en œuvre d'une analyse statique à l'aide de l'outil et des directives appropriés vous aidera à protéger votre programme. Poursuivez votre lecture pour découvrir comment mettre en œuvre la sécurité dès la conception pour le RGPD à l'aide de l'analyse statique.

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. Intégrer 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 soient développées et testées dès les premières étapes du développement d'une application, par exemple. Tout comme la sécurité ne peut être testée ultérieurement dans le cycle de vie d'un produit, il en va de même pour la protection des données du RGPD. De plus, la protection des données doit être la configuration par défaut des systèmes et applications informatiques et ne doit pas être supposée activée ultérieurement via 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 que nécessaires et importantes, ces technologies de test réduisent le risque de commercialisation de logiciels non sécurisés, sans pour autant les rendre plus sûrs ni garantir la confidentialité. Or, 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 exige donc des concepts appelés « sécurité dès la conception » et « protection des données dès la conception », ce qui implique de concevoir des logiciels de meilleure qualité dès le départ.

L'approche « Privacy by Design » se caractérise par des mesures proactives plutôt que réactives. Elle anticipe et prévient les atteintes à la vie privée avant qu'elles ne surviennent. Elle n'attend pas que les risques de confidentialité se matérialisent et n'offre pas de solutions pour résoudre les atteintes à la vie privée une fois qu'elles ont eu lieu ; elle vise à les prévenir. En bref, la protection de la vie privée dès la conception intervient avant les faits, et non après.

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

J'évoque ces deux concepts car ils constituent l'étape suivante après les activités normales de sécurité des applications (pare-feu, tests d'intrusion, équipes rouges, DAST, etc.). L'aspect « par conception » peut également être interprété comme « intégré ». Il s'agit de l'idée qu'au lieu de s'attaquer à votre application et de corriger les failles, vous créez une application sans failles dès le départ… par conception, en quelque sorte. Par exemple, l'injection SQL (SQLi) reste l'une des failles les plus courantes.

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 » consiste à intégrer toute entrée (de base de données, d'utilisateur ou autre) dans une fonction de validation dès son acquisition. Cela réduit à zéro les chemins possibles par lesquels les données peuvent contourner. Vous devez toujours effectuer des tests d'intrusion pour vous assurer que votre logiciel est correctement développé, mais la différence réside dans le fait qu'en cas de succès d'un test d'intrusion, vous ne corrigez pas simplement la faiblesse identifiée. Vous analysez le problème et déterminez pourquoi le test d'intrusion a réussi, puis développez votre logiciel de manière à ce qu'il ne réussisse pas.

Si un test d'intrusion révèle de nombreuses failles de sécurité dans votre logiciel, vous ne créez pas un logiciel sécurisé « par conception ». À l'instar du principe de confidentialité par conception, nous surveillons qui, quoi et où nous partageons des informations, et nous partons du principe que toutes les données sont importantes, sauf indication contraire. Là encore, les programmeurs partent souvent du principe que les données ne sont PAS importantes, sauf si elles sont spécifiquement 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 ?

Construction rôle de l'analyse statique Il ne s'agit pas de nous dire que notre logiciel est vulnérable. C'est le rôle des tests. Le rôle de l'analyse statique est de garantir la robustesse du logiciel dès sa conception. Bien que l'analyse de flux soit devenue populaire ces dix dernières années comme technique de test de sécurité, elle reste une méthode de test plutôt qu'un moyen de le renforcer (ou d'y intégrer la sécurité) ou de le faire « par conception ».

L'analyse statique peut être particulièrement bien placée pour agir comme une véritable technique préventive si elle est utilisée correctement. Outre analyse de flux sécurité Outre les règles de détection de données corrompues, nous activons également des règles garantissant la sécurité du logiciel. Dans les deux cas précédents, en appliquant la protection de la vie privée dès la conception, je peux définir des règles d'analyse statique qui signalent les cas suivants :

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

Démarrer

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.

Les tests d'intrusion ne peuvent pas y parvenir seuls. L'avantage supplémentaire est que vous constaterez qu'une approche de la sécurité par conception est bien plus efficace que de tenter de sécuriser les logiciels entre l'assurance qualité et la publication.