# Test d'intrusion en Suisse – Black/Grey/White-Box comparés > Tests d'intrusion en Suisse : boîte noire, grise et blanche comparées, standards de méthode, périmètre, retests, rapport et aspects juridiques. - Source: https://www.sidd.swiss/fr/perspectives/test-dintrusion-en-suisse-black-grey-white-box-compares/ - Langue: fr-CH - Publié: 2026-05-24 - Mise à jour: 2026-05-24 - Auteur·e: Oliver Stutz - Éditeur: SIDD Institut pour la protection des données et la sécurité des données, une marque de Priverion GmbH, Zugerstrasse 32, 6340 Baar (ZG), Suisse ## Introduction Un test d'intrusion est la simulation contrôlée d'une cyberattaque contre un système cible défini, réalisée par des spécialistes en sécurité éthiques. Sur le marché suisse, la question est rarement « si », mais presque toujours « quel niveau de connaissance, quelle norme, à quelle fréquence ». Les trois variantes classiques – Black-Box, Grey-Box et White-Box – présentent des atouts, des coûts et une valeur informative différents. Le choix influence directement la qualité des résultats et donc l'investissement à une période où les budgets de cybersécurité sont déjà sous pression. **Cet article couvre :** - Les trois niveaux de connaissance Black, Grey, White – définition, cas d'utilisation typiques, coûts. - Les normes méthodologiques : OSSTMM 3, PTES, OWASP WSTG, NIST SP 800-115. - Les bonnes pratiques de périmétrage et les prix indicatifs du marché suisse (2025). - Les cycles de retest, l'évaluation de la sévérité, les attentes en matière de reporting. - Les aspects juridiques des tests d'intrusion en Suisse (protection des données, secret professionnel, preuve de conformité). Les références juridiques et normatives sont : ISO/IEC 27001:2022 Annexe A.8.29 (Tests de sécurité en développement et en acceptation), A.8.8 (Gestion des vulnérabilités), art. 8 LPD (Sécurité des données), FINMA RS 23/01 Rz 59-65 (Tests dans le cadre des risques opérationnels), DORA art. 24-27, OSSTMM 3 (ISECOM, 2010 avec adaptations), PTES (Penetration Testing Execution Standard) ainsi que l'OWASP Web Security Testing Guide v4.2 (2024). ## Les trois niveaux de connaissance en détail Les trois variantes classiques se distinguent principalement par le niveau de connaissance préalable que l'équipe de test a du système cible : - **Black-Box :** L'équipe de test ne reçoit que le périmètre (p. ex. une URL ou une plage d'IP) et travaille entièrement sans information interne. Simule un attaquant externe sans connaissance de l'intérieur. Avantages : grande proximité avec la réalité, test de la surface d'attaque externe. Inconvénients : part importante d'efforts de reconnaissance, éventuels « angles morts » dans les couches logiques profondes. - **Grey-Box :** L'équipe de test reçoit des informations sélectionnées – p. ex. des comptes utilisateurs dans différents rôles, des schémas d'architecture, une sélection de spécifications API. Simule un initié ou un attaquant externe après une première compromission réussie. Meilleur équilibre entre proximité avec la réalité et profondeur ; mode le plus fréquent dans la pratique suisse. - **White-Box :** L'équipe de test dispose d'un accès complet, incluant le code source, la documentation d'architecture, les instantanés de configuration, éventuellement les schémas de base de données. Profondeur maximale et meilleure couverture, adapté aux applications critiques pour la sécurité et aux preuves de conformité (p. ex. SOC 2, ISO 27001 pour les fournisseurs SaaS). Requiert une maturité plus élevée chez le mandant et un niveau de confiance plus important. Aide au choix : qui réalise son premier test d'intrusion commence typiquement en Grey-Box. Pour l'exposition externe sur Internet (Web, API, passerelle de messagerie), le Black-Box est souvent pertinent comme « contrôle de réalité ». Pour le développement logiciel interne et les preuves de conformité, le White-Box est l'étalon-or. ## Normes méthodologiques Les fournisseurs sérieux de tests d'intrusion suivent des méthodologies reconnues, dont le choix est consigné dans le document de périmétrage : - **OSSTMM 3 (Open Source Security Testing Methodology Manual) :** Cadre structuré en 7 phases avec son propre modèle d'évaluation des risques (RAVs – Risk Assessment Values). Solide pour les tests d'infrastructure, moins adapté aux applications web. - **PTES (Penetration Testing Execution Standard) :** 7 phases (Pré-engagement, Collecte de renseignements, Modélisation des menaces, Analyse des vulnérabilités, Exploitation, Post-exploitation, Reporting). Pragmatique et le plus répandu en Suisse et dans la région DACH. - **OWASP Web Security Testing Guide v4.2 :** L'étalon-or pour les tests d'applications web. Contient environ 100 cas de test détaillés organisés en 11 catégories (Collecte d'informations, Configuration, Gestion des identités, Authentification, Autorisation, Gestion des sessions, Validation des entrées, Gestion des erreurs, Cryptographie, Logique métier, Côté client). - **OWASP ASVS v4 / v5 :** Application Security Verification Standard avec trois niveaux de maturité (L1 pour la sécurité minimale, L2 pour les applications standard, L3 pour les applications hautement critiques). Approche par liste de contrôle structurée, complémentaire au WSTG. - **NIST SP 800-115 :** Guide des autorités américaines, plutôt générique, peu répandu en UE/CH, mais parfois exigé par des mandants américains. - **MITRE ATT&CK :** Pas une norme de test, mais le vocabulaire de facto pour les TTPs des attaquants. Devrait être utilisé pour l'évaluation de la sévérité et le reporting. Dans la pratique suisse, nous combinons typiquement PTES comme cadre de processus avec OWASP WSTG pour les composants web et MITRE ATT&CK pour le reporting. ## Bonnes pratiques de périmétrage Un test d'intrusion bien délimité fournit des résultats exploitables à un prix maîtrisé. Éléments essentiels d'un périmétrage solide : - **Liste des actifs :** Énumération précise des IP cibles, URL, points de terminaison API, applications mobiles ; clarification de l'hébergement cloud (quelles régions, quels fournisseurs). - **Niveau de connaissance :** Black, Grey, White – explicitement documenté avec les informations concrètes transmises à l'équipe de test. - **Fenêtre de test :** Jours de la semaine, horaires, escalade d'urgence, interlocuteur ; pour les tests en production, évaluation claire du risque de disponibilité. - **Objectifs :** « Qu'est-ce que le succès ? » – p. ex. contournement d'authentification, exfiltration de données, élévation de privilèges, mouvement latéral. - **Hors périmètre :** Qu'est-ce qui ne peut pas être testé ? (manipulation de la base de données de production, DoS, ingénierie sociale sans autorisation explicite). - **Règles d'engagement :** Quelles techniques sont autorisées ? Que se passe-t-il lors de la découverte d'une vulnérabilité critique (escalade immédiate ou poursuite du test jusqu'à la fin) ? - **Lettre de mission :** Autorisation du mandant, NDA, clause de responsabilité, preuve d'assurance du prestataire. Prix indicatifs en Suisse (2025) : petite application web (10-15 points de terminaison, Grey-Box) typiquement CHF 12'000-25'000 ; plateforme SaaS de taille moyenne CHF 35'000-80'000 ; audit d'infrastructure externe avec 50-200 IP CHF 20'000-50'000 ; test de réseau interne avec Active Directory CHF 30'000-70'000. ## Cycles de retest et évaluation de la sévérité Un test d'intrusion ponctuel est une photographie instantanée. La plupart des normes (ISO 27001 Annexe A.8.29, FINMA RS 23/01 Rz 59-65, DORA art. 25) exigent une répétition régulière. Cycles courants sur le marché : - **Annuellement :** Applications web externes, applications mobiles, infrastructure cloud – après chaque version majeure. - **Semestriellement ou à chaque version majeure :** Plateformes SaaS critiques, applications financières réglementées, systèmes de santé avec données patients. - **Tous les 2-3 ans :** Architecture réseau interne, environnements OT/ICS (avec précautions particulières). - **Après chaque modification significative :** Revues de code, changements d'architecture, nouvelles intégrations, migrations cloud. Les retests après remédiation sont essentiels. Déroulement habituel : test d'intrusion -> rapport avec constatations priorisées (typiquement CVSS 3.1 plus facteur de risque spécifique à l'organisation) -> remédiation par l'équipe de développement -> retest des constatations spécifiques (typiquement 4-8 semaines après le test initial, avec environ 20-30 % de l'effort du test initial). L'évaluation de la sévérité suit typiquement CVSS 3.1 (4 niveaux : Faible, Moyen, Élevé, Critique) ou le système de notation des risques OWASP ; la contextualisation spécifique à l'organisation est déterminante – un CVSS « Élevé » sur un système de test interne doit être évalué différemment que sur une API de production accessible publiquement. ## Attentes en matière de reporting Le rapport est le livrable principal. Un rapport de test d'intrusion professionnel possède une structure cohérente : - **Résumé de direction (2-4 pages) :** Contexte, méthodologie, principales constatations, situation des risques, recommandations stratégiques. Lisible pour la direction sans formation technique. - **Périmètre & méthodologie :** Ce qui a été testé, quelle norme, quel niveau de connaissance, quelle fenêtre de test. - **Vue d'ensemble des constatations :** Tableau trié par sévérité, avec description succincte, score CVSS, actifs concernés et recommandation. - **Constatations détaillées :** Par constatation : description, preuve technique (captures d'écran, exemples de requêtes/réponses, éventuellement code de preuve de concept), impact, recommandation, références (CWE, OWASP, ID MITRE ATT&CK). - **Annexe :** Liste des outils, déclaration hors périmètre, journal de test, éventuellement outils personnalisés de l'équipe de test. Indicateurs de qualité d'un bon rapport : étapes de reproduction compréhensibles, pas uniquement des sorties d'outils (les exports Nessus/Burp seuls ne constituent pas un rapport de test d'intrusion), priorisation claire avec contexte, recommandations exploitables plutôt que formules génériques, et – très important – une évaluation honnête de ce qui N'a PAS été testé et des risques non traités dans le périmètre restant. Un rapport sans section « Limitations » est un rapport suspect. ## Aspects juridiques en Suisse Les tests d'intrusion en Suisse touchent plusieurs régimes juridiques qui doivent être intégrés dans le contrat : - **Droit pénal :** Les art. 143 (obtention illicite de données) et 143bis CP (accès indu à un système informatique) sont les « articles hackers » classiques. Les tests d'intrusion requièrent une autorisation écrite du mandant disponible avant le début des tests ; une déclaration générale de « tolérance » ne suffit pas. Pour les tests cloud, l'autorisation du fournisseur cloud est également nécessaire (AWS, Azure, Google Cloud disposent de processus d'autorisation en libre-service). - **Protection des données :** Si des données personnelles sont traitées lors des activités de test (p. ex. comptes clients dans une application web), les art. 6 ss. LPD et éventuellement l'art. 9 LPD (sous-traitance) s'appliquent. Recommandation : comptes de test sans données personnelles réelles ou accord explicite sur le traitement des données personnelles. - **Secrets professionnels :** Pour les tests contre des banques (art. 47 LB), des avocats (art. 321 CP), des médecins (art. 321 CP), les obligations de confidentialité sont particulièrement strictes. Les testeurs doivent signer un NDA et idéalement justifier de la nationalité ou de la résidence suisse. - **Preuve de conformité :** Les rapports de test d'intrusion servent de preuves vis-à-vis de la FINMA (RS 23/01), des auditeurs ISO (Annexe A.8.29), des auditeurs SOC 2, de la supervision DORA et des clients de l'UE. Durée de conservation : typiquement 5-10 ans. Pour en savoir plus sur notre offre de tests d'intrusion, consultez [Test d'intrusion](https://www.sidd.swiss/fr/services/test-intrusion). ## Comment SIDD vous accompagne SIDD réalise des tests d'intrusion pour les PME suisses, les entreprises de taille intermédiaire et les entreprises réglementées dans les trois niveaux de connaissance. Nous utilisons PTES comme cadre de processus, OWASP WSTG / ASVS pour les composants web, OWASP MASVS pour les applications mobiles et MITRE ATT&CK pour le reporting. Nos testeurs sont certifiés CREST, OSCP ou OSCE3 et suivent un processus documenté d'assurance qualité. Packages d'entrée typiques : un test d'application web en configuration Grey-Box avec méthodologie OWASP WSTG (CHF 15'000-30'000 selon la complexité), un test d'infrastructure externe sur les systèmes exposés à Internet, un audit de sécurité Active Directory, ou un TLPT complet pour les établissements financiers réglementés (voir l'[article TLPT](https://www.sidd.swiss/einblicke/tlpt-threat-led-penetration-testing)). Pour la surveillance continue de la situation des menaces, nous combinons les tests d'intrusion avec des [analyses de vulnérabilités](https://www.sidd.swiss/fr/services/analyse-vulnerabilites) régulières. Prenez rendez-vous pour un entretien de périmétrage sans engagement via [/kontakt](https://www.sidd.swiss/fr/contact) ou demandez une offre à prix fixe sur [/offerte](https://www.sidd.swiss/fr/devis). Nous fournissons généralement une offre écrite avec plan d'effort détaillé, description de la méthodologie et délais de livraison dans les 5 jours ouvrables suivant l'entretien de périmétrage. --- Ce document est la version Markdown de la page liée ci-dessus. Merci de citer l'URL HTML.