Demystification du test d'intrusion
Article écrit par Pierre Jaury, formateur chez Sysdream. Merci à lui.
Cela fait quelques années déjà que le test d’intrusion est bien installé dans les mœurs des DSI. Quelques-un en ont mené de front, certains les ont encadrés, observés, et la plupart ont au moins eu écho de la présence pas rassurante d’un “pentesteur” dans les locaux ; pire : sur le réseau.
Il attaque et il effraie, on ne sait ni combien ni comment mais on craint pour ses données. Et pourtant bien rares sont ceux qui réalisent l’intérêt profond du test d’intrusion ou ses aboutissants. Ce bref article ne fait pas état de méthodologies ou de techniques d’attaque mais cherche à démystifier ces prestations.
Test de pénétration ?
Outre Atlantique on le nomme plutôt “Penetration Test” ou “Pentesting” et il est vrai que les anglophones jouent également de la connotation et s’en amusent. Il n’est pas rare en débarquant chez un client étranger de deviner un sourire moqueur quand le responsable sécurité vous présente aux employés comme « penetration tester » ; c’est sans oublier le ton presque scabreux des « So, will you penetrate us? »
Bien connus pour leur pudeur et leur professionnalisme, les francophones préfèrent le « test d’intrusion » pour désigner ce type de prestations. *Exit* donc le « test de pénétration » et autres variantes, les deux termes sont savamment choisis.
Tester d’abord, car il s’agit bien d’évaluer quelque chose et d’établir un rapport de la sécurité d’une société, de ses systèmes. Intrusion ensuite, puisqu’on ne se contente plus d’observer et relater : on entre bel et bien sur les systèmes comme le ferait un attaquant réel.
En d’autres termes, le test d’intrusion consiste à adopter le rôle d’un individu malveillant afin d’identifier des problèmes (vulnérabilités), tenter de s’introduire afin de mesurer l’impact d’une réelle attaque et évaluer la sécurité des systèmes d’information.
Auditer et tester les systèmes d’information
On confond bien souvent le test d’intrusion et l’audit de sécurité, à tort. Si l’un va difficilement sans l’autre, il s’agit bien de deux approches complètement différentes qui visent toutes les deux à mesurer le niveau de sécurité d’un système d’information.
Auditer, c’est d’abord vérifier. Loin d’être complètement binaire, c’est toutefois le propre de l’audit que de déterminer si un système est conforme ou pas. Et qui dit conformité entend critères ! Aussi audit rime avec « checklist » d’éléments à valider ou éliminatoires. Sans généraliser trop, un audit nécessite le plus souvent une préparation technique et documentaire supérieure à un test ; il est également intrinsèquement limité dans la durée, la liste de critères ayant une fin. En ressort le plus souvent, un rapport complet mettant en valeur les critères intéressants ainsi qu’une note ou bien un « oui/non » de conformité.
Les exemples classiques incluent la majorité des audits certifiants (audits organisationnels, réglementation bancaire, etc.) mais également des prestations purement techniques : Auditer un code source, c’est vérifier s’il répond aux normes fixées ; auditer une configuration, c’est vérifier une liste de critères de conformité (les agences gouvernementales en charge de la sécurité des systèmes d’information éditent par exemple des référentiels en ce sens).
À l’inverse, un test et notamment le test d’intrusion n’est pas borné par une liste de points à vérifier. Il s’agit au contraire pour un pentesteur de découvrir des problèmes souvent mal détectés lors d’audits. En respectant les limites contractuelles (il faut bien s’arrêter quelque part, on fixe donc au moins des limites d’espace et de temps), le test d’intrusion consiste à imaginer où et comment développeurs, administrateurs, souvent même utilisateurs des systèmes d’information ont commis des erreurs.
En ce sens, le test d’intrusion est plus réaliste que l’audit en termes d’attaques menées, de démarches employées. Le rapport est toutefois bien plus difficile à établir et souvent moins complet : la limite de temps imposée oblige le pentesteur à prioriser ses recherches de vulnérabilités et ses tentatives d’intrusion là où un attaquant malfaisant n’est borné que par la motivation.
Évaluer et mesurer
On évalue la sécurité, on mesure le risque. Mais en pratique, à quoi s’apparentent ces métriques et que qualifient-elles vraiment ?
Le risque est la mesure d’une nuisance incertaine. Particulièrement difficile à appréhender, il tient compte d’aspects orthogonaux pour quantifier un effet potentiel. La littérature en gestion du risque le qualifie souvent d’effet de l’incertitude sur le résultat, ou bien sur l’atteinte des objectifs. Bien trop globale pour être appliquée à l’analyse des éléments techniques identifiés lors d’un test d’intrusion, on préfère généralement à cette définition des approches beaucoup plus pragmatiques.
De nombreuses méthodologies de gestion de la sécurité ou des tests d’intrusion proposent des approches adaptées à l’analyse du risque informatique. La très populaire méthode française EBIOS adopte une approche confrontant les événements redoutés et les éléments de menace. En identifiant les points essentiels pour la sécurité du système d’information et en déterminant quels scénarios peuvent les compromettre et dans quelle mesure, on évalue efficacement le risque associé à chaque combinaison. La priorisation des actions n’en est que facilitée.
Plus terre-à-terre encore, l’analyse proposée par les méthodes OWASP et OSSTMM se rapproche des définitions du risque en ingénierie : la combinaison d’un impact et d’une probabilité. Plus l’impact (atteinte à la confidentialité des données, à l’image de la société, etc.) est élevé, plus le risque est important. Plus la probabilité d’intrusion en un point (facilité de découverte, d’exploitation d’une vulnérabilité, etc.) est grande, plus le risque est important.
On préfère souvent une combinaison de ces approches. Dans une première phase très technique, le pentesteur identifie les problèmes individuels et évalue le risque associé en combinant probabilité et impact. Dans une seconde phase, il juge de la sécurité du système d’information dans son ensemble et prend en compte le contexte métier des systèmes testés, les événements les plus redoutés par le client et les scénarios plausibles exploitant les vulnérabilités qu’il a découvertes.
Pentesteurs et Hackers
Et le hacking dans cette histoire ? Pas là pour discuter de la juste définition entre esr et rms, on en propose une qui reprend les principaux éléments sans disserter : le hacking n’est pas une discipline mais une approche applicable à de nombreuses disciplines. Avec pour objectifs de résoudre des problèmes et d’augmenter le savoir, il se concentre sur le détournement d’outils et techniques existantes, l’utilisation de la technologie de façon experte mais ludique et curieuse, sans chercher nécessairement l’application immédiate.
Le hacking, c’est essayer de manger en remplaçant la fourchette par trois paires de baguettes. L’application pratique n’est pas évidente, mais nécessite une maîtrise fine des outils et détourne clairement les techniques habituelles. Le hacking, c’est démonter la télécommande du téléviseur non pour changer les piles mais pour en comprendre le fonctionnement et pourquoi pas y ajouter un bouton ou en dériver d’autres outils bien pratiques.
L’approche du hacker s’applique à de nombreuses disciplines, notamment à la sécurité informatique où il a permis de soulever de nombreuses questions. Que se passe-t-il si j’utilise cette variable pourtant non allouée ? Comment se comporte l’application si mon numéro de téléphone contient autre chose que des chiffres ? Autant de questions curieuses que pose le hacker et qui mettent le doigt sur les sources usuelles de vulnérabilités informatiques.
Le hacker n’est donc pas un attaquant, malveillant ou pentesteur. Mais le pentesteur a tout intérêt à être familier de la démarche propre au hacking pour poser rapidement les questions pertinentes et découvrir les problèmes techniques du système d’information beaucoup trop vaste pour que chaque élément fasse l’objet de vérifications complètes.
Là où la communauté de hackers était majoritairement constituée de chercheurs et développeurs jusque dans les années 1980, elle a largement évolué depuis et se compose effectivement aujourd’hui de bon nombre d’amateurs ou professionnels de la sécurité informatique, motivation oblige.
Penser et agir comme un attaquant
Pour mener à bien sa prestation, le pentesteur se met dans la peau d’un attaquant réel. Bien plus qu’une prestation théâtrale, il s’agit d’adopter les outils, les techniques et la démarche de l’individu malveillant.
La démarche notamment a été formalisée pour professionnaliser l’attaque des systèmes d’information. On retrouve dans les méthodologies de test d’intrusion les étapes usuelles franchies par les attaquants malintentionnés : cerner sa cible et identifier les éléments de valeur, découvrir le périmètre attaquable et les points apparemment les plus faibles, s’introduire sur les systèmes et y maintenir un accès, limiter les traces de son intrusion, etc.
La ressemblance avec le véritable attaquant s’arrête aux limites du « périmètre ». Cette frontière virtuelle définie contractuellement borne le pentesteur : temps limité, techniques tolérées, cibles autorisées, autant de clauses qui rendent la prestation possible en l’encadrant mais qui s’opposent au réalisme recherché lors d’un test. Le compromis lié au périmètre est ainsi l’une des étapes les plus cruciales et délicates de la préparation d’un test d’intrusion.
Le test d’intrusion : un métier
Le test d’intrusion est une activité épanouissante. Il s’agit d’une très bonne porte d’entrée sur le milieu de la sécurité informatique, d’un excellent prétexte pour s’intéresser au hacking. Les missions y sont souvent courtes et variées, l’ennui s’y fait rare et les voyages fréquents.
C’est aussi un métier très exigeant. On ne l’improvise pas, ne serait-ce que réglementairement : le code pénal (articles 323-1 à 323-7) rappellera aux apprentis pentesteurs l’importance du cadre contractuel et légal des prestations. On s’y repose peu également : les missions sont intenses ; il n’est pas rare de découvrir une technologie le lundi matin et de devoir en maîtriser les rouages fonctionnels et techniques le soir même. Il faut en très peu de temps cerner les aspects bas niveau et prendre du recul sur un système d’information, son contexte métier.
C’est finalement un domaine encore mûrissant où l’activité ne manque pas, un marché grandissant où les acteurs, les offres, évoluent rapidement. Encore méconnu et réservé à quelques industriels il y a dix ans, le test d’intrusion s’est formalisé, professionnalisé, a encore gagné en crédibilité depuis la création de l’ANSSI et se diversifie récemment avec la multiplication des projet de type bug bounty. Il ne fait aucun doute que le paysage professionnel aura à nouveau largement évolué d’ici à 2020.
Que faire après le bac quand on est passionné de cybersécurité ?
Entièrement dédiée à la cybersécurité, l'école Guardia est accessible soit directement après le bac (post-bac), soit après un bac+2 ou bac+3. En rejoignant l'école Guardia, vous deviendrez développeur informatique option cybersécurité (Bac+3) ou expert en cybersécurité (Bac+5).