AS2_2025

Marzo 2025 Automazione e Strumentazione Tecnica 82 CONTROLLO Tabella 2 - Esempio di matrice per l’analisi del rischio I quattro Security Levels (che possono essere differenziati per ‘zone’ geografiche o funzionali) sono: • SL-1: protezione contro violazioni accidentali. • SL-2: protezione contro semplici attacchi intenzionali effettuati con mezzi e competenze limitate. • SL-3: protezione contro attacchi deliberati per- petrati con risorse adeguate e competenze non superficiali. • SL-4: protezione contro attacchi specifica- mente mirati perpetrati con risorse sofisticate, competenze profonde e motivazione elevata. • I quattro livelli di maturità (ML) compren- dono: • ML-1: Modesta: policies e contromisure incomplete e non del tutto documentate. • ML-2: Gestibile: procedure e competenze documentate ma osservate con non assoluta ripetibilità. • ML-3: Praticata: policies e procedure ben con- solidate e seguite in modo tracciabile (audit). • ML-4: Elevata: policies e procedure soggette seguite e aggiornate in base a monitoraggio continuo delle prestazioni secondo metriche quantitative. Le indicazioni della IEC62443 sono di procedere con una analisi del rischio supportata da oppor- tune matrici che incrociano l’occorrenza di ogni possibile incidente con il suo impatto e determi- nano così la severità complessiva della minaccia da prevenire e quindi il grado SL da perseguire; queste matrici si presentano tipicamente nella forma della tabella 2 . Naturalmente la ‘taratura’ della matrice è a discrezione di chi effettua l’analisi del rischio. Indi, una volta stabilito il security level (SL) associato a quel potenziale incidente, è oppor- tuno declinare i rispettivi accorgimenti tecnici e/o procedurali per ciascuno dei sette Requisiti Fondamentali. L’incrocio tra i Requisiti Fondamentali e i Security-Levels può essere schematizzato ancora una volta in forma tabellare e da esso discende la necessità o meno di impiegare le varie contromisure, che devono essere collo- cate nelle varie celle in funzione della natura tecnica del requisito. Se SL è basso, dunque, anche i requisiti pos- sono essere soddisfatti più semplicemente. Per esempio, potrebbe non essere necessario arri- vare a implementare controllo accessi con il riconoscimento oculare o basati su dispositivi hardware (per esempio tessere), oppure il trac- ciamento di tutte le azioni di tutti gli utenti, o la gestione centralizzata/automatizzata dei backup, o magari, infine, l’impiego di data- diode o controllori logici non programmabili (solo hardware). Oltre all’impiego di dispositivi e soluzioni, dal target SL risultano condizionate anche le ore di ingegneria da prevedere per la abilitazione e configurazione delle loro funzioni opzionali (per esempio alcune tra le numerose messe a disposi- zione da un Network Management System). Secondo una analisi condivisa tra il DCS Vendor Yokogawa e H-ON a TÜV Rheinland Com- pany , la tabulazione tra i requisiti e gli SL è riportata nelle tabelle 4-10 . Le risoluzioni dei vari requisiti dipendono dalle molte impostazioni da fare a livello di sistema operativo, all’implementazione di pacchetti addizionali fino alla introduzione di dispositivi dedicati in base alle funzionalità e alla architet- tura del sistema di controllo complessivamente implementato. In generale, le contromisure più tipicamente considerate sono le seguenti: Hardening delle macchine per ridurre i possibili punti attaccabili (no AutoRun, no NetBIOS over TCP/IP, no removable devices + USB port secu- rity, no SNMP SET command, many other Win- dows related settings). Antivirus per individuare malware & whiteli- sting per impedire l’esecuzione di programmi non autorizzati / ransomware. Patch Management per eliminare le vulnerabi- lità rilevate (relativamente alle quali vengono Tabella 3 - Incrocio tra i Requisiti Fondamentali e i Security-Levels