La engineering station è il punto da cui si progetta, si modifica e si carica il software che governa l'impianto. Su una postazione con TIA Portal passano progetti PLC, configurazioni HMI, parametri di rete, credenziali e know-how di processo. Eppure, su molti impianti, la engineering station è trattata come un qualsiasi PC aziendale: browser aperto, email configurata, utente amministratore locale, nessuna restrizione software, nessun backup strutturato.

Il risultato è una superficie di attacco ampia, con privilegi elevati e accesso diretto al processo produttivo. Qualsiasi compromissione della engineering station ha impatto potenziale sull'intero impianto: modifica del codice PLC, alterazione delle configurazioni HMI, esfiltrazione di proprietà intellettuale, propagazione laterale sulla rete OT.

L'hardening di queste postazioni non richiede prodotti particolari. Richiede disciplina, scelte coerenti e la volontà di trattare la engineering station per quello che è: un asset critico di impianto, non un PC di reparto.

A chi si rivolge questo articolo

A chi gestisce o mantiene postazioni di engineering con TIA Portal in ambienti di produzione. System integrator, responsabili automazione, tecnici di stabilimento, responsabili OT security. Le indicazioni valgono in larga parte anche per ambienti con altri tool Siemens (STEP 7, WinCC) e, con adattamenti, per postazioni di engineering di altri vendor.

Tecnico al lavoro su un quadro elettrico industriale con cablaggio strutturato
Un tecnico interviene su un quadro elettrico industriale. La engineering station ha accesso diretto a componenti critici dell'impianto. Foto: Pexels (licenza Pexels, uso gratuito).

Hardening del sistema operativo

TIA Portal gira su Windows. Questo significa che la prima linea di hardening è il sistema operativo stesso. Il punto di partenza è ridurre la superficie di attacco della macchina eliminando tutto ciò che non serve al funzionamento del tool di engineering.

Servizi e funzionalità Windows non necessari

Una engineering station non ha bisogno di Bluetooth, di Xbox Game Bar, di OneDrive, di Cortana, di Windows Media Player né della maggior parte dei servizi attivi di default su un'installazione standard di Windows 10 o 11. Disabilitare i servizi non necessari riduce i vettori di attacco e migliora la stabilità complessiva.

In pratica conviene partire dalla lista dei servizi attivi e valutare caso per caso. Alcuni servizi sono chiaramente inutili su una postazione di engineering; altri vanno verificati rispetto alle dipendenze di TIA Portal e dei driver di comunicazione. Siemens pubblica le compatibility list con le versioni di Windows supportate e i prerequisiti software: partire da quelle è il modo più sicuro per evitare problemi.

Un approccio che funziona è installare Windows da un'immagine pulita, applicare le patch cumulative, installare TIA Portal con i componenti strettamente necessari e poi procedere a disabilitare ciò che resta e non serve. Fare il contrario — partire da un PC già in uso e "ripulirlo" — è meno affidabile e lascia quasi sempre residui.

Configurazioni di sicurezza del sistema operativo

  • Windows Firewall: lasciarlo attivo e configurare regole esplicite per le porte usate da TIA Portal e dalla comunicazione PLC (tipicamente TCP 102 per la comunicazione S7, più le porte per la diagnostica e il download). Tutto il resto in ingresso va bloccato per default.
  • Remote Desktop: disabilitare RDP se non strettamente necessario. Se serve, limitarlo a utenti specifici e abilitare Network Level Authentication.
  • Autorun e autoplay: disabilitare completamente. Le chiavette USB sono uno dei vettori più comuni in ambienti industriali.
  • PowerShell: valutare la Constrained Language Mode o, dove possibile, limitare l'esecuzione di script non firmati tramite policy.
  • Registro eventi: aumentare la dimensione dei log di sicurezza e di sistema. Su molte installazioni Windows di default i log ruotano troppo velocemente per essere utili in fase di analisi post-incidente.

Se la postazione è in dominio Active Directory, molte di queste configurazioni possono essere distribuite via Group Policy. Se è standalone — come accade spesso negli impianti più piccoli o nelle postazioni mobili — vanno applicate localmente e documentate.

Gestione delle utenze

Su troppe engineering station tutti lavorano con lo stesso account, che è amministratore locale. Questo rende impossibile distinguere chi ha fatto cosa e garantisce privilegi massimi a chiunque si sieda davanti alla macchina.

Utenze nominali e privilegi minimi

Ogni persona che accede alla engineering station dovrebbe avere un account nominale. L'account di amministratore locale va protetto con una password forte, custodita e usata solo per operazioni di manutenzione del sistema operativo. Il lavoro quotidiano — apertura di TIA Portal, consultazione di progetti, diagnostica — non richiede privilegi di amministratore.

TIA Portal stesso ha un sistema di gestione degli accessi utente a livello di progetto (User Management Component, UMC) che consente di assegnare ruoli e permessi differenziati. Abilitare questa funzione permette di separare chi può solo leggere un progetto da chi può modificarlo e scaricarlo sul PLC. Non è un meccanismo perfetto e aggiunge complessità alla gestione quotidiana, ma su impianti dove lavorano più persone o dove intervengono fornitori esterni è una misura concreta per ridurre il rischio di modifiche non autorizzate.

Account di servizio e account condivisi

Se esistono account di servizio per comunicazioni automatiche (per esempio, verso un sistema di versionamento o un server OPC), questi vanno documentati, con permessi strettamente limitati e password gestite con rotazione. Gli account condivisi generici ("automazione", "engineering", "admin") vanno eliminati progressivamente. Finché esistono, ogni evento di log associato a quell'utente è inutilizzabile ai fini dell'accountability.

Protezione dei progetti TIA Portal

Un progetto TIA Portal contiene il software PLC, la configurazione HMI, la parametrizzazione hardware, le reti, la diagnostica e in molti casi il know-how di processo dell'azienda. Proteggere il progetto significa proteggere la proprietà intellettuale e la capacità di ripristino dell'impianto.

Protezione con password dei blocchi

TIA Portal consente di impostare una protezione know-how sui blocchi (OB, FB, FC, DB) per impedirne la lettura e la modifica a chi non ha la password. Questa protezione non è crittografia di livello militare — è una misura di contenimento che scoraggia l'accesso casuale e limita la visibilità del codice sorgente a chi non è autorizzato. Va usata in modo selettivo: proteggere tutto rende difficile anche la manutenzione legittima; proteggere i blocchi critici (cicli di processo, ricette, logiche safety-related) è un compromesso ragionevole.

Protezione del progetto complessivo

A livello di progetto, TIA Portal offre la possibilità di associare una password per l'apertura. Questo impedisce l'apertura del file di progetto da parte di chi non ha le credenziali. Anche qui, la password va gestita in modo controllato: se la conosce chiunque, la protezione è nulla; se la conosce una sola persona e quella persona non è reperibile, si ha un problema operativo.

La gestione delle password di progetto va documentata e condivisa in modo sicuro — un password manager dedicato o un archivio offline protetto sono preferibili alle email, ai post-it o ai file Excel sul desktop.

Application whitelisting

L'application whitelisting è una delle misure più efficaci per una engineering station, anche se tra le più impegnative da mantenere. Il principio è semplice: sulla macchina può girare solo il software esplicitamente autorizzato. Tutto il resto viene bloccato.

Windows offre strumenti nativi per questo: AppLocker nelle edizioni Enterprise e Education, e Windows Defender Application Control (WDAC) su Windows 10 e 11. AppLocker consente di definire regole basate su publisher, percorso o hash del file. WDAC offre un controllo più granulare ma è anche più complesso da configurare.

Nella pratica, implementare il whitelisting su una engineering station richiede un lavoro iniziale significativo: bisogna identificare tutti gli eseguibili legittimi (TIA Portal, runtime di comunicazione, driver, tool ausiliari Siemens, eventuali utility di terze parti) e creare regole che li autorizzino senza bloccare il funzionamento normale.

Il rischio concreto è bloccare qualcosa che serve. Per questo conviene partire in modalità audit (solo log, senza blocco), verificare per un periodo adeguato e poi passare alla modalità enforcement. Gli aggiornamenti di TIA Portal e dei pacchetti HSP/SSP richiedono una revisione delle regole, perché nuovi eseguibili e DLL vengono aggiunti o sostituiti.

Il vantaggio è reale: un ransomware, un tool di lateral movement o un eseguibile portato dentro con una chiavetta USB non autorizzata vengono bloccati prima ancora di partire. Su una macchina che non deve fare altro che far girare TIA Portal e comunicare con i PLC, il whitelisting ha pieno senso.

Gestione degli aggiornamenti

L'aggiornamento di una engineering station non è come aggiornare un laptop aziendale. Ogni patch del sistema operativo, ogni aggiornamento di TIA Portal e ogni modifica ai driver di comunicazione può avere effetti collaterali sul funzionamento del tool, sulla compatibilità con il firmware dei PLC o sulla stabilità della comunicazione online.

Aggiornamenti Windows

Siemens pubblica regolarmente informazioni sulla compatibilità delle patch Microsoft con i propri prodotti. Prima di applicare un aggiornamento cumulativo di Windows su una engineering station in produzione, è buona pratica verificare le note di compatibilità e, dove possibile, testare prima su una macchina non critica.

Lasciare Windows Update in modalità completamente automatica su una engineering station è rischioso: un riavvio non previsto durante un'attività di commissioning o un'incompatibilità con un componente TIA Portal possono creare problemi operativi seri. Meglio configurare gli aggiornamenti in modalità controllata — download automatico, installazione manuale — oppure gestirli tramite WSUS o strumenti analoghi, con approvazione esplicita.

Aggiornamenti TIA Portal

TIA Portal ha un ciclo di aggiornamento proprio: versioni principali (V17, V18, V19, V20), update e hotfix. L'aggiornamento della versione principale non va fatto alla leggera. Ogni versione di TIA Portal supporta specifiche versioni di firmware delle CPU, dei moduli e dei dispositivi HMI. Aggiornare TIA Portal senza verificare la compatibilità con l'hardware installato in campo può impedire il download o la comunicazione con i dispositivi.

Gli hotfix Siemens sono meno invasivi e in genere risolvono bug specifici o vulnerabilità. Anche questi vanno applicati con consapevolezza, ma il rischio di incompatibilità è inferiore.

Una regola pratica ragionevole: tenere aggiornati i componenti di sicurezza (antivirus, patch critiche del sistema operativo, hotfix di sicurezza TIA Portal) con cadenza ravvicinata; pianificare gli aggiornamenti di versione principale di TIA Portal in finestra di manutenzione, con backup completo e possibilità di rollback.

Protezione dell'accesso ai PLC

La engineering station è il tramite tra il progettista e il controllore. Se la postazione è compromessa, anche il PLC è a rischio. Ma la protezione non riguarda solo la engineering station: i PLC stessi offrono meccanismi di protezione che vanno configurati.

Livelli di accesso delle CPU Siemens

Le CPU S7-1200 e S7-1500 supportano livelli di protezione configurabili dall'interno di TIA Portal. I livelli limitano le operazioni possibili da remoto: lettura, scrittura, accesso HMI, download completo. Configurare un livello di accesso adeguato impedisce che chiunque possa collegarsi al PLC e modificare il programma senza autenticazione.

Le CPU S7-1500 di generazione più recente supportano anche un controllo di accesso basato su password individuali per diverse operazioni (lettura, scrittura, accesso completo). Questo consente di differenziare chi può solo monitorare da chi può scaricare modifiche.

Comunicazione sicura

Le CPU S7-1500 con firmware recente supportano la comunicazione TLS per il canale di engineering. Abilitare la comunicazione sicura protegge il traffico tra engineering station e PLC da intercettazione e manipolazione. Richiede la gestione di certificati, che aggiunge complessità operativa, ma su impianti esposti o su reti non completamente segregate è una misura rilevante.

È bene ricordare che non tutte le CPU supportano tutte le funzionalità di sicurezza allo stesso modo: dipende dalla versione hardware e dal firmware. Prima di fare affidamento su una funzione specifica, va verificata la compatibilità sulla documentazione Siemens aggiornata.

Backup della engineering station

La engineering station va inclusa nella strategia di backup dell'impianto. Non basta salvare i progetti TIA Portal: serve un backup che consenta di ricostruire la postazione operativa in tempi ragionevoli.

Cosa salvare

  • Progetti TIA Portal: esportati o archiviati (.zap), con indicazione della versione di TIA Portal utilizzata
  • Licenze: documentare quali licenze TIA Portal, STEP 7, WinCC, Safety sono installate e come sono attivate (Automation License Manager)
  • Configurazione del sistema operativo: immagine disco o almeno documentazione dettagliata della configurazione (servizi, policy, firewall, utenze, software installato)
  • Driver e pacchetti di supporto hardware (HSP/SSP): le versioni specifiche installate, perché non sempre l'ultima versione è quella corretta per l'impianto
  • Certificati e chiavi: se si usano comunicazioni TLS o VPN dalla engineering station
  • Tool ausiliari: PRONETA, Automation Tool, eventuali utility di terze parti configurate

Dove e come salvare

Il backup va conservato in un luogo separato dalla engineering station stessa. Un NAS sulla stessa rete non protetta dalla engineering station non è un backup, è una copia esposta allo stesso rischio. Meglio un supporto offline, un volume su rete segregata o un backup su infrastruttura dedicata.

La frequenza dipende dalla frequenza delle modifiche. Dopo ogni intervento significativo sul progetto o sulla configurazione della macchina, un backup aggiornato dovrebbe essere la regola. Almeno una volta va verificato che dal backup sia possibile ripristinare una postazione funzionante: installare TIA Portal, reimportare i progetti, riattivare le licenze, ristabilire la comunicazione con i PLC.

Se il ripristino non è mai stato provato, il backup è un'ipotesi, non una garanzia.

Sala server di un data center con rack e postazione di monitoraggio
Un data center con rack server e postazione di controllo. La segregazione di rete tra IT e OT è fondamentale per proteggere le engineering station. Foto: Brett Sayles / Pexels (licenza Pexels, uso gratuito).

Gestione della rete e segregazione

La engineering station ha bisogno di comunicare con i PLC, con eventuali server SCADA o historian e con i sistemi di versionamento o backup. Non ha bisogno di navigare su Internet, di accedere alla posta elettronica né di raggiungere la rete office.

In uno scenario ideale, la engineering station è collegata alla rete OT tramite un'interfaccia dedicata e non ha alcun collegamento diretto con la rete IT o con Internet. Nella pratica questo non sempre è possibile — aggiornamenti, download di pacchetti Siemens, comunicazione con il sistema di ticketing o di versionamento possono richiedere connettività. In questi casi, il compromesso è una connessione controllata, mediata da un firewall con regole restrittive e monitorata.

L'uso di doppia scheda di rete — una verso la rete OT, una verso la rete IT — senza firewall intermedio è una configurazione che si vede spesso ma che crea un ponte diretto tra i due mondi. La engineering station diventa di fatto un router non controllato. Se questa configurazione esiste, va documentata, valutata e possibilmente sostituita con un'architettura più segmentata.

Antivirus e protezione endpoint

Siemens mantiene una lista di prodotti antivirus testati e compatibili con TIA Portal e con gli altri prodotti della piattaforma. Usare un antivirus non testato può causare problemi di prestazioni, blocchi di eseguibili legittimi o interferenze con la comunicazione PLC.

Le esclusioni consigliate da Siemens per i percorsi di installazione di TIA Portal e per i file di progetto vanno configurate. Senza esclusioni, la scansione in tempo reale può rallentare sensibilmente l'apertura dei progetti e la compilazione.

L'antivirus da solo non è sufficiente: su una engineering station è un complemento al whitelisting e all'hardening del sistema operativo, non un sostituto. Su macchine air-gapped o con connettività molto limitata, l'aggiornamento delle firme va pianificato in modo specifico — tramite aggiornamenti manuali o server di distribuzione interno.

Controllo delle porte fisiche

Le porte USB sono un vettore di attacco classico in ambito industriale. Chiavette con firmware infetto, dispositivi di attacco dedicati, semplice copia non autorizzata di progetti — il rischio è concreto e documentato.

Le opzioni vanno dalla disabilitazione completa delle porte USB non necessarie (via BIOS/UEFI o via policy di sistema) all'uso di soluzioni di device control che consentono solo dispositivi autorizzati. La scelta dipende dal contesto operativo: se la engineering station è fissa in un armadio di controllo e non necessita mai di USB, la disabilitazione è la scelta più semplice. Se le chiavette servono per trasferire progetti o aggiornamenti, serve un processo controllato — per esempio, una stazione di scansione dedicata prima dell'uso.

Anche le porte di rete fisiche meritano attenzione: una engineering station portatile collegata a una rete non controllata (hotel, rete cliente, hotspot) e poi riportata sulla rete OT può trasportare minacce.

Cavi ethernet collegati a uno switch di rete industriale
Cavi ethernet Cat.6 collegati a uno switch di rete. Il controllo delle connessioni fisiche e logiche è parte integrante dell'hardening. Foto: Pexels (licenza Pexels, uso gratuito).

Logging e visibilità

Una engineering station senza logging è una scatola nera. In caso di incidente, non si riesce a ricostruire chi ha fatto cosa, quando e da dove.

Come minimo, i log del sistema operativo (Security, System, Application) devono essere attivi, con dimensione adeguata e possibilmente inoltrati a un collector centralizzato. I login, i tentativi falliti, le installazioni software, le modifiche alle policy e gli accessi da remoto sono eventi che vanno conservati.

Se l'infrastruttura lo consente, anche i log applicativi di TIA Portal (attività di download, modifiche online, accessi ai progetti) contribuiscono alla ricostruzione degli eventi. La profondità del logging dipende dalla maturità dell'organizzazione e dagli strumenti disponibili, ma partire almeno dai log di Windows è un passo accessibile a chiunque.

Errori frequenti e compromessi realistici

L'hardening perfetto su carta è inutile se non regge nella pratica quotidiana. Alcuni errori ricorrenti che vale la pena segnalare:

  • Hardening fatto una volta e mai aggiornato: ogni aggiornamento di TIA Portal, ogni cambio di configurazione o ogni nuovo pacchetto installato può invalidare le regole di whitelisting, le esclusioni antivirus o le policy di firewall. L'hardening è un processo continuo, non un'attività una tantum.
  • Regole troppo restrittive che vengono aggirate: se il whitelisting blocca un tool necessario al commissioning, il tecnico in campo troverà il modo di disabilitarlo. Meglio una configurazione sostenibile e rispettata che una configurazione ideale e sistematicamente bypassata.
  • Backup dei progetti ma non della macchina: avere il file .zap del progetto non basta se per ricostruire la engineering station servono tre giorni, licenze da riattivare e pacchetti da reinstallare. Il backup deve coprire tutto ciò che serve a tornare operativi.
  • Nessuna separazione tra ambiente di sviluppo e produzione: usare la stessa postazione per sviluppare, testare e scaricare in produzione senza alcun processo di verifica aumenta il rischio di errori e di modifiche non controllate.
  • Utente unico amministratore: se tutti usano lo stesso account con privilegi massimi, ogni misura di tracciabilità e di protezione dei progetti diventa inefficace.

La realtà degli impianti impone compromessi. Ma i compromessi vanno scelti consapevolmente, documentati e rivalutati nel tempo — non subiti per inerzia.

Una sequenza di priorità ragionevole

Non tutto si fa in un giorno. Per chi parte da una engineering station non protetta, una sequenza di intervento che bilancia impatto e sforzo può essere questa:

Priorità 1utenze nominali, eliminazione dell'account condiviso, password amministratore custodita
Priorità 2backup completo della postazione e dei progetti, con verifica di ripristino
Priorità 3firewall Windows attivo con regole esplicite, disabilitazione RDP e servizi non necessari
Priorità 4antivirus compatibile con esclusioni Siemens, aggiornamento patch OS in modalità controllata
Priorità 5protezione accessi PLC (livelli di accesso, password), protezione know-how sui blocchi critici
Priorità 6application whitelisting in modalità audit, poi enforcement
Priorità 7logging centralizzato, revisione periodica delle configurazioni, documentazione delle eccezioni

Il nostro punto di vista

La engineering station è probabilmente l'asset più sottovalutato nella sicurezza OT. Ha accesso diretto ai PLC, contiene il know-how dell'impianto, è usata da più persone (spesso con privilegi massimi) ed è il primo punto di contatto tra il lavoro di engineering e il processo produttivo. Trattarla come un PC qualsiasi è un rischio che molte organizzazioni si portano dietro senza rendersene conto.

L'hardening non richiede budget straordinari. Richiede decisioni, coerenza e manutenzione nel tempo. Le misure descritte qui sono tutte implementabili con strumenti già disponibili, a patto di investire il tempo necessario per configurarle, testarle e mantenerle.

Vuoi valutare lo stato di sicurezza delle engineering station del tuo impianto?

Contattaci per un assessment tecnico — analizziamo configurazione OS, utenze, protezione progetti, accessi PLC, backup e segregazione di rete.

Risorse ufficiali e guide utili