Cybersicurezza delle infrastrutture critiche per difesa connessa e controllo operativo

La cybersicurezza delle infrastrutture critiche protegge i sistemi che sostengono i servizi essenziali. Cypher Sentinel aggiunge un livello sovrano di convergenza all’ambiente di sicurezza esistente, collegando il contesto di sicurezza IT e OT approvato a funzionalità native e coordinamento assistito dall’IA. Gli operatori definiscono il confine del deployment e l’autorità per le azioni che incidono sui loro sistemi.

Proteggete il servizio, il processo e i dati

La tecnologia operativa comprende sistemi di controllo industriale (ICS) e sistemi di supervisione e acquisizione dati (SCADA) utilizzati per monitorare e controllare processi fisici.

Una decisione di cybersicurezza in un ambiente operativo può influire su un processo fisico. La protezione delle infrastrutture critiche deve quindi considerare continuità del servizio, vincoli ingegneristici e persone responsabili del funzionamento sicuro.

Il NIST SP 800-82 Rev. 3 affronta i requisiti distinti di prestazioni, affidabilità e sicurezza fisica della tecnologia operativa. Questi requisiti devono entrare nel flusso di sicurezza fin dall’inizio: come vengono raccolti i dati, come viene valutato un avviso e chi può autorizzare una modifica a un sistema operativo.

Collegate il contesto di sicurezza IT e OT

L’approccio di Cypher Sentinel che privilegia l’integrazione parte dai sistemi SIEM, endpoint, identità, rete e monitoraggio OT già presenti. Ponti di integrazione e API collegano fonti e flussi selezionati alla piattaforma di convergenza. Il pilota verifica interfacce, direzione dei dati, autorizzazioni e versioni dei prodotti necessarie per il caso d’uso scelto.

• Contesto di identità e accesso: comprendete account, percorso di accesso remoto e ruolo consentito coinvolti nell’indagine.
• Contesto di asset e servizi: collegate l’attività osservata ai sistemi interessati, alla zona operativa e alle dipendenze dei servizi.
• Contesto di sicurezza: collegate avvisi, eventi e intelligence selezionati necessari per indagare lo scenario.
• Autorità operativa: identificate il team che può approvare la risposta, l’ambito consentito e il percorso di ripristino.

L’architettura della piattaforma spiega come si collegano input, contesto condiviso, coordinamento delle funzionalità e confini delle azioni.

Un flusso da valutare: accesso remoto di ingegneria

Consideriamo uno scenario pilota illustrativo che coinvolge l’uso sospetto di un account remoto di ingegneria. Portate nell’indagine i segnali approvati di identità, endpoint e monitoraggio. Esaminate la criticità dell’asset, il lavoro svolto e la finestra di manutenzione. L’operatore responsabile sceglie quindi l’azione consentita e registra la decisione. Questo flusso va validato rispetto ai vostri sistemi e procedure durante il pilota.

Definite l’ambito intorno al servizio essenziale

La stessa architettura di convergenza può essere valutata rispetto a requisiti operativi diversi. Definite gli asset importanti e le dipendenze dei servizi prima di scegliere un ambito tecnologico.

• Energia e servizi pubblici: date priorità a continuità, accesso di ingegneria e confine tra sistemi aziendali e ambienti di controllo.
• Acqua e attività industriali: identificate processi, vincoli delle apparecchiature e attività di manutenzione autorizzate che danno significato operativo a un avviso.
• Comunicazioni e trasporti: mappate dipendenze dei servizi, amministrazione distribuita ed effetto di una risposta sulle operazioni collegate.
• Infrastruttura finanziaria: stabilite i requisiti di identità, servizi transazionali ed evidenze per i sistemi inclusi nel pilota.

Ogni pilota dovrebbe documentare dispositivi, protocolli, versioni e strumenti di monitoraggio esistenti da cui dipende. Confermate la copertura e il metodo di raccolta necessari per quell’ambiente prima di ampliare l’ambito.

Mantenete deployment e risposta sotto il vostro controllo

L’operatore definisce dove opera la piattaforma, dove risiedono dati e chiavi, quali identità possono amministrarla e quali connessioni esterne sono consentite. Il piano di deployment copre anche hosting dei modelli, fonti di intelligence, procedure di aggiornamento e funzionalità necessarie durante una perdita di connettività. Consultate la piattaforma sovrana di cybersicurezza per le decisioni di deployment.

L’automazione deve rispettare l’autorità operativa. Distinguete osservazione e raccomandazioni dalle azioni soggette ad approvazione e dagli eventuali flussi automatizzati circoscritti. Per le azioni che potrebbero incidere sulla produzione o sulla sicurezza fisica, definite decisore responsabile, verifiche operative e procedura di ripristino prima di abilitare il flusso.

Create un pilota intorno alla sicurezza operativa

Un pilota utile è abbastanza circoscritto da poter essere valutato e abbastanza significativo da orientare la successiva decisione di deployment. Partite da un servizio o un sito e da uno scenario di minaccia che i team di sicurezza e operativi ritengono rilevante.

• Stabilire il confine: identificate asset, vincoli operativi, fonti di dati consentite e persone responsabili del pilota.
• Verificare la raccolta: concordate il metodo di raccolta, inclusa telemetria passiva o esistente dove opportuno, e valutatene l’impatto operativo.
• Esercitare il flusso: indagate lo scenario scelto con le integrazioni selezionate, le approvazioni concordate e la procedura di ripristino.
• Esaminare le evidenze: confrontate completezza dei dati, sforzo di indagine, tempo fino a una decisione approvata e impatto operativo con il riferimento documentato.

Passate dal pilota a un deployment più ampio attraverso una decisione di accettazione dei sistemi e delle funzionalità valutati. Utilizzate i risultati per affinare copertura di integrazione, responsabilità operative e caso d’uso successivo.

Integrate le evidenze di garanzia nell’architettura

Utilizzate i requisiti settoriali applicabili e gli standard operativi interni per definire controlli ed evidenze necessari. Gli obiettivi intersettoriali di prestazione della cybersicurezza della CISA offrono una base volontaria e prioritizzata di pratiche di sicurezza. Le indicazioni del NIST sulla sicurezza OT forniscono un riferimento per i vincoli dei sistemi industriali e di altri sistemi fisici.

Per ogni requisito, identificate la funzione pertinente della piattaforma o lo strumento esistente, la configurazione, il responsabile e le evidenze da esaminare. Un’implementazione e una valutazione documentate stabiliscono il quadro di garanzia per l’ambiente effettivo.

Preparate le infrastrutture di lunga durata al cambiamento crittografico

Includete la crittografia nella revisione di asset e dipendenze: dove vengono utilizzati chiavi e certificati, quali comunicazioni richiedono protezione, come vengono autenticati gli aggiornamenti software e quali apparecchiature possono essere modificate. Cypher Sentinel introduce funzionalità crittografiche avanzate nella piattaforma di sicurezza affinché le funzioni selezionate possano essere valutate insieme all’architettura operativa più ampia.

Il NIST invita le organizzazioni ad avviare la migrazione post-quantistica identificando la crittografia vulnerabile e pianificando gli aggiornamenti. ML-KEM, standardizzato in FIPS 203, riguarda l’instaurazione delle chiavi; ML-DSA e SLH-DSA, standardizzati in FIPS 204 e 205, riguardano le firme digitali. La transizione deve considerare interoperabilità dei protocolli, ciclo di vita delle chiavi, vincoli delle apparecchiature e finestre di modifica approvate. Leggi la panoramica della cybersicurezza post-quantistica.