Plus tôt ce mois-ci, le NIST, la NSA et la CISA ont publié Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Notre premier billet sur le sujet a traduit les dix pratiques en contrôles pour les organisations qui déploient des agents. Celui-ci fait l’étape suivante : rattacher ces pratiques au cadre sur lequel votre programme de sécurité rend déjà des comptes.
Le document fait la moitié du travail pour vous. Ses dix pratiques se divisent en 50 sous-pratiques numérotées, et 38 d’entre elles citent des sous-catégories précises du Cybersecurity Framework 2.0 du NIST. Lisez ces renvois comme une carte. Lisez ensuite les douze sous-pratiques qui n’ont aucun ancrage dans le CSF : c’est là qu’est le travail vraiment nouveau pour les agents.
Étapes d’incident et fonctions du CSF, ce n’est pas pareil
Les pratiques clés suivent cinq étapes de gestion des incidents : préparer, détecter, intervenir, rétablir, déclarer. Le CSF 2.0 compte six fonctions : Gouverner, Identifier, Protéger, Détecter, Répondre, Rétablir. Les deux ne se superposent pas, et les renvois le montrent bien.
La pratique 1.7, sous Préparer, demande des mécanismes pour bloquer, contenir ou arrêter l’activité d’un agent. Elle cite RS.MI-01, « les incidents sont contenus », une sous-catégorie de la fonction Répondre. La pratique 7.2, sous Rétablir, demande de corriger les vulnérabilités exploitées et cite RS.MI-02, « les incidents sont éradiqués ». La pratique 7.4 cite ID.IM-03 et ID.IM-04, qui relèvent de la fonction Identifier.
Ça compte pour savoir qui est responsable de quoi. Vos responsables de contrôles sont organisés selon les fonctions du CSF ou un catalogue qui en découle, pas selon les étapes d’un incident. Regroupez les pratiques par sous-catégorie du CSF et vous voyez tout de suite quel responsable existant détient déjà chacune d’elles.
La correspondance, fonction par fonction
Chaque ligne donne la sous-catégorie du CSF 2.0, son intitulé (en traduction libre et parfois abrégé ; le document du NIST fait foi) et les sous-pratiques qui la citent.
Gouverner
- GV.OC-03. Les exigences légales, réglementaires et contractuelles en matière de cybersécurité sont comprises et gérées : 9.1 (respecter les obligations légales de déclaration).
- GV.RR-02. Les rôles, responsabilités et pouvoirs liés à la gestion du risque de cybersécurité sont établis, communiqués, compris et appliqués : 2.6 (évaluation structurée des risques, approbation de la haute direction).
- GV.RM-06. Une méthode normalisée pour calculer, documenter, catégoriser et prioriser les risques de cybersécurité est établie et communiquée : 2.6.
Identifier
- ID.RA-05. Les menaces, vulnérabilités, probabilités et impacts servent à comprendre le risque inhérent : 1.4 (canaux de persistance et de communication), 1.8 (s’attendre à ce que les agents exploitent les erreurs de configuration).
- ID.RA-06. Les réponses au risque sont choisies, priorisées, planifiées, suivies et communiquées : 1.8, 2.1 (indicateurs et gravité des incidents et quasi-incidents).
- ID.IM-01. Des améliorations sont repérées à partir des évaluations : 10.2 (faciliter l’examen par des tiers).
- ID.IM-02. Des améliorations sont repérées à partir des tests et exercices de sécurité : 1.9 (red team des contrôles), 2.2 (exercices), 4.1 (red team des mécanismes de surveillance).
- ID.IM-03. Des améliorations sont repérées à partir de l’exécution des processus, procédures et activités opérationnels : 5.4 (analyse des journaux et cause première), 7.4 (rejouer l’incident contre les nouveaux contrôles), 10.3 (publier les améliorations).
- ID.IM-04. Les plans de réponse aux incidents et les autres plans de cybersécurité qui touchent les opérations sont établis, communiqués, tenus à jour et améliorés : 7.4.
Protéger
- PR.AA-05. Les permissions, droits et autorisations d’accès intègrent le moindre privilège et la séparation des tâches : 1.1 (moindre privilège pour les agents).
- PR.IR-01. Les réseaux et environnements sont protégés contre l’accès et l’usage logiques non autorisés : 1.2 (infrastructure à usage unique), 1.4, 1.5 (allowlist sortante par une gateway surveillée), 3.1 (définir le périmètre prévu de chaque agent).
- PR.DS-01. La confidentialité, l’intégrité et la disponibilité des données au repos sont protégées : 1.10 (bonnes pratiques d’ingénierie).
- PR.PS-04. Des journaux sont produits et rendus disponibles pour la surveillance continue : 3.2 (surveiller chaque couche), 5.3 (logs inviolables).
- PR.PS-06. Des pratiques de développement logiciel sécuritaire sont intégrées : 1.10.
Détecter
- DE.CM-01. Les réseaux et services réseau sont surveillés pour déceler les événements potentiellement néfastes : 3.2.
- DE.CM-06. Les activités et services des fournisseurs externes sont surveillés : 3.2.
- DE.CM-09. Le matériel, les logiciels, les environnements d’exécution et leurs données sont surveillés : 3.2, 4.2 (considérer que les sorties de l’agent peuvent contenir des attaques visant les mécanismes de surveillance).
- DE.AE-02. Les événements potentiellement néfastes sont analysés pour mieux comprendre les activités associées : 3.5 (escalade et leurres).
- DE.AE-03. L’information provenant de plusieurs sources est corrélée : 3.3 (l’agent ne peut pas toucher à sa surveillance ; recouper les couches de surveillance).
- DE.AE-06. L’information sur les événements néfastes est transmise au personnel et aux outils autorisés : 3.5, 5.5 (enquête assistée par des modèles, vérifiée par des humains).
Répondre
- RS.MA-01. Le plan de réponse aux incidents est exécuté en coordination avec les tiers concernés : 5.5.
- RS.MA-03. Les incidents sont catégorisés et priorisés : 2.1, 9.3.
- RS.AN-03. Une analyse établit ce qui s’est produit et la cause première : 5.4.
- RS.AN-07. Les données et métadonnées d’incident sont recueillies, et leur intégrité et leur provenance sont préservées : 5.1 (conserver les actions et tool calls refusés), 5.2 (conserver la configuration), 5.3.
- RS.AN-08. L’ampleur d’un incident est estimée et validée : 6.1 (politiques d’arrêt calibrées selon la gravité).
- RS.MI-01. Les incidents sont contenus : 1.7, 6.1.
- RS.MI-02. Les incidents sont éradiqués : 6.2 (arrêt automatique), 6.4 (révoquer les identifiants), 6.5 (éliminer la persistance), 7.2.
- RS.CO-02. Les parties prenantes internes et externes sont avisées des incidents : 8.1 (aviser les parties touchées), 9.1.
- RS.CO-03. L’information est partagée avec les parties prenantes internes et externes désignées : 8.2, 9.3, 10.3.
Rétablir
- RC.RP-03. L’intégrité des sauvegardes et des autres ressources de restauration est vérifiée avant leur utilisation : 7.1 (reconstruire à partir de références vérifiées).
- RC.RP-05. L’intégrité des actifs restaurés est vérifiée, les systèmes et services sont rétablis et le fonctionnement normal est confirmé : 6.4, 7.3 (prouver que le confinement fonctionne avant la relance).
- RC.RP-06. La fin du rétablissement est déclarée selon des critères, et la documentation de l’incident est complétée : 7.5 (consigner la décision de relance), 7.6 (rapport post-incident).
Ça fait 32 sous-catégories en tout.
Ce que la correspondance fait ressortir
Le poids est sur les frontières et la preuve. Les sous-catégories les plus citées sont PR.IR-01 et RS.MI-02, avec quatre sous-pratiques chacune, puis RS.AN-07, ID.IM-02 et ID.IM-03, avec trois chacune. Être prêt pour un incident d’agent, c’est surtout une affaire de frontières de réseau et d’environnement, d’éradication et de preuve dont vous pouvez défendre l’intégrité.
La fonction Gouverner est mince. Seules les pratiques 2.6 et 9.1 citent une sous-catégorie de gouvernance. Le document vise les labos qui font des évaluations, et il dit peu de choses sur qui est responsable d’un agent dans une entreprise. Pour une organisation qui déploie des agents, ce trou est réel. La responsabilité, l’imputabilité et l’inventaire, c’est par là qu’un programme d’entreprise commence, et c’est pour ça qu’on a mis l’inventaire des agents en premier.
Douze sous-pratiques ne citent aucune sous-catégorie du CSF. Quatre d’entre elles citent plutôt d’autres références. Les pratiques 1.6 (politique de contrôle avec application automatisée), 2.3 (canaux de signalement entrants) et 10.1 (partager publiquement, tôt) renvoient à la SP 800-61r3. La pratique 9.2 (déclarer les vulnérabilités) renvoie au programme de divulgation coordonnée des vulnérabilités de la CISA et à son catalogue des vulnérabilités exploitées connues. Ce sont des pratiques classiques.
Les huit autres, c’est là que les agents se distinguent des systèmes pour lesquels le CSF a été écrit :
- 1.3. Donner aux agents des instructions qui précisent la portée de la tâche et les règles d’engagement. Pour un agent, les instructions sont un intrant de contrôle. Pour un serveur, ça n’existe pas.
- 2.4. Faire vérifier par des auditeurs externes indépendants que le contrôle, la surveillance et la détection fonctionnent comme prévu.
- 2.5. Envisager de publier des identifiants pour le trafic des agents, pour que les défenseurs puissent le reconnaître.
- 3.4. Surveiller avec plusieurs modèles, idéalement de familles différentes.
- 5.6. Vérifier si d’autres agents semblables ont été impliqués ou ont eu la même défaillance de contrôle.
- 6.3. Selon la gravité, suspendre les agents semblables jusqu’à ce que les contrôles soient renforcés et vérifiés.
- 7.7. Concevoir le rétablissement en cours d’entraînement pour ne pas renforcer le comportement ni le rendre plus difficile à détecter. Celle-là s’adresse aux développeurs de modèles.
- 8.3. Partager les leçons dans toute la chaîne de valeur, y compris avec le développeur du modèle et les fournisseurs d’infrastructure.
Pour une entreprise, ce sont les pratiques 5.6 et 6.3 qui méritent le plus d’attention. Elles traitent un incident d’agent comme un constat sur une catégorie d’agents, pas sur un seul hôte. Si un agent bâti sur un modèle et un ensemble d’outils donnés est sorti de son périmètre, tous les agents qui partagent ce modèle et ces outils sont suspects jusqu’à preuve du contraire. Aucune sous-catégorie du CSF ne dit ça, donc aucun responsable de contrôle existant ne va s’en charger à moins que vous lui donniez la tâche.
Des données, pas une diapo
Une correspondance sur une diapo est périmée le jour où la source change, et cette source va changer. C’est la version 1.0, et elle énumère neuf pistes de travaux futurs, dont des cotes de gravité, des références d’activité prévue et des identifiants d’agents.
Gardez plutôt la correspondance sous forme d’enregistrements structurés. Un enregistrement par sous-pratique, avec les sous-catégories du CSF qu’elle cite, le contrôle interne qui y répond, le responsable et la preuve :
- practice: "1.5"
csf: [PR.IR-01]
control: Allowlist sortante sur les runners d’agents, via le proxy surveillé
owner: Responsable de la sécurité réseau
evidence: Logs de refus du proxy
- practice: "6.3"
csf: []
control: Suspendre tous les agents du même modèle et des mêmes outils en attendant l’examen
owner: Responsable de la plateforme d’IA
evidence: Étape du runbook, date du dernier exercice tabletop
Les questions deviennent alors des requêtes. À quelles pratiques d’agents notre proxy sortant répond-il ? Quelles pratiques n’ont pas de responsable ? Quelles sous-catégories du CSF ont gagné des obligations propres aux agents cette année ?
C’est l’argument qu’on faisait dans pourquoi utiliser NIST OSCAL. Décrivez une seule fois votre proxy sortant, votre fournisseur d’identité et votre pipeline de journalisation comme des composants, puis faites-les correspondre à chaque cadre auquel vous devez répondre. En termes OSCAL, les contrôles d’agents deviennent des entrées d’une définition de composant, à côté des correspondances que vous tenez déjà pour la SP 800-53 ou l’ISO 27001. Le NIST publie le noyau du CSF 2.0 sous forme de données structurées dans son Cybersecurity and Privacy Reference Tool, et a présenté un convertisseur de ces données vers des catalogues OSCAL. Les pratiques clés, elles, ne sont publiées qu’en PDF. Transformer leurs 50 sous-pratiques en enregistrements, c’est quelques heures de travail, une seule fois.
Besoin d’un deuxième regard ?
Notre Évaluation de la sécurité de l’IA générative rattache chaque constat aux pratiques clés et au CSF 2.0, avec un responsable et une mesure corrective. Si votre programme de conformité roule déjà sur OSCAL, ou veut s’y mettre, on livre les contrôles d’agents sous forme de données que vous pouvez fusionner, pas dans un document à ressaisir.
Trois questions à poser à votre équipe
- Pour PR.IR-01 et RS.MI-02, les deux sous-catégories sur lesquelles les pratiques s’appuient le plus, est-ce qu’on peut nommer le responsable du contrôle et montrer la preuve pour nos agents en particulier ?
- Qui, chez nous, est responsable de la pratique 6.3, soit suspendre tous les agents semblables après un incident ?
- Quand la version 2.0 des pratiques clés va sortir, combien de temps ça va nous prendre pour savoir ce qui change pour nos contrôles ?