NIST CSF 2.0
Six fonctions structurent le travail : Govern, Identify, Protect, Detect, Respond, Recover.
- Demander un diagnostic
- France et Afrique francophone
Intégrer la sécurité dès le diagnostic avec le NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), protéger identités et données, et anticiper les risques spécifiques à l'IA.
Six fonctions structurent le travail : Govern, Identify, Protect, Detect, Respond, Recover.
MFA, SSO, comptes nominatifs, suppression des départs, moindre privilège et séparation des comptes d'administration.
Injection de prompt, outils trop permissifs, fuite via les logs et dépendance à un fournisseur de modèle unique.
Chaque partie traite un point de la démarche ; les liens ci-dessous mènent directement à la section correspondante.
Plus de systèmes, d'API, de comptes SaaS, d'automatisations et d'agents signifient davantage d'identités, de secrets et de flux à protéger. La sécurité doit donc être intégrée au diagnostic et au portefeuille d'initiatives, pas ajoutée après le lancement. Le choix d'un outil d'automatisation, n8n, Make ou Zapier, fait partie de ce périmètre : localisation des données, gestion des secrets et responsabilité de la sécurité diffèrent selon le modèle choisi.
Le NIST Cybersecurity Framework 2.0 organise les résultats de cybersécurité autour de six fonctions : Govern (qui décide du risque : politique, rôles, tolérance, exigences fournisseurs), Identify (inventorier appareils, applications, comptes, données, sauvegardes, y compris le "shadow IT", outils utilisés sans gouvernance formelle), Protect (identités et accès), Detect, Respond et Recover.
Mesures prioritaires dans de nombreuses PME : authentification multifacteur (MFA), SSO lorsque pertinent, comptes nominatifs, suppression des comptes partis, moindre privilège, gestion des comptes admin, rotation des secrets, correctifs, chiffrement, sauvegardes, configuration sécurisée et formation anti-phishing. Un compte partagé empêche d'attribuer les actions ; un compte administrateur utilisé au quotidien augmente le risque : séparer administration et usage normal. Ces mesures forment le cœur des 10 vérifications essentielles de cybersécurité pour une PME, en commençant par l'authentification multifacteur.
OWASP publie un Top 10 des risques d'applications web qui sert de point de départ à la sensibilisation, complété par une revue d'architecture, des tests, la gestion des dépendances, des secrets et des contrôles métier. Pour les API : authentification, autorisation objet par objet, limitation de débit, validation d'entrée, journalisation et gestion des versions.
Détecter suppose de centraliser les logs critiques et de surveiller authentifications, modifications d'admin, erreurs massives, changements de permissions, exfiltration potentielle et comportements inhabituels, une alerte doit conduire à une action, une centaine d'emails d'alerte non lus ne constitue pas une capacité de détection.
Préparer avant l'incident : contacts, rôles, canaux hors bande, sauvegardes, fournisseurs, critères d'escalade, collecte de preuves, exercices. Après incident : contenir, éradiquer, restaurer, surveiller et tirer des actions correctives, la restauration doit être testée avant une crise, pas pendant.
Minimisation des données : ne collecter que ce qui est nécessaire à un objectif défini, documenter finalité, accès, durée de conservation, partage et suppression. Pour un projet IA, vérifier aussi si les données sont envoyées à un fournisseur externe, utilisées pour l'entraînement, transférées entre régions ou présentes dans les logs, l'anonymisation et la pseudonymisation sont différentes, une donnée pseudonymisée peut souvent être reliée de nouveau à une personne avec une information supplémentaire.
Le registre cyber doit intégrer les risques propres à l'IA : injection de prompt, données sensibles présentes dans le contexte, outils trop permissifs, dépendance à un fournisseur de modèle unique, fuite via les logs, exfiltration par un outil, contenus non fiables et modification de comportement après une mise à jour du modèle. Le bon contrôle ne consiste pas uniquement à écrire "ne fais pas ceci" dans le prompt, les permissions et validations doivent exister au niveau système.
Chaque fiche de risque documente : actif, menace, vulnérabilité, probabilité, impact, risque brut, traitement, owner, échéance et risque résiduel après traitement. Exemple du cours : actif CRM, menace compromission d'un compte administrateur, vulnérabilité MFA absent, probabilité 4/5, impact 5/5, traitement MFA + compte admin séparé + journalisation, risque résiduel ramené de 20/25 à 10/25.
Ces écueils reviennent régulièrement en mission. Les identifier tôt évite de reconstruire un chantier déjà livré.
Ignorer le shadow IT : les outils utilisés sans gouvernance font partie de la surface d'attaque.
Considérer une sauvegarde comme valide sans avoir testé la restauration.
Confondre anonymisation et pseudonymisation : une donnée pseudonymisée reste souvent réidentifiable.
Oublier de vérifier si les données d'un projet IA partent chez un fournisseur externe, servent à l'entraînement ou transitent entre régions.
Nous produisons un registre de risques chiffré et un plan 90 jours plutôt qu'une liste de recommandations génériques : MFA, comptes nominatifs, journalisation et restauration testée passent avant les outils de sécurité avancés.
Govern (qui décide du risque, politique, rôles, tolérance, exigences fournisseurs), Identify (inventaire des appareils, applications, comptes, données et sauvegardes), Protect, Detect, Respond et Recover.
L'authentification multifacteur, le SSO lorsque pertinent, des comptes nominatifs, la suppression des comptes des personnes parties, le moindre privilège, la gestion des comptes admin, la rotation des secrets, les correctifs, le chiffrement, les sauvegardes testées et la formation anti-phishing.
Injection de prompt, données sensibles présentes dans le contexte, outils trop permissifs, dépendance à un fournisseur unique, fuite via les logs, exfiltration par un outil, contenus non fiables et changement de comportement après une mise à jour du modèle.
Ce chapitre appartient au pilier « Construire un système fiable ». Architecture, données, infrastructure, automatisation, IA et cybersécurité : les capacités sur lesquelles reposent tous les usages métier.
Représenter le système d'information en six couches, définir la source de vérité de chaque donnée, et choisir entre acheter, configurer, intégrer ou développer.
Lire le chapitre →Chapitre 5Socle techniqueFaire de la donnée un actif utile : types de données, qualité, gouvernance, tableaux de bord orientés décision et préparation de la donnée pour l'IA.
Lire le chapitre →Chapitre 6Socle techniqueChoisir une infrastructure proportionnée (IaaS/PaaS/SaaS), séparer les environnements, industrialiser avec CI/CD et l'observabilité, sans créer de dette d'exploitation.
Lire le chapitre →