Il confine tra IT e OT in un'azienda di servizi pubblici non è una linea netta su un diagramma di rete. È una membrana permeabile attraverso la quale i dati fluiscono in entrambe le direzioni: programmi batch COBOL che generano file di configurazione dei setpoint utilizzati dai PLC, programmi RPG che leggono i dati storici SCADA per la fatturazione e la reportistica normativa, bridge C legacy che traducono gli output dei mainframe in formati comprensibili ai sistemi di controllo distribuiti, flussi di job JCL che pianificano e sequenziano gli scambi di dati attraverso il confine in base alle tempistiche da cui dipendono i processi operativi. Il software che gestisce questo flusso non è né puramente IT né puramente OT. È il tessuto connettivo che fa funzionare le aziende di servizi pubblici ed è la categoria di codice che i team di modernizzazione sono meno preparati ad analizzare all'inizio di un programma di trasformazione.
Il settore energetico sta attraversando una delle trasformazioni digitali più significative della sua storia. Con la modernizzazione delle infrastrutture da parte delle aziende di servizi pubblici attraverso reti intelligenti, sottostazioni connesse, sistemi di controllo industriale (ICS) e automazione avanzata, le reti OT (Operational Technology) sono diventate più interconnesse che mai. Questa interconnessione non elimina il codice legacy, ma lo rende più critico, perché ogni nuovo endpoint della rete intelligente e ogni piattaforma di analisi cloud dipendono da flussi di dati provenienti da applicazioni scritte decenni fa. Modernizzare queste applicazioni senza comprenderne il ruolo nella catena dati operativa non è una modernizzazione, bensì una vera e propria rivoluzione, le cui conseguenze si estendono dal data center all'infrastruttura fisica.
Trova ogni parametro operativo codificato
SMART TS XL Individua ogni costante UE, limite di allarme e indirizzo di protocollo incorporato nel tuo portfolio di codice legacy.
SCOPRI DI PIÙ…Cosa significa realmente "adiacente al sistema SCADA"
Il termine "SCADA-adjacent" descrive il software lato IT che si interfaccia con i sistemi di tecnologia operativa, non il software SCADA in sé, non il firmware del PLC, non il codice integrato dell'RTU, bensì il livello applicativo aziendale che immette dati in tali sistemi e li riceve. Questa categoria è ampia, poco analizzata e genuinamente diversa dal resto del portfolio di applicazioni aziendali.
In un tipico ambiente di servizi pubblici, il codice adiacente al sistema SCADA include:
Programmi per il calcolo di parametri e setpoint. Programmi COBOL e PL/I che calcolano i setpoint di carico, i target di tensione, le soglie di pressione e i limiti operativi, forniti ai sistemi SCADA come file di configurazione o tramite input di dati diretti. Questi programmi codificano i requisiti di conformità normativa, le specifiche ingegneristiche e i limiti di sicurezza fisica. Un calcolo errato non produce un numero errato in un report, bensì un setpoint operativo errato su cui agisce il sistema di controllo.
Utenti dei dati storici. Programmi RPG e COBOL che leggono i dati operativi dai database storici SCADA per la fatturazione, la reportistica normativa e l'analisi delle prestazioni. Questi programmi dipendono da formati di dati specifici, convenzioni di timestamp e definizioni di unità ingegneristiche prodotte dal sistema storico. Una modifica del formato nell'output del sistema storico o una modifica nel programma utente lato IT può compromettere silenziosamente i calcoli di fatturazione o le presentazioni normative.
Programmi di interfaccia per protocolli. Si tratta di programmi C personalizzati che traducono i formati di output dei mainframe con le interfacce basate su file o su rete utilizzate dai sistemi DCS (Distributed Control System) e SCADA. Questi programmi di interfaccia implementano protocolli specifici, come Modbus, DNP3, IEC 61850 e formati proprietari di fornitori, e presentano presupposti predefiniti sulla struttura dei messaggi, l'ordine dei byte e la temporizzazione, assenti in qualsiasi documentazione.
Percorsi dati da batch a tempo reale. Flussi di job JCL che pianificano e sequenziano gli scambi di dati attraverso il confine IT/OT in finestre temporali specifiche. L'esecuzione di un batch notturno di un'azienda di servizi pubblici può produrre dati di configurazione che devono essere disponibili al sistema SCADA prima dell'inizio delle operazioni mattutine. La dipendenza temporale è implicita nella configurazione dello scheduler e nelle aspettative operative della sala di controllo, e non è documentata in alcun punto del codice applicativo.
Programmi di elaborazione di allarmi ed eventi. Programmi che ricevono registrazioni di allarme dai sistemi SCADA, applicano la logica di classificazione e instradamento, generano ordini di lavoro e producono registrazioni di conformità normativa. La logica di classificazione degli allarmi, che stabilisce quali eventi richiedono quali report normativi, entro quali tempistiche, è spesso incorporata nel codice del programma, che ha accumulato decenni di modifiche normative.
Questo è il codice che controlla ingegneri e sviluppatori IT, i quali ne possiedono solo una parte e nessuno dei due lo comprende appieno. Quando un programma di modernizzazione chiede "cosa possiamo cambiare?", la risposta per il codice correlato al sistema SCADA è quasi sempre "meno di quanto pensiate, e solo dopo un'analisi più approfondita di quanto previsto".
Perché l'analisi standard di modernizzazione fallisce in questo caso
La maggior parte dei framework di analisi per la modernizzazione aziendale presuppone che il codice analizzato controlli solo i dati e la logica di business, e che una modifica a un programma produca un risultato diverso sui dati senza conseguenze nel mondo fisico. Il codice adiacente ai sistemi SCADA infrange questa ipotesi in quattro modi specifici.
Conseguenze fisiche degli errori nei dati
In un'applicazione di fatturazione standard, un calcolo errato produce una fattura errata. L'errore è rilevabile, reversibile e di portata limitata. Nel codice correlato ai sistemi SCADA, un calcolo errato può produrre un setpoint errato, ovvero un valore target su cui un sistema di controllo agisce regolando parametri fisici come pressione, tensione, portata e temperatura. La conseguenza non è un numero errato in un database, bensì un processo fisico che opera al di fuori dei parametri previsti, con conseguenze che vanno dall'inefficienza al danneggiamento delle apparecchiature, fino a incidenti di sicurezza.
Questa asimmetria tra errore nei dati e conseguenza fisica è la ragione fondamentale per cui il codice adiacente ai sistemi SCADA non può essere analizzato con la stessa tolleranza al rischio del codice aziendale standard. Una modifica che "funziona correttamente" dal punto di vista della produzione di output validi può comunque produrre un output operativamente errato, entro i limiti consentiti del tipo di dati, sintatticamente valido, ma fisicamente errato per il contesto operativo che rappresenta.
Dipendenze temporali che l'analisi statica non è in grado di modellare
I programmi lato IT adiacenti ai sistemi SCADA presentano spesso vincoli temporali significativi dal punto di vista operativo, ma invisibili agli strumenti di analisi statica. Un programma che genera dati di configurazione deve terminare prima che il ciclo di polling del sistema SCADA li legga. Un job batch che aggrega i dati storici deve terminare prima del timestamp di fine intervallo richiesto dalla reportistica normativa. Un programma di interfaccia che inoltra gli allarmi deve elaborare gli eventi entro il tempo di risposta specificato dalle procedure operative della sala di controllo.
Questi vincoli temporali risiedono nelle procedure operative dell'azienda, nella configurazione dello scheduler e nella comprensione implicita degli sviluppatori che hanno scritto i programmi, non nel codice sorgente. Gli strumenti di analisi statica che si concentrano sulla struttura del codice e sul flusso di dati non hanno visibilità sui requisiti temporali che esistono al di fuori del codice stesso.
L'implicazione pratica: l'analisi di modernizzazione del codice adiacente al sistema SCADA deve documentare esplicitamente il contesto temporale per ogni programma in esame. Ciò richiede conoscenze operative, interviste con gli operatori della sala di controllo, revisione dei programmi di conformità normativa, analisi delle dipendenze tra i processi dello scheduler, e non solo analisi del codice.
Identificazione della funzione di sicurezza
Le norme IEC 61511 (sicurezza funzionale per i settori dell'industria di processo) e IEC 61508 (sicurezza funzionale per sistemi elettrici/elettronici/elettronici programmabili relativi alla sicurezza) definiscono i requisiti di certificazione per il software che svolge funzioni di sicurezza. Il codice certificato secondo queste norme non è semplicemente codice legacy che può essere ristrutturato per migliorarne la manutenibilità. La certificazione si riferisce a specifici artefatti di codice, alla specifica versione del file binario valutato dall'ente di certificazione. Modificare il codice, anche per correggere un problema di qualità che sarebbe irrilevante in un'applicazione aziendale, invalida la certificazione e richiede una nuova certificazione prima che il codice modificato possa essere implementato in una funzione di sicurezza.
Molte aziende di servizi pubblici dispongono di programmi correlati al sistema SCADA che eseguono calcoli relativi alla sicurezza, al rilevamento di sovrapressione, al calcolo del setpoint di protezione dei trasformatori e alla logica di arresto di emergenza, e che potrebbero essere soggetti a requisiti di certificazione di sicurezza senza che il team di modernizzazione IT ne sia a conoscenza. La prima domanda analitica da porsi per il codice correlato al sistema SCADA è: parte di questo codice svolge una funzione di sicurezza? In caso affermativo, quali funzioni, in base a quale certificazione e cosa richiede una sua modifica?
Accoppiamento hardware e di protocollo
I programmi di interfaccia di protocollo e il codice di interfaccia incorporato dipendono direttamente dall'hardware e dalle versioni del protocollo che implementano. Un programma che implementa Modbus RTU con codici funzione, mappature dei registri e valori di timeout specifici per un determinato modello di RTU di un fornitore specifico non sta implementando Modbus in modo generico, bensì sta implementando quella specifica combinazione, con presupposti che potrebbero non essere validi per altre configurazioni.
Quando si analizza questo codice ai fini della modernizzazione, la dipendenza non riguarda solo il codice sorgente COBOL o C, ma anche il modello del dispositivo RTU, la versione del firmware, la topologia del cablaggio fisico e la configurazione di rete. Modifiche a uno qualsiasi di questi elementi possono compromettere l'interfaccia anche se il codice sorgente del programma rimane invariato. Inoltre, le modifiche al codice sorgente del programma possono compromettere interfacce apparentemente non correlate, poiché il bridge è stato scritto per compensare peculiarità di protocollo specifiche del fornitore, non documentate da alcuna fonte.
Il confine tra IT e OT: dove risiede il codice
Il modello Purdue (ISA-99 / IEC 62443) definisce l'architettura concettuale delle reti di sistemi di controllo industriale su cinque livelli, dai processi fisici al Livello 0 ai sistemi aziendali al Livello 4. Il codice legacy adiacente allo SCADA negli ambienti di servizio si trova tipicamente ai Livelli 3 e 4, le zone delle operazioni di produzione e della rete aziendale, ma i suoi flussi di dati attraversano il Livello 2 (il livello di supervisione SCADA) in entrambe le direzioni.
Il confine tra IT e OT, tra i livelli 3 e 2, è il punto in cui il rischio per la sicurezza e l'operatività è più elevato. Attori statali si posizionano all'interno delle reti OT mesi prima dell'attivazione, mentre i gruppi ransomware ora distribuiscono payload specifici per i sistemi di controllo industriale (ICS) progettati per bloccare le interfacce uomo-macchina (HMI) e arrestare la produzione. Il punto di ingresso più frequente non è il software SCADA integrato, bensì il livello di confine IT/OT, dove il codice lato IT e i sistemi lato OT si scambiano dati attraverso interfacce progettate per l'affidabilità operativa piuttosto che per la sicurezza contro gli attacchi.
Comprendere l'insieme esatto dei programmi che attraversano questo confine e cosa fanno al suo interno è il prerequisito sia per la pianificazione della modernizzazione che per il miglioramento della sicurezza. Un programma che legge i dati da un archivio SCADA e scrive i risultati in un database di fatturazione attraversa il confine in una direzione. Un programma che calcola i setpoint e li scrive in una directory di configurazione letta da un PLC lo attraversa nell'altra. Entrambi sono adiacenti al sistema SCADA. Nessuno dei due compare in una scansione di rete SCADA o in un inventario delle applicazioni IT, motivo per cui vengono sistematicamente sottovalutati nell'analisi.
Modelli di codice specifici per programmi adiacenti ai sistemi SCADA
Codice di calcolo delle unità ingegneristiche
I calcoli in unità ingegneristiche (EU) convertono i valori grezzi dei sensori, in genere conteggi interi provenienti da convertitori analogico-digitali, in misurazioni fisiche con unità, intervalli e precisione specifici. Un circuito di corrente 4-20 mA proveniente da un trasmettitore di pressione produce un conteggio grezzo; il calcolo EU lo converte in PSI o bar con la corretta calibrazione dello zero e della portata.
Questo codice di calcolo presenta caratteristiche che lo distinguono dalla logica aziendale standard:
cobolo
CALCULATE-PRESSURE-EU.
* RAW-COUNT ranges 0-4095 (12-bit ADC)
* SENSOR-ZERO-OFFSET = 819 (4mA = 20% of 4095)
* SENSOR-SPAN = 3276 (16mA span = 80% of 4095)
* RANGE-LOW-PSI = 0
* RANGE-HIGH-PSI = 500
COMPUTE EU-PRESSURE-PSI =
(RAW-COUNT - SENSOR-ZERO-OFFSET) /
SENSOR-SPAN *
(RANGE-HIGH-PSI - RANGE-LOW-PSI)
+ RANGE-LOW-PSI
IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
EU-PRESSURE-PSI > RANGE-HIGH-PSI
MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
PERFORM GENERATE-ALARM
END-IF.Le costanti in questo calcolo, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, corrispondono alle specifiche dello strumento fisico. Se sono codificate in modo rigido (come spesso accade nel codice legacy), una modifica allo strumento fisico richiede una modifica del codice. Se sono errate (a causa di ricalibrazione dello strumento, sostituzione o errata configurazione iniziale), il valore EU è sistematicamente errato per ogni record che il programma ha mai prodotto. L'analisi statica può individuare dove sono definite queste costanti; solo la validazione operativa può confermare se sono corrette per l'attuale configurazione dello strumento.
Logica di generazione e classificazione degli allarmi
Il codice per la generazione di allarmi è tra i codici SCADA più sensibili alle normative negli ambienti delle utility. Gli standard NERC CIP (Critical Infrastructure Protection) per le aziende elettriche, i requisiti NRC per gli impianti nucleari e i requisiti di segnalazione EPA per le aziende idriche e di trattamento delle acque reflue specificano quali eventi devono generare allarmi, quali informazioni devono contenere tali allarmi ed entro quali tempi devono essere segnalati.
cobolo
CLASSIFY-ALARM.
EVALUATE TRUE
WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
MOVE 'HH' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
WHEN EU-PRESSURE-PSI > HIGH-LIMIT
MOVE 'HI' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LIMIT
MOVE 'LO' TO ALARM-PRIORITY
MOVE 'LOG' TO REPORTING-FLAG
WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
MOVE 'LL' TO ALARM-PRIORITY
MOVE 'NERC' TO REPORTING-FLAG
PERFORM GENERATE-NERC-EVENT
END-EVALUATE.I limiti di allarme in questo codice, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITI parametri operativi hanno rilevanza normativa. Le modifiche a questi limiti influiscono sia sul comportamento operativo del sistema di controllo sia sugli obblighi di rendicontazione normativa dell'azienda. Qualsiasi programma di modernizzazione che riguardi il codice di classificazione degli allarmi deve prevedere una revisione da parte degli affari regolatori nel suo processo di gestione delle modifiche, e non solo l'approvazione tecnica.
Implementazioni di Protocol Bridge
I programmi di interfaccia con protocolli legacy sono tra i codici adiacenti ai sistemi SCADA più difficili da modernizzare, poiché le loro dipendenze sono le più complesse da enumerare. Il programma implementa una versione specifica del protocollo per un dispositivo specifico, compensando nel codice comportamenti specifici del fornitore non documentati.
c
/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */
#define MODBUS_FC03_READ_HOLDING 0x03
#define MAX_REGS_PER_REQUEST 60 /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET 1 /* 984 uses 1-based addressing */
int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
/* Compensate for 984 1-based addressing */
uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
if (count > MAX_REGS_PER_REQUEST) {
/* 984 will return error if count exceeds 60 */
/* Split into multiple requests silently */
return read_registers_chunked(adjusted_start, count, buffer);
}
/* ... */
}Questo codice contiene quattro presupposti impliciti relativi a uno specifico modello di PLC che non fanno parte delle specifiche Modbus: indirizzamento dei registri a base 1, solo codice funzione 03, massimo 60 registri e comportamento di suddivisione in blocchi per richieste di grandi dimensioni. Nessuno di questi presupposti è presente nella documentazione Modbus. Si tratta di comportamenti specifici del produttore del Modicon 984, documentati in un manuale hardware del 1998 che potrebbe non essere più disponibile. Se questo bridge viene modernizzato senza comprendere questi presupposti, o se il PLC viene sostituito con un modello più recente che utilizza l'indirizzamento standard a base 0, ogni lettura di registro restituisce un valore errato di esattamente un offset di indirizzo di registro.
Analisi premoderna: cosa deve essere prodotto
Prima di modificare, rifattorizzare o sostituire qualsiasi codice correlato al sistema SCADA, l'analisi deve produrre una serie di risultati che vadano oltre quanto previsto dalle analisi standard di modernizzazione aziendale.
Inventario delle funzioni operative. Ogni programma correlato al sistema SCADA deve essere classificato in base alla sua funzione operativa: calcolo dell'unità di elaborazione (EU), erogazione del setpoint, utilizzo dei dati storici, generazione di allarmi, interfaccia di protocollo, percorso batch-to-realtime. Questa classificazione determina chi deve essere coinvolto nel processo di modifica: solo ingegneri IT o un team interfunzionale che includa ingegneri del controllo, personale operativo e addetti alla conformità normativa.
Mappa di attraversamento del confine IT/OT. Ogni flusso di dati che attraversa il confine IT/OT deve essere documentato: quale programma produce i dati, in quale formato, con quale tempistica; quale sistema OT li utilizza; e quali sono le conseguenze in caso di dati errati, ritardati o mancanti. Questa mappa rappresenta il profilo di rischio operativo per il livello adiacente al sistema SCADA.
Identificazione delle funzioni di sicurezza. Ogni programma deve essere valutato per verificare se svolge una funzione di sicurezza ai sensi delle norme IEC 61511, IEC 61508, NERC CIP o altre norme applicabili. I programmi identificati come codice con funzioni di sicurezza richiedono una gestione separata delle modifiche, una notifica alle autorità competenti e, potenzialmente, una ricertificazione; la tempistica di modernizzazione per questi programmi è sostanzialmente diversa da quella del codice operativo standard.
Registro dei parametri operativi codificati. Ogni costante codificata che rappresenta un parametro operativo, valori di calibrazione del sensore, limiti di allarme, vincoli di protocollo, soglie temporali, deve essere identificata, documentata con il suo significato operativo e convalidata rispetto alle specifiche attuali dello strumento. Questo registro diventa l'input per il processo di gestione della configurazione che sostituisce le costanti codificate con una configurazione gestita esternamente.
Documentazione delle dipendenze temporali. Il contesto temporale di ogni programma, le finestre operative entro cui deve essere completato, le dipendenze dello scheduler che impongono tali finestre e le procedure operative che dipendono dal suo completamento, devono essere documentati esplicitamente. Questa documentazione costituisce la specifica rispetto alla quale deve essere validata l'implementazione modernizzata.
Specifiche di protocollo e interfaccia. Ogni programma di interfaccia di protocollo deve essere analizzato per individuare comportamenti specifici del fornitore, presupposti relativi alla versione del protocollo e compensazioni specifiche del dispositivo. Il risultato è un documento di specifica che può essere utilizzato per convalidare un'implementazione sostitutiva, confermando che ogni comportamento compensativo sia preservato, anche quelli non presenti nella specifica originale.
Gli approcci di modernizzazione che funzionano e quelli che non funzionano
Il pattern "Fico strangolatore", applicato con attenzione. Il pattern "Fico strangolatore", che prevede la creazione di nuove funzionalità a fianco di quelle esistenti, con instradamento incrementale e dismissione graduale, è appropriato per il codice adiacente ai sistemi SCADA che esegue l'elaborazione dei dati lato IT (consumatori di dati storici, calcoli di fatturazione). Il vecchio programma continua a essere eseguito durante la transizione; la nuova implementazione produce output paralleli che vengono validati per l'equivalenza prima che il vecchio programma venga dismesso.
Il principio del "fico strangolatore" non si applica ai percorsi in tempo reale. Per i programmi che si trovano in un percorso dati in tempo reale, dove non esiste un modo sicuro per eseguire in parallelo le versioni vecchie e nuove perché produrrebbero effetti operativi contrastanti, la transizione deve essere istantanea e convalidata offline prima di qualsiasi passaggio alla produzione. L'esecuzione di un programma di calcolo del setpoint in parallelo che produce valori diversi dal programma corrente invierebbe setpoint contrastanti al sistema di controllo.
Esternalizzazione della configurazione prima delle modifiche al codice. Per i programmi con parametri operativi hardcoded, il primo passo di modernizzazione più sicuro consiste nell'esternalizzare tali parametri in un file di configurazione o in un database senza modificare la logica di calcolo. In questo modo i parametri diventano visibili, gestibili e verificabili senza dover intervenire sul codice di calcolo che ha rilevanza operativa. Il rischio di esternalizzare i parametri è sostanzialmente inferiore rispetto al refactoring della logica di calcolo.
Codice di sicurezza: analisi e documentazione, non refactoring. Il codice certificato per la sicurezza deve essere analizzato e documentato durante la fase di pianificazione della modernizzazione, ma le modifiche devono essere rimandate a un programma di ricertificazione specifico, coordinato con gli enti regolatori, e non affrontate nell'ambito di un'iniziativa di modernizzazione generale. Il rischio di invalidare una certificazione di sicurezza durante un'ampia modernizzazione non è giustificato da alcun beneficio tipico della modernizzazione stessa.
Come SMART TS XL Supporta l'analisi del codice legacy adiacente ai sistemi SCADA.
SMART TS XL'S analisi statica del codice Si applica al lato IT del confine adiacente al SCADA, ovvero ai programmi COBOL, JCL, RPG, PL/I e C che vengono eseguiti su mainframe e sistemi di fascia media e che generano, trasformano o utilizzano dati che transitano negli ambienti OT. Per questo codice, l'analisi strutturale produce l'inventario delle funzioni operative e il registro dei parametri hardcoded richiesti dall'analisi pre-modernizzazione.
La mappatura delle dipendenze delle applicazioni crea la mappa di attraversamento del confine IT/OT: ogni programma che scrive su un'interfaccia file utilizzata da un sistema SCADA, ogni passaggio di un job JCL che produce dati con rilevanza temporale operativa, ogni programma nel percorso dei dati storici dalla sorgente OT al consumatore IT. Quando un programma COBOL di fatturazione di un'azienda di servizi pubblici legge i dati storici attraverso un bridge C intermedio, la mappa delle dipendenze rappresenta sia la dipendenza da COBOL a C sia la dipendenza da C a storico come una catena connessa, rendendo visibile l'intero attraversamento IT/OT anziché rilevabile solo tramite un incidente operativo.
La capacità di analisi dell'impatto è particolarmente critica per il codice adiacente ai sistemi SCADA, poiché quantifica il raggio d'azione di qualsiasi modifica proposta prima che questa venga implementata. Una modifica a un programma di calcolo dell'unità di elaborazione dati (EU) condiviso (tramite copybook) con il codice di generazione degli allarmi, il codice di erogazione dei setpoint e il codice di scrittura dello storico dei dati richiede la comprensione di tutti e tre gli impatti secondari prima di intervenire sul calcolo. Nel codice aziendale standard, una modifica errata produce dati errati. Nel codice adiacente ai sistemi SCADA, produce parametri operativi errati.
La capacità di espansione JCL rivela la struttura temporale e di sequenziamento del livello batch: quali job vengono eseguiti in quale ordine, quali output dei dataset alimentano quali fasi successive e quali flussi di job sono vincolati temporalmente da requisiti operativi. Questa è la base di prova strutturale per la documentazione delle dipendenze temporali richiesta dalla modernizzazione dei sistemi SCADA.
La funzionalità di ricerca aziendale rende possibile la creazione di un registro di parametri hardcoded su larga scala: è possibile trovare ogni occorrenza di una specifica costante di unità ingegneristica, ogni valore limite di allarme, ogni indirizzo di protocollo hardcoded in ogni artefatto COBOL, C, RPG e JCL presente nell'ambiente, in pochi secondi e su milioni di righe di codice. Per le aziende di servizi che gestiscono centinaia di migliaia di righe di codice legacy correlato ai sistemi SCADA, questa funzionalità di ricerca fa la differenza tra un audit manuale che richiede mesi e un inventario automatizzato che richiede ore.
Per i team di pianificazione modernizzazione dell'eredità dei sistemi di utilità, SMART TS XL Fornisce l'analisi strutturale lato IT che consente al team di modernizzazione di lavorare efficacemente a fianco degli ingegneri di controllo lato OT che comprendono il contesto operativo. Il confine IT/OT non viene attraversato in sicurezza dai soli team IT o dai soli team OT, ma solo quando entrambe le parti possiedono una conoscenza strutturale accurata di ciò che i rispettivi sistemi contengono.
Perché questo codice richiede un'attenzione diversa
Le aziende di servizi pubblici che modernizzano il codice legacy adiacente ai sistemi SCADA non si limitano ad aggiornare il vecchio software. Stanno modificando lo strato software che funge da intermediario tra i sistemi aziendali e l'infrastruttura fisica. Le conseguenze di un errore in questo senso non si limitano a errori di dati, interruzioni del servizio o perdite finanziarie, ma si estendono ai sistemi fisici che servono le persone che dipendono dai servizi pubblici per vivere.
Le caratteristiche che rendono speciale questo codice, le conseguenze fisiche degli errori di dati, le dipendenze temporali invisibili all'analisi statica, i vincoli di certificazione di sicurezza, l'accoppiamento hardware e di protocollo, non sono argomenti contro la sua modernizzazione. Sono invece argomenti a favore di una comprensione completa prima di apportare qualsiasi modifica. Il quadro di analisi presentato in questa guida permette di raggiungere tale comprensione. Il programma di modernizzazione che ne consegue è più sicuro perché l'ambito delle modifiche è definito da dati concreti anziché da ipotesi, le dipendenze temporali sono documentate anziché implicite, il codice relativo alle funzioni di sicurezza è identificato anziché modificato accidentalmente e i punti di intersezione tra IT e OT sono mappati anziché scoperti tramite incidenti operativi dopo l'implementazione.
