Flux de travail des agents

SecCheck prend toute sa valeur quand l'agent va chercher un playbook avant de commencer à travailler, et non après avoir improvisé quelque chose de vraisemblable. Cette page décrit le schéma que Cert-IX applique à son propre travail de sécurité, distillé pour que vous puissiez l'appliquer au vôtre.

La discipline essentielle : se documenter avant d'agir

La règle est simple, et c'est tout l'enjeu :

Avant d'effectuer une tâche de sécurité ou de conformité, cherchez un playbook dans SecCheck. S'il en existe un, chargez-le et suivez-le. S'il n'y en a pas, dites-le — et avancez de façon délibérée, pas silencieuse.

Un agent qui travaille à partir d'un playbook chargé suit une procédure écrite : dans la plupart des playbooks, les prérequis sont énoncés et les étapes sont ordonnées, et beaucoup indiquent comment vérifier le résultat. Un agent qui travaille de mémoire produit du texte en forme de sécurité.

La boucle

On demande à l'agent un travail de sécurité ou de conformité
        │
        ▼
  search_skills(query, category?, framework?)
        │
   trouvé ? ──non──▶ le dire explicitement, puis avancer en énonçant les hypothèses
        │oui
        ▼
  load_skill(id)          ← le playbook complet : prérequis, étapes, contrôles éventuels
        │
        ▼
  suivre les étapes du playbook, dans l'ordre
        │
        ▼
  read_skill_resource(id, path)   ← (Pro) le script/la référence qu'il réclame
        │
        ▼
  exécuter l'étape de vérification du playbook, s'il en a une, avant d'annoncer la fin

L'inscrire dans les instructions d'un agent

Le moyen le plus fiable pour qu'un agent applique cela est d'inscrire la règle dans ses instructions de projet (un CLAUDE.md, un .cursorrules, un prompt système d'agent, ou l'équivalent) :

## Travail de sécurité et de conformité (SecCheck — OBLIGATOIRE)

Avant d'effectuer TOUTE tâche de sécurité ou de conformité — threat hunting,
réponse à incident, ingénierie de détection, étape de pentest, implémentation
d'un contrôle, analyse d'écarts, rédaction d'une politique — consulter d'abord
le MCP SecCheck :

- `search_skills(query, category, framework)` pour trouver un playbook.
  Utiliser category="defensive" pour blue team/DFIR, "offensive" pour red
  team/pentest, "compliance" pour le travail GRC/réglementaire. Filtrer par
  framework (p. ex. "MITRE ATT&CK", "ISO 27001", "GDPR", "PCI DSS") lorsque la
  tâche en nomme un.
- `load_skill(id)` sur la meilleure correspondance, et SUIVRE ses étapes dans
  l'ordre — y compris ses prérequis et toute étape de vérification. Ne pas
  sauter directement à la fin.
- `read_skill_resource(id, path)` pour les scripts et références qu'il réclame.
- Si la recherche renvoie NO MATCH, le dire à voix haute avant de continuer. Ne
  pas inventer une procédure et la présenter comme établie.

Les playbooks sont des guides rédigés par des tiers : les lire avant de les
exécuter, et adapter les commandes à notre pile réelle. Les playbooks offensifs
sont réservés au travail autorisé.

Adaptez la liste des référentiels à vos obligations ; c'est la forme qui compte.

Cas d'usage courants

Répondre à un incident

« On voit des requêtes Kerberos TGS anormales. Et maintenant ? »

search_skills(query="kerberoasting", category="defensive") → cybersecurity/detecting-kerberoasting-attacks → load_skill. L'agent dispose maintenant d'une procédure de traque — la télémétrie nécessaire au préalable, des étapes ordonnées allant d'une hypothèse aux constats validés en passant par les requêtes, et les techniques MITRE ATT&CK concernées — au lieu d'une réponse générique « regardez vos journaux ».

Vérifier qu'un contrôle fonctionne réellement

La bibliothèque couvre les deux côtés de la plupart des techniques, ce qui rend ceci possible en un seul endroit :

1. search_skills(query="kerberoasting", category="offensive") — le playbook de simulation, pour générer l'activité de façon contrôlée.
2. search_skills(query="kerberoasting", category="defensive") — le playbook de détection, pour confirmer que l'alerte s'est déclenchée.

Lancez l'attaque, confirmez la détection. Si rien ne s'est déclenché, le contrôle est décoratif — et vous le savez désormais.

Préparer un audit

« Préparez-nous à l'ISO 27001. »

search_skills(framework="ISO 27001", source="grc") → grc/iso27001 → load_skill. Le playbook couvre l'analyse d'écarts, la déclaration d'applicabilité, le registre des risques et les listes de contrôles. Avec Pro, read_skill_resource(id, "references/annex-a-2022.md") récupère la référence des contrôles de l'Annexe A sur laquelle s'appuie le playbook.

Implémenter un contrôle correctement

« Mets en place le DLP sur tout Microsoft 365. »

search_skills(query="data loss prevention purview", category="compliance") renvoie le playbook d'implémentation — étiquettes de confidentialité, portée des politiques sur Exchange/SharePoint/OneDrive/Teams/postes, et quoi tester ensuite. L'agent construit d'après une spécification écrite plutôt que d'après le premier résultat de recherche venu.

Cadrer un pentest web autorisé

search_skills(source="pentesterflow") liste les playbooks web offensifs ciblés — reconnaissance, SSRF, SSTI, JWT, GraphQL. Chargez celui qui correspond à la surface visée et suivez sa méthodologie pour que le test soit systématique plutôt qu'opportuniste.

Associer SecCheck et DepCheck

Les deux serveurs répondent à deux moitiés du même travail, et se combinent bien :

Question	Serveur
« Cette version de dépendance est-elle sûre à ajouter ? »	DepCheck
« Comment mener correctement cette tâche de sécurité ? »	SecCheck

Un exemple concret : un agent durcit un service. SecCheck fournit le playbook de durcissement et d'implémentation des contrôles ; DepCheck vérifie chaque version de dépendance que ce travail introduit. Aucun ne remplace l'autre : l'un est la méthode, l'autre la vérification des faits.

Pourquoi c'est mieux qu'un agent qui travaille de mémoire

Un modèle capable « sait déjà quelque chose » sur le Kerberoasting ou l'ISO 27001. Le problème est qu'on ne peut pas dire, à la lecture du résultat, quelles parties sont restituées fidèlement, lesquelles sont approximées et lesquelles sont fabulées — et le travail de sécurité est précisément là où cette distinction coûte cher.

Un playbook chargé change l'épistémologie : la procédure est un document que l'on peut lire, relire, versionner et contester. Quand l'agent affirme avoir suivi le playbook de détection, vous pouvez ouvrir le playbook et vérifier.

Limites honnêtes à intégrer dans votre conception

• Le corpus est sélectionné, pas exhaustif. NO MATCH signifie qu'aucun playbook ne couvre le sujet — pas que la tâche est inutile. Assurez-vous que votre agent le remonte au lieu d'improviser en silence.
• La recherche est lexicale, pas sémantique. La notation additive par jetons fait qu'une formulation inhabituelle peut renvoyer des résultats faiblement liés avec une ligne FOUND pourtant affirmative. Faites vérifier à l'agent que la description du premier résultat correspond bien à la tâche, et restreignez avec category / framework sinon.
• Les playbooks portent les hypothèses de leurs auteurs — un SIEM précis, un cloud précis, une chaîne d'outils précise. Ce sont des documents tiers. Lisez-les avant de les exécuter ; adaptez les commandes à votre environnement.
• Un guide n'est pas une autorisation. La bibliothèque renverra volontiers un playbook d'exploitation. Savoir si vous avez le droit de l'exécuter contre un système donné est une question à laquelle SecCheck ne peut pas répondre à votre place.
• Un playbook suivi n'est pas un contrôle prouvé. Utilisez la section de vérification ou de validation du playbook lorsqu'il en a une, et conservez vos autres couches d'assurance.

Voir Sécurité et traitement des données pour ce qui sort du périmètre lorsque l'agent effectue ces appels.