« Retour

30 Days of Security Testing – Partie 2/4 : Découvrir les bonnes pratiques

Mots clés : test de sécurité, Ministry of Testing, scan de vulnérabilité, test d'intrusion, pentest, ANSSI, ISO 27 000, STRIDE, OWASP

Le principe

Bienvenue dans notre deuxième article consacré au défi 30 Days of Security Testing.

  1. Compulser la documentation
  2. Découvrir les bonnes pratiques
  3. Découvrir les outils
  4. Aller plus loin

Les challenges

Défi 4 : S’informer sur les scans de vulnérabilité

Le scan des vulnérabilités est une technique de recherche proactive et automatisée des failles de sécurité d’un système. Une liste de failles est recherchée, puis un reporting est généré pour savoir lesquelles se trouvent effectivement dans le système. Le logiciel ZAP (dont nous parlerons dans un prochain article) est un outil de scan des vulnérabilités.

Même s’ils permettent d’identifier rapidement un certain nombre de problèmes, les scans de vulnérabilité ne sont pas suffisants pour assurer la sécurité d’un système d’information ou d’un applicatif donné. Premièrement, parce que toutes les failles existantes ne peuvent être répertoriées, et a fortiori par un seul outil. Deuxièmement, parce que les scanneurs de vulnérabilités ne permettent pas de simuler une situation d’attaque sophistiquée.

Il est donc nécessaire de mettre en place, en plus des scans de vulnérabilités, des tests d’intrusion mettant en oeuvre une stratégie d’attaque plausible.

Défi 5 : Découvrir un outil de modélisation des menaces (par exemple, le modèle STRIDE)

L’évaluation des menaces est essentiel si l’on souhaite renforcer la sécurité de son SI. Le modèle STRIDE répond à ce besoin. Cet acronyme signifie :

  • Spoofing of user identity (usurpation d’identité). Cela peut se faire en cassant un mot de passe.
  • Tampering (falsification de données).
  • Repudiation. La répudiation est le fait de pouvoir nier avoir pris part à une action sur le système informatique. Il est critique d’assurer la non-répudiation lors des transactions en accumulant des preuves que cette transaction a bien été effectuée.
  • Information disclosure (divulgation d’informations).
  • Denial of service (déni de service). Le fait de rendre indisponible un service, que ce soit universellement ou pour une cible donnée.
  • Elevation of privilege (élévation du privilège). L’utilisateur se voit obtenir des droits qu’il n’est pas censé avoir. Il peut accéder à des informations ou effectuer des actions qui n’étaient pas prévues.

Un même scénario faire intervenir plusieurs de ces pratiques frauduleuse.

Voici un exemple d’application du modèle STRIDE, publié par le département d’informatique et de recherche opérationnelle de l’université de Montréal.

Défi 7 : S’informer sur les tests d’intrusion

Un test d’intrusion, ou pentest, est un test où l’on simule une attaque visant à outrepasser la sécurité d’un système afin d’obtenir, corrompre ou rendre indisponibles des informations. Le but est de révéler, par la pratique, les failles de sécurité spécifiques au système testé.

Un test d’intrusion commence par une analyse des traces laissées par le système que l’on veut tester (ses empreintes, ou footprints). Cela passe par des informations directement trouvables sur le web (informations sur les collaborateurs, politiques de confidentialité), ainsi que des informations techniques telles que son adresse IP (en effectuant un simple ping du site concerné), éventuellement les autres sites qui se trouvent sur la même IP, la date d’expiration du nom de domaine (ce que permet Whois), etc. Des informations techniques peuvent être trouvées via une simple requête dans un moteur de recherche. On parle alors de Google dorks.

Viennent ensuite :

  • la phase de scanning, où l’on cherche par exemple quels ports sont ouverts ou quelles machines sont actives,
  • l’énumération, où les informations recueillies sont utilisées pour effectivement entrer dans le système,
  • l’exploitation, où les actions sont effectuées au sein même du système.

L’un des intérêts d’un test d’intrusion est de comprendre quelles informations il serait stratégique de tenir secrètes, et quelles actions interdire au sein du système, afin d’éviter d’être confronté à des attaques similaires.

Comme vu précédemment, il est intéressant de combiner scans de vulnérabilités et tests d’intrusion.

  Scans de vulnérabilité Tests d’intrusion
Fréquence de lancement Haute.

 

Cela peut être fait à chaque itération.

Relativement basse.

 

Les investissements en tests d’intrusion dépendent évidemment du niveau de risque associé.

Contenu des reportings Liste des vulnérabilités, comparatif avec les précédents résultats. Liste des données en danger.
Coût Faible

 

Les outils de scan demandent généralement peu d’efforts de configuration. Leur coût d’exécution est nul.

Elevé

 

Trouver les failles spécifiques demande davantage de temps, et souvent l’intervention d’experts indépendants.

ROI Immédiat. Une liste de défauts est rapidement générée, qui permet de planifier les prochaines corrections. Garanti, proportionnel à l’expertise de l’équipe de test. Si des failles sont détectées, on anticipe d’éventuelles attaques. Dans le cas contraire, on gagne en confiance dans le produit.

Inspiré d’un schéma du groupe TNS.

Défi 9 : Découvrir les processus et procédures d’audits de sécurité

La plupart du temps, les audits de sécurité sont menés par des entités externes à l’organisation. L’ANSSI, l’agence nationale de la sécurité des systèmes d’information, définit 5 champs d’investigation :

  • Audit d’architecture
  • Audit de configuration
  • Audit de code source
  • Tests d’intrusion
  • Audit organisationnel et physique

Un référentiel d’exigences définit le cadre méthodologique et réglementaire des audits de sécurité. Il comporte également des notions pratiques, telle qu’une échelle de classification des vulnérabilité.

Défi 11 : Essayer d’évaluer la sécurité d’une application + Défi 14 : Développer un plan de test incluant des tests de sécurité

L’intérêt d’une évaluation de la sécurité (en anglais « security posture assessment ») est de pouvoir prendre une décision en fonction des risques. Cette décision peut être de mettre ou non un applicatif en production.

Pour mener à bien cette activité, nous avons procédé de cette manière :

  • Définition du périmètre à tester
  • Définition de scénarios à l’aide du modèle STRIDE.
  • Lancement d’un scan de vulnérabilités avec le logiciel ZAP
  • Tests d’intrusion manuels suivant les scénarios les plus critiques
  • Etablissement d’une matrice de risques en tenant compte de la facilité à accéder aux informations critiques. La sévérité des risques est calculée en s'appuyant sur le modèle DREAD (Dommages + Reproductibilité + Exploitabilité + Affectation des utilisateurs + Découvrabilité)

Défi 12 : Se demander à quel moment du cycle de développement les tests de sécurité doivent être réalisés

Dans le cycle de développement logiciel, à quel moment faire intervenir les tests de sécurité ?

Les scans de vulnérabilité sont si rapides qu’ils peuvent être lancés à tout moment. L’intérêt est de pouvoir détecter les failles le plus tôt possible afin de pouvoir y répondre rapidement et adéquatement. Des scans peuvent être directement incorporés dans la chaîne d’intégration continue, par exemple grâce aux plugins Jenkins ZAP (Zed Attack Proxy), VAddy, Walti.

Pour ce qui est des tests d’intrusion, la réponse est moins évidente. En effet, il paraît fructueux de ne pas raisonner en fonction du cycle de développement (approche boîte noire), car une attaque extérieure peut survenir à tout moment. Cela dit, le testeur peut également tirer profit des informations qu’il connaît : la date et l’heure du déploiement en environnement de test, certains mots de passe, ou encore les dates de congés de l’administrateur système. Avec cette approche « boîte grise », il devient capable de trouver d’autres failles de sécurité.

Nous n’avons pas trouvé de ressources répondant à cette question. Si vous avez des pistes, merci de nous laisser un commentaire.

Défi 22 : Trouver une problématique de sécurité logicielle concernant son environnement technique & Défi 24 : Appliquer une suggestion issue de la checklist OWASP Web Application Security

Cette checklist se trouve ici.

En plus d’être d’une aide pratique au moment de se lancer dans des tests de sécurité d’une application, elle montre que la frontière entre tests fonctionnels et tests de sécurité est assez ténue. Les items à tester lors de la validation d’une fonctionnalité d’authentification illustrent bien cette proximité :

  • Force du mot de passe choisi par l’utilisateur
  • Fonctionnalité de sauvegarde temporaire des informations de connexion (« Remember me »)
  • Fonctionnalité de réinitialisation du mot de passe
  • Fonctionnalité de changement du mot de passe
  • CAPTCHA
  • Authentifications à plusieurs facteurs
  • Déconnexion
  • Présence d’identifiants par défaut
  • Notifications (de succès ou d’échec)
  • Authentification inter-applicative utilisant une authentification unique (SSO)
  • Force des questions servant à la récupération des mots de passe

Défi 29 : Chercher des standards de sécurité spécifiques à un domaine

Une famille de normes est consacrée à la sécurité de l’information : ce sont les normes ISO 27000. Cette page fournit un schéma qui permet de comprendre leurs liens de parenté.

Un audit de sécurité peut être effectué dans l’optique d’obtenir la certification ISO 27001, qui établit des spécifications de sécurité de l’information. Dans ce cas, le processus dure trois ans. Lors de la première année, un audit complet est effectué et les non-conformités sont résolues. Un suivi est effectué lors des deux années suivantes.

Cette norme est destinée à accompagner la mise en place d’un système de management de la sécurité de l’information (SMSI). Respectant explicitement le principe de la roue de Deming (PDCA : Plan, Do, Check, Act), elle illustre parfaitement la maxime du cryptologue Bruce Schneier : « Security is not a product; it’s a process ». Elle est téléchargeable gratuitement à cette adresse.

La norme ISO 27002, qui se réfère étroitement à la 27001, développe plus en détail les bonnes pratiques, ne représente pas une condition pour obtenir la certification.

Conclusion

  • Les objets et les techniques des test de sécurité sont multiples. Mettre en oeuvre les tests adéquat requiert une étude approfondie du contexte.
  • Comme pour les tests fonctionnels, il existe une complémentarité entre les tests manuels et automatisés. Il ne s’agit pas de choisir entre l’une et l’autre de ces approches.
  • La sécurité de l’information, même si elle n’est jamais totalement garantie, peut être favorisée au sein d’un organisation par l’application de standards nationaux et internationaux.

Rendez-vous sur notre article suivant, qui porte sur les défis liés aux outils de test de sécurité !

Un avis ? Un commentaire ?

Cet espace est pour vous.