🛡️ GRC-as-Code

Piloter la cybersécurité et la conformité comme on pilote du code

EBIOS RM · ISO 27001:2022 · NIS2 · NIST CSF 2.0 · MITRE ATT&CK Appliqué à un Centre d'Imagerie Médicale (cas fictif)

---

💡 Le problème

Dans la plupart des organisations, la conformité vit dans des tableurs et des documents Word : ils deviennent obsolètes dès le lendemain de l'audit, personne ne sait qui a modifié quoi, et les résultats des scans de vulnérabilités n'ont aucun lien avec le registre des risques.

✅ L'approche

GRC-as-Code traite la gouvernance, les risques et la conformité comme du code :

Principe	Concrètement
Déclaratif	Risques, contrôles et mappings sont des fichiers YAML dans grc/
Versionné	Chaque changement passe par Git : historique, revue, traçabilité d'audit
Automatisé	Les rapports (SoA, heatmap, KPIs) sont générés, jamais rédigés à la main
Connecté	Un scan SARIF ingéré réévalue automatiquement le risque résiduel

📊 Le projet en chiffres

12	93	3	10 / 10	20 / 20	13
scénarios EBIOS RM	contrôles ISO 27001 évalués	référentiels mappés	mesures NIS 2 couvertes	techniques ATT&CK couvertes	plans de traitement

---

📑 Sommaire

Fonctionnalités · Architecture · Démarrage rapide · CLI · API · Structure · Limites · Crédits · Licence

---

✨ Fonctionnalités

🎯 Analyse de risques EBIOS RM

Les 5 ateliers sont modélisés : valeurs métier (base patients, PACS), événements redoutés, scénarios stratégiques et opérationnels, puis traitements. Chaque risque porte un score inhérent et un score résiduel (gravité × vraisemblance).

📋 Conformité ISO 27001:2022

Les 93 contrôles de l'Annexe A sont évalués dans une Déclaration d'Applicabilité (SoA) avec statut, maturité et justification contextualisée (PACS, VPN, HDS), y compris l'exclusion motivée du développement logiciel.

🔗 Mappings réglementaires croisés

Chaque contrôle est relié à NIS2 (art. 21), NIST CSF 2.0 et MITRE ATT&CK v14, ce qui permet de mesurer la couverture réglementaire d'un seul coup d'œil.

🔍 Télémétrie sécurité (SARIF)

Les rapports de scan (Trivy pour les CVE, BloodHound pour Active Directory) sont ingérés et reliés aux scénarios de risque : une vulnérabilité critique dégrade le risque résiduel.

🎫 Suivi des traitements

Les plans de traitement (réduire, transférer, accepter) ont un porteur, une échéance, et peuvent être exportés vers Jira Service Management.

📈 Dashboard CISO / auditeur

Cinq vues : vue d'ensemble, heatmap inhérent vs résiduel, avancement de la SoA, conformité globale (NIS2 / NIST / ATT&CK) et rapports exportables.

---

🏗️ Architecture

flowchart LR
    subgraph Git["📁 Git : source de vérité"]
        EBIOS["EBIOS RM<br>grc/ebios/*.yaml"]
        ISO["ISO 27001<br>grc/iso27001/"]
        MAP["Mappings<br>NIS2 · NIST · ATT&CK"]
    end

    subgraph Ops["⚙️ SecOps"]
        SARIF["Rapports SARIF<br>Trivy · BloodHound"]
        CLI["CLI Typer<br>load · ingest · export-jira"]
    end

    subgraph Core["🧠 Backend"]
        DB[("PostgreSQL 15")]
        API["FastAPI<br>scoring inhérent / résiduel"]
    end

    DASH["📈 Dashboard<br>Streamlit"]
    JIRA["🎫 Jira"]

    Git --> CLI
    SARIF --> CLI
    CLI --> DB
    DB <--> API
    API --> DASH
    API -.-> JIRA

Loading

Stack : Python 3.11 · FastAPI · SQLAlchemy · PostgreSQL 15 · Typer · Streamlit · Docker Compose.

---

⚡ Démarrage rapide

Prérequis : Docker et Docker Compose (Make est optionnel).

git clone https://github.com/h-4mza/grc-as-code-imaging-center.git
cd grc-as-code-imaging-center
make demo

make demo construit les conteneurs, attend que PostgreSQL et l'API soient opérationnels (avec vérification de santé et timeout de 60 s), charge le référentiel GRC (grc load), ingère automatiquement les rapports de scan SARIF (grc ingest), puis affiche les URLs d'accès.

Pour arrêter la stack et réinitialiser les volumes :

make demo-down

Sans Make (commandes manuelles)

docker-compose up -d --build

# 1. Charger le référentiel (EBIOS RM, ISO 27001, mappings)
docker-compose exec -T api grc load

# 2. Ingérer les scans SARIF d'exemple
docker-compose exec -T api grc ingest --source sarif --file grc/scans/projet1_trivy.sarif
docker-compose exec -T api grc ingest --source sarif --file grc/scans/projet3_ad_audit.sarif

Service	URL
🖥️ Dashboard	http://localhost:8501
📡 API (Swagger)	http://localhost:8000/docs

🔐 Sécurité & Identifiants de démo :
Les identifiants PostgreSQL (grc_user / grc_password) définis dans docker-compose.yml sont strictement réservés à la démonstration locale. Ne les réutilisez jamais en production.
Un fichier d'exemple .env.example est fourni pour surcharger la configuration (DATABASE_URL, jetons JIRA_*) sans exposer de secrets :

cp .env.example .env

---

🧰 CLI

Commande	Rôle
grc validate [--grc-dir <dir>]	Valide l'intégrité, la cohérence et l'échelle des YAML GRC sans toucher à la base
grc load [--grc-dir <dir>]	Chargement idempotent en base : validation préalable, upsert, prune des éléments obsolètes, préservation des constats/clés Jira, et relink automatique
grc reset [--yes]	Réinitialise complètement la base (drop_all + create_all) avec confirmation interactive (ou --yes)
grc relink [--grc-dir <dir>]	Recalcule les liaisons constat ↔ scénario (ATT&CK) et constat ↔ contrôle (ISO 8.8)
grc ingest --source sarif --file <fichier>	Ingère un rapport de scan (ex. Trivy, BloodHound) et réévalue le risque résiduel
grc export-matrix [--output <fichier>]	Exporte la matrice de conformité croisée (ISO 27001, NIS2, NIST CSF 2.0, ATT&CK)
grc export-jira [--project <KEY>] [--dry-run | --no-dry-run]	Synchronise les plans de traitement vers Jira Service Management

Exécution dans le conteneur : docker-compose exec -T api grc <commande>

⚙️ Intégration Jira Cloud

Par défaut, grc export-jira s'exécute en mode simulation (--dry-run). Pour créer réellement les tickets (--no-dry-run), configurez les variables d'environnement suivantes :

• JIRA_URL : URL de votre instance Atlassian (ex. https://mon-domaine.atlassian.net)
• JIRA_EMAIL : Adresse e-mail du compte de service (ex. ciso@mon-domaine.com)
• JIRA_API_TOKEN : Jeton d'API Atlassian
• JIRA_PROJECT_KEY : Clé de projet par défaut (optionnel, repli sur SEC si non spécifié)

# Simulation (dry-run par défaut, aucun appel réseau)
docker-compose exec -T api grc export-jira --project CIMSEC

# Création réelle des tickets Jira (avec labels risk-id et control-id, et description ADF)
docker-compose exec -T api grc export-jira --project CIMSEC --no-dry-run

📡 API

Endpoint	Retourne
GET /kpi/heatmap	Matrice de risques inhérent / résiduel
GET /kpi/coverage	Taux de couverture NIS2 (10/10) et ATT&CK (20/20), ventilation par statut et alertes
GET /kpi/compliance	Couverture agrégée NIS2 / NIST CSF / ATT&CK
GET /kpi/soa	Avancement de la SoA par thème

Documentation interactive complète sur /docs.

---

📸 Aperçu

Matrice de Risques EBIOS RM (Heatmap)

Déclaration d'Applicabilité (SoA) ISO 27001:2022

Matrice de Couverture Réglementaire (NIS2, NIST CSF, ATT&CK)

📸 Captures d'écran

Pour régénérer automatiquement les captures d'écran du dashboard avec Playwright :

playwright install chromium
python scripts/capture_screenshots.py

---

📁 Structure du projet

├── app/
│   ├── main.py              # Endpoints FastAPI
│   ├── cli.py               # CLI Typer
│   ├── models.py            # Modèles SQLAlchemy
│   ├── parsers/sarif.py     # Parseur SARIF
│   └── services/scoring.py  # Calcul des risques EBIOS RM
├── dashboard/streamlit_app.py
├── grc/
│   ├── ebios/               # Ateliers EBIOS RM (YAML)
│   ├── iso27001/            # 93 contrôles Annexe A
│   ├── mappings/            # NIS2, NIST CSF, ATT&CK
│   └── scans/               # Rapports SARIF d'exemple
├── docs/                    # Documentation, note d'applicabilité (NIS2, RGPD, HDS)
├── tests/
├── docker-compose.yml
└── Dockerfile

---

🧪 Qualité

• Tests automatisés dans tests/
• Hooks pre-commit (voir .pre-commit-config.yaml)
• Pipeline CI GitHub Actions
• Documentation générée avec MkDocs (mkdocs.yml)

🗺️ Feuille de route

• Ingestion d'autres formats (Nessus, OpenVAS, CycloneDX)
• Authentification et rôles (CISO, auditeur, lecture seule)
• Export PDF de la SoA et du registre des risques
• Mapping RGPD et HDS au niveau contrôle
• Historisation des scores pour suivre la tendance du risque

⚠️ Limites

Ce projet a été conçu comme un démonstrateur méthodologique et technique :

• Système d'Information fictif : Le centre d'imagerie médicale (16 collaborateurs), les flux d'imagerie, les serveurs PACS/RIS et les topologies réseau modélisent un cas d'étude fictif. Le projet ne contient aucune donnée médicale réelle ni aucune donnée à caractère personnel (DCP).
• Preuves documentaires illustratives : Les références d'éléments de preuve (evidence) associées aux contrôles ISO 27001 et aux plans de traitement constituent des attendus méthodologiques types et non des documents d'audit réels issus d'une structure en production.
• Mappings à valider formellement : Les correspondances réglementaires et techniques établies entre ISO 27001:2022, la Directive NIS 2, le NIST CSF 2.0 et MITRE ATT&CK v14 sont fournies à titre indicatif et pédagogique. Elles doivent faire l'objet d'une validation formelle par des auditeurs ou juristes qualifiés avant tout réemploi en environnement opérationnel.
• Outil non certifié : Ce moteur d'évaluation et de pilotage GRC-as-code n'est pas un outil de conformité ou de certification officiel.

---

👥 Crédits

Ce projet prolonge et industrialise le travail académique original :

• Rapport de recherche : Gestion des risques : Application du NIST Cybersecurity Framework (CSF 2.0) dans un centre d'imagerie médicale (rapport PDF conservé dans grc/legacy/nist_csf_report.pdf).
• Institution : Université Chouaib Doukkali — École Nationale des Sciences Appliquées d'El Jadida (ENSA El Jadida), Département Télécommunications, Réseaux et Informatique.
• Année universitaire : 2025 – 2026.

---

📜 Licence

Distribué sous licence open-source MIT. Vous êtes libre d'utiliser, modifier et redistribuer ce projet selon les termes de la licence.

Développé par h-4mza · Si le projet vous est utile, une ⭐ fait plaisir.