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 (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 moduloRiconoscere perché la MSC.428(98) tratta il rischio cyber come parte della gestione della sicurezza e non come materia a sé stante.
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, la base vincolante resta l’SMS attuato secondo bandiera, classe e diritto applicabile. La MSC.428(98) si rivolge alle Amministrazioni e ha portato il rischio cyber nella verifica dell’SMS; la Rev.4 spiega come strutturarlo.
In sintesi
- I rischi cyber vanno affrontati nell'SMS entro la prima verifica annuale del Document of Compliance dopo il 1° gennaio 2021.
- La risoluzione incoraggia le Amministrazioni: la non conformità si scrive citando l'ISM Code, non la risoluzione.
- Le Guidelines MSC-FAL.1/Circ.3 sono raccomandazioni di alto livello, ma sono il riferimento con cui l'auditor legge il piano.
Gli strati regolatori: chi obbliga a cosa, e da quando
Obiettivo del moduloDistinguere gli strumenti che compongono il quadro cyber marittimo, a chi si rivolgono e da quando, e a chi si segnala un incidente.
Gli strati hanno destinatari e natura diversi: ISM/SMS, guidance IMO Rev.4, regole di classe E26/E27 e diritto nazionale o UE non sono intercambiabili.
NIS2: verificare prima il perimetro
L’Allegato I include compagnie di trasporto passeggeri e merci per vie d’acqua, managing bodies di porti e port facilities e operatori VTS; le singole navi non sono le entità destinatarie. In generale rilevano almeno la soglia media, le eccezioni dell’articolo 2, stabilimento, identificazione e legge nazionale. Una ship manager non rientra automaticamente solo perché gestisce una nave.
Incidente significativo e reporting
- 24 ore: early warning senza ingiustificato ritardo.
- 72 ore: notifica con valutazione iniziale e indicatori disponibili.
- Su richiesta: rapporto intermedio.
- Entro un mese: rapporto finale; se l’incidente continua, progress report e finale entro un mese dalla gestione.
La significatività dipende da grave perturbazione operativa, perdita finanziaria o danni considerevoli. La matrice combina bandiera, SMS, classe, NIS2/norme nazionali, assicuratori, contratti, privacy e law enforcement.
In sintesi
- Gli strumenti si rivolgono a destinatari diversi: un piano cyber costruito per l’SMS non soddisfa automaticamente gli altri due.
- La NIS2 chiede un’allerta precoce entro 24 ore dalla conoscenza dell’incidente significativo e la notifica entro 72 ore.
- In ambito IMO non esiste un obbligo di notifica dell’incidente cyber: l’unico canale imposto è il §9.1 dell’ISM Code.
Sistemi IT e OT: una distinzione essenziale
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 |
Tabella 3.1 — Sistemi IT e OT a bordo.
Un principio fondamentale della cyber security a bordo è che i sistemi OT critici per la navigazione e la sicurezza operativa non dovrebbero essere raggiungibili da un attacco che origina in un sistema IT meno protetto (per esempio tramite un'email di phishing). Verificare che questa segregazione sia effettivamente in vigore, e non solo dichiarata, è un compito di supervisione del DPA e dell'HSEQ manager.
Dalla segregazione al progetto: IEC 62443 e le regole di classe
Obiettivo del moduloRiconoscere il vocabolario con cui la segregazione è scritta nelle specifiche di cantiere e nei rapporti di classe.
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.
In sintesi
- Il conduit non è un cavo ma la connessione logica fra due zone; il security level si assegna alla zona, non al singolo apparato.
- La E26 si rivolge al cantiere con 17 requisiti sulla nave integrata; la E27 al fornitore con 30 capacità minime.
- La E27 impone al fornitore un inventario degli asset e diagrammi di topologia, che mostrano zone e conduit reali.
Vettori di attacco più comuni
A livello concettuale, è utile per il personale non specialistico conoscere le categorie generali di vettori di attacco più comuni, 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 |
Tabella 5.1 — Categorie generali di vettori di attacco (panoramica non tecnica).
La maggior parte degli attacchi cyber a bordo sfrutta comportamenti umani (aprire un allegato sospetto, collegare un dispositivo non verificato) più che vulnerabilità tecniche sofisticate. Una formazione di base che aumenti la prudenza dell'equipaggio ha un impatto protettivo spesso superiore a molte misure tecniche.
Il ciclo di gestione del rischio cyber
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.
Gestione degli accessi e aggiornamenti
Due delle misure preventive più efficaci, e spesso le più trascurate nella pratica quotidiana, sono la gestione rigorosa degli accessi ai sistemi critici e il mantenimento aggiornato del software installato.
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.
Rilevamento di anomalie
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.
Risposta a un incidente cyber
Obiettivo del moduloRiconoscere le fasi della risposta a un incidente cyber, dall'isolamento del sistema sospetto al ripristino da backup verificati e all'analisi post-incidente.
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
- Un percorso di risposta chiaro e addestrato riduce il tempo fra rilevamento e contenimento dell'incidente.
- La notifica al DPA o al responsabile IT/OT di compagnia segue un canale di escalation predefinito.
- Riattivare un sistema colpito senza verificarne l'integrità rischia di reintrodurre la vulnerabilità che ha causato l'incidente.
Backup e continuità operativa
Obiettivo del moduloRiconoscere i principi di una politica di backup efficace e distinguere l'esistenza di una copia dalla sua effettiva ripristinabilità.
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.
In sintesi
- Backup verificati e regolarmente testati sono fra le misure di resilienza più importanti contro attacchi come il ransomware.
- Conservare i backup su supporti separati dalla rete principale serve a evitare che l'attacco raggiunga anche le copie.
- La frequenza dei backup dei sistemi critici va commisurata alla criticità del sistema stesso.
Convergenza tra sicurezza fisica e cyber security
Obiettivo del moduloRiconoscere perché l’accesso fisico batte quasi tutte le protezioni di rete e trattare i locali con sistemi OT critici come aree ad accesso ristretto.
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
- La convergenza si guarda dal lato di chi progetta la protezione digitale: che cosa significa che una porta possa restare aperta.
- Chi raggiunge fisicamente un armadio di automazione o una porta di servizio è già dentro la zona, senza attraversare un conduit.
- Un locale con apparati OT critici liberamente accessibile può permettere di collegare un dispositivo dannoso ai sistemi critici.
Formazione e cultura organizzativa
Obiettivo del moduloRiconoscere gli elementi di una buona formazione di cyber security awareness e il ruolo della cultura organizzativa nella segnalazione degli errori.
Come per la safety e la security fisica viste nei corsi precedenti, anche la cyber security dipende in larga misura dalla cultura organizzativa e dalla formazione diffusa, non solo dagli strumenti tecnici.
Elementi di una buona formazione di cyber security awareness
- Formazione periodica per tutto l'equipaggio, non solo per il personale tecnico specializzato.
- Esempi pratici e concreti di comportamenti prudenti (verifica dei mittenti, cautela con dispositivi esterni), senza necessità di competenze tecniche specialistiche.
- Cultura di segnalazione non punitiva per chi commette un errore in buona fede (per esempio cliccando inavvertitamente su un link sospetto), analoga alla just culture vista nel corso di Incident Investigation.
Un membro dell'equipaggio che teme punizioni per aver cliccato inavvertitamente su un link sospetto tenderà a non segnalarlo, perdendo la finestra temporale critica per contenere l'incidente. La cultura di non punizione per errori in buona fede, già vista per la safety, si applica identicamente alla cyber security.
In sintesi
- La cyber security dipende in larga misura dalla cultura organizzativa e dalla formazione diffusa, non solo dagli strumenti tecnici.
- La formazione periodica riguarda tutto l'equipaggio, con esempi concreti di comportamenti prudenti come verificare i mittenti.
- Punire l'errore in buona fede scoraggia la segnalazione tempestiva e fa perdere la finestra per contenere l'incidente.
DPA, responsabile cyber e governo delle interfacce
Obiettivo del moduloRiconoscere la supervisione del DPA sul rischio cyber come parte dell'SMS e il piano di gestione che deve verificare.
La Rev.4 richiede 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.
In sintesi
- Il DPA si assicura che gli incidenti cyber siano segnalati con la stessa priorità di quelli di sicurezza tradizionali.
- Il DPA monitora che la formazione di cyber security awareness raggiunga tutto l'equipaggio, non solo il personale tecnico.
- Il DPA non deve essere un esperto tecnico: il suo ruolo è garantire che il sistema di gestione esista e funzioni.
Tendenze emergenti
Obiettivo del moduloRiconoscere le principali direzioni di cambiamento della cyber security marittima, dai requisiti di progetto alla crescita della connettività a bordo.
- 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: edizione corrente delle Guidelines on Cyber Security Onboard Ships; il Cyber Security Workbook è una pubblicazione diversa.
- In sviluppo, non obbligatorio: Maritime Cyber Code FAL/MSC, non ancora adottato come codice vincolante.
- Da monitorare: Maritime Single Window, supply chain, remote operations e connettività ship–shore.
In sintesi
- Per le navi contrattualizzate dal 1° luglio 2024 la cyber security è un requisito di progetto che la classe verifica.
- Il NIST CSF 2.0 aggiunge la funzione «Govern» e sposta il baricentro dalla misura tecnica alla responsabilità del vertice.
- Le compagnie più preparate valutano il rischio cyber già quando scelgono e installano un nuovo sistema, non solo dopo come rimedio.
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 |
| Gestione Traffico VTS | Percezione delle indicazioni VTS come ordini vincolanti anziché come informazione/assistenza | Decisioni nautiche subottimali senza piena valutazione critica del Comandante | 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 | Codice dannoso che cifra dati e sistemi e chiede un riscatto per il ripristino |
| SMS | Safety Management System |
| UR | Unified Requirement — requisito unificato IACS, vincolante per le società di classificazione membri |
Riferimenti e fonti
Elenco consolidato delle fonti citate. Aggiornato ad agosto 2026.
| Category | Instrument and status |
|---|---|
| IMO/ISM | MSC.428(98); ISM Code; MSC-FAL.1/Circ.3/Rev.4, 28 May 2026 — current high-level guidance. |
| Class | IACS UR E26 Rev.1 and E27 Rev.1 — scope, contract date and class rules apply. |
| EU | Directive (EU) 2022/2555: Articles 2, 20, 21, 23 and Annex I; check national transposition. |
| Frameworks | NIST CSF 2.0; ISO/IEC 27001; IEC 62443 — distinct purpose and scope. |
| Status | Current industry guidance verified at build date; Maritime Cyber Code under development and non-mandatory. |
.
Questo corso è materiale didattico a scopo formativo e non costituisce certificazione professionale né titolo abilitante. Leggi le avvertenze complete.