Cyber & GRC, sécuriser la chaîne, y compris l’IA elle-même

Le socle est un SIEM (Elastic Security) alimenté par une journalisation normalisée (ECS) : sans normalisation, la corrélation inter-sources est illusoire. Nous pilotons la détection par la couverture ATT&CK : chaque cas d'usage est rattaché à des techniques précises, ce qui rend les angles morts visibles et la priorisation rationnelle. Les règles sont écrites en detection-as-code (Sigma, YARA, requêtes KQL), versionnées, testées contre des jeux d'attaque (Atomic Red Team) et déployées par pipeline, une règle non testée est une fausse assurance.

La réponse est outillée : triage discipliné pour protéger les analystes de la fatigue d'alerte, enrichissement automatique du contexte (MISP pour la threat intel, VirusTotal, géolocalisation, réputation), et orchestration SOAR (XSOAR, Phantom) pour automatiser les gestes répétitifs de containment. La gestion d'incident s'appuie sur une vraie chaîne de case management (TheHive, Cortex), avec traçabilité et capitalisation. Côté endpoint et réseau, l'EDR/XDR (SentinelOne, CrowdStrike, Defender) et le NDR donnent la visibilité ; le threat hunting proactif (Velociraptor, Osquery, Zeek, Suricata, Wireshark) cherche ce que la détection automatique a manqué, en partant d'hypothèses fondées sur la threat intel.

Le NOC/VOC complète le dispositif : opérations réseau et gestion continue des vulnérabilités (Qualys, Tenable), avec priorisation par exploitabilité réelle, pas par CVSS brut. Nous incluons des cas d'usage de détection propres à l'IA (abus d'API d'inférence, exfiltration via prompts) en lien avec l'offre Sécurité de l'IA.

Nous structurons la démarche autour des risques propres aux systèmes d'IA, l'OWASP Top 10 pour les LLM est notre référentiel de base. L'injection de prompt, directe et surtout indirecte (charge utile dissimulée dans un document récupéré par un RAG), est la menace centrale : elle détourne le comportement du modèle sans toucher au code. Nous traitons aussi l'exfiltration de données via les sorties, l'empoisonnement de la base de connaissances RAG, le déni de service par requêtes coûteuses, l'abus d'outils par les agents (un agent qui peut appeler des API est un chemin d'attaque), et la chaîne d'approvisionnement des modèles (provenance, intégrité, dépendances).

La défense est en profondeur. En amont, modélisation de menaces dédiée et durcissement de l'architecture (isolation, moindre privilège des agents, validation et bornage des entrées/sorties). En cœur, garde-fous : filtrage des sorties, détection de PII, politiques de refus, séparation stricte entre instructions système et données récupérées. En validation, red teaming offensif des modèles, jailbreaks, contournement de garde-fous, attaques sur la récupération, mené de façon répétée, car un garde-fou non testé ne tient pas. En aval, journalisation et traçabilité complètes des prompts, contextes et réponses, intégrées au SOC pour la détection et l'investigation.

Le tout s'aligne sur l'EU AI Act : classification du risque des systèmes, obligations associées, traçabilité et documentation. La posture reste celle de l'IA responsable : l'humain décide sur les usages sensibles, et les garde-fous sont conçus pour échouer en sécurité.

Elle va accélérer le passage en production au lieu de le freiner.

Notre point de départ est l'analyse de risque structurée. EBIOS RM pour la démarche par scénarios et sources de risque, adossée à ISO 27005, et, quand la décision exige de chiffrer, une quantification type FAIR pour exprimer le risque en termes financiers, exploitables par un comité. Cette base alimente la PSSI et un référentiel de contrôles aligné sur des cadres reconnus (NIST CSF, ISO 27001 Annexe A), de sorte que chaque contrôle a une raison d'être traçable jusqu'à un risque.

Sur la conformité réglementaire, nous opérons un mapping unique vers des exigences multiples plutôt qu'une démarche en silos : un même socle de contrôles couvre, selon le périmètre, DORA (résilience opérationnelle du secteur financier), NIS2 (entités essentielles et importantes), RGPD (via DPIA pour les traitements à risque), le Cyber Resilience Act, et les exigences sectorielles (PCI-DSS pour le paiement, SOC 2). Ce mapping évite de re-auditer dix fois le même contrôle pour dix obligations.

La continuité (PCA/PRA) s'appuie sur ISO 22301 et une analyse d'impact (BIA) qui fixe des RTO et RPO réalistes, testés et non théoriques. Le risque tiers (TPRM) est piloté avec des notations externes (BitSight, UpGuard) et des questionnaires standardisés (CAIQ/SIG), parce que la surface d'attaque inclut les fournisseurs. L'outillage GRC (ServiceNow, RSA Archer, MetricStream, OneTrust pour la privacy) industrialise le suivi des contrôles, des plans d'action et des preuves, la preuve d'audit se collecte en continu, pas la veille de l'audit.

Offres packagées sur la partie audit :

1. Audit de conformité NIS2

• Cible : entités essentielles et importantes (énergie, santé, transport, numérique, industrie, etc.), ainsi que leurs sous-traitants.
• Contenu : vérification du périmètre d'assujettissement, écart entre l'existant et les exigences (gouvernance, gestion des risques, gestion d'incidents, continuité, chaîne d'approvisionnement, notification), en s'appuyant sur les référentiels ANSSI.
• Livrables : matrice de conformité, plan de remédiation priorisé, synthèse pour la direction (responsabilité des dirigeants).
• Durée indicative : 5 à 8 jours.

2. Audit DORA et résilience opérationnelle

• Cible : banques, assurances, sociétés de gestion, fintechs et leurs prestataires TIC.
• Contenu : gestion des risques TIC, registre des prestataires tiers, classification et déclaration des incidents, tests de résilience, clauses contractuelles.
• Livrables : évaluation par pilier, revue du registre d'information, feuille de route.
• Durée indicative : 6 à 10 jours.

3. Audit de maturité ISO 27001:2022 (préparation à la certification)

• Cible : entreprises qui répondent à des appels d'offres ou à des exigences clients.
• Contenu : revue du SMSI, du périmètre, de l'analyse de risques, de la déclaration d'applicabilité (SoA) et des 93 mesures de l'Annexe A, avec un audit interne à blanc.
• Livrables : rapport d'écarts, plan d'action, préparation à l'audit de certification.
• Durée indicative : 5 à 8 jours.
• Variante possible : SecNumCloud pour les hébergeurs.

4. Audit de la maîtrise des risques tiers et de la chaîne d'approvisionnement (TPRM)

• Cible : toute organisation dépendante de fournisseurs SaaS, cloud ou TI. C'est un enjeu transverse à NIS2, DORA et au Cyber Resilience Act.
• Contenu : cartographie et criticité des fournisseurs, revue du processus d'évaluation, clauses contractuelles, plans de sortie, échantillon de fournisseurs critiques.
• Livrables : cartographie des tiers, grille d'évaluation réutilisable, plan d'amélioration.
• Durée indicative : 4 à 7 jours.

5. Audit de gouvernance et de sécurité de l'IA

• Cible : toute organisation qui déploie ou utilise de l'IA générative, pour l'usage interne comme pour les produits.
• Contenu : inventaire des usages (dont shadow AI), classification des risques selon l'AI Act, fuite de données et confidentialité, politique d'usage, sécurité des projets IA (prompt injection, gestion des accès aux données), alignement ISO 42001.
• Livrables : registre des systèmes d'IA, analyse de risques, politique et charte d'usage, plan d'actions.
• Durée indicative : 4 à 6 jours.

Nous structurons l'IAM autour du cycle de vie des identités (Joiner-Mover-Leaver) : un compte créé doit être automatiquement provisionné avec les bons droits, ajusté à chaque changement de poste, et, le point le plus souvent défaillant, désactivé sans délai au départ. Le provisioning s'appuie sur des standards (SCIM) et une gouvernance des identités (IGA, SailPoint) qui orchestre les workflows d'attribution, les campagnes de recertification et la détection des droits dormants ou excessifs. Sans recertification régulière, les droits s'accumulent et la surface d'attaque enfle silencieusement.

La fédération (SAML, OIDC) centralise l'authentification (Entra ID, Okta) et permet le SSO avec MFA résistant au phishing. Sur les modèles d'autorisation, nous arbitrons entre RBAC (lisible, gouvernable) et ABAC (granulaire, contextuel) selon le besoin réel, souvent une combinaison, le RBAC pour la structure, l'ABAC pour les exceptions sensibles au contexte. Le principe directeur est le moindre privilège, opérationnalisé par de l'accès juste-à-temps (JIT) plutôt que des droits permanents.

Les identifiants et accès à privilèges sont stockés de manière sécurisée dans un coffre-fort PAM (CyberArk, BeyondTrust, WALLIX ou Teleport), avec rotation des secrets, enregistrement de session et élévation contrôlée, un compte d'administration permanent et partagé est un point de défaillance majeur. Pour les charges applicatives et l'IA, l'identité des workloads (SPIFFE/SPIRE) remplace les secrets statiques par des identités vérifiables et éphémères. L'ensemble s'inscrit dans une trajectoire Zero Trust : vérifier explicitement, limiter le privilège, présumer la compromission.

Nous calibrons l'intensité selon l'objectif. Le pentest répond à une question de périmètre (cette application, ce réseau, ce cloud sont-ils exploitables ?) : reconnaissance, identification et exploitation des vulnérabilités, sur le web (Burp Suite, OWASP ZAP), l'infrastructure (Metasploit, nmap, Nessus/OpenVAS) ou le cloud (ScoutSuite, Pacu, AzureHound pour les chemins d'attaque Azure). La Red Team répond à une question d'efficacité défensive : un adversaire déterminé, avec un objectif (atteindre tel actif), teste la détection et la réponse réelles, au-delà du simple inventaire des vulnérabilités.

Sur les environnements Active Directory, vecteur dominant en entreprise, nous cartographions les chemins d'attaque (BloodHound), exploitons les faiblesses Kerberos, le mouvement latéral (CrackMapExec, Responder) et l'escalade jusqu'au contrôle de domaine. Les opérations s'appuient sur des C2 (Cobalt Strike, Sliver, Mythic) avec des techniques d'évasion réalistes, parce qu'un test qui ne contourne pas l'EDR ne mesure pas grand-chose. Chaque action est mappée sur MITRE ATT&CK pour relier les résultats à la couverture de détection.

Nous privilégions le purple teaming : l'équipe offensive et le SOC travaillent en boucle, l'émulation d'adversaire (Caldera, Atomic Red Team) servant à valider et améliorer les détections, plutôt qu'à simplement « gagner ». L'offensif appliqué à l'IA monte en puissance : jailbreaks, attaques sur les chaînes RAG, abus d'agents, en lien direct avec l'offre Sécurité de l'IA.