Tests d'Intrusion & Évaluation des Menaces

Comprendre les évaluations de sécurité

Une évaluation de sécurité est une analyse structurée des défenses d'une organisation — ses systèmes, réseaux, applications et processus — pour identifier les faiblesses qui pourraient être exploitées par un attaquant. L'objectif n'est pas de générer une liste de CVE. C'est de fournir une image honnête et fondée sur des preuves de ce qu'un adversaire pourrait accomplir compte tenu de votre posture de sécurité actuelle.

ForgeWork fournit des services de tests d'intrusion et d'évaluation des menaces aux organisations en Belgique et en Europe.

Les évaluations existent sur un spectre. À une extrémité, les scanners de vulnérabilités automatisés effectuent des vérifications larges contre des signatures connues et des problèmes de configuration. À l'autre, les missions red team complètes simulent un adversaire déterminé sur des semaines ou des mois, testant non seulement les contrôles techniques mais aussi les capacités de détection, les réponses humaines et la prise de décision organisationnelle sous pression.

Où votre organisation devrait se situer sur ce spectre dépend de sa maturité, de son modèle de menace et de ses obligations réglementaires. Une organisation qui n'a jamais réalisé d'évaluation de vulnérabilités devrait commencer par là — et non sauter directement à une mission red team. À l'inverse, une organisation mature avec un SOC bien doté et une infrastructure régulièrement patchée tire peu de bénéfice d'un autre scan automatisé ; elle a besoin d'une simulation d'adversaire qui teste ses capacités de détection et de réponse aux limites de ce qu'elle a préparé.

Le paysage des évaluations souffre également d'une terminologie mal utilisée. Le terme « test d'intrusion » est fréquemment appliqué à des missions qui ne sont en réalité que des scans automatisés avec un rapport PDF de marque. Comprendre les différences est important, car chaque type d'évaluation répond à des questions différentes, coûte des montants différents et est approprié à différents stades de maturité sécuritaire.

Pourquoi les évaluations sont importantes

Les organisations existent dans un état de changement continu — nouveaux systèmes déployés, configurations modifiées, employés intégrés, applications mises à jour, ressources cloud provisionnées. Chaque changement peut introduire des vulnérabilités. Les évaluations fournissent des vérifications de réalité périodiques : un instantané de votre posture de sécurité réelle, mesurée par rapport à ce qu'un adversaire rencontrerait.

Sans évaluations régulières, les organisations fonctionnent sur des hypothèses. Elles supposent que leurs règles de pare-feu sont correctes, que leurs correctifs sont à jour, que leurs configurations cloud suivent les bonnes pratiques et que leurs applications web gèrent correctement les entrées. Les évaluations remplacent les hypothèses par des preuves. Parfois les preuves confirment que les choses fonctionnent bien. Plus souvent, elles révèlent des lacunes dont l'organisation ignorait l'existence — des lacunes qu'un attaquant finirait par trouver.

Types d'évaluations

Le tableau suivant détaille les principaux types d'évaluations, leur méthodologie et leurs cas d'utilisation optimaux. Comprendre ces distinctions est essentiel pour sélectionner la bonne mission et définir les attentes appropriées.

Scan de vulnérabilités vs. test d'intrusion : la distinction essentielle

Le malentendu le plus courant en matière d'évaluations de sécurité est de confondre le scan de vulnérabilités avec le test d'intrusion. Un scan de vulnérabilités identifie les faiblesses potentielles en vérifiant les systèmes contre des bases de données de vulnérabilités connues — demandant essentiellement « ce système a-t-il la version logicielle X connue comme vulnérable ? ». Le résultat est une liste de constats avec des niveaux de gravité, dont beaucoup peuvent être des faux positifs ou techniquement exacts mais pratiquement inexploitables dans l'environnement donné.

Un test d'intrusion va plus loin. Le testeur tente activement d'exploiter les vulnérabilités identifiées, chaîne plusieurs constats pour démontrer de véritables chemins d'attaque, et montre ce qu'un attaquant pourrait réellement accomplir : accéder à des données sensibles, escalader les privilèges jusqu'à l'administrateur de domaine, pivoter d'une application exposée sur Internet vers les systèmes financiers internes. Le résultat n'est pas une liste de vulnérabilités — c'est le récit de ce qui s'est passé lorsqu'un attaquant expérimenté a consacré du temps concentré à votre environnement.

Red Team vs. test d'intrusion

Les tests d'intrusion ont généralement un périmètre défini (« tester cette application » ou « tester ce segment réseau ») et les défenseurs savent que le test a lieu. Les missions red team simulent un véritable adversaire : le périmètre est plus large (généralement l'ensemble de l'organisation), seuls quelques dirigeants seniors sont au courant, et l'équipe red team utilise les mêmes techniques que les vrais attaquants — y compris l'ingénierie sociale, l'accès physique et les malwares personnalisés. La question principale à laquelle une mission red team répond n'est pas « quelles vulnérabilités existent ? » mais plutôt « nos défenses peuvent-elles détecter et répondre à une attaque réaliste ? »

Purple Team

Le purple teaming transforme le modèle adversarial en un modèle collaboratif. Le testeur offensif exécute des techniques à partir d'un cadre structuré (généralement MITRE ATT&CK) tandis que l'équipe défensive surveille ses outils de monitoring et tente de détecter chaque technique. Lorsque la détection échoue, les deux équipes travaillent ensemble en temps réel pour comprendre pourquoi et construire de meilleures détections. Le purple teaming est très efficace pour améliorer la couverture de détection car il combine la connaissance de l'équipe offensive sur le fonctionnement des attaques avec la connaissance de l'équipe défensive de l'environnement et des outils.

Notre méthodologie

La méthodologie d'évaluation de ForgeWork s'appuie sur des cadres établis — le Penetration Testing Execution Standard (PTES), le Guide de test OWASP et MITRE ATT&CK — adaptés par notre expérience opérationnelle. Chaque mission suit ces phases, calibrées de manière appropriée au type d'évaluation.

1. Cadrage et règles d'engagement

Avant tout test, nous travaillons avec le client pour définir exactement ce qui sera testé, ce qui est exclu, quelles techniques sont autorisées et quels protocoles de communication s'appliquent si une vulnérabilité critique est découverte pendant les tests. Le document de cadrage devient le contrat de la mission — il protège les deux parties et garantit l'alignement des attentes.

Les conversations de cadrage couvrent : systèmes et réseaux cibles, fenêtre de test, vecteurs d'attaque autorisés, procédures d'escalade pour les constats critiques, informations de contact et toute contrainte légale ou de conformité affectant la méthodologie.

2. Reconnaissance

Nous commençons par la même étape qu'un véritable attaquant : la collecte d'informations. La reconnaissance passive utilise le renseignement en sources ouvertes (OSINT) pour cartographier l'empreinte externe du client : enregistrements DNS, logs de transparence des certificats, dépôts de code publics, informations sur les employés sur les réseaux sociaux et professionnels, identifiants divulgués dans les bases de données de violations, et services exposés sur l'infrastructure accessible depuis Internet.

La reconnaissance active étend cela avec une interaction directe : scan de ports, énumération de services, empreinte technologique et exploration d'applications web. La phase de reconnaissance révèle souvent une exposition surprenante — des serveurs de développement oubliés, des actifs cloud non surveillés, des applications obsolètes encore accessibles depuis Internet.

3. Identification de vulnérabilités

En combinant scan automatisé et analyse manuelle, nous identifions les vulnérabilités sur l'ensemble du périmètre cible. Les outils automatisés offrent une couverture en largeur ; les tests manuels offrent profondeur et contexte. Nous nous concentrons sur les constats qu'un attaquant exploiterait réellement, et non sur les vulnérabilités théoriques nécessitant des conditions improbables dans l'environnement réel.

4. Exploitation

Pour les tests d'intrusion et les missions red team, nous tentons d'exploiter les vulnérabilités identifiées pour démontrer l'impact en conditions réelles. Cette phase distingue une véritable évaluation d'un simple scan — elle répond à la question « et alors ? » en montrant quel accès un attaquant obtient et ce qu'il peut en faire. Nous chaînons les constats lorsque c'est possible, démontrant comment une mauvaise configuration de faible gravité combinée à une faille applicative de gravité moyenne peut produire un chemin d'attaque à impact critique.

5. Post-exploitation

Une fois l'accès initial obtenu, nous évaluons l'étendue de la compromission possible : mouvement latéral à travers le réseau, escalade de privilèges vers un accès administrateur, accès aux dépôts de données sensibles et potentiel d'accès persistant. Cette phase révèle le rayon d'impact réel d'une violation — qui est souvent bien plus large que le point d'entrée initial ne le suggérerait.

6. Rapport

Le livrable qui compte le plus. Nos rapports sont conçus pour être exploitables par les audiences tant exécutives que techniques.

Domaines d'évaluation

Les évaluations de sécurité peuvent être ciblées sur des domaines spécifiques selon les priorités de l'organisation, son modèle de menace et son infrastructure.

Infrastructure réseau

Les évaluations réseau internes et externes évaluent la sécurité des routeurs, commutateurs, pare-feu, VPN, réseaux sans fil et segmentation réseau. Nous testons si un attaquant qui obtient un point d'appui sur un segment réseau peut atteindre les actifs critiques sur un autre. Les constats courants incluent : des règles de pare-feu trop permissives, des architectures réseau plates sans segmentation, des protocoles de gestion non chiffrés, des identifiants par défaut sur les équipements réseau et des opportunités de VLAN hopping.

Applications web

Les évaluations d'applications web suivent la méthodologie du Guide de test OWASP, couvrant le spectre complet des vulnérabilités de la couche applicative : failles d'injection (SQL, commande, LDAP), faiblesses d'authentification et de gestion de session, contournement de contrôle d'accès, cross-site scripting (XSS), références d'objets directs non sécurisées, mauvaise configuration de sécurité et failles de logique métier que les scanners automatisés ne peuvent pas détecter. Nous testons à la fois l'application elle-même et son infrastructure de support — APIs, bases de données, services d'authentification et intégrations tierces.

Environnements cloud

Les évaluations cloud évaluent la posture de sécurité des environnements AWS, Azure et GCP. Le cloud introduit un ensemble distinct de risques : politiques IAM mal configurées accordant des permissions excessives, buckets de stockage accessibles publiquement, données non chiffrées au repos et en transit, groupes de sécurité trop permissifs, absence de journalisation d'audit et fonctions serverless avec des identifiants intégrés. Nous évaluons par rapport aux CIS Cloud Benchmarks et aux bonnes pratiques de sécurité spécifiques au fournisseur cloud.

Applications mobiles

Les évaluations mobiles examinent à la fois l'application cliente (iOS et Android) et ses services back-end. Les tests couvrent : le stockage de données non sécurisé sur l'appareil, la faiblesse de la sécurité de la couche transport, l'authentification et l'autorisation incorrectes, l'injection côté client, la résistance à la rétro-ingénierie et la manipulation en temps d'exécution. Nous suivons la méthodologie OWASP Mobile Application Security Testing Guide (MASTG).

Ingénierie sociale

Les évaluations d'ingénierie sociale testent la couche humaine de défense par des campagnes de phishing, du vishing (hameçonnage vocal), du prétexte et — lorsque autorisé — des tentatives d'accès physique. Ces évaluations mesurent dans quelle mesure la formation à la sensibilisation à la sécurité se traduit en comportement réel dans des conditions réalistes. Les résultats orientent les améliorations de formation ciblées et aident les organisations à comprendre leur exposition réelle aux attaques centrées sur l'humain.

Comprendre votre rapport

Une évaluation de sécurité n'a de valeur que par le rapport qu'elle produit. Si les constats restent non lus parce que le rapport est impénétrable, ou si la remédiation stagne parce que les recommandations sont vagues, l'évaluation a échoué indépendamment de la rigueur des tests.

Les rapports d'évaluation de ForgeWork comprennent les composants suivants :

Résumé exécutif

Un aperçu non technique de l'objectif de l'évaluation, du périmètre, des constats clés et de la posture de risque globale. Rédigé pour les dirigeants, les membres du conseil d'administration et les parties prenantes qui ont besoin de comprendre les implications métier sans lire les détails techniques. Cette section répond à : « Quelle est notre sécurité, quels sont les risques les plus importants, et que devons-nous prioriser ? »

Constats techniques

Chaque constat inclut : une description claire de la vulnérabilité, sa localisation dans l'environnement, les étapes suivies pour la découvrir et l'exploiter, des preuves de concept (captures d'écran, sorties de commandes, données capturées), un score CVSS v3.1 avec ajustements environnementaux, et une évaluation de l'exploitabilité en conditions réelles dans le contexte spécifique du client. Les constats sont catégorisés par gravité et par système ou application affecté.

Récits d'attaque

Pour les tests d'intrusion et les missions red team, nous incluons des descriptions narratives des chemins d'attaque — comment des constats individuels ont été chaînés pour atteindre un impact significatif. Ces récits sont des outils puissants pour communiquer le risque aux parties prenantes non techniques car ils racontent une histoire : « Nous avons commencé par un email de phishing, utilisé les identifiants capturés pour accéder au VPN, exploité une mauvaise configuration pour atteindre le réseau interne, escaladé les privilèges par une attaque Kerberoasting, et accédé à la base de données financière contenant 200 000 dossiers clients. »

Conseils de remédiation

Chaque constat inclut des conseils de remédiation spécifiques et actionnables — pas simplement « appliquer le correctif » mais des étapes détaillées que l'équipe du client peut suivre pour résoudre le problème. Les recommandations sont priorisées par risque et effort : les gains rapides (impact élevé, effort faible) sont signalés pour action immédiate, tandis que les changements architecturaux à plus long terme sont positionnés dans une feuille de route stratégique.

Matrice de priorisation des risques

Une vue consolidée qui cartographie les constats par gravité et exploitabilité, aidant l'équipe du client à concentrer l'effort de remédiation là où il aura le plus grand impact sur la réduction du risque réel. Cette matrice identifie explicitement quels constats un attaquant exploiterait en premier et quels chemins d'attaque représentent le plus de dommages potentiels.

Comment se préparer à une évaluation

La préparation côté client affecte directement la qualité et l'efficacité de l'évaluation. Voici une checklist pratique.

Définir le périmètre clairement

Identifiez les systèmes, applications, réseaux ou environnements spécifiques à tester. Incluez les plages d'adresses IP, les URLs, les identifiants de comptes cloud et tout système explicitement exclu du périmètre. Si certains systèmes sont fragiles (systèmes de production hérités qui pourraient planter sous les tests), signalez-les afin que l'équipe de test puisse ajuster son approche.

Établir les règles d'engagement

Déterminez quelles techniques de test sont autorisées. Les testeurs peuvent-ils utiliser l'ingénierie sociale ? Les techniques de déni de service sont-elles permises ? À quelles heures les tests peuvent-ils avoir lieu ? Quel est le chemin d'escalade si une vulnérabilité critique est trouvée pendant les tests ? Documentez cela par écrit avant le début de la mission.

Préparer les identifiants

Pour les évaluations authentifiées (qui fournissent une couverture plus complète), créez des comptes de test à chaque niveau de privilège évalué. Fournissez ces identifiants de manière sécurisée et prévoyez de les désactiver après la mission. Pour les applications web, préparez des comptes pour chaque rôle utilisateur.

Notifier les équipes concernées

Selon le type de mission, votre SOC, vos équipes d'exploitation IT et cloud peuvent avoir besoin d'être informées. Pour un test d'intrusion avec périmètre connu, notifier le SOC évite un effort gaspillé à investiguer l'activité du testeur. Pour une mission red team où la détection fait partie du test, seul le point de contact désigné doit être informé.

Rassembler la documentation

Les schémas réseau, les documents d'architecture applicative et les rapports d'évaluations antérieures aident l'équipe de test à travailler plus efficacement et à se concentrer sur les domaines les plus susceptibles de produire des constats significatifs.

Contexte de conformité

De nombreux cadres réglementaires et de conformité exigent ou recommandent des évaluations de sécurité. Comprendre quels cadres requièrent quels types d'évaluations aide les organisations à planifier efficacement leurs programmes d'évaluation.

PCI DSS

Le standard de sécurité des données de l'industrie des cartes de paiement exige des scans de vulnérabilités réseau trimestriels par un fournisseur de scan agréé (ASV) pour les systèmes exposés à l'extérieur, et des tests d'intrusion annuels des couches réseau et applicative. PCI DSS v4.0 a introduit des exigences plus rigoureuses pour les scans authentifiés et un périmètre élargi pour les tests d'intrusion.

SOC 2

Bien que SOC 2 n'impose pas de types d'évaluation spécifiques, les Critères Communs exigent que les organisations évaluent la conception et l'efficacité opérationnelle de leurs contrôles. Les tests d'intrusion fournissent des preuves solides pour les critères CC7.1 (détection des événements de sécurité) et CC6.1 (accès logique et physique). La plupart des auditeurs s'attendent à voir des évaluations de vulnérabilités régulières et des tests d'intrusion périodiques.

ISO 27001

Le contrôle A.8.8 de l'Annexe A d'ISO 27001 (Gestion des vulnérabilités techniques) exige que les organisations identifient, évaluent et traitent les vulnérabilités techniques. Les évaluations de vulnérabilités régulières et les tests d'intrusion sont les principaux mécanismes pour satisfaire ce contrôle. ISO 27001 exige également que les organisations évaluent l'efficacité de leur système de management de la sécurité de l'information, ce que les constats d'évaluation soutiennent directement.

NIS2

La directive NIS2 exige que les entités essentielles et importantes mettent en oeuvre des mesures de sécurité basées sur les risques, y compris des tests et audits réguliers de la sécurité. Les évaluations de sécurité — en particulier les tests d'intrusion — fournissent la base probante pour démontrer la conformité à l'exigence de l'article 21 relative aux « politiques et procédures pour évaluer l'efficacité des mesures de gestion des risques de cybersécurité ».

Ressources associées

• Guide d'évaluation de sécurité — Un guide complet pour choisir et préparer les évaluations de sécurité.
• Services d'Ingénierie de Sécurité — Transformez les constats d'évaluation en défenses renforcées.