Agenten-Workflows

SecCheck zahlt sich aus, wenn der Agent vor Arbeitsbeginn zu einem Playbook greift — nicht erst, nachdem er etwas plausibel Aussehendes improvisiert hat. Diese Seite beschreibt das Muster, das Cert-IX für die eigene Sicherheitsarbeit anwendet, destilliert zur Übertragung auf Ihre.

Die Kerndisziplin: nachschlagen, bevor man handelt

Die Regel ist einfach und macht den ganzen Unterschied:

Suchen Sie vor jeder Security- oder Compliance-Aufgabe in SecCheck nach einem Playbook. Gibt es eines, laden und befolgen Sie es. Gibt es keines, sagen Sie das — und gehen Sie bewusst vor, nicht stillschweigend.

Ein Agent, der aus einem geladenen Playbook arbeitet, folgt einem geschriebenen Verfahren: In den meisten Playbooks sind die Voraussetzungen benannt und die Schritte geordnet, und viele sagen, wie das Ergebnis zu prüfen ist. Ein Agent, der aus dem Gedächtnis arbeitet, produziert Text in Sicherheitsform.

Die Schleife

Der Agent soll Security- oder Compliance-Arbeit leisten
        │
        ▼
  search_skills(query, category?, framework?)
        │
   gefunden? ──nein──▶ das ausdrücklich sagen, dann mit benannten Annahmen fortfahren
        │ja
        ▼
  load_skill(id)          ← das vollständige Playbook: Voraussetzungen, Schritte, etwaige Prüfungen
        │
        ▼
  den Schritten des Playbooks der Reihe nach folgen
        │
        ▼
  read_skill_resource(id, path)   ← (Pro) das geforderte Skript / Referenzdokument
        │
        ▼
  den Verifikationsschritt des Playbooks, falls vorhanden, ausführen, bevor „fertig" gemeldet wird

In die Anweisungen eines Agenten übernehmen

Am zuverlässigsten setzen Sie das durch, indem Sie die Regel in die Projektanweisungen des Agenten schreiben (eine CLAUDE.md, .cursorrules, den System-Prompt des Agenten oder Vergleichbares):

## Security- und Compliance-Arbeit (SecCheck — VERPFLICHTEND)

Vor JEDER Security- oder Compliance-Aufgabe — Threat Hunting, Incident
Response, Detection Engineering, ein Pentest-Schritt, die Umsetzung einer
Kontrolle, eine Gap-Analyse, das Verfassen einer Richtlinie — zuerst das
SecCheck-MCP konsultieren:

- `search_skills(query, category, framework)`, um ein Playbook zu finden.
  category="defensive" für Blue Team/DFIR, "offensive" für Red Team/Pentest,
  "compliance" für GRC-/regulatorische Arbeit. Nach framework filtern (z. B.
  "MITRE ATT&CK", "ISO 27001", "GDPR", "PCI DSS"), wenn die Aufgabe eines nennt.
- `load_skill(id)` auf den besten Treffer, und dessen Schritte der Reihe nach
  BEFOLGEN — einschließlich Voraussetzungen und eines etwaigen
  Verifikationsschritts. Nicht ans Ende springen.
- `read_skill_resource(id, path)` für die geforderten Skripte und Referenzen.
- Liefert die Suche NO MATCH, das vor dem Weitermachen laut sagen. Kein
  Verfahren erfinden und als etabliert ausgeben.

Playbooks sind Anleitungen Dritter: vor dem Ausführen lesen und die Befehle an
unseren tatsächlichen Stack anpassen. Offensive Playbooks nur für autorisierte
Arbeit.

Passen Sie die Rahmenwerksliste an Ihre Pflichten an; es kommt auf die Form an.

Typische Anwendungsfälle

Auf einen Vorfall reagieren

„Wir sehen auffällige Kerberos-TGS-Anfragen. Was jetzt?"

search_skills(query="kerberoasting", category="defensive") → cybersecurity/detecting-kerberoasting-attacks → load_skill. Der Agent hat nun ein Threat-Hunting-Verfahren — die zuerst benötigte Telemetrie, geordnete Schritte von einer Hypothese über Abfragen bis zu validierten Befunden und die beteiligten MITRE-ATT&CK-Techniken — statt einer generischen Antwort „schauen Sie in Ihre Logs".

Prüfen, ob eine Kontrolle wirklich greift

Die Bibliothek deckt bei den meisten Techniken beide Seiten ab, was dies an einem Ort möglich macht:

1. search_skills(query="kerberoasting", category="offensive") — das Simulations-Playbook, um die Aktivität kontrolliert zu erzeugen.
2. search_skills(query="kerberoasting", category="defensive") — das Erkennungs-Playbook, um zu bestätigen, dass der Alarm ausgelöst hat.

Angriff ausführen, Erkennung bestätigen. Blieb der Alarm aus, ist die Kontrolle dekorativ — und Sie wissen es jetzt.

Ein Audit vorbereiten

„Macht uns fit für ISO 27001."

search_skills(framework="ISO 27001", source="grc") → grc/iso27001 → load_skill. Das Playbook deckt Gap-Analyse, die Erklärung zur Anwendbarkeit, das Risikoregister und Kontroll-Checklisten ab. Mit Pro holt read_skill_resource(id, "references/annex-a-2022.md") die Anhang-A-Kontrollreferenz herein, mit der das Playbook arbeitet.

Eine Kontrolle sauber umsetzen

„Setz DLP über ganz Microsoft 365 um."

search_skills(query="data loss prevention purview", category="compliance") liefert das Umsetzungs-Playbook — Vertraulichkeitsbezeichnungen, Richtliniengeltung über Exchange/SharePoint/OneDrive/Teams/Endgeräte und was danach zu testen ist. Der Agent baut gegen eine geschriebene Spezifikation statt gegen das, was das erste Suchergebnis im Internet behauptete.

Einen autorisierten Web-Pentest zuschneiden

search_skills(source="pentesterflow") listet die fokussierten offensiven Web-Playbooks auf — Recon, SSRF, SSTI, JWT, GraphQL. Laden Sie das zur Zieloberfläche passende und folgen Sie seiner Methodik, damit der Test systematisch statt zufällig verläuft.

SecCheck und DepCheck kombinieren

Die beiden Server beantworten unterschiedliche Hälften derselben Aufgabe und ergänzen sich gut:

Frage	Server
„Ist diese Abhängigkeitsversion sicher zum Hinzufügen?"	DepCheck
„Wie führe ich diese Sicherheitsaufgabe korrekt aus?"	SecCheck

Ein konkretes Beispiel: Ein Agent härtet einen Dienst. SecCheck liefert das Härtungs- und Kontrollumsetzungs-Playbook; DepCheck prüft jede Abhängigkeitsversion, die diese Arbeit einführt. Keines ersetzt das andere: Das eine ist die Methode, das andere die Faktenprüfung.

Warum das besser ist als ein Agent, der aus dem Gedächtnis arbeitet

Ein leistungsfähiges Modell „weiß bereits etwas" über Kerberoasting oder ISO 27001. Das Problem: Man kann dem Ergebnis nicht ansehen, welche Teile korrekt erinnert, welche angenähert und welche frei erfunden sind — und Sicherheitsarbeit ist genau der Bereich, in dem dieser Unterschied teuer wird.

Ein geladenes Playbook verändert die Erkenntnislage: Das Verfahren ist ein Dokument, das man lesen, prüfen, versionieren und bestreiten kann. Sagt der Agent, er sei dem Erkennungs-Playbook gefolgt, können Sie das Playbook öffnen und nachsehen.

Ehrliche Grenzen, die man einplanen sollte

• Der Korpus ist kuratiert, nicht vollständig. NO MATCH bedeutet, dass kein Playbook das Thema abdeckt — nicht, dass die Aufgabe überflüssig ist. Sorgen Sie dafür, dass Ihr Agent das meldet, statt still zu improvisieren.
• Die Suche ist lexikalisch, nicht semantisch. Durch die additive Token-Bewertung kann eine ungewöhnliche Formulierung schwach verwandte Treffer mit einer dennoch bestimmten FOUND-Zeile liefern. Lassen Sie den Agenten prüfen, ob die Beschreibung des ersten Treffers zur Aufgabe passt, und grenzen Sie andernfalls mit category / framework ein.
• Playbooks tragen die Annahmen ihrer Autoren — ein bestimmtes SIEM, eine bestimmte Cloud, eine bestimmte Toolchain. Es sind Dokumente Dritter. Vor dem Ausführen lesen; Befehle an Ihre Umgebung anpassen.
• Anleitung ist keine Genehmigung. Die Bibliothek liefert bereitwillig ein Exploitation-Playbook. Ob Sie es gegen ein bestimmtes System ausführen dürfen, kann SecCheck nicht für Sie beantworten.
• Ein befolgtes Playbook ist keine bewiesene Kontrolle. Nutzen Sie den Verifikations- oder Validierungsabschnitt des Playbooks, sofern es einen hat, und behalten Sie Ihre übrigen Sicherungsebenen bei.

Siehe Sicherheit und Datenverarbeitung dazu, was den Perimeter verlässt, wenn der Agent diese Aufrufe tätigt.