AI-SEC · Percorso 3: Regolare e proteggere
Secure GenAI e Agent Threat Modeling
Due giorni, dopo i quali Lei ha un threat model, un diagramma del flusso di dati e un piano di test per un’applicazione reale invece di una lista di rischi teorici.
- Durata
- 2 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Da remoto · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 4 settimane
- Prezzo
- 15.800 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Per responsabili di sicurezza e governance insieme all’engineering, che devono mettere in sicurezza un’applicazione GenAI o agentica. Ideale quando un’applicazione sta per andare in produzione o è già in esercizio e la sua protezione deve diventare sistematica.
Per chi no
Non per team che non hanno ancora un’applicazione concreta e cercano solo una panoramica. Per la panoramica a livello decisionale è più adatto il Sovereign AI Executive Briefing (AI-EXEC).
Situazione di partenza
La Sua prima applicazione GenAI con collegamento al sapere aziendale o un agente con accesso a strumenti è pronta, ma manca l’analisi di sicurezza. I modelli di minaccia classici non si adattano in modo pulito a input di prompt, fonti RAG e chiamate a tool, e nessuno ha registrato per intero il flusso di dati.
Questo esiste dopo il track
- Un diagramma del flusso di dati della Sua applicazione, dall’input attraverso modello, fonti di sapere e strumenti fino all’output
- Un threat model che trasferisce una sistematica in stile STRIDE su GenAI e agenti
- Un catalogo di misure di protezione concrete: Guardrails, permessi e filtri di output, assegnati per ogni minaccia
- Un piano di test che rende verificabile se una misura funziona
- Una lista dei rischi residui con priorità e responsabili
Prerequisiti
Conoscenze di base di architettura delle applicazioni e sicurezza delle informazioni. Le serve un’applicazione reale da esaminare, almeno come schizzo di architettura.
Preparazione prima del track
Lei porta una descrizione della Sua applicazione target: quali modelli, quali fonti di sapere, quali strumenti e permessi, quali gruppi di utenti. Da questo schizzo nasce al Giorno 1 il diagramma comune del flusso di dati.
Contenuto della fornitura
- Due giornate in presenza o da remoto con Dino Bordonaro e massimo dodici partecipanti
- Template di threat modeling per GenAI e agenti con notazione del flusso di dati
- Quadro di riferimento lungo i noti campi di rischio OWASP LLM come checklist, in formulazione propria
- Template per misure e piano di test da proseguire in azienda
- Accesso all’ambiente di Lab per le dimostrazioni e colloquio di follow-up di 30 minuti dopo quattro settimane
Agenda
Giorno 1
Perché la GenAI ha minacce diverse
Prompt Injection, output non sicuri, fuga di dati attraverso fonti di sapere e strumenti. Domanda centrale: dove questo si distingue dalla sicurezza applicativa classica e dove no?
Diagramma del flusso di dati della Sua applicazione
Disegniamo il flusso completo: input, modello, fonti RAG, chiamate a tool, output. Esercizio: ogni trust boundary viene marcato e nominato.
Trasferire una sistematica in stile STRIDE sulla GenAI
Percorriamo le categorie di minaccia e le traduciamo su prompt, contesto, strumenti e output. Il quadro di riferimento OWASP LLM serve da checklist, perché nessuna categoria venga dimenticata.
Raccogliere le minacce sulla Sua applicazione
Esercizio sul Suo diagramma del flusso di dati: per ogni trust boundary nominiamo attacchi plausibili. Risultato del giorno: un primo threat model con minacce in ordine di priorità.
Giorno 2
Dimostrazione dal vivo nel Lab
Mostriamo in un ambiente preparato come agisce una Prompt Injection attraverso una fonte RAG e cosa rivela uno strumento con permessi troppo ampi. Nessun dato di clienti, solo per capire l’effetto.
Misure di protezione per ogni minaccia
Guardrails, permessi secondo il minimo privilegio, filtri di output, verifica delle fonti. Decisione per ogni minaccia: quale misura, quale sforzo, quale rischio residuo resta?
Costruire il piano di test
Per ogni misura un test che ne dimostra l’effetto. Esercizio: per ogni minaccia importante formuliamo un caso di test concreto con risultato atteso.
Rischi residui e consegna
Raccogliamo ciò che resta e nominiamo i responsabili. Risultato del giorno: threat model, catalogo delle misure, piano di test e lista dei rischi residui con priorità per la Sua applicazione.
Esercitazioni e quota lab
Al secondo giorno dimostrazioni dal vivo nell’ambiente di Lab mostrano l’effetto di Prompt Injection e permessi troppo ampi. Il threat model e il piano di test nascono sulla Sua applicazione reale.
Piattaforme
Svolgimento nei Suoi locali, da remoto o nel nostro Enterprise Lab. Le dimostrazioni girano in un ambiente preparato senza dati di clienti, il Suo threat model lavora con il Suo schizzo di architettura, non con sistemi produttivi.
Prova di transfer
Si verifica la completezza di threat model, catalogo delle misure e piano di test alla fine del Giorno 2, ciascuno sulla Sua applicazione. Partecipazione e contenuti vengono documentati in modo tracciabile e verificabile.
Artefatti che porta con sé
- Diagramma del flusso di dati della Sua applicazione con trust boundary marcati
- Threat model con minacce in ordine di priorità
- Catalogo delle misure con Guardrails, permessi e filtri di output
- Piano di test con casi di test concreti per ogni misura
- Lista dei rischi residui con priorità e responsabili
Estensioni opzionali
- Evaluation, Observability e Guardrails (AI-EVAL) per la messa in sicurezza misurabile della Sua applicazione in esercizio
- AI Risk Classification Lab (AI-RISK) per la classificazione preliminare dell’applicazione
- Evaluation, Observability e Guardrails (AI-EVAL) per il monitoraggio continuo delle misure attuate
Delimitazione
Il track fornisce modello, misure e piano di test come bozza. Non sostituisce un’implementazione, né un mandato di penetration test, né un servizio di sicurezza gestito.
Domande frequenti
Dobbiamo portare un’applicazione finita?
No, basta uno schizzo di architettura solido. È importante che modelli, fonti di sapere, strumenti e gruppi di utenti siano nominati, perché da lì nascono il diagramma del flusso di dati e il threat model.
Copiate semplicemente la lista OWASP LLM?
No. Usiamo i noti campi di rischio OWASP LLM come quadro di riferimento e checklist, perché non manchi nessuna categoria, e li trasferiamo con una sistematica propria sulla Sua applicazione concreta. Il risultato è il Suo threat model, non una lista copiata.
Nel farlo attaccate il nostro sistema?
No. Modelliamo le minacce e ne mostriamo l’effetto in una dimostrazione di Lab preparata. Il Suo team esce con un piano di test in ordine di priorità e lo lavora da solo o con un partner di verifica.