Cas avances de sécurité infrastructure¶

Gestion des incidents sécurité, purple team, threat modeling, supply chain et SBOM.

Incident sécurité : spécificités¶

Un incident sécurité se distingue d'un incident opérationnel classique par ses contraintes legales et forensiques. La gestion suit les mêmes grandes étapes (détection, triage, résolution, post-mortem) mais avec des obligations supplémentaires.

Voir Gérer les incidents pour le cadre général de gestion d'incidents.

Spécificités d'un incident sécurité¶

Étape	Spécificité sécurité	Raison
Détection	Correlate avec les logs SIEM	Les alertes métier seules ne suffisent pas
Confinement	Isoler sans eteindre si possible	Preservation des preuves en mémoire
Investigation	Chaîne de custody des preuves	Requis pour action legale eventuelle
Notification	CNIL (72h si données personnelles), ANSSI (OIV/OSE)	Obligations reglementaires
Post-mortem	Inclure le vecteur d'attaque	Prévenir la reintroduction

Preservation des preuves¶

Avant tout confinement agressif :

Capturer une image mémoire du système compromis si possible
Snapshoter les disques avant toute intervention
Exporter les logs vers un stockage externe immuable
Documenter chaque action avec horodatage (chaîne de custody)

Purple Team¶

Le purple team combine les compétences offensives (red team) et defensives (blue team) dans des exercices collaboratifs. L'objectif n'est pas de gagner mais d'améliorer les capacités de détection et de réponse.

Comparaison des approches¶

Approche	Participants	Objectif	Fréquence
Red team	Attaquants uniquement	Tester les defenses à l'insu des defenseurs	Annuel
Blue team	Defenseurs uniquement	Détecter et répondre aux menaces	Continu
Purple team	Attaquants + defenseurs	Améliorer conjointement détection et réponse	Trimestriel

Déroulement d'un exercice purple team¶

Définir les scenarios sur base du threat model de l'organisation
Red team exécuté les techniques (MITRE ATT&CK)
Blue team observe ce qui est détecté et ce qui ne l'est pas
Analyse conjointe des gaps de détection
Implémentation des règles de détection manquantes
Validation par re-exécution des scenarios

Le threat modeling n'est pas réservé aux développeurs — modelisez vos infrastructures

STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) s'applique aussi bien aux architectures d'infrastructure qu'aux applications. Chaque composant réseau, chaque flux de données, chaque service expose peut être modélisé.

Threat Modeling infrastructure¶

Méthodologie STRIDE appliquee à l'infra¶

flowchart TB
    A["Inventaire des composants\net flux de donnees"] --> B["Identification\ndes menaces STRIDE"]
    B --> C["Evaluation\ndu risque"]
    C --> D["Definition\ndes controles"]
    D --> E["Validation\n(test, red team)"]
    E --> F["Mise a jour\ndu modele"]
    F --> A

Application pratique¶

Composant infra	Menaces STRIDE pertinentes	Contrôles
API Gateway	Spoofing (identité), DoS	Auth forte, rate limiting, WAF
Pipeline CI/CD	Tampering (artefacts), Elevation	Signature artefacts, least privilege
Base de données	Information disclosure	Chiffrement, audit accès, masquage
Bastion SSH	Spoofing, Elevation	MFA, session recording, PAM

Supply chain infrastructure¶

La supply chain d'infrastructure couvre tous les composants tiers qui entrent dans les systèmes : images de base, packages OS, outils IaC, dépendances Helm.

Vecteurs d'attaque supply chain¶

Compromission d'une image Docker publique (Docker Hub)
Package NPM/PyPI malveillant dans une image
Helm chart d'un registry tiers modifie
Action GitHub tierce avec permissions excessives

Contrôles recommandes¶

Contrôle	Mise en œuvre
Images de base verifiees	Utiliser des images officielles ou construites en interne
Registry prive	Miroir interne des images approuvees (Harbor, ECR prive)
Signature d'artefacts	Cosign (Sigstore) pour signer et vérifier les images
Politique d'admission	Bloquer les images non signees en admission K8s (OPA, Kyverno)
Scan au build	Trivy, Grype sur chaque image avant push

flowchart LR
    A["Source\nofficielle"] --> B["Build\ninterne"]
    B --> C["Scan\nvulnerabilites"]
    C --> D["Signature\nCosign"]
    D --> E["Registry\nprive"]
    E --> F["Verification\nsignature\nadmission K8s"]
    F --> G["Deploiement"]

SBOM — Software Bill of Materials¶

Un SBOM est un inventaire exhaustif des composants logiciels d'un artefact : packages, bibliotheques, versions, licences, sources.

Pourquoi générer des SBOMs¶

Identifier rapidement les composants vulnerables lors d'une CVE (ex. : Log4Shell)
Répondre aux obligations reglementaires emergentes (US Executive Order 14028, NIS2)
Auditer les licences open source (GPL, LGPL, MIT)

Formats et outils¶

Aspect	Détail
Formats	SPDX (ISO standard), CycloneDX (OWASP)
Génération	Syft (containers + packages), Trivy (SBOM integ), cdxgen
Vérification	Grype peut scanner un SBOM pour les CVE connues
Attestation	SLSA (Supply chain Levels for Software Artifacts) pour la provenance

Intégration dans le pipeline¶

Générer le SBOM au moment du build (Syft sur l'image finale)
Signer le SBOM avec Cosign et l'attacher à l'image
Stocker dans le registry (OCI artifact)
Scanner le SBOM à chaque déploiement pour les nouvelles CVE
Archiver pour la traçabilité reglementaire