Plan de test d'intrusion — SuperSOC
Ce document cadre la campagne de test d'intrusion menée sur la plateforme SuperSOC. Il définit le périmètre, la méthodologie, les règles d'engagement et les scénarios, avant toute exécution. Il constitue le livrable de cadrage de la phase d'audit.
1. Objectifs
- Évaluer la résistance de la solution complète (web, API, infrastructure) face à un attaquant externe.
- Vérifier l'efficacité des mesures défensives : segmentation VLAN, durcissement, contrôle d'accès.
- Valider la chaîne de détection et de réponse : confirmer que Wazuh détecte les attaques et que le SOAR réagit.
La plateforme étant elle-même un outil défensif (un SOC), chaque test joue un double rôle : éprouver une vulnérabilité et vérifier que la solution la détecte. Une attaque non détectée est autant un défaut qu'une vulnérabilité exploitée.
2. Périmètre (scope)
| Surface | Cibles | Inclus |
|---|---|---|
| Application web | Dashboard analyste (Vue.js) | Oui |
| API | Backend SOAR (FastAPI) | Oui |
| Infrastructure | pfSense, segmentation VLAN, services réseau | Oui |
| Bases de données | MariaDB, MongoDB (exposition) | Oui |
| Cyber Range | DVWA (cible volontairement vulnérable) | Oui |
| Hors périmètre | Services tiers externes (VirusTotal, AbuseIPDB), réseau domestique | Non |
3. Approche
- Boîte noire : le testeur ne dispose d'aucun identifiant ni accès initial. Il part de la position d'un attaquant externe et ne connaît que ce qu'il découvre.
- Deux positions d'attaquant simulées :
| Position | Point de départ | Question testée |
|---|---|---|
| Externe | Depuis le WAN, derrière pfSense | Qu'est-ce qui est exposé sur Internet ? |
| Pied dans la place | Depuis le Cyber Range (VLAN 100) | La segmentation contient-elle un attaquant interne ? |
La seconde position simule un scénario réaliste : une machine du Cyber Range a été compromise, l'attaquant tente un déplacement latéral. C'est le test direct de la segmentation réseau.
4. Méthodologie
La campagne suit le standard PTES (Penetration Testing Execution Standard), complété par l'OWASP WSTG (Web Security Testing Guide) pour la partie web/API et l'OWASP Top 10 pour la classification.
Les 5 phases
| Phase | Objectif | Outils types |
|---|---|---|
| 1. Reconnaissance | Cartographier la surface d'attaque | nmap (host discovery) |
| 2. Énumération / Scan | Identifier services, versions, vulnérabilités potentielles | nmap -sV, nikto, scanners |
| 3. Exploitation | Confirmer les vulnérabilités exploitables (preuve) | Burp Suite, OWASP ZAP, sqlmap |
| 4. Post-exploitation | Mesurer l'impact, tester le déplacement latéral | manuel, selon contexte |
| 5. Reporting | Documenter, scorer (CVSS), recommander | CVSS v3.1, ce rapport |
5. Règles d'engagement
- Tests menés exclusivement sur l'infrastructure du projet, jamais sur des cibles tierces.
- Exploitation non destructive : pas de suppression de données, pas de déni de service volontaire en production.
- Tests offensifs lourds (fuzzing, brute force) cantonnés au Cyber Range isolé.
- Horodatage systématique de chaque test pour corrélation avec les alertes Wazuh.
- Sauvegarde préalable des bases avant tout test à risque.
Même sur sa propre infrastructure, formaliser une autorisation de test et des règles d'engagement est la marque d'une démarche professionnelle. C'est un point que le jury valorise.
6. Scénarios de test par surface
6.1 Application web (Dashboard Vue.js)
Référentiel : OWASP WSTG. Points à tester :
- Authentification : robustesse du login, gestion des tokens JWT, expiration, déconnexion.
- Gestion de session : le token est-il exposé (localStorage vs mémoire) ? Rejouable ?
- XSS : injection de scripts dans les champs (titre de ticket, commentaires).
- Contrôle d'accès : un utilisateur peut-il accéder à une ressource d'un autre (IDOR) ?
- En-têtes de sécurité : CSP, HSTS, X-Frame-Options présents ?
6.2 API (FastAPI)
- Authentification/autorisation : peut-on appeler un endpoint protégé sans token ? Avec un token expiré ? Avec un rôle insuffisant (test du RBAC) ?
- Injection : paramètres non validés (bien que Pydantic limite le risque).
- Exposition d'informations : messages d'erreur trop verbeux, documentation OpenAPI exposée ?
- Rate limiting : l'anti-bruteforce se déclenche-t-il réellement ?
6.3 Infrastructure & réseau
- Surface externe : depuis le WAN, quels ports répondent ? (attendu : WireGuard uniquement).
- Segmentation : depuis le Cyber Range, peut-on atteindre le VLAN admin ? Les bases de données ?
- Exposition des bases : MariaDB (3306) et MongoDB (27017) sont-ils joignables ? (attendu : non,
internal: true). - pfSense : interface d'administration exposée ? Identifiants par défaut ?
6.4 Cyber Range (DVWA) — validation défensive
- Exécuter des attaques connues (SQLi, XSS, brute force) sur DVWA.
- Vérifier la détection Wazuh : les alertes remontent-elles ?
- Vérifier la réponse SOAR : un ticket est-il créé ? L'enrichissement et le playbook se déclenchent-ils ?
7. Cotation des vulnérabilités
Chaque vulnérabilité trouvée sera scorée avec CVSS v3.1, donnant un niveau de criticité :
| Score CVSS | Criticité |
|---|---|
| 9.0 – 10.0 | Critique |
| 7.0 – 8.9 | Élevée |
| 4.0 – 6.9 | Moyenne |
| 0.1 – 3.9 | Faible |
Chaque finding sera documenté selon le modèle : description, preuve (capture/commande), impact, score CVSS, recommandation de correction.
8. Livrables
- Ce plan de test (cadrage).
- Un rapport de findings (une fiche par vulnérabilité).
- Une synthèse des corrections appliquées.
- La corrélation attaques ↔ détections Wazuh (preuve d'efficacité défensive).
Si le scan externe ne révèle aucun port exposé hormis WireGuard, ce n'est pas un échec du pentest : c'est la preuve que le durcissement et la segmentation fonctionnent. Un bon rapport documente aussi ce qui résiste.