Come proteggere la logica PLC dalle intrusioni utilizzando la norma IEC 62443 in OLLA Lab

Per proteggere la logica PLC dalle intrusioni secondo la norma IEC 62443-4-2, gli ingegneri dovrebbero implementare il controllo degli accessi a livello di componente, controlli sull'integrità della comunicazione e un comportamento deterministico in stato sicuro direttamente all'interno della logica di controllo. OLLA Lab fornisce un ambiente di simulazione delimitato per testare blocchi di accesso, rilevamento della perdita di heartbeat e validazione della risposta alle intrusioni prima che tali comportamenti vengano affidati ad apparecchiature reali.

La sicurezza perimetrale è necessaria, ma non è l'ultima linea di difesa. Se un attore malevolo raggiunge la rete di controllo, il PLC non sta più solo eseguendo la logica di processo; sta decidendo se i comandi non sicuri debbano trasformarsi in movimento fisico.

La norma IEC 62443-4-2 è rilevante in questo contesto perché sposta parte dell'onere della sicurezza sul componente stesso. Ciò include l'identificazione, la robustezza dell'autenticazione, l'integrità della comunicazione e l'accesso agli eventi rilevanti per l'audit a livello di dispositivo, non solo a livello di firewall. In pratica, ciò significa che la logica ladder dovrebbe rifiutare cambiamenti di stato impossibili o non autorizzati, rilevare la perdita di supervisione attendibile e forzare il processo in una condizione di sicurezza definita.

Metrica Ampergon Vallis: In 24 simulazioni di red-team in OLLA Lab su cambiamenti di stato forzati e non autorizzati contro un modello di permessi per pompe e valvole, 24 tentativi su 24 sono stati bloccati da un interblocco di perdita di heartbeat unito a permessi di esecuzione espliciti prima che il motore simulato entrasse in uno stato di marcia comandato [Metodologia: n=24 prove di intrusione simulate su uno scenario di addestramento con permessi di sicurezza, comparatore di base = stesso scenario senza interblocco di perdita di heartbeat e logica di blocco, osservato a marzo 2026]. Ciò supporta il valore dei controlli di fallback a livello di logica in tale scenario. Non stabilisce una riduzione generale del tasso di violazione su tutte le piattaforme PLC, architetture o impianti. Un simulatore è utile per fornire prove, non per creare miti.

La sicurezza a livello di logica è necessaria perché la norma IEC 62443 non tratta il PLC come un endpoint passivo. La IEC 62443-4-2 definisce i requisiti di sicurezza dei componenti per dispositivi embedded e host, inclusi i controlli relativi all'identificazione e all'autenticazione, all'integrità della comunicazione e al comportamento rilevante per l'audit.

Il cambiamento pratico è semplice: un PLC non deve presumere che ogni comando proveniente da un percorso di rete attendibile sia legittimo. Tale presupposto è sempre stato ottimistico. Ora è semplicemente meno difendibile.

I requisiti pertinenti comunemente citati in questo contesto includono:

- CR 1.1 — Identificazione e autenticazione dell'utente umano: il componente deve supportare l'identificazione e l'autenticazione degli utenti umani. - CR 1.7 — Robustezza dell'autenticazione basata su password: i meccanismi di password devono soddisfare le aspettative di robustezza minima. - CR 3.1 — Integrità della comunicazione: il componente deve proteggere l'integrità delle comunicazioni o rilevare guasti di integrità. - CR 6.1 — Accessibilità del log di audit: gli eventi rilevanti per la sicurezza devono essere disponibili per la revisione e l'indagine.

Questi requisiti non significano che ogni funzione di sicurezza sia implementata direttamente nella logica ladder. Alcune appartengono al firmware, alla configurazione del controller, alla progettazione HMI o all'architettura circostante. Il punto ingegneristico è più ristretto e utile: laddove la sicurezza del processo o la protezione delle apparecchiature dipendono dalla validità del comando, il programma di controllo deve imporre permessi deterministici e un comportamento in caso di stato anomalo anche dopo che la fiducia a monte è venuta meno.

Un malinteso comune è che la sicurezza informatica e la logica di controllo siano discipline separate. Non lo sono più nel momento in cui un comando errato può avviare un motore contro una valvola chiusa, annullare una sequenza o mantenere un'uscita in uno stato che il processo non dovrebbe mai tollerare. A quel punto, un problema di rete può trasformarsi rapidamente in danno meccanico.

Gli avvisi CISA sui prodotti industriali evidenziano ripetutamente debolezze come controllo degli accessi improprio (CWE-284) e trasmissione in chiaro di informazioni sensibili (CWE-319) in ambienti legacy. Tali avvisi non implicano che la sola logica ladder risolva il problema. Rafforzano però una verità più dura: se le credenziali, le sessioni o i percorsi di comando sono deboli, il programma del controller dovrebbe essere scritto per diffidare delle transizioni di stato non sicure.

La "prontezza alla simulazione" (Simulation-Ready) dovrebbe essere definita come la capacità di dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento di processo realistico prima dell'implementazione in un processo reale. Non è un sinonimo di "saper scrivere sintassi ladder".

Operativamente, un ingegnere "Simulation-Ready" può:

• definire cosa è consentito fare al processo,
• codificare tali limiti come permessi, scatti (trip) e blocchi,
• iniettare condizioni anomale,
• osservare il comportamento dei tag e la risposta delle apparecchiature,
• rivedere la logica dopo un guasto,
• e documentare perché il comportamento rivisto è più corretto.

Questa distinzione è importante perché sintassi contro implementabilità è il punto in cui molti ambienti di formazione si fermano troppo presto. Un rung che compila non è ancora una strategia di controllo. Un rung che sopravvive a input errati, perdita di supervisione e stati di campo contraddittori è più vicino.

In questo articolo, OLLA Lab è posizionato all'interno di questo ruolo delimitato. È un ambiente di simulazione e logica ladder basato sul web dove gli ingegneri possono testare compiti di validazione ad alto rischio in sicurezza: monitorare I/O, forzare valori anomali, tracciare causa ed effetto, confrontare lo stato ladder con lo stato dell'apparecchiatura simulata e rivedere la logica dopo un guasto. Non è un sostituto per l'accettazione in sito, la conformità formale o la competenza dimostrata su un impianto reale.

La protezione tramite password nella logica ladder dovrebbe essere trattata come un meccanismo di controllo degli accessi delimitato, non come una piattaforma di identità completa. Il modello utile consiste nel verificare un valore inserito dall'HMI, contare i tentativi falliti e bloccare uno stato di lockout che impedisce i comandi privilegiati finché non viene soddisfatta una condizione di ripristino supervisionata.

Un'implementazione compatta può essere costruita con istruzioni standard:

• `EQU` per confrontare i valori inseriti e memorizzati
• `CTU` per contare i tentativi falliti
• bobina bloccata / bit di memoria per mantenere lo stato di lockout
• contatti di permesso per bloccare le azioni protette
• condizione di ripristino supervisionata per cancellare il lockout

Modello di logica di base

Obiettivo: Consentire un'azione amministrativa o di manutenzione solo quando il PIN inserito corrisponde al valore memorizzato e il sistema non è in lockout.

Tag suggeriti:

- `HMI_PIN_Entry` : intero inserito dall'HMI - `Stored_Admin_PIN` : costante intera o valore protetto - `PIN_Submit_Pulse` : one-shot dall'azione di invio HMI - `PIN_Match` : bit interno - `Failed_Attempt_CTU` : contatore - `System_Lockout_Alarm` : bit bloccato - `Admin_Access_Granted` : bit interno - `Lockout_Reset_Request` : comando di ripristino supervisionato

Esempio di flusso di logica ladder

Rung 1: Valutazione del PIN inviato

| PIN_Submit_Pulse |----[EQU HMI_PIN_Entry Stored_Admin_PIN]----( PIN_Match )

Rung 2: Conteggio dei tentativi falliti

| PIN_Submit_Pulse |----[/PIN_Match]----------------------------[CTU Failed_Attempt_CTU PRE 3]

Rung 3: Blocco (lockout) quando i tentativi falliti raggiungono il preset

| Failed_Attempt_CTU.ACC >= 3 |---------------------------------(L) System_Lockout_Alarm

Rung 4: Concessione dell'accesso solo se la corrispondenza è vera e non esiste lockout

| PIN_Submit_Pulse |----[PIN_Match]----[/System_Lockout_Alarm]--( Admin_Access_Granted )

Rung 5: Ripristino del lockout solo in condizioni supervisionate

| Lockout_Reset_Request |----[Supervisor_Mode]------------------(U) System_Lockout_Alarm | Lockout_Reset_Request |----[Supervisor_Mode]------------------[RES Failed_Attempt_CTU]

Lo scopo ingegneristico non è un'elegante gestione delle credenziali. È il controllo deterministico sulle azioni privilegiate. Se l'HMI è oggetto di un attacco brute-force, il PLC dovrebbe smettere di accettare tentativi dopo una soglia definita e richiedere un percorso di ripristino supervisionato esplicito.

Cosa fa bene questa logica

• blocca i tentativi ripetuti per tentativi ed errori,
• crea uno stato di lockout visibile,
• impedisce l'esecuzione di comandi protetti dopo fallimenti ripetuti,
• fornisce un evento chiaro per la revisione dell'operatore o della manutenzione.

Cosa non fa questa logica

• non sostituisce la gestione sicura degli utenti nell'HMI o nella piattaforma del controller,
• non crittografa le credenziali,
• non soddisfa da sola ogni requisito di autenticazione della norma IEC 62443,
• non dimostra che l'architettura circostante sia sicura.

Quel confine è importante. Un contatore non è un sistema di identità.

I permessi di accesso dovrebbero essere strutturati basandosi innanzitutto sulla validità del processo, e in secondo luogo sul privilegio dell'utente. Un comando utente valido dovrebbe comunque fallire se lo stato del processo rende il comando non sicuro.

Ad esempio, un comando di avvio pompa non dovrebbe eccitare l'uscita di marcia solo perché un utente HMI autenticato lo ha richiesto. Il rung dovrebbe richiedere anche:

• percorso di scarico disponibile,
• condizione di aspirazione o livello accettabile,
• nessun lockout attivo,
• nessun trip attivo,
• heartbeat integro,
• stato della modalità e della sequenza valido,
• feedback di prova coerenti con lo stato di pre-avvio previsto.

Un modello di permesso compatto appare così:

| Start_Command | |----[Admin_Access_Granted OR Operator_Run_Permitted] |----[/System_Lockout_Alarm] |----[HMI_Heartbeat_Healthy] |----[Discharge_Valve_Open_Proof] |----[/Pump_Trip_Active] |----[Auto_Sequence_Ready] |----------------------------------------------------( Pump_Run_Permissive )

Quindi il rung di uscita dovrebbe consumare `Pump_Run_Permissive`, non il comando grezzo.

Quella separazione è importante. L'intento del comando non è l'autorità del comando. Nella logica di controllo sicura, il comando chiede; il permesso decide.

Un monitor di heartbeat è un modello logico che conferma la comunicazione continua da una fonte di supervisione attendibile richiedendo una transizione di bit periodica entro una finestra temporale definita. Se il bit smette di cambiare, il PLC lo tratta come perdita di supervisione e rimuove l'autorità di marcia o porta il processo in uno stato sicuro.

Questo è un modo pratico per supportare l'intento dietro i requisiti di integrità della comunicazione. Non dimostra che il mittente sia benevolo, ma rileva una modalità di guasto comune: la sessione HMI o di supervisione prevista è scomparsa, si è bloccata o è stata sostituita.

Perché la logica di heartbeat è importante

Se un HMI legittimo dovrebbe commutare un bit ogni secondo e quel bit smette di cambiare, esistono diverse possibilità:

• l'HMI ha avuto un guasto,
• le comunicazioni sono state interrotte,
• la sessione di supervisione si è bloccata,
• un dispositivo non autorizzato ha sostituito o bypassato il percorso previsto,
• o il processo non è più sotto le ipotesi di controllo che il PLC era stato progettato per considerare attendibili.

Il controller dovrebbe reagire a tale perdita in modo deterministico. Aspettare educatamente è raramente una strategia di controllo.

Esempio di design di heartbeat utilizzando `TON`

Tag suggeriti:

- `HMI_Heartbeat_Bit` : commutato dall'HMI - `Last_Heartbeat_State` : stato precedente memorizzato - `Heartbeat_Change_Pulse` : one-shot quando lo stato cambia - `Heartbeat_Timer` : `TON` - `HMI_Heartbeat_Healthy` : bit interno - `System_Run_Permissive` : bit interno utilizzato altrove

Concetto di logica

Rung 1: Rilevamento del cambio di heartbeat

| HMI_Heartbeat_Bit XOR Last_Heartbeat_State |------------------( Heartbeat_Change_Pulse )

Rung 2: Aggiornamento dello stato memorizzato al cambio

| Heartbeat_Change_Pulse |--------------------------------------( Last_Heartbeat_State := HMI_Heartbeat_Bit )

Rung 3: Ripristino del timer al cambio di heartbeat; timeout se non si verifica alcun cambio

| /Heartbeat_Change_Pulse |-------------------------------------[TON Heartbeat_Timer PRE 2000ms]

Rung 4: Dichiarazione di heartbeat integro solo quando il timer non è terminato

| /Heartbeat_Timer.DN |-----------------------------------------( HMI_Heartbeat_Healthy )

Rung 5: Rimozione del permesso di marcia in caso di perdita di heartbeat

| Existing_Process_Permissives |----[HMI_Heartbeat_Healthy]-----( System_Run_Permissive )

L'implementazione esatta varia in base alla famiglia di PLC e al set di istruzioni. Il principio no: se la fonte di supervisione attendibile smette di comportarsi come tale, il PLC dovrebbe degradare in sicurezza.

Scelta della finestra di timeout

Il timeout dovrebbe basarsi su:

• tasso di aggiornamento HMI previsto,
• determinismo della rete,
• criticità del processo,
• tolleranza ai falsi allarmi (nuisance-trip),
• e le conseguenze dello stato sicuro di un falso positivo.

Un timeout di 500 ms può essere appropriato in alcuni contesti di supervisione veloci. Un timeout di 2000 ms può essere più stabile in altri. Il numero corretto è quello giustificato dal processo e testato sotto un comportamento di scansione e comunicazione realistico, non quello che sembra severo in un diagramma.

È possibile simulare un attacco brute-force in OLLA Lab forzando ripetutamente valori di credenziali non validi tramite il pannello delle variabili, osservando il contatore e i bit di lockout nella simulazione e confermando che il gemello digitale o l'apparecchiatura simulata rimangano in uno stato sicuro nonostante le continue richieste di marcia.

È qui che OLLA Lab diventa operativamente utile. Praticare questo su un processo reale sarebbe un pessimo modo per preservare l'uptime.

3 passaggi per testare la logica difensiva

#### 1. Iniettare dati anomali

Utilizzare il Pannello delle Variabili per manipolare:

• `HMI_PIN_Entry`
• `PIN_Submit_Pulse`
• qualsiasi bit di comando correlato come `Start_Command`

Inserire ripetutamente valori interi errati e dare l'impulso al bit di invio come se una sessione HMI fosse oggetto di un attacco brute-force.

Cosa osservare:

• se `PIN_Match` rimane falso,
• se `Failed_Attempt_CTU.ACC` si incrementa una volta per tentativo,
• se gli one-shot si comportano correttamente e non conteggiano eccessivamente a causa del comportamento di scansione.

#### 2. Verificare l'esecuzione del lockout

Continuare con invii non validi finché il contatore non raggiunge il suo preset.

Risultato atteso:

• `Failed_Attempt_CTU.ACC` raggiunge `3`,
• `System_Lockout_Alarm` si eccita e si blocca,
• `Admin_Access_Granted` rimane falso,
• i comandi protetti non creano più permessi a valle.

Questa validazione è importante perché contatori e latch sono facili da disegnare e sorprendentemente facili da gestire male. I dettagli del ciclo di scansione sono dove la fiducia viene corretta.

#### 3. Validare lo stato sicuro nella simulazione

Utilizzare l'ambiente di simulazione di OLLA Lab per confermare che lo stato dell'apparecchiatura segua la logica di lockout, non il comando ostile.

Per un esempio di pompa e valvola, verificare che:

• l'uscita del motore rimanga diseccitata,
• la valvola non transiti in una sequenza non sicura,
• `Pump_Run_Permissive` si disattivi,
• i comandi di marcia successivi rimangano bloccati fino al ripristino supervisionato.

Se è disponibile una vista 3D o un gemello digitale per lo scenario selezionato, confrontare lo stato ladder direttamente con lo stato dell'apparecchiatura simulata. Questa è l'utile definizione di validazione del gemello digitale in questo contesto: l'apparecchiatura virtuale dovrebbe obbedire visibilmente alla logica di controllo difensiva in condizioni anomale.

Si simula la perdita di heartbeat fermando o congelando gli aggiornamenti del bit di heartbeat, osservando poi se il timer scade e il processo transita nello stato sicuro previsto. Si simulano i cambiamenti di stato non autorizzati forzando i tag di comando o di stato a valori che dovrebbero essere rifiutati dal modello di permessi.

Procedura di test per la perdita di heartbeat

5. Verificare che:

• `Heartbeat_Timer.DN` diventi vero,
• `HMI_Heartbeat_Healthy` diventi falso,
• `System_Run_Permissive` si disattivi,
• l'apparecchiatura simulata transiti nello stato sicuro definito.

1. Eseguire lo scenario normalmente con un heartbeat che commuta correttamente.
2. Confermare che `HMI_Heartbeat_Healthy` sia vero e che `System_Run_Permissive` possa essere stabilito in condizioni di processo valide.
3. Congelare `HMI_Heartbeat_Bit` nel Pannello delle Variabili.
4. Osservare l'accumulatore del `TON` finché il timeout non scade.

Procedura di test per il cambiamento di stato non autorizzato

Forzare un comando che dovrebbe essere impossibile nelle attuali condizioni di processo. Ad esempio:

• comandare la marcia della pompa mentre il feedback della valvola di scarico è falso,
• comandare l'avanzamento della sequenza mentre un passaggio precedente è incompleto,
• forzare un comando di sola manutenzione mentre `System_Lockout_Alarm` è attivo.

Comportamento atteso:

• il bit di comando grezzo può cambiare,
• il permesso dovrebbe rimanere falso,
• l'uscita non dovrebbe eccitarsi,
• e qualsiasi bit di allarme o diagnostico dovrebbe indicare perché l'azione è stata rifiutata.

Vale la pena preservare questa distinzione nella documentazione: un cambiamento di stato non autorizzato non è semplicemente un valore di tag cambiato; è un valore di tag cambiato che non riesce a ottenere l'autorità di processo.

Gli ingegneri dovrebbero documentare un corpo compatto di prove ingegneristiche, non una galleria di screenshot. Il punto è mostrare il ragionamento, la disciplina di validazione e la revisione in condizioni di guasto.

Utilizzare questa struttura:

Definire l'unità di processo, l'obiettivo di controllo, le modalità operative e le azioni protette. Esempio: pompa centrifuga con feedback valvola di scarico, comando di avvio emesso dall'HMI e percorso di lockout per manutenzione.

Indicare l'esatto comportamento previsto. Esempio: la pompa può marciare solo quando il feedback della valvola è vero, nessun lockout è attivo, l'heartbeat è integro e nessun trip esiste; in caso di perdita di heartbeat, il permesso di marcia deve disattivarsi entro 2 secondi.

Registrare il test anomalo: tentativi di PIN brute-force, bit di heartbeat congelato, comando di marcia forzato contro permessi falliti, feedback contraddittorio, e così via.

Mostrare cosa è cambiato dopo il primo tentativo fallito o incompleto. Esempio: aggiunto condizionamento one-shot per evitare il conteggio eccessivo, allarme di lockout bloccato o separazione del comando grezzo dal permesso di marcia.

1. Descrizione del sistema
2. Definizione operativa di "corretto"
3. Logica ladder e stato dell'apparecchiatura simulata Includere i rung pertinenti, l'elenco dei tag e il comportamento dell'apparecchiatura corrispondente nella simulazione. Il ladder e il modello della macchina dovrebbero raccontare la stessa storia.
4. Il caso di guasto iniettato
5. La revisione effettuata
6. Lezioni apprese Indicare cosa ha rivelato il test sul comportamento di scansione, sulla progettazione dei permessi, sulla gestione dei guasti o sul ripristino dell'operatore.

Questo è il tipo di prova che dimostra un pensiero "Simulation-Ready". Mostra che l'ingegnere può passare dalla stesura della logica alla validazione e alla correzione. I revisori generalmente trovano questo più utile di una cartella piena di screenshot.

OLLA Lab supporta la prova di sicurezza informatica delimitata offrendo agli ingegneri un ambiente basato sul web per costruire logica ladder, eseguire simulazioni, ispezionare variabili e comportamento I/O e confrontare lo stato della logica con il comportamento dell'apparecchiatura simulata in condizioni anomale.

Nell'ambito di questo articolo, ciò include:

• costruire logica di lockout e permessi nell'editor ladder basato su browser,
• utilizzare la Modalità Simulazione per eseguire ed eseguire il debug del programma senza hardware fisico,
• manipolare i tag tramite il Pannello delle Variabili per emulare input ostili o non validi,
• e, dove lo scenario lo supporta, utilizzare viste 3D o gemelli digitali per confermare che il comportamento dell'apparecchiatura segua la logica difensiva.

This is a credible use case because these are exactly the tasks that are risky, inconvenient, or expensive to test on real systems. It is also where the value of training becomes concrete: not "learning cybersecurity" in the abstract, but watching the permissive fail closed when the heartbeat dies and the command still insists.

Il confine è altrettanto importante. OLLA Lab non certifica la conformità alla norma IEC 62443, non sostituisce l'hardening del fornitore né valida un'architettura di produzione da solo. È un sandbox a rischio contenuto per testare il comportamento difensivo a livello di logica prima che tale comportamento venga affidato ad apparecchiature reali.

I principali errori di progettazione sono solitamente architetturali, non sintattici. Gli ingegneri spesso aggiungono una funzione di sicurezza come un rung isolato e dimenticano di integrarla nel percorso di autorità effettivo.

Gli errori comuni includono:

Un contatore che non agisce su un permesso è puramente decorativo.

• Contare i tentativi falliti senza bloccare le azioni protette

I controlli di sicurezza devono trovarsi nella catena di autorità, non in un ramo laterale che nessuna uscita consuma effettivamente.

• Utilizzare comandi grezzi direttamente nella logica di uscita

Se la supervisione scompare e il processo continua per impostazione predefinita, la logica di heartbeat è teatro.

• Non fallire in sicurezza (fail-open) in caso di perdita di heartbeat

Il ripristino automatico o non supervisionato vanifica lo scopo del lockout.

• Ripristinare il lockout troppo facilmente

Impulsi di invio, one-shot e incrementi del contatore possono comportarsi male se il rilevamento dei fronti è approssimativo.

• Ignorare il comportamento del ciclo di scansione

Un utente valido può comunque emettere un comando non valido per lo stato attuale del processo.

• Trattare l'autenticazione HMI come una validazione di processo sufficiente

"Sicuro" dovrebbe significare qualcosa di osservabile: motore diseccitato, valvola chiusa, sequenza interrotta, allarme bloccato, riavvio bloccato fino al ripristino supervisionato.

• Non definire esplicitamente lo stato sicuro

La logica di sicurezza fallisce in modi familiari. È pur sempre logica.

Proteggere la logica PLC dalle intrusioni secondo la norma IEC 62443 significa spostare parte della difesa nel programma di controllo stesso. I comportamenti fondamentali sono semplici: autenticare dove appropriato, contare e bloccare i fallimenti ripetuti, monitorare l'integrità della supervisione, rifiutare comandi impossibili e forzare uno stato sicuro deterministico quando le condizioni di fiducia crollano.

Il valore pratico della simulazione è che consente agli ingegneri di testare tali comportamenti prima che un processo reale fornisca il feedback in un dialetto più costoso. Un flusso di lavoro "Simulation-Ready" non riguarda il disegno di un rung più pulito. Riguarda il dimostrare che il rung fa ancora la cosa corretta quando le ipotesi circostanti smettono di collaborare.

- Zero-Trust OT: Perché la fiducia implicita è ora una responsabilità in fabbrica - Il programmatore PLC che mette la sicurezza al primo posto: Implementazione IEC 62443

• Torna all'Hub di Padronanza della Logica Ladder
• Apri il preset di Sicurezza e Permessi in OLLA Lab

- Su (Hub Pilastro): Esplora la guida del pilastro - Di lato: Articolo correlato 1 - Di lato: Articolo correlato 2 - Giù (Commerciale/CTA): Costruisci il tuo prossimo progetto in OLLA Lab

- Panoramica della serie IEC 62443 - Risorse del comitato per gli standard ISA/IEC 62443 - Avvisi CISA ICS - NIST SP 800-82 Rev. 3 Guida alla sicurezza della tecnologia operativa