Cosa dovrebbe succedere quando un edificio intelligente perde la connessione Internet?

Pochissimo di ciò che conta Quando la connessione esterna si interrompe, l'edificio stesso dovrebbe continuare a funzionare in sicurezza: l'impianto continua sotto il controllo locale, le porte continuano a funzionare, gli allarmi continuano a raggiungere qualcuno e i dati vengono memorizzati nel buffer, non persi. Ciò che si ferma dovrebbe essere limitato alle funzioni che hai consapevolmente accettato come dipendenti dal cloud, come dashboard remoti o analisi del portafoglio. Arrivarci dipende da due cose: decidere il comportamento previsto di ogni funzione prima che il progetto sia finito, e poi testarlo disconnettendo effettivamente l’edificio.

Una domanda che gli edifici più vecchi non hanno mai dovuto porsi

I sistemi degli edifici più vecchi funzionavano interamente in loco. I servizi più recenti spesso si basano su connessioni esterne: analisi cloud, monitoraggio remoto, credenziali mobili, controlli delle licenze, servizi firmware, app guest, sincronizzazione temporale e supporto dei fornitori. Ciascuno è utile e ciascuno crea una dipendenza che può rimanere invisibile finché la connessione non viene interrotta.

La guida del NIST alla sicurezza OT (SP 800-82) raccomanda di progettare la tecnologia operativa in modo che si degradi gradualmente, passando dall'automazione completa a modalità con un maggiore coinvolgimento dell'operatore e infine al funzionamento manuale, in modo che non ceda tutto insieme. Il NIST rileva inoltre che la perdita delle comunicazioni di rete può innescare un comportamento fail-safe e che le organizzazioni dovrebbero definire le soglie alle quali i componenti possono continuare a funzionare con capacità ridotte. La guida CI Fortify di CISA, scritta per le infrastrutture critiche, sottolinea un punto che si applica anche agli edifici commerciali: la pianificazione del ripristino dovrebbe coprire le dipendenze di comunicazione come i server di licenza e le connessioni di rete aziendali, e i produttori dovrebbero spiegare come si comportano i componenti altamente connessi quando le telecomunicazioni falliscono.

Deve continuare, può degradare, può fermarsi

Una semplice classificazione a tre vie, concordata tra l'operatore, il progettista dei controlli e ciascun fornitore, rende esplicito il comportamento previsto.

Ogni servizio dovrebbe essere collocato in una delle tre classi e i contratti e i test di accettazione dovrebbero quindi riflettere la classificazione.

Le dipendenze che nessuno ricorda finché non falliscono

Le licenze e l'autenticazione sono una sorpresa comune. Alcuni software controllano una licenza o autenticano gli utenti rispetto a un servizio online e, se tale controllo fallisce, la workstation dell'operatore locale potrebbe bloccare gli utenti. Chiedi a ciascun fornitore cosa succede dopo un'ora, un giorno e una settimana offline.

Le chiavi mobili e il controllo degli accessi gestito dal cloud possono funzionare molto bene, ma è necessario sapere cosa succede alle nuove credenziali, alle revoche e alle autorizzazioni memorizzate nella cache dei controllori della porta quando il servizio cloud non può essere raggiunto. L'instradamento degli allarmi è un altro punto debole: se gli allarmi critici raggiungono il tecnico di turno solo attraverso un servizio di notifica cloud, un'interruzione li silenzia, quindi dovrebbe esserci un percorso locale, come un pannello di allarme o una workstation in loco, o un percorso alternativo.

Il tempo viene facilmente trascurato. Pianificazioni, registri e dati di tendenza dipendono dal fatto che l’ora sia corretta, quindi qualcuno deve decidere dove i dispositivi ottengono il loro tempo quando le fonti esterne non sono disponibili. Il supporto remoto crea una dipendenza più sottile. Se tutta la diagnosi si basa sull'accesso del fornitore, un'interruzione che coincide con un guasto lascia il sito senza aiuto e gli ingegneri in loco necessitano dell'accesso e della documentazione per utilizzare e ripristinare i sistemi da soli. E laddove programmi, setpoint o sequenze vengono modificati in una piattaforma cloud e inviati al sito, l'ultima configurazione valida deve rimanere attiva localmente.

Anche i dati devono sopravvivere

Al ripristino della connessione le piattaforme dati dovrebbero ricevere quanto accaduto nel frattempo. La specifica dovrebbe indicare per quanto tempo i dispositivi locali o i gateway memorizzano i dati nel buffer, in quale ordine vengono inviati alla riconnessione, come vengono contrassegnati i gap e come vengono evitati i duplicati. Senza ciò, i rapporti energetici e le registrazioni dei guasti possono mostrare false lacune o picchi fuorvianti.

Costruire la resilienza dal brief all'operazione

Il brief è il punto in cui inizia. Dovrebbe includere un programma di comportamento in caso di guasto che elenchi ciascuna funzione, la sua classe, il comportamento previsto offline e alla riconnessione e il fornitore responsabile. Nell'approvvigionamento, ai fornitori dovrebbe essere chiesto di dichiarare quali caratteristiche del proprio prodotto dipendono da connessioni esterne e come si comporta il prodotto senza di esse. La guida CI Fortify sottolinea che le condizioni contrattuali e di licenza possono impedire agli operatori di prepararsi all’isolamento, quindi le licenze e i termini di servizio devono essere verificati esattamente per questo.

La progettazione della rete può giustificare una seconda connessione esterna per i servizi essenziali, da un fornitore diverso o su un percorso fisico diverso. Ciò riduce la probabilità di un'interruzione; non elimina la necessità di operazioni locali.

La messa in servizio è il luogo in cui le affermazioni diventano prove. I collegamenti esterni dell'edificio dovrebbero essere disconnessi in un test pianificato, ogni comportamento "deve continuare" e "può degradare" verificato e quindi verificato anche il ripristino. La dichiarazione di un fornitore non costituisce una prova; un test assistito lo è. Durante il funzionamento, il test dovrebbe essere ripetuto periodicamente, soprattutto dopo modifiche significative del software o nuove integrazioni, e i backup della configurazione attuale e i supporti di installazione dovrebbero essere conservati sul posto, in modo che il ripristino non dipenda dalla connessione interrotta.

Cinque domande al proprietario

• Abbiamo un elenco scritto di ogni funzione che dipende da una connessione esterna?
• Per ciascuno di essi abbiamo deciso se deve continuare, peggiorare o arrestarsi?
• Abbiamo testato una disconnessione completa e quando l'abbiamo ripetuta l'ultima volta?
• Il nostro team in loco può gestire e ripristinare i sistemi essenziali senza che un fornitore acceda?
• Gli allarmi critici hanno un percorso che non dipende da internet?