MISURE DI SICUREZZA

La sicurezza informatica è una pietra miliare molto importante che spesso viene trascurata e può avere conseguenze catastrofiche. Ritter Technologie GmbH attribuisce grande importanza a un concetto di sicurezza continuo che cresce con le sue esigenze. Aderiamo alle raccomandazioni MITRE / LIST e le nostre misure di sicurezza vengono regolarmente controllate da specialisti esterni per individuare eventuali lacune. I test automatici non forniscono solo una base importante a livello di software, ma se possibile anche l'hardware viene controllato automaticamente per individuare eventuali irregolarità.

L'ente di certificazione TÜV SÜD Management Service GmbH certifica che l'azienda Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Germania) ha implementato e applica un sistema di gestione della sicurezza delle informazioni in conformità alla "Dichiarazione di Applicabilità" per il campo di applicazione adiacente. Attraverso un audit, rapporto n. 707066405, è stata fornita la prova che i requisiti della norma ISO/IEC 27001:2017 sono soddisfatti. Questo certificato è valido dal 01.01.2023 al 31.12.2025.

Il campo di applicazione del sistema di gestione della sicurezza delle informazioni di Ritter Technologie GmbH si estende alla sede di Oberhausen, Essener Straße 2-24, applicando la norma DIN EN ISO 27001:2013, per il profilo di servizio "Soluzioni IT innovative e sicure, consulenza, infrastruttura, gestione del centro dati, software e servizi".


CICLO DI VITA DEL SOFTWARE

  • Concetti di sicurezza: ad es. CRS, OWASP contro SQLi, XSS, LFI, RFI, PHPci
  • Utilizzo degli standard BSI 2020
  • Test manuali e automatici, ad esempio Cypress / Postman
  • Centro dati certificato 27K e sviluppo hardware/software

DALLE RACCOMANDAZIONI MITRE / NIST

  • Stabilità del componente in termini di funzionalità
  • Utilizzare principalmente prodotti open source per effettuare le proprie revisioni del codice sorgente (creare un fork se necessario).
  • Utilizzare solo progetti attivi

Il rischio maggiore si presenta se i progetti open source vengono abbandonati. In questo caso, gli ulteriori sviluppi devono essere realizzati internamente o si deve passare a prodotti alternativi.

I prodotti sono inoltre testati e controllati da specialisti esterni per la sicurezza informatica.


SCANSIONI DI VULNERABILITÀ

Abbiamo già implementato un processo per controllare quotidianamente tutti i repository di codice alla ricerca di nuovi CVE. Questo processo utilizza Trivy, che pubblica automaticamente i rapporti e li crea in ticket per i reparti interessati. L'integrazione di Trivy con Buildroot avverrà tramite un parser per le statistiche PKG generate da Buildroot.


DIRITTI DI ACCESSO IEC 60870-104

Ogni processo server IEC60870-104 può connettersi solo a 1 client, esclusa la connessione passiva ridondante. Se più sistemi client, come Salvador e SCADA, desiderano connettersi alla RTU, è quindi necessario avere 2 processi server IEC6087-104 in esecuzione sulla RTU. Ciò può essere fatto tramite il file di mappatura creando 2 oggetti di configurazione. Ogni processo server IEC60870 ha il proprio spazio oggetti IOA. Se si desidera fornire oggetti di monitoraggio/controllo per entrambi i processi server 104, è necessario creare 2 oggetti nella mappatura. 1 oggetto per ogni server.

Questa procedura consente di specificare esattamente quali oggetti di monitoraggio e controllo devono essere resi disponibili per ogni processo server. A tale scopo viene fornito un filtro IP.


CONTROLLO DEGLI ACCESSI


CONTROLLO DEGLI ACCESSI (SCADA)

Accesso basato su filtro IP, protetto da Ipsec VPN


VALIDAZIONE DEI FILE DI CONFIGURAZIONE

Tutte le configurazioni sono fornite da Node-Red e vengono controllate automaticamente.


GESTIONE DI CHIAVI E CERTIFICATI

Durante la prima messa in servizio e al raggiungimento della data di scadenza, l'RTU recupera un certificato dal server PKI tramite SCEP. Questo certificato viene utilizzato per stabilire la connessione IPsec tra l'RTU e la rete del cliente. Opzionalmente, viene utilizzato anche per la comunicazione tra l'RTU e il DEMAS. Requisito: fornire una CA root adeguata per DEMAS, poiché la PKI del cliente genera i certificati.

OPZIONALE SU RICHIESTA

Sicurezza - Riservatezza e integrità della comunicazione di rete: su RTU
Se la connessione WAN è già protetta tramite VPN, disattivare facoltativamente l'ulteriore crittografia e quindi, naturalmente, i certificati per la deep packet inspection.


CONTROLLO DEGLI ACCESSI PER INGEGNERI (DEMAS)

  • La struttura della nostra protezione tecnica è generica. Tutti i fornitori di autorizzazioni possono essere collegati tramite Keycloak e NGINX.
  • Abbiamo scelto mTLS (certificato client TLS rilasciato tramite PKI locale (SCEP)).
  • Oltre a DEMAS, qualsiasi altro sistema può essere opzionalmente protetto con questo concetto generico.

CONTROLLO DEGLI ACCESSI PER GLI INGEGNERI (RTU)

L'RTU è gestita centralmente da DEMAS. L'accesso diretto all'RTU tramite SSH è quindi possibile, ma non necessario. Con l'RTU è possibile definire qualsiasi utente, password e assegnazione di gruppi nella configurazione del sistema.

Un servizio di login centrale gestisce i login per i moduli DEMAS e Node Red. Questa configurazione è normalmente fornita da DEMAS, ma può essere modificata localmente. In questo caso, la modifica viene riconosciuta e l'UUID 0 viene riportato a DEMAS. Ciò consente a DEMAS di reagire alla modifica.

I file e gli script di ripristino fatali possono essere modificati o eseguiti solo da utenti con diritti di root.

L'utente deve quindi far parte del gruppo root o del gruppo sudo. Nel secondo caso, l'utente deve avviare tutte le azioni con sudo.

  • Utilizziamo Strongswan IPsec per proteggere il percorso di comunicazione WAN dalla RTU alla rete del cliente. La configurazione dei parametri IPsec può essere definita nella configurazione del sistema.
  • Il certificato utilizzato viene recuperato dal server PKI durante il primo accesso e il processo tramite SCEP.
  • L'autenticazione tra 104 server e client non è ancora stata implementata perché non fa parte delle specifiche del protocollo.
  • Per proteggere la comunicazione, utilizziamo IPsec per la riservatezza e l'integrità.

CARATTERISTICHE DI SICUREZZA DELLA RTU

  • FIT (Albero di immagini appiattite)
    • Analizzato: SHA-256
    • Crittografato: AES-256-CBC
    • Certificato X.509 firmato (chiave RSA a 4096 bit)
  • Verifica della certificazione e decodifica dell'immagine all'avvio
  • Il bootloader è protetto tramite firma HABv4 (closed source di NXP)
  • La CPU offre una funzione di avvio sicuro HABv4
  • La CPU carica solo il bootloader con la firma HABv4 corretta
    • Doppio avvio per il fall back del firmware
    • Cert programmato in fusibili OTP (One Time Programmable)

SICUREZZA DEL FIRMWARE

Il firmware RTU utilizza il formato FIT. Questo file contiene il kernel, l'albero dei dispositivi e il file system principale. L'RTU utilizza un file system RAM per evitare di danneggiare il root FS. Il boot loader U-Boot controlla la validità dell'immagine del firmware FIT a ogni avvio, scompone i dati nella RAM ed esegue il kernel Linux. Tutte le modifiche apportate al root FS vengono perse dopo un riavvio.
Il processo rtu-mgr imposta le impostazioni di tutti i servizi in base alla configurazione del sistema fornita da DEMAS.

L'immagine FIT viene firmata di conseguenza. La chiave pubblica si trova nel bootloader perché deve verificare l'immagine. La chiave privata si trova solo sul server di creazione del firmware RITTEC e non lo lascia. Utilizziamo il formato massimo di chiave supportato da U-Boot, RSA 4096 bit con SHA256.

I dati dell'immagine FIT sono criptati e la chiave corrispondente è nascosta solo in U-Boot. Questo non è rilevante per la sicurezza, ma solo una misura contro il reverse engineering.

Inoltre, ogni immagine FIT è dotata di una firma HABv4. Si tratta di una procedura proprietaria di
proprietaria di NXP, implementata nella CPU. A tale scopo, viene generata una chiave pubblica e privata con uno strumento NXP. La chiave privata non lascia mai il server di compilazione.
La chiave pubblica viene masterizzata nella CPU tramite i fusibili programmabili OneTime.

Una volta che la CPU è bloccata in modo permanente tramite un altro fusibile OTP, può eseguire solo bootloader con firma HABv4. Il bootloader U-Boot che utilizziamo ha quindi la firma HABv4, proprio come l'immagine FIT del firmware. Dopo aver caricato l'immagine FIT, il bootloader controlla prima la firma HABv4 con l'aiuto della CPU, poi la firma FIT, decifra i dati nella RAM e avvia il kernel.

L'aggiornamento del firmware avviene sovrascrivendo l'intera immagine FIT inattiva. L'immagine precedentemente inattiva viene attivata e riavviata. A questo punto seguono tutti i processi descritti in precedenza. Se l'immagine non si avvia, il watchdog torna alla vecchia immagine.