Mois : février 2017

Le principe

Notre série d’article sur le défi de Ministry of Testing, 30 Days of Security Testing, se termine aujourd’hui avec un article dans lequel sont regroupé les défis qui permettent d’enrichir sa connaissance générale des tests de sécurité (actualités, aspects sociologiques, mises en application).

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

Les challenges

Défi 10 : Comprendre ce qu’est l’« ethical hacking » & Défi 30 : Découvrir la différence entre les hackers black hat, white hat et grey hat

Pour rappel, en anglais « to hack » veut simplement dire « bidouiller », il n’y a pas de connotation négative en soi.

Alors que le hacker malveillant (ou black hat) tire profit des failles de sécurité à des fins personnelles, l’ethical hacker (ou white hat) les documente et propose des pistes afin de les solutionner. Il est en possession de toutes les autorisations nécessaires pour entrer dans le système à tester.

Comme vu précédemment, certaines entreprises embauchent des spécialistes en tests de sécurité (qui, par nature, sont des ethical hackers) afin de réaliser un audit. D’autres choisissent de récompenser les personnes qui leur rapportent bénévolement des failles de sécurité découvertes dans les limites de la légalité. Ces récompenses sont appelées « bounties ».

Si le hacker entre dans le système sans disposer des autorisations nécessaires, mais ne commet aucun acte malveillant, on parle de hacker « gray hat ». Des sites comme CVE Details (common vulnerabilities exposure) ou NVD (National Vulnerability Database) répertorient les failles de sécurité d’une multitude de produits.

L’imagerie populaire du hacker est déconcertante : nous serions tentés de croire que tous portent une capuche en permanence. En cause, une méconnaissance de l’activité de hacking, comme en témoigne cette interview d’un photographe de la banque d’images Shutterstock. Il serait pourtant utile que l’activité de hacking, de même que la sécurité informatique, soit mieux comprise, afin que chacun puisse mettre en oeuvre le nécessaire pour se protéger.

Défi 17 : Trouver une faille de sécurité récente

Lorsqu’une faille de sécurité est découverte dans un SI, volontairement ou non, le fait de la rapporter à l’organisation concernée sans exploiter la faille est appelé « disclosure ». Un acte bénévole dont il peut être risqué de parler, comme l’a montré en 2009 l’affaire Forever living products contre Zataz. Le fait de rendre une faille publique avant sa correction (chose que n’avait pas fait Zataz) est appelé « full disclosure ».

L’équipe Project Zero, qui regroupe sous l’égide de Google des spécialistes en sécurité informatique, a pour objectif de trouver des failles de sécurité « zero day », c’est-à-dire n’ayant jamais été exploitées. Leur ligne de conduite : informer immédiatement l’organisation responsable de l’application (disclosure), et ne procéder à une full disclosure qu’après que celle-ci a fourni un patch, ou au bout de 90 jours.

Le 25 novembre dernier, Google a informé Microsoft d’une faille de sécurité présente dans les navigateurs Internet Explorer et Edge. Malheureusement, Microsoft n’a pas été en mesure de fournir un patch dans les temps, et la faille est désormais publique et exploitable même dans la dernière version ! Voici son ticket d’anomalie.

Défi 20 : S’informer sur les attaques DOS/DDOS.

Une attaque DDOS (Distributed Denial Of Service) est une attaque visant à rendre indisponible un serveur. Son qualificatif « Distributed » est employé lorsque l’attaque provient de plusieurs machines différentes. Lorsque l’origine est une unique machine, on parle simplement d’attaque DOS.

On peut distinguer les attaques DDOS réseau et applicatives. Dans le premier cas, on sature la connexion réseau d’un serveur afin de le rendre incapable de répondre aux requêtes. Dans le second, après identification des actions de l’application qui demandent beaucoup de ressources (par exemple, des calculs impactant de nombreuses lignes en base de donnée), l’attaque consiste à les répéter jusqu’à saturation du serveur (source).

Un site web permet de visualiser sur une carte les récentes attaques DDOS.

Défi 23 : Quelles sont les 10 menaces de sécurité les plus courantes en 2016 ?

La liste des 10 failles de sécurité les plus courantes est éditée tous les trois ans par la fondation OWASP. La liste qui devait paraître en 2016 a été repoussée en 2017. L’équipe OWASP explique que le classement est resté sensiblement le même. Voici donc le classement de 2013.

Défi 26 : Comparer les tests de sécurité web et mobiles

Les tests à effectuer dépendent des menaces inhérentes à un système donné.

Certaines menaces sont propres aux applications web, comme les vulnérabilités liées aux cookies. Ces petits fichiers, stockés sur la machine cliente au cours de la navigation, qui contiennent des informations utiles : pages visitées, actions effectuées sur le site, mots de passe.

D’autres sont spécifiques aux applications mobiles, qui demandent des permissions susceptibles de compromettre les informations personnelles de l’utilisateur.

Mais les frontières des menaces tendent à se brouiller, notamment avec l’essor de frameworks tels que Cordova ou Ionic, qui permettent de développer des applications mobiles en se servant de technologies web. Les applications mobiles ne sont plus, logiquement, à l’abri des injections Javascript.

Défi 27 : Comment la tendance BYOA peut-elle affecter la sécurité ?

BYOA signifie « bring your own application » : cette tendance désigne par exemple les employés utilisant Google Docs avec leur compte personnel en lieu et place du SharePoint de leur entreprise. On parle aussi de shadow IT.

Plusieurs points peuvent être soulevés :

• En stockant des informations sur un outil tiers de son choix (souvent un cloud), l’utilisateur endosse la responsabilité de leur sécurité et devient en même temps dépendant du niveau de sécurité de l’application choisie. Un aspect que ni lui, ni son entreprise, ne maîtrisent. Un éditeur de bonne foi n’est pas à l’abris d’une fuite de données. En outre, l’utilisation des données stockées sur un outil tiers ne peut pas être entièrement maîtrisée.
• En cas de vol de son ordinateur, l’utilisateur est le seul à pouvoir mettre en oeuvre la protection de ses données (changement immédiat des mots de passe).
• En cas de vol d’identifiants, l’utilisateur n’a plus aucune prise sur l’utilisation du contenu qu’il a stocké sur un outil tiers.

Pour répondre à ces risques, certaines entreprises mettent en place une politique d’utilisation de logiciels tiers afin de sensibiliser aux menaces de cette tendance et de responsabiliser les employés.

Défi 28 : Partager des idées concernant les tests de sécurité dans un domaine particulier

Nous avons choisi de ne pas nous pencher sur un domaine en particulier, mais plutôt sur un type d’applicatif que nous utilisons quotidiennement : les logiciels open-source.

Logiquement, les failles d’un logiciel open source sont plus susceptibles d’être découvertes par le public que celles d’un logiciel propriétaire. Mais elles sont également plus susceptibles d’être révélées à son éditeur par la communauté, et donc plus vite corrigées. A contrario, les failles d’un logiciel propriétaires ne sont susceptibles d’être découvertes que par son éditeur lui-même, ou par les hackers black et grey hat. Les logiciels propriétaires ne sont pas à l’abris du reverse engineering, une pratique pourtant souvent interdite par les conditions générales d’utilisation.

Voici quelques articles ressources que nous avons trouvé sur le sujet :

• Is Open Source Software More Secure? de Russell Clarke et David Dorwin. Ce document donne une vue d’ensemble de la problématique
• Security Concerns in Using Open Source Software for Enterprise Requirements, de l’Institut SANS. Ce livre blanc fournit des bonnes pratiques afin de répondre aux enjeux spécifiques des logiciels open source dans l’entreprise.

… Défi 15 : S’exprimer sur les tests de sécurité sur les réseaux sociaux ou un blog

Voilà qui est fait. Déjà la fin des 28 jours de test de sécurité ! Si vous aussi avez participé au défi, laissez-nous un commentaire avec vos articles de blog, nous sommes curieux de les lire.

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Le kit de secours métaphorique du testeur agile

Notre série dédiée à Protractor

Le principe

Voici notre troisième article consacré au défi lancé par Ministry of Testing au mois de février : 30 Days of Security Testing.

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

Les challenges

Défi 3 : Use a security tool – Examples: ZAP or BurpSuite & Défi 8 : Utiliser un outil de proxy pour étudier le trafic d’un site web ou d’une application mobile

Comme nous privilégions les solutions open-source, notre choix s’est tourné vers ZAP (Zed Attack Proxy, anciennement WebScarab). ZAP est une application lourde qui peut être enrichie par une gamme d’extensions. BurpSuite nous a semblé prometteur, mais comme les fonctionnalités qui nous intéressaient le plus sont payantes (voir le tableau des formules), nous l’avons laissé de côté.

La prise en main de ZAP est très rapide. Une fois l’installation terminée, l’utilisateur est invité à entrer une URL à attaquer. Après validation, le diagnostic commence.

Attention, il faut avoir une autorisation écrite pour attaquer un site qui n’est pas à soi. Pour tester ZAP, nous avons d’abord lancé une analyse en local sur notre test ISTQB.

Après quelques secondes, une liste d’alertes est générée, qui affiche les failles de sécurité identifiées.

Dans le détail de chaque alerte, il est clairement expliqué en quoi la pratique mise en avant est dangereuse, par exemple, ci-dessous, la corrélation directe entre absence d’en-tête X-Frame-Options et risque de ClickJacking. Dans cet exemple, la traduction française est prise en charge, mais ce n’est pas toujours le cas.

Dans un deuxième temps, nous avons réalisé une attaque sur une de nos applications de test, qui contient un formulaire d’inscription. Et là, ZAP s’en donne à coeur joie : en une minute, une centaine de nouveaux comptes sont créés. Aucune alerte n’apparaît, mais le problème est bien visible.

Défi 6 : Explorer Google gruyere, HackYourself First, Ticket Magpie et The BodgeIt store

Google Gruyere, Hack Yourself First, Ticket Magpie et The BodgeItStore sont de sites à vocation pédagogique que contiennent de nombreuses failles de sécurité. Ce sont des terrains de jeu où l’utilisateur est encouragé à effectuer des tests de sécurité. Retenez bien ces adresses ; le nombre d’applications dont vous avez le droit de tester la sécurité est très réduit, et celles-ci en font partie.

Lançons un scan ZAP sur Hack Yourself First. Comme promis, une flopée de failles de sécurité sont découvertes :

Rendons-nous sur la page où est diagnostiquée la première erreur.

Maintenant, si nous entrons une valeur inattendue pour le paramètre orderby (par exemple « youpi »), l’erreur n’est pas correctement gérée ; nous obtenons une stack d’erreur qui contient des informations fort intéressantes. Ici, en fin de page, le type et la version du framework utilisé pour développer cette application.

Un comportement à la fois risqué d’un point de vue de la sécurité, et désagréable d’un point de vue UX.

Nous avons découvert un autre site proposant des exercice des hacking, Hack this Site!, qui propose des tutoriels de hacking à niveau croissant.

Défi 13 : Intégrer un aspect de sécurité dans une user story

Ce défi en cache un autre : comment intégrer les tests de sécurité à un cycle de développement agile ?

Approche « utilisateur honnête »

Si l’on reprend l’exemple précédent d’un point de vue utilisateur, cette user story pourrait être :

« En tant qu’utilisateur (inscrit ou non) de Supercar Showdown, je veux obtenir une réponse compréhensible quels que soient les caractères que j’ajoute à la suite de l’URL, afin que mon expérience sur le site soit fluide et cohérente.

Critères d’acceptation :

• Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur une page d’erreur indiquant « La ressource demandée n’existe pas. »
• Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la page d’erreur précédemment évoquée. »

Vérifions que cette user story est conforme au modèle INVEST :

• Indépendante : (oui)
• Négociable : oui, car la mention « quels que soient les caractères que j’ajoute » peut être précisée selon les besoins du client.
• Valorisable : oui, et l’intérêt est double : une meilleur expérience client et une meilleure protection des informations techniques du produit.
• Estimable : (oui)
• Suffisamment petit : à valider selon la complexité de l’architecture technique du site.
• Testable : oui, des critères d’acceptabilité sont présents.

Certaines affirmations sont entre parenthèses car elles dépendent du reste du projet (autres US, taille de l’équipe, durée des sprints, complexité de l’application…), élément sur lesquels nous n’avons pas assez d’informations.

Approche hacker

Afin d’intégrer pleinement les tests de sécurité aux projets agiles, la fondation OWASP (Open Web Application Security Project, qui est à l’origine du logiciel ZAP) recommande de créer des user stories « diaboliques » (evil user stories), dont le protagoniste n’est autre qu’un hacker. L’enjeu est, à chaque sprint, de s’assurer que ces user stories ne passent pas dans la colonne « terminé ». Nous aurons alors :

« En tant que hacker, je peux accéder aux stacks d’erreur afin de collecter des informations techniques sur l’application. »

Critères d’acceptation :

• Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur la stack d’erreur générée automatiquement par le framework.
• Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la stack d’erreur. »

Une autre appellation de ce type d’US : abuser story.

Approche implicite

Une autre approche consiste enfin à intégrer la sécurité dans la définition de « terminé ». Quelques exemples d’implémentation de cette stratégie peuvent être trouvés ici.

Défi 16 : Trouver comment créer une tiger box

Une tiger box est un ordinateur contenant les outils requis pour réaliser un audit de sécurité. Cet ordinateur doit pouvoir mettre à disposition plusieurs systèmes d’exploitation. Cela peut se faire en créant plusieurs options de boot ou en utilisant des outils tels que VirtualBox.

La distribution Linux nommée Kali Linux est une tiger box en soi. Dédiée à la sécurité informatique, elle contient une suite d’outils de test d’intrusion.

Défi 25 : Trouver et utiliser un outil de sécurité mobile

La fondation OWASP propose une application mobile de sécurité gratuite nommée SeraphimDroid. Elle identifie rapidement les failles de sécurité d’un téléphone, ajoute un niveau de sécurité supplémentaire en permettant plusieurs types de verrouillage :

• automatique, par application. A chaque fois qu’il souhaite les utiliser, l’utilisateur déverrouille avec un code d’accès les applications qu’il a choisies.
• automatique, par géolocalisation. L’appareil devient inutilisable s’il sort d’un périmètre défini par l’utilisateur.
• manuel, à distance.

L’application avertit l’utilisateur lorsqu’il reçoit des SMS ou MMS malveillants.

Davantage d’informations dans cette documentation.

Conclusion

• Il existe des sites web spécialement conçus pour qu’on les hacke afin de se former aux tests de sécurité.
• Des outils permettent d’établir un diagnostic rapide des failles de sécurité les plus connues. Les scans sont si rapides qu’ils peuvent être faits en environnement de test ou de préproduction à chaque nouveau déploiement de l’application.
• Il est possible d’inclure des outils de test de sécurité dans une chaîne d’intégration continue. Le test de sécurité agile est en pleine expansion.

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. EDIT du 21 février 2019 : le schéma n’est malheureusement plus disponible en ligne. Et si on le sait, c’est grâce à JSoup et Gatling 🙂

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é !

Le principe

Ministry of Testing est une mine d’or qui permet de se tenir au courant de ce qui se passe dans le monde du test. Au début du mois de février, un défi a été lancé dans le Dojo, l’espace dédié à sa communauté : 30 Days of Security Testing. Le principe : pendant un mois, se former aux tests de sécurité en réalisant 31 défis.

Pourquoi participer ?

Les tests de sécurité représentent une discipline à part entière, voire plusieurs disciplines. Le but de ce défi est de prendre la mesure des risques, des types de solutions et des méthodologies existantes, afin d’enrichir sa façon de tester.

Notre feuille de route

Nous avons réparti les 31 défis du Dojo en 4 catégories, dont chacune fera l’objet d’un article.

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

Comme la répartition est thématique, les numéros des défis ne se suivent pas forcément.

Avant de commencer

Attention, les tests de sécurité font appel à des techniques qui, selon la façon dont elles sont employées, peuvent être illégales. Il est de la responsabilité du testeur d’obtenir les autorisations nécessaires avant de pratiquer des tests de sécurité sur un système. Soyez très précautionneux avant de vous servir des tutoriels et des outils à votre disposition. Si vous avez un doute, préférez ne rien faire plutôt que de risquer des poursuites, ou mettre en danger le fruit du travail d’autres personnes.

Les challenges

Défi 1 : Lire un blog sur la sécurité informatique

Nous avons apprécié le blog de Veracode, qui contient de bons articles de fond sur l’implémentation d’une politique de sécurité au sein d’une entreprise. Celui-ci évoque les réactions parfois conflictuelles des équipes de développement lorsqu’elles sont confrontées à leurs responsabilités en termes de sécurité informatique.

Défi 2 : Lire un livre sur les tests de sécurité

La sécurité informatique n’est pas seulement une affaire d’outils, mais également de prudence humaine. Afin d’explorer ce deuxième axe, nous avons choisi de lire L’Art de la supercherie de Kevin Mitnick (2002), un livre qui fournit de nombreuses pistes pour contrer les attaques basées sur l’ingénierie sociale.

Dans le domaine de la sécurité de l’information, l’ingénierie sociale est une pratique qui consiste à extorquer des informations en abusant de la crédulité des personnes qui y ont accès. Selon l’auteur, le facteur humain représente le pire danger dans le domaine de la sécurité informatique.

Une information jugée anodine, comme un terme de jargon (qui n’est pas traitée en soi comme une information confidentielle), peut être un outil redoutable pour une personne souhaitant obtenir, en abusant de la confiance des collaborateurs, des informations plus sensibles.

L’auteur développe la notion de compromis entre sécurité et productivité. Une attitude trop laxiste ou insouciante est évidemment dangereuse, mais une position trop défensive peu donner une mauvaise image de l’entreprise, aussi bien que des processus trop sécurisés peuvent freiner la performance d’une entreprise.

Ce livre est donc une excellente base de réflexion sur l’ingénierie sociale. Une lecture complémentaire : cette liste des 25 principaux biais cognitifs. La plupart des biais énumérés peuvent être exploités afin de mettre en danger la sécurité informatique d’une entreprise. La croyance en un monde juste est un biais très commun, souvent évoqué par Kevin Mitnick, et qui représente souvent un obstacle à la compréhension des politiques de sécurité informatique.

Défi 18 : S’informer sur les en-têtes de sécurité

Les en-tête HTTP (ou headers en anglais) contiennent des informations échangées par le navigateur et le serveur. Ils impactent la façon dont l’un et l’autre devront se comporter. Quand un navigateur envoie au serveur l’en-tête user-agent, il lui donne des informations sur sa version, son système d’exploitation ou la langue utilisée. En retour, le serveur peut renvoyer une page web adaptée au profil du navigateur.

Pour savoir quels en-têtes renvoie un site web en particulier, rendez-vous sur Web Sniffer.

Certains en-têtes jouent un rôle critique en sécurité informatique, comme X-XSS-Protection, qui protège contre une partie des risques de cross-site-scripting. Un site web existe, qui permet d’évaluer la sécurité d’un site web par la configuration de ses en-têtes HTTP : Security Headers.

Pour en savoir plus, et en particulier sur la manière de modifier les en-têtes HTTP, nous vous conseillons cet article.

Défi 19 : Comprendre ce que sont les « script kiddies » et les « packet monkeys »

Les Script Kiddies sont « les hackers débutants qui ne s’embarrassent pas de connaissances techniques et se contentent de télécharger les outils des hackers pour s’introduire dans des systèmes informatiques » (Kevin Mitnick, L’Art de la supercherie).

Les Packet Monkeys sont des Script Kiddies qui se spécialisent dans l’envoi massif de paquets en vue de provoquer des dénis de service.

Défi 21 : Trouver une problématique de vulnérabilité réseau concernant son environnement technique

Une problématique réseau nous concerne en particulier, à savoir la sécurité des réseaux Wifi.

Sécuriser son réseau Wifi, quels enjeux ?

• Sécurisation des données : un réseau mal protégé peut permettre l’interception de données ou l’accès aux données des ordinateurs du réseau.
• Disponibilité du réseau : des scripts mal intentionnés peuvent brouiller les transmissions ou provoquer des dénis de service, rendant la Wifi inutilisable.
• Responsabilité de l’utilisation des données : en cas d’utilisation frauduleuse d’Internet (ex : téléchargements illicites), le propriétaire du réseau utilisé est très souvent mis en cause. La loi Hadopi notamment pointe du doigt les propriétaires faisant preuve de « négligence caractérisée », même si c’est une autre personne qui exploite illégitimement leur réseau.
• Protection des ressources : si un inconnu se retrouve capable d’utiliser le réseau Wifi pour accéder à Internet, les performances seront affectées en fonction de son utilisation. Cela peut, en corollaire, faire augmenter la facture du FAI.

Des applications mobiles telles que Fing permettent d’obtenir la liste des autres appareils connectés sur le réseau WIFI, ainsi que leur nom, leur IP locale, leur marque, leur adresse MAC (Media Access Control), et ainsi initier une phase de scanning. Ces informations sont même directement exploitables : l’adresse MAC peut en effet être utilisée à des fins d’usurpation d’identité, ce qui peut se révéler utile en cas de filtrage d’accès par adresse MAC. Par ailleurs, ces informations peuvent également être utiles dans une stratégie reposant sur l’ingénierie sociale.

Les enjeux que nous venons d’évoquer reflètent des menaces pouvant être extrêmement critiques. Or, au sein d’une société, il est monnaie courante de partager son accès Wifi auprès de ses clients, prospects, ou toute personne participant à des ateliers animés en interne. Il est intéressant d’évaluer les risques qu’une telle pratique présente. La problématique soulevée par Kevin Mitnick dans L’Art de la supercherie (sécurité versus productivité) est tout à fait éclairante ici.

Bonus

Une vidéo de Bruce Schneier, qui donne une vision intéressante et pragmatique de ce qu’est la sécurité. La sécurité (informatique ou non) est envisagée comme un processus toujours en action, une suite d’échanges et de compromis dont on juge à chaque instant s’ils sont avantageux.

Conclusion

Ce que nous retenons de cette première approche des tests de sécurité :

• Il s’agit d’une discipline à part entière, mais dont les frontières se mêlent avec d’autres problématiques qui nous sont proches : tests système, tests d’intégration, tests de maintenabilité. Afin d’assurer une approche globale de la qualité, un testeur gagne à maîtriser les fondamentaux des tests de sécurité.
• La sécurité informatique est l’affaire de tous les employés de l’entreprise. Il existe une tendance de fond qui consiste à responsabiliser les équipes techniques quant aux risques d’intrusion.
• De même qu’il est impossible de prouver l’absence d’anomalies dans une application (c’est le premier principe du test logiciel), il est impossible de prouver l’absence de faille de sécurité. Assurer la meilleure sécurité possible requiert les mêmes qualités de pessimisme et de pragmatisme que dans les autres branches du test.

A bientôt pour la prochaine partie de cette série !