Méthodologie d'Audit Combiné Red Team / Blue Team : Cas Cylentra Robotics¶
1. Synthèse exécutive¶
Cette fiche documente la méthodologie appliquée lors d'un audit combiné d'une infrastructure de production (serveur 192.168.151.61), mené en une journée selon deux volets complémentaires :
- Red Team : test d'intrusion en boîte noire sur les services exposés.
- Blue Team : déploiement d'un SIEM (Wazuh) et évaluation de la capacité de détection/réponse selon le cadre PICERL.
Référentiels mobilisés : OWASP Top 10, MITRE ATT&CK, NIST Cybersecurity Framework.
L'intérêt de cette méthodologie est de traiter l'offensif et le défensif comme un seul cycle : chaque vulnérabilité exploitée côté Red Team est immédiatement confrontée à la question "le SIEM l'a-t-il vue ?", ce qui objective le vrai niveau de risque (exploitabilité et détectabilité).
2. Volet Red Team¶
A. Reconnaissance (MITRE ATT&CK T1592)¶
Objectif : identifier les services accessibles et collecter du renseignement sur l'infrastructure cible.
- 6 services identifiés (FTP, SSH, HTTP 3000/5000, MySQL).
- Logiciels obsolètes détectés : ProFTPD 1.3.3c, MySQL 5.5.
- Endpoints API découverts par analyse du code JavaScript côté client (
curl, exploration manuelle au navigateur).
B. Évaluation des vulnérabilités¶
Approche boîte noire, sans identifiants initiaux.
- Contrôle d'accès défaillant : tentative d'accès aux API sans authentification, vérification de la faisabilité d'exfiltration.
- Manipulation de données : tentatives d'opérations DELETE/POST sans autorisation ni validation.
- Test de la capacité de détection : Wazuh surveillé en parallèle de l'exploitation pour identifier les angles morts de journalisation/alerte.
C. Exploitation — preuves de concept¶
| Vulnérabilité | CVSS | Détail |
|---|---|---|
| Contrôle d'accès défaillant | 7.5 | GET /api/contacts retourne l'annuaire complet des employés (PII : noms, emails, téléphones, niveaux d'habilitation) sans authentification |
| Manipulation de données non validée | 7.2 | DELETE /api/alerts/1 supprime une alerte sans aucun contrôle d'autorisation |
| Journalisation insuffisante | 5.3 | Les tentatives d'exploitation ne génèrent aucune alerte Wazuh (absence de couverture applicative) |
3. Volet Blue Team¶
A. Mise en place de l'infrastructure de détection¶
- Wazuh v4.11.2 déployé en mode Manager sur le serveur de production.
- Source de logs applicative configurée (
/var/log/cylentra-api.log). - Règles locales créées :
100101(niveau 10, accès API non authentifié suspect),100102(niveau 12, tentative de modification malveillante via API).
B. Cadre de réponse à incident — PICERL¶
| Phase | Actions menées |
|---|---|
| Preparation | SIEM opérationnel, règles de détection API créées, journalisation configurée |
| Identification | Trafic d'attaque simulé, supervision Wazuh pendant l'exploitation, angles morts identifiés |
| Containment | Évaluation d'impact (données opérationnelles à risque), classification de sévérité HIGH/CRITICAL |
| Eradication | Recommandations de remédiation formalisées, délai cible de 7 jours pour les correctifs critiques |
| Recovery | Affinage des règles de détection, amélioration de la journalisation applicative |
| Lessons Learned | La journalisation au niveau applicatif est aussi critique que la journalisation système ; le SIEM doit être aligné avec l'architecture réelle, pas seulement l'infrastructure |
C. Conformité à la politique de sécurité (ISSP)¶
| Règle évaluée | Résultat |
|---|---|
| Contrôle d'accès (section 6) | Échec — aucune authentification sur les API |
| Protection des données (section 4) | Échec partiel — absence de chiffrement / contrôles RGPD |
| Journalisation & supervision (section 7.2) | Échec — couche applicative non supervisée |
| Sécurité système (section 9) | Conforme — patching OS à jour |
4. Timeline d'attaque et TTP MITRE ATT&CK¶
| T+ | Action |
|---|---|
| 0m00s | Reconnaissance — scan nmap lancé |
| 0m30s | Énumération de services — 6 ports identifiés |
| 1m00s | Analyse du code source — /src/scripts.js consulté |
| 2m00s | Découverte d'API — endpoint /api/robots testé |
| 2m30s | Exfiltration — GET /api/contacts exécuté |
| 3m00s | Exfiltration — GET /api/alerts exécuté |
| 3m30s | Manipulation — DELETE /api/alerts/1 exécuté |
| 4m00s | Manipulation — POST /api/missions exécuté |
Techniques MITRE ATT&CK mobilisées : Reconnaissance (T1592), Initial Access via contrôle d'accès défaillant (T1190), tentatives de brute-force FTP/MySQL (T1110), exfiltration de données (T1567), destruction de données via suppression d'alertes (T1485).
5. Résultats détection & réponse¶
- Attaques exécutées : 6 — Attaques détectées avant configuration des règles : 0 (écart de détection de 100 % au niveau applicatif).
- Règles créées :
100101(niveau 10),100102(niveau 12).
Feuille de route de remédiation¶
- Immédiat : reverse proxy HTTP avec journalisation.
- Semaine 1 : journalisation applicative Node.js (middleware
morgan). - Semaine 2 : WAF / API Gateway avec détection de menaces.
- Mois 1 : analytique comportementale (UEBA).
6. Évaluation du risque¶
Posture de risque globale : CRITIQUE
| Vulnérabilité | CVSS | Impact métier | Délai de remédiation |
|---|---|---|---|
| Contrôle d'accès défaillant | 7.5 | Exposition de données | 7 jours |
| Manipulation de données | 7.2 | Sabotage opérationnel | 7 jours |
| Journalisation insuffisante | 5.3 | Compromissions non détectées | 14 jours |
Coût de non-conformité estimé (amendes RGPD + réponse à incident) : 150 000 €+. Coût de remédiation estimé : 3 750 € (75h à 50€/h). Ratio bénéfice/coût de l'ordre de 40:1.
7. Livrables produits¶
Côté Red Team : lettre d'engagement (périmètre/objectifs), rapport de pentest détaillant les vulnérabilités et PoC, preuves à l'appui (captures, commandes curl, réponses).
Côté Blue Team : rapport de réponse à incident (détection, TTP, procédures), présentation de conformité ISSP (analyse d'écarts et feuille de route), règles de détection Wazuh.
8. Conclusion¶
Cet audit illustre l'intérêt de coupler systématiquement exploitation et supervision : une vulnérabilité critique non détectée par le SIEM (comme les 3 identifiées ici) représente un risque supérieur à une vulnérabilité équivalente mais visible. La méthodologie Red + Blue combinée transforme un simple rapport de pentest en feuille de route de durcissement priorisée par la détectabilité réelle, pas seulement par le score CVSS.