Flussi di lavoro degli agenti

SecCheck dà il meglio quando l'agente ricorre a un playbook prima di cominciare a lavorare, non dopo aver improvvisato qualcosa dall'aria plausibile. Questa pagina raccoglie lo schema che Cert-IX applica al proprio lavoro di sicurezza, distillato perché possa applicarlo al suo.

La disciplina di fondo: informarsi prima di agire

La regola è semplice ed è tutto ciò che conta:

Prima di eseguire un compito di sicurezza o conformità, cerchi un playbook in SecCheck. Se esiste, lo carichi e lo segua. Se non esiste, lo dica — e proceda in modo deliberato, non silenzioso.

Un agente che lavora a partire da un playbook caricato segue una procedura scritta: nella maggior parte dei playbook i prerequisiti sono dichiarati e i passaggi sono in ordine, e molti spiegano come verificare il risultato. Un agente che lavora a memoria produce testo a forma di sicurezza.

Il ciclo

All'agente viene chiesto un lavoro di sicurezza o conformità
        │
        ▼
  search_skills(query, category?, framework?)
        │
   trovato? ──no──▶ dirlo esplicitamente, poi procedere dichiarando le ipotesi
        │sì
        ▼
  load_skill(id)          ← il playbook completo: prerequisiti, passaggi, eventuali verifiche
        │
        ▼
  seguire i passaggi del playbook, in ordine
        │
        ▼
  read_skill_resource(id, path)   ← (Pro) lo script/il riferimento richiesto
        │
        ▼
  eseguire il passaggio di verifica del playbook, se presente, prima di dichiarare concluso

Inserirlo nelle istruzioni di un agente

Il modo più affidabile perché un agente lo faccia è mettere la regola nelle sue istruzioni di progetto (un CLAUDE.md, un .cursorrules, il prompt di sistema dell'agente o equivalente):

## Lavoro di sicurezza e conformità (SecCheck — OBBLIGATORIO)

Prima di eseguire QUALSIASI compito di sicurezza o conformità — threat hunting,
risposta agli incidenti, detection engineering, un passaggio di pentest,
l'implementazione di un controllo, un'analisi degli scostamenti, la stesura di
una policy — consultare prima l'MCP SecCheck:

- `search_skills(query, category, framework)` per trovare un playbook.
  Usare category="defensive" per blue team/DFIR, "offensive" per red
  team/pentest, "compliance" per lavoro GRC/regolamentare. Filtrare per
  framework (ad es. "MITRE ATT&CK", "ISO 27001", "GDPR", "PCI DSS") quando il
  compito ne nomina uno.
- `load_skill(id)` sulla corrispondenza migliore, e SEGUIRNE i passaggi in
  ordine — prerequisiti ed eventuale passaggio di verifica compresi. Non saltare
  alla fine.
- `read_skill_resource(id, path)` per gli script e i riferimenti richiesti.
- Se la ricerca restituisce NO MATCH, dirlo ad alta voce prima di proseguire.
  Non inventare una procedura e presentarla come consolidata.

I playbook sono indicazioni di terze parti: leggerli prima di eseguirli e
adattare i comandi al nostro stack reale. I playbook offensivi sono riservati al
lavoro autorizzato.

Adatti l'elenco dei framework ai suoi obblighi; è la forma che conta.

Casi d'uso ricorrenti

Rispondere a un incidente

«Vediamo richieste Kerberos TGS anomale. E adesso?»

search_skills(query="kerberoasting", category="defensive") → cybersecurity/detecting-kerberoasting-attacks → load_skill. L'agente dispone ora di una procedura di threat hunting — la telemetria che gli serve prima di iniziare, passaggi ordinati che vanno da un'ipotesi, attraverso le query, fino a riscontri convalidati, e le tecniche MITRE ATT&CK coinvolte — invece di una risposta generica del tipo «controlli i log».

Validare che un controllo funzioni davvero

La libreria copre entrambi i lati della maggior parte delle tecniche, ed è questo a rendere possibile tutto ciò in un unico posto:

1. search_skills(query="kerberoasting", category="offensive") — il playbook di simulazione, per generare l'attività in modo controllato.
2. search_skills(query="kerberoasting", category="defensive") — il playbook di rilevamento, per confermare che l'allarme sia scattato.

Esegua l'attacco, confermi il rilevamento. Se non è scattato, il controllo è decorativo — e adesso lo sa.

Prepararsi a un audit

«Preparaci alla ISO 27001.»

search_skills(framework="ISO 27001", source="grc") → grc/iso27001 → load_skill. Il playbook copre l'analisi degli scostamenti, la Dichiarazione di Applicabilità, il registro dei rischi e le liste di controllo. Con Pro, read_skill_resource(id, "references/annex-a-2022.md") recupera il riferimento dei controlli dell'Allegato A su cui il playbook lavora.

Implementare un controllo per bene

«Implementa il DLP su tutto Microsoft 365.»

search_skills(query="data loss prevention purview", category="compliance") restituisce il playbook di implementazione — etichette di riservatezza, ambito delle policy su Exchange/SharePoint/OneDrive/Teams/dispositivi e cosa testare dopo. L'agente costruisce a partire da una specifica scritta anziché da ciò che diceva il primo risultato di ricerca su internet.

Delimitare un pentest web autorizzato

search_skills(source="pentesterflow") elenca i playbook web offensivi mirati — ricognizione, SSRF, SSTI, JWT, GraphQL. Carichi quello corrispondente alla superficie bersaglio e ne segua la metodologia, così che il test sia sistematico anziché opportunistico.

Abbinare SecCheck e DepCheck

I due server rispondono a due metà dello stesso lavoro e si combinano bene:

Domanda	Server
«Questa versione di dipendenza è sicura da aggiungere?»	DepCheck
«Come eseguo correttamente questo compito di sicurezza?»	SecCheck

Un esempio concreto: un agente irrobustisce un servizio. SecCheck fornisce il playbook di hardening e implementazione dei controlli; DepCheck verifica ogni versione di dipendenza che quel lavoro introduce. Nessuno sostituisce l'altro: uno è il metodo, l'altro la verifica dei fatti.

Perché è meglio di un agente che lavora a memoria

Un modello capace «sa già qualcosa» su Kerberoasting o sulla ISO 27001. Il problema è che dall'output non si distingue quali parti siano ricordate con esattezza, quali approssimate e quali inventate — e il lavoro di sicurezza è proprio l'ambito in cui quella distinzione costa cara.

Un playbook caricato cambia l'epistemologia: la procedura è un documento che si può leggere, rivedere, versionare e contestare. Quando l'agente dice di aver seguito il playbook di rilevamento, può aprire il playbook e verificare.

Limiti onesti da mettere in conto

• Il corpus è curato, non esaustivo. NO MATCH significa che nessun playbook copre l'argomento — non che il compito sia superfluo. Si assicuri che il suo agente lo segnali invece di improvvisare in silenzio.
• La ricerca è lessicale, non semantica. Il punteggio additivo sui token fa sì che una formulazione insolita possa restituire risultati poco pertinenti con una riga FOUND comunque perentoria. Faccia verificare all'agente che la descrizione del primo risultato corrisponda al compito, e restringa con category / framework quando non è così.
• I playbook portano con sé le assunzioni dei loro autori — un SIEM preciso, un cloud preciso, una toolchain precisa. Sono documenti di terze parti. Li legga prima di eseguirli; adatti i comandi al suo ambiente.
• L'indicazione non è un'autorizzazione. La libreria restituirà volentieri un playbook di sfruttamento. Se lei sia autorizzato a eseguirlo contro un dato sistema è una domanda a cui SecCheck non può rispondere al posto suo.
• Un playbook seguito non è un controllo dimostrato. Usi la sezione di verifica o di convalida del playbook, quando c'è, e mantenga gli altri livelli di garanzia.

Si veda Sicurezza e trattamento dei dati per sapere cosa esce dal perimetro quando l'agente effettua queste chiamate.