Obiettivi di apprendimento
- Descrivere il quadro normativo IMO sulla gestione del rischio cyber (Risoluzione MSC.428(98)).
- Distinguere sistemi IT e OT a bordo e comprendere la logica della segregazione di rete.
- Riconoscere i principali vettori di attacco cyber a livello concettuale.
- Applicare un ciclo di gestione del rischio cyber (governare, identificare, proteggere, rilevare, rispondere, ripristinare).
- Gestire il percorso di risposta a un incidente cyber a bordo.
- Contribuire a una cultura organizzativa di cyber security awareness.
Il quadro normativo: la Risoluzione MSC.428(98)
Obiettivo del moduloDistinguere la base vincolante dell’ISM Code e dell’SMS dal ruolo di MSC.428(98) e delle linee guida IMO Rev.4 nella strutturazione della gestione del rischio cyber.
Il documento IMO corrente è la MSC-FAL.1/Circ.3/Rev.4, emanata il 28 maggio 2026 dopo FAL 50 e MSC 111. È guidance di alto livello con sei elementi funzionali e controlli organizzativi, operativi e tecnici.
Per le navi soggette all’ISM Code, l’ISM Code e l’attuazione di bandiera costituiscono la base obbligatoria della gestione tramite SMS. La MSC.428(98) si rivolge alle Amministrazioni e ha portato il rischio cyber nella verifica dell’SMS; la Rev.4 spiega come strutturarlo.
La MSC.428(98) incoraggia le Amministrazioni ad assicurare che i rischi cyber siano affrontati nell’SMS non oltre la prima verifica annuale del DOC successiva al 1° gennaio 2021. La base obbligatoria per le navi soggette è l’ISM Code tramite SOLAS IX e l’attuazione di bandiera; le regole di classe costituiscono un livello distinto. Un rilievo di audit deve collegare evidenze e requisito applicabile, senza confondere una raccomandazione con un obbligo autonomo.
In sintesi
- MSC.428(98) indirizza le Amministrazioni; la verifica concreta passa attraverso l’SMS e il regime applicabile.
- La fonte IMO corrente è
MSC-FAL.1/Circ.3/Rev.4del 28 maggio 2026. - Cyber risk management integra safety e security management; non è un fascicolo IT separato.
Gli strati regolatori: chi obbliga a cosa, e da quando
Obiettivo del moduloMappare IMO/ISM, guidance, regole di classe e NIS2 sui rispettivi destinatari, campi di applicazione, verifiche e finestre di reporting.
ISM/SMS, guidance IMO, regole di classe e diritto UE/nazionale hanno destinatari e forza diversi. Un unico piano può coordinarli, ma non ne rende identici gli obblighi.
NIS2: verificare il perimetro
L’Allegato I della Direttiva (UE) 2022/2555 include compagnie di trasporto passeggeri e merci per vie d’acqua interne, marittime e costiere, organismi di gestione dei porti e relative port facilities, e operatori VTS. Le singole navi operate dalle compagnie sono escluse come entità destinatarie. Verificare attività, dimensione (in generale almeno media), stabilimento, eccezioni dell’articolo 2, identificazione e recepimento nazionale: una ship manager non rientra automaticamente perché gestisce una nave.
Significatività e notifiche — articolo 23
È significativo un incidente che ha causato o può causare grave perturbazione operativa dei servizi o perdite finanziarie all’entità, oppure che ha colpito o può colpire altre persone causando danni materiali o immateriali considerevoli.
- Senza ingiustificato ritardo ed entro 24 ore dalla conoscenza dell’incidente significativo: preallarme al CSIRT o all’autorità competente.
- Senza ingiustificato ritardo ed entro 72 ore dalla stessa conoscenza: notifica con valutazione iniziale di gravità e impatto e indicatori di compromissione disponibili.
- Rapporto intermedio su richiesta.
- Entro un mese dalla notifica dell’incidente: rapporto finale. Se l’incidente è ancora in corso, rapporto sui progressi a tale scadenza e rapporto finale entro un mese dalla sua gestione.
La Rev.4, §3.5.5.1, raccomanda il reporting alle parti necessarie nei tempi definiti dall’Amministrazione: non fissa una scadenza cyber globale unica. La matrice aziendale deve includere obblighi applicabili di bandiera, safety/security, ISM §9.1, classe, NIS2/norme nazionali, privacy, assicurazioni e contratti. Il reporting interno non sostituisce le notifiche esterne.
In sintesi
- SMS, class e NIS2 non hanno lo stesso destinatario né la stessa natura giuridica.
- NIS2 riguarda entità in scope, non automaticamente ogni ship manager o singola nave.
- La matrice di reporting deve unire bandiera, classe, legge nazionale, contratti e assicurazioni.
Sistemi IT e OT: una distinzione essenziale
Obiettivo del moduloRiconoscere IT, OT, interdipendenze e conduit di bordo, collegando la criticità cyber alle conseguenze operative e di safety.
Comprendere la distinzione tra sistemi IT (Information Technology) e OT (Operational Technology) è il primo passo per una gestione efficace del rischio cyber a bordo, poiché le due categorie richiedono approcci di protezione diversi.
| Categoria | Esempi tipici a bordo |
|---|---|
| IT (Information Technology) | Email, sistemi amministrativi, comunicazioni con l'ufficio, intrattenimento equipaggio |
| OT (Operational Technology) | ECDIS, GPS, sistemi di automazione dell'apparato motore, sistemi di gestione del carico |
La classificazione dipende da funzione e interdipendenze. Il rischio comprende compromissione della riservatezza, integrità e disponibilità, dovuta anche a errori di configurazione, manutenzione o aggiornamento, oltre che ad azioni intenzionali. La segmentazione va verificata da personale IT/OT competente con prove compatibili con la sicurezza operativa; DPA e HSEQ ne seguono la gestione nell’SMS secondo le funzioni assegnate.
In sintesi
- IT usa principalmente dati e comunicazioni; OT controlla o monitora processi fisici.
- La classificazione di un asset dipende dalla funzione e dalle dipendenze, non solo dal tipo di dispositivo.
- Inventario, topologia e flussi sono prerequisiti di una segmentazione verificabile.
Dalla segregazione al progetto: IEC 62443 e le regole di classe
Obiettivo del moduloInterpretare zone, conduit e deliverable E26/E27 per verificare requisiti di progetto, responsabilità contrattuali ed evidenze ricevute alla consegna.
IEC 62443 organizza sistemi industriali in zone e conduits. La segmentazione è risk-based: architettura, inventario, flussi, dipendenze, accessi e security levels devono essere verificabili.
IACS UR E26 riguarda la nave integrata; E27 sistemi ed equipment di bordo. Sono requisiti di classe applicati secondo ship type, tonnage, contract date, scope e regole della società di classifica: non un identico obbligo diretto per cantiere, supplier e owner.
Deliverable, topologie, configurazioni, test e responsabilità di handover vanno mantenuti lungo il ciclo di vita.
IEC 62443-3-2 associa livelli di sicurezza obiettivo (SL-T) a zone e conduit sulla base della valutazione del rischio. Le capacità di sicurezza dei componenti sono trattate separatamente, per esempio dalla IEC 62443-4-2. Questi livelli non sono i livelli di security 1, 2 e 3 dell’ISPS. La responsabilità per inventari, topologie, configurazioni, integrazione, prove e consegna va assegnata secondo E26/E27 applicabili, contratti e regole di classe.
In sintesi
- E26 guarda alla nave integrata; E27 ai sistemi e agli equipment di bordo.
- Lo scope va verificato su tipo, stazza, data contrattuale e regole della classe.
- Inventari, topologie, configurazioni e test sono asset operativi da mantenere dopo la consegna.
Esempi di vettori di attacco
Obiettivo del moduloRiconoscere vettori di attacco e altre cause di incidente, collegandoli a vulnerabilità, sistemi esposti e controlli preventivi.
A livello concettuale, è utile per il personale non specialistico conoscere alcuni esempi di vettori di attacco, per riconoscere segnali di allarme e adottare comportamenti prudenti, senza addentrarsi in dettagli tecnici operativi che esulano dallo scopo di questo corso.
| Categoria | Descrizione generale |
|---|---|
| Phishing via email | Comunicazioni ingannevoli che inducono l'utente a fornire credenziali o eseguire codice dannoso |
| Dispositivi rimovibili non controllati | Chiavette USB o dispositivi esterni non verificati che possono introdurre codice dannoso |
| Accesso remoto di manutenzione | Connessioni esterne per assistenza tecnica che, se non adeguatamente controllate, possono essere sfruttate |
| Reti wireless non protette | Punti di accesso wireless a bordo o in porto privi di adeguata protezione |
Formazione, controlli tecnici e procedure si completano: non è giustificato attribuire la maggior parte degli incidenti a un’unica causa senza dati pertinenti. Considerare anche errori, configurazioni, manutenzione e supply chain.
In sintesi
- Email, removable media, remote access e wireless sono esempi, non un elenco completo.
- Il vettore descrive come si entra; vulnerabilità e conseguenze dipendono dall’architettura e dai privilegi.
- Comportamento, configurazione, manutenzione e supply chain devono essere valutati insieme.
Il ciclo di gestione del rischio cyber
Obiettivo del moduloApplicare i sei elementi della Rev.4 come sistema continuo di governance, identificazione, protezione, rilevamento, risposta e recupero.
La MSC-FAL.1/Circ.3/Rev.4 usa sei elementi concorrenti e continui: Govern, Identify, Protect, Detect, Respond e Recover. Govern definisce strategia, aspettative, politiche, ruoli, risorse, continuità e crisis management; gli altri trasformano la governance in inventario, protezioni, rilevamento, risposta e recupero.
NIST CSF 2.0 usa la stessa architettura a sei funzioni. Govern non è quindi un’aggiunta esterna al modello IMO corrente, pur restando i due framework distinti per natura e applicazione.
In sintesi
- Govern è ora un elemento sia IMO sia NIST CSF 2.0.
- I sei elementi operano in parallelo e producono feedback continuo.
- Strategia, responsabilità e risorse devono precedere e sostenere i controlli tecnici.
Gestione degli accessi e aggiornamenti
Obiettivo del moduloDefinire controlli risk-based per identità, privilegi, accessi di terzi, patching e modifiche senza compromettere disponibilità e safety OT.
La gestione degli accessi e degli aggiornamenti contribuisce alla protezione dei sistemi critici e deve essere compatibile con la continuità operativa.
Principi generali di buona pratica
- Limitare l'accesso ai sistemi OT critici solo al personale che ne ha effettiva necessità operativa.
- Revocare tempestivamente gli accessi del personale che sbarca o lascia la compagnia.
- Mantenere un inventario aggiornato di tutti i sistemi digitali di bordo e del loro stato di aggiornamento.
- Verificare l'identità e l'autorizzazione di ogni tecnico esterno prima di consentire un accesso di manutenzione, remoto o fisico.
Tecnici esterni per la manutenzione di impianti specifici (per esempio il costruttore del motore o dell'impianto di automazione) richiedono spesso accesso a sistemi OT critici: verificarne identità, autorizzazione e limitare l'accesso al tempo strettamente necessario è una misura di protezione essenziale spesso trascurata per ragioni di comodità operativa.
Usare credenziali individuali, cambiare le password predefinite, separare gli account privilegiati e applicare il minimo privilegio; prevedere MFA dove appropriata e accessi di emergenza controllati. Gli accessi dei fornitori devono essere approvati, limitati nel tempo, registrati e chiusi al termine del lavoro. Per gli aggiornamenti OT valutare vulnerabilità, compatibilità del costruttore e dipendenze: eseguire test, approvare una finestra operativa, predisporre backup e ritorno alla configurazione precedente, poi verificare il funzionamento. Se una patch non è applicabile, documentare rischio residuo, misure compensative e riesame. Evitare aggiornamenti automatici o scansioni invasive non validati sui sistemi critici.
In sintesi
- Account individuali e privilegi separati rendono le azioni attribuibili.
- L’accesso remoto deve essere autorizzato, limitato, monitorato e chiuso verificabilmente.
- Patch e configurazioni OT richiedono compatibilità, test, approvazione e management of change.
Rilevamento di anomalie
Obiettivo del moduloCombinare monitoring tecnico, baseline operative e segnalazioni dell’equipaggio per riconoscere anomalie senza confondere un guasto con un attacco.
La capacità di riconoscere tempestivamente un'anomalia, prima che degeneri in un incidente conclamato, dipende sia da strumenti tecnici sia dalla consapevolezza dell'equipaggio nel riconoscere comportamenti insoliti dei sistemi.
Segnali generali di allarme (livello concettuale)
- Comportamento anomalo o rallentamento inatteso di sistemi critici senza causa apparente.
- Richieste di accesso o comunicazioni non richieste e non attese da fonti apparentemente legittime.
- Modifiche non autorizzate a configurazioni di sistema rilevate durante controlli di routine.
Come per il reporting di sicurezza visto nel corso Incident Investigation, anche in ambito cyber un equipaggio che teme di apparire eccessivamente cauto tende a non segnalare anomalie che potrebbero rivelarsi significative. Costruire un canale di segnalazione semplice e non giudicante per i dubbi di natura cyber è altrettanto importante quanto per i dubbi di sicurezza operativa tradizionale.
Un’anomalia non dimostra da sola un attacco. Confrontare lo stato con una baseline e con fonti indipendenti, registrare orari e allarmi e attivare l’escalation prevista. Per esempio, un’anomalia GNSS può dipendere da interferenza radio e richiede una valutazione nautica anche senza compromissione della rete. Conservare i log in modo protetto e usare strumenti di monitoraggio validati per i sistemi OT, senza improvvisare prove invasive.
In sintesi
- Un’anomalia è un segnale da verificare, non una prova automatica di compromissione.
- Log sincronizzati, baseline e canali di escalation riducono il tempo di diagnosi.
- La segnalazione precoce deve preservare evidenze e non indurre azioni tecniche improvvisate.
Risposta a un incidente cyber
Obiettivo del moduloCondurre una risposta cyber safety-led che coordini comando nave, supporto IT/OT, contenimento, evidenze, notifiche e ripristino.
La risposta agli incidenti OT è safety-led. Non si disconnette, spegne o riavvia automaticamente un sistema critico.
- Rilevare e registrare anomalia, ora, sistema e allarmi senza alterare inutilmente lo stato.
- Proteggere navigazione e operazione, informando il Comandante e attivando modalità manuali o ridondanti previste.
- Escalare al piano cyber e ai ruoli IT/OT, DPA e altri destinatari della matrice.
- Contenere rete, account, servizio o apparato dopo aver valutato dipendenze, autorità e conseguenze operative.
- Preservare log, configurazioni e cronologia; notificare secondo soglia e regime.
- Eradicare e recuperare da uno stato noto e verificato.
- Autorizzare il ritorno in servizio con test, monitoring e root-cause review.
In sintesi
- La sicurezza della nave governa ogni decisione di isolamento o spegnimento.
- Contenimento, preservazione delle prove e reporting possono svolgersi in parallelo.
- Il ritorno in servizio richiede uno stato noto e verificato, non la semplice riaccensione.
Backup e continuità operativa
Obiettivo del moduloProgettare e verificare una capacità di recovery che includa dati, configurazioni, dipendenze, procedure manuali e criteri di accettazione.
Il backup è una capacità di recovery, non la sola presenza di una copia. Include dati, software, configurazioni, licenze, chiavi, dipendenze, versioni, procedure manuali e contatti di supporto.
RTO, recovery point, segregazione e test devono riflettere la criticità operativa. Il restore tecnico e l’autorizzazione operativa al ritorno in servizio sono decisioni distinte, con criteri di accettazione e monitoring rafforzato.
RTO (Recovery Time Objective) è il tempo obiettivo per ripristinare il servizio; RPO (Recovery Point Objective) esprime il punto di recupero richiesto e la perdita di dati tollerabile in termini temporali. Definirli in funzione della continuità operativa. Copie offline o immutabili e credenziali di backup separate riducono il rischio che anche le copie siano compromesse: non garantiscono da sole il recupero. Provare il restore da uno stato attendibile, incluse dipendenze e configurazioni; custodire chiavi e licenze con controlli di accesso dedicati.
In sintesi
- Una copia esistente ma non testata non dimostra la capacità di recupero.
- RTO, RPO e dipendenze devono riflettere la criticità operativa.
- Restore tecnico e autorizzazione al ritorno in servizio sono decisioni distinte.
Convergenza tra sicurezza fisica e cyber security
Obiettivo del moduloIntegrare accesso fisico, porte di servizio e locali tecnici nella valutazione cyber coordinando SMS, SSA/SSP e controlli operativi.
L’accesso fisico può bypassare controlli logici, ma non rende inutili segmentazione, autenticazione, logging o least privilege. Locali tecnici, porte di servizio e removable media entrano nella valutazione cyber.
Restricted areas e misure ISPS derivano da SSA/SSP approvati: non ogni locale OT è automaticamente un’area ristretta. SMS, SSP e procedure tecniche devono produrre defence-in-depth coerente, senza imporre universalmente un flusso unidirezionale.
In sintesi
- L’accesso fisico può bypassare controlli logici, ma non rende inutili le difese di rete.
- Restricted areas e misure ISPS derivano dall’assessment e dal piano approvato.
- Controlli fisici, logici e procedurali devono formare una defence-in-depth coerente.
Formazione e cultura organizzativa
Obiettivo del moduloCostruire formazione e familiarizzazione proporzionate ai ruoli, includendo esercitazioni, verifica delle conoscenze e reporting non punitivo.
La Rev.4, §3.5.3.6, raccomanda formazione cyber di base annuale per tutti i dipendenti, formazione specifica per gli utenti OT e familiarizzazione di tutti i marittimi all’imbarco. Comprende igiene informatica, rilevamento, risposta e recupero; conoscenze e capacità vanno verificate anche tramite esercitazioni.
Adattare contenuti e verifiche a equipaggio, personale di terra, direzione e fornitori secondo il ruolo. Le esercitazioni devono verificare contatti, escalation, continuità operativa e criteri di ripristino senza mettere a rischio i sistemi reali.
Una just culture favorisce la segnalazione tempestiva degli errori in buona fede: chiarire canali, trattamento equo e limiti di riservatezza e responsabilità secondo legge e policy. Non è una promessa di immunità per condotte intenzionali o gravemente negligenti. In caso di errore, segnalare e preservare le evidenze senza tentare cancellazioni o rimedi improvvisati.
In sintesi
- La Rev.4 indica formazione cyber di base annuale, formazione OT specifica e familiarizzazione all’imbarco.
- Awareness generale e competenza specialistica hanno destinatari e risultati attesi diversi.
- Una just culture sostiene il reporting, ma non elimina accountability per condotte intenzionali o gravemente negligenti.
DPA, responsabile cyber e governo delle interfacce
Obiettivo del moduloDistinguere le funzioni ISM del DPA dall’accountability cyber designata e costruire una matrice di interfaccia ed escalation.
La Rev.4 raccomanda di designare una persona o entità accountable per pianificazione, risorse ed esecuzione cyber, con autorità, supporto e competenza. Non prescrive che sia il DPA.
Il DPA conserva le funzioni ISM: collegamento nave–vertice, monitoraggio safety/pollution e disponibilità di risorse e supporto. Per rischi cyber safety-relevant verifica che l’SMS governi il rischio e che l’escalation raggiunga chi ha competenza e autorità.
La matrice distingue senior accountability, cyber risk owner, autorità del Comandante, IT/OT, DPA, CSO/SSO, privacy/legal e comunicazioni.
La priorità dipende da impatto e urgenza. Il DPA necessita della competenza adeguata alle funzioni assegnate e del supporto di specialisti; un’eventuale nomina anche a responsabile cyber richiede competenze e autorità aggiuntive definite.
In sintesi
- La Rev.4 raccomanda di designare un accountable person/entity, non prescrive automaticamente il DPA.
- Il DPA verifica che i rischi safety-relevant siano governati nell’SMS e che il supporto sia disponibile.
- Autorità del Comandante, IT/OT, DPA, CSO/SSO, legal e comunicazioni devono essere definiti prima dell’incidente.
Tendenze emergenti
Obiettivo del moduloValutare gli sviluppi 2024–2026 distinguendo strumenti già correnti, guidance di settore e lavori IMO ancora non obbligatori.
- Corrente: MSC-FAL.1/Circ.3/Rev.4, 28 maggio 2026, sei elementi e controlli minimi.
- Corrente nello scope: IACS E26/E27 Rev.1 per nuove costruzioni contrattualizzate dal 1° luglio 2024.
- Guidance: Guidelines on Cyber Security Onboard Ships, versione 5 del 14 novembre 2024; il Cyber Security Workbook è una pubblicazione diversa.
- In sviluppo, non obbligatorio: Maritime Cyber Code FAL/MSC, in sviluppo come strumento non obbligatorio, non ancora adottato.
- Da monitorare: Maritime Single Window, supply chain, remote operations e connettività ship–shore.
In sintesi
- E26/E27 Rev.1 si applicano alle navi nel loro campo contrattualizzate per la costruzione dal 1° luglio 2024.
- La Rev.4 IMO del maggio 2026 porta governance e controlli minimi nel quadro corrente.
- Il Maritime Cyber Code è in sviluppo come strumento non obbligatorio: non va presentato come adottato o vincolante.
Errori ricorrenti
Dalla Mistake Library di SuperbaKnowledge, filtrata sugli argomenti trattati in questo corso. Questa vista seleziona e ordina contenuti pubblicati in SuperbaKnowledge; non li modifica né li sostituisce. La scheda collegata resta la versione di riferimento e i testi ufficiali restano autorevoli.
| Argomento | Errore | Conseguenza tipica | Scheda |
|---|---|---|---|
| Cyber Risk Management nella SMS (MSC.428(98)) | Rischio cyber gestito come argomento IT separato, non integrato nella valutazione dei rischi generale dell'SMS | Assenza di evidenza documentale integrata in caso di audit, nonostante l'esistenza di misure IT tecniche | Vedi scheda |
| Designated Person Ashore (DPA) | DPA nominato solo formalmente, senza accesso reale al top management | NC in audit di certificazione, sistema di escalation inefficace in emergenza | Vedi scheda |
| Management of Change | Cambiamenti implementati informalmente senza processo di valutazione strutturato | Rischi associati al cambiamento non identificati prima dell'implementazione | Vedi scheda |
Glossario degli acronimi
| Sigla | Definizione |
|---|---|
| DPA | Designated Person Ashore |
| ECDIS | Electronic Chart Display and Information System |
| IACS | International Association of Classification Societies |
| ISM | International Safety Management Code |
| IT | Information Technology |
| MSC-FAL.1/Circ.3 | Circolare IMO con le linee guida sulla gestione del rischio cyber marittimo; revisione corrente Rev.4, 28 maggio 2026 |
| NIST | National Institute of Standards and Technology |
| NIST CSF | NIST Cybersecurity Framework — dalla versione 2.0 (2024) sei funzioni: Govern, Identify, Protect, Detect, Respond, Recover |
| OT | Operational Technology |
| Ransomware | Software dannoso usato per estorsione, spesso mediante cifratura; l’incidente può comprendere furto di dati e minacce di pubblicazione |
| SMS | Safety Management System |
| UR | Unified Requirement — requisito unificato IACS, vincolante per le società di classificazione membri |
| CBS | Computer-Based System |
| DMZ | Demilitarized Zone |
| CSIRT | Computer Security Incident Response Team |
| MFA | Multi-Factor Authentication |
| RTO | Recovery Time Objective |
| RPO | Recovery Point Objective |
| NIS2 | Directive (EU) 2022/2555 |
Riferimenti e fonti
Fonti consultate per la revisione del 15 settembre 2026. Verificare requisiti di bandiera, recepimento nazionale e regole di classe applicabili.
| Fonte | Documento e riferimento |
|---|---|
| IMO/ISM | ISM Code — SOLAS IX; §§1.2.2.2, 4, 9, 12 |
| IMO | MSC.428(98) — 2017 |
| IMO | MSC-FAL.1/Circ.3/Rev.4 — 28 May 2026; §§2–4 |
| IACS | UR E26 Rev.1 — Cyber resilience of ships |
| IACS | UR E27 Rev.1 — Cyber resilience of onboard systems and equipment |
| UE / EU | NIS2 — Directive (EU) 2022/2555, Articles 2, 20, 21, 23; Annex I |
| IEC | IEC 62443-3-2:2020 — zones, conduits, SL-T |
| NIST | Cybersecurity Framework 2.0 — 2024 |
| Linee guida di settore | The Guidelines on Cyber Security Onboard Ships — v5, 14 November 2024 |
| IMO — sviluppi | FAL 50 — non-mandatory Maritime Cyber Code |
Questo corso è materiale didattico a scopo formativo e non costituisce certificazione professionale né titolo abilitante. Leggi le avvertenze complete.