Vai al contenuto
Legiscope
Menu
Protezione dei dati

EBIOS Risk Manager: condurre gli atelier e documentare gli scenari

Percorso in cinque atelier per definire scenari, misure e responsabilità del rischio. Metodo, responsabilità, verifiche e documentazione da adattare al proprio contesto.

EBIOS Risk Manager è un metodo di analisi e trattamento del rischio digitale sviluppato dall’ANSSI. Organizza il lavoro in cinque atelier, dal perimetro e dagli impatti fino agli scenari di attacco e al piano di trattamento. Per un’organizzazione italiana può essere un metodo di lavoro scelto in funzione del contesto; non è una certificazione GDPR né un obbligo generale imposto a ogni impresa.

La presentazione ufficiale ANSSI distingue un insieme di misure di base e un’analisi per scenari concentrata sulle minacce intenzionali e mirate. Il valore del metodo sta nel collegare servizio, ecosistema e percorsi di attacco a decisioni concrete. Questo articolo segue i cinque atelier e propone un esempio ipotetico per preparare una riunione di rischio con risultati utilizzabili.

Preparare partecipanti, perimetro e linguaggio comune

Individuare il servizio da studiare, il decisore, il responsabile operativo, l’IT, la sicurezza e le persone che conoscono fornitori e contratti. Il gruppo non deve essere composto soltanto da tecnici: gli impatti sulle attività e sulle persone richiedono conoscenza del servizio.

Prima delle riunioni, raccogliere la mappatura dei sistemi e dei flussi, incidenti pertinenti, vincoli contrattuali, dipendenze e controlli già verificati. Se questi elementi mancano, registrare l’incertezza e assegnare una verifica. Inventare dettagli per completare il diagramma rende lo scenario apparentemente preciso ma poco attendibile.

Definire scale comprensibili per gravità e verosimiglianza. Ogni livello dovrebbe avere una descrizione applicabile al servizio. Un numero da uno a quattro senza criteri condivisi non permette di confrontare valutazioni fatte da reparti diversi.

Atelier 1: delimitare lo studio e verificare le misure di base

Il primo atelier individua missioni, valori dell’attività, beni che li sostengono ed eventi temuti. Un valore può essere la capacità di erogare il servizio o l’affidabilità di un’informazione; il server è un bene di supporto. Partire soltanto dall’elenco delle macchine fa perdere il significato dell’impatto.

Per un portale di documenti, gli eventi temuti potrebbero essere indisponibilità prolungata, alterazione dei documenti o accesso da parte di un destinatario non autorizzato. Descrivere conseguenze concrete e persone coinvolte, evitando «danno reputazionale» come unica spiegazione di ogni evento.

Valutare poi il rispetto delle misure di base pertinenti. Il piano di igiene informatica aiuta a verificare identità, aggiornamenti, backup e accessi. Le carenze evidenti possono già generare azioni nel piano finale; non occorre costruire uno scenario sofisticato per correggere un account amministrativo dimenticato.

Atelier 2: individuare fonti di rischio e obiettivi

Il secondo atelier considera chi potrebbe compromettere il servizio e per quale obiettivo. Distinguere, per esempio, un attore interessato all’estorsione da uno che cerca informazioni commerciali o da un soggetto interno che intende usare indebitamente i propri accessi.

Non basta elencare categorie di aggressori. Valutare motivazione, capacità e pertinenza rispetto all’organizzazione, dichiarando le informazioni disponibili e le ipotesi. Un’impresa non dovrebbe attribuire capacità eccezionali a ogni scenario solo per renderlo impressionante, né escludere un rischio perché non ha mai osservato un attacco simile.

Il risultato è una selezione motivata di coppie fonte di rischio e obiettivo. Le coppie escluse possono essere annotate con la ragione, così da riesaminarle quando cambiano attività, esposizione o informazioni sulla minaccia. La selezione deve restringere il lavoro in modo consapevole, non nascondere i rischi scomodi.

Atelier 3: costruire scenari strategici attraverso l’ecosistema

Esaminare partner, fornitori, filiali e altri soggetti che contribuiscono al servizio. Per ciascuna relazione, valutare dipendenza, accessi e capacità di influenzare i valori individuati. Un fornitore piccolo può avere un ruolo decisivo se dispone dell’unico accesso di manutenzione a un sistema centrale.

Lo scenario strategico descrive un percorso di alto livello: un attore compromette il supporto esterno e lo usa per raggiungere il portale, oppure sfrutta una relazione di fiducia tra due organizzazioni. Non è ancora un elenco di comandi tecnici, ma deve mostrare i passaggi che rendono plausibile l’attacco.

Per i servizi finanziari nel relativo ambito, la valutazione dei fornitori TIC secondo DORA può fornire elementi sul rapporto e sulle dipendenze. EBIOS RM resta un metodo di analisi: i requisiti normativi pertinenti devono essere verificati separatamente e inseriti nel quadro dello studio.

Atelier 4: descrivere scenari operativi e verosimiglianza

Il quarto atelier sviluppa i percorsi tecnici sui beni di supporto. Collegare punto di ingresso, passaggi necessari, privilegi, controllo aggirato e obiettivo. Dichiarare quali condizioni siano confermate e quali debbano essere verificate.

Un percorso ipotetico può partire da un account di assistenza compromesso, proseguire attraverso un accesso remoto troppo ampio e raggiungere un archivio non segmentato. La valutazione deve considerare autenticazione, limitazioni, rilevazione e capacità dell’attore. La politica di password e autenticazione multifattore e l’architettura dei log diventano elementi dello scenario, non semplici allegati.

Quando occorre verificare un’ipotesi tecnica, definire un audit di sicurezza o una prova autorizzata con perimetro chiaro. Non trasformare la riunione di rischio in un’autorizzazione implicita a eseguire test su sistemi di terzi.

Atelier 5: decidere misure, rischio residuo e controllo

Riunire gli scenari, individuare una strategia di trattamento e tradurla in misure con proprietario, risorse, scadenza e prova di efficacia. La misura deve interrompere o ridurre un passaggio concreto, oppure limitare le conseguenze. «Fare formazione» è incompleto se non si indica quale comportamento rischioso deve cambiare.

Valutare il rischio residuo dopo le misure previste distinguendolo da quello già ridotto da controlli attivi e verificati. Un acquisto approvato ma non installato non può essere considerato operativo. La decisione sul rischio residuo deve identificare chi decide e quali condizioni accompagnano l’approvazione.

La guida e il materiale ufficiale EBIOS RM forniscono gli strumenti metodologici. Il gruppo deve comunque motivare le proprie scelte: un foglio compilato secondo il formato corretto non dimostra che lo scenario sia pertinente.

Un esempio ipotetico lungo i cinque atelier

Un’organizzazione gestisce un portale che consegna documenti ai clienti. La direzione teme sia l’indisponibilità sia la consultazione da parte di altri clienti. Il fornitore di manutenzione dispone di accesso remoto e gli account privilegiati non hanno ancora un controllo periodico completo.

Atelier Risultato dell’esempio
Primo Portale, archivio e accesso di manutenzione inclusi; indisponibilità e divulgazione individuate come eventi temuti
Secondo Attore interessato all’estorsione selezionato per pertinenza al servizio
Terzo Percorso attraverso il fornitore di manutenzione descritto e dipendenza documentata
Quarto Ipotesi di compromissione dell’account, accesso eccessivo e movimento verso l’archivio da verificare
Quinto Riduzione dei privilegi, autenticazione forte, controllo dei log e prova di ripristino assegnati a responsabili distinti

Il piano indica che la riduzione dei privilegi sarà verificata con un account di prova e che la capacità di recupero sarà dimostrata attraverso il piano di disaster recovery. La direzione distingue le azioni completate da quelle ancora aperte e non descrive l’intero rischio come risolto dopo una sola modifica.

Collegare EBIOS RM alla DPIA senza confondere gli obiettivi

La DPIA dell’articolo 35 del GDPR considera trattamento, necessità, proporzionalità e rischi per diritti e libertà. EBIOS RM può contribuire all’analisi della sicurezza, ma non sostituisce l’esame della liceità o dei diritti. Un servizio tecnicamente resistente può comunque raccogliere dati non necessari.

Includere quindi nel lavoro privacy anche usi impropri, errori organizzativi e conseguenze sulle persone che non dipendono da un attacco intenzionale. Le misure tecniche e organizzative devono restare collegate al trattamento e al rischio che intendono ridurre.

Mantenere lo studio utilizzabile nel tempo

Definire un ciclo di riesame e gli eventi che lo anticipano: nuovo fornitore, nuova esposizione, incidente, modifica dei privilegi o cambiamento del servizio. Conservare ipotesi e limiti, così che il gruppo successivo possa capire perché una coppia fonte-obiettivo o una misura sia stata scelta.

Il responsabile dello studio deve controllare le azioni e aggiornare gli scenari quando le prove smentiscono un’ipotesi. Una mappa di rischio non è un oggetto da difendere per coerenza con la prima riunione: deve cambiare quando il servizio e le evidenze cambiano. Il valore dell’analisi emerge nelle decisioni che rende possibili e nella verifica delle misure effettivamente attuate.

L
Scritto da
Legiscope
Legiscope

Metti in pratica questa guida

Scopri come Legiscope collega registri privacy, fonti e attività soggette a revisione.

Prenota una demo personalizzata
Continua a leggere

Articoli correlati

01Protezione dei dati

Accesso civico generalizzato: valutare il pregiudizio ai dati personali

Quando una richiesta di accesso civico generalizzato riguarda documenti con dati personali, l'amministrazione deve valutare se l'ostensione comporti un pregiudizio concreto alla protezione di quei…

8 settembre 2026
02Protezione dei dati

Accountability GDPR: organizzare prove e decisioni

L'accountability GDPR impone al titolare di rispettare i principi del trattamento e di poterlo dimostrare. Il punto di partenza è l'articolo 5, paragrafo 2, mentre l'articolo 24 collega la…

8 settembre 2026
03Protezione dei dati

Albo pretorio: oscurare i dati prima della pubblicazione

Prima di pubblicare un atto nell'albo pretorio online, l'ente deve verificare quale norma imponga o consenta la diffusione, quali dati siano necessari e per quanto tempo debbano restare disponibili.…

8 settembre 2026
04Protezione dei dati

Amministratori di sistema: fascicolo e verifica annuale

La verifica annuale degli amministratori di sistema deve collegare persone, funzioni autorizzate e sistemi effettivamente gestiti. Il risultato utile è un fascicolo che dimostra chi può svolgere…

8 settembre 2026
05Protezione dei dati

Approvare la sicurezza di un sistema: dossier e rischio residuo

L'approvazione della sicurezza di un sistema è una decisione documentata sulle condizioni alle quali il servizio può essere utilizzato. Riunisce perimetro, rischi, misure, verifiche e limitazioni…

8 settembre 2026
06Protezione dei dati

Articolo 12 GDPR: organizzare comunicazioni e richieste di diritti

L'articolo 12 GDPR stabilisce come rendere comprensibili le informazioni e come facilitare l'esercizio dei diritti. Per un'organizzazione, questo significa predisporre canali riconoscibili, personale…

8 settembre 2026
07Protezione dei dati

Audit di sicurezza informatica: scegliere il perimetro e le prove

Un audit di sicurezza informatica deve rispondere a una domanda definita e produrre conclusioni sostenute da prove. Prima di chiedere un preventivo, stabilire se occorre valutare architettura,…

8 settembre 2026
08Protezione dei dati

Basi giuridiche del trattamento: art. 6 GDPR in pratica

Ogni trattamento di dati personali deve poggiare su una delle sei basi giuridiche dell'art. 6, par. 1 GDPR: consenso, contratto, obbligo legale, interesse vitale, compito di interesse pubblico,…

7 luglio 2026