Detection & Reaction personalizzate.

Ispirazioni daI TCAS, sistema anticollisione degli aerei

Immagina due aerei, che volano a più di 10.000 metri di quota, nella stessa zona, perfettamente funzionanti: nulla da segnalare per i piloti, nessuna anomalia, nessuna compromissione. Si trovano esattamente dove dovrebbero essere e procedono tranquillamente sulla traiettoria a loro assegnata.

Ma insieme?

Esiste una tecnologia per rispondere a questa domanda: si chiama TCAS (Traffic Alert and Collision Avoidance System). Il TCAS è un sistema anticollisione di bordo, il suo compito è sorvegliare gli aeromobili “vicini” – che devono essere dotati di transponder – e valutare come stanno evolvendo le rispettive posizioni per individuare un possibile rischio di collisione. È stato progettato per operare come ultima rete di sicurezza, indipendentemente dai sistemi di controllo del traffico aereo a terra.

Mi spiego meglio: sapere che ci sono altri aerei intorno è utile, ma non è il dato più importante.
Quello che interessa davvero è capire se due traiettorie, normali se osservate separatamente, stanno creando una situazione pericolosa quando vengono osservate insieme.

Se questo accade, il TCAS entra in gioco e lavora per livelli: 

In primo luogo, può avvisare l’equipaggio attraverso una Traffic Advisory: segnala cioè un traffico che, per posizione ed evoluzione, richiede attenzione. In pratica mette in allerta i piloti, ma non indica ancora una manovra da eseguire.

Se il rischio aumenta, TCAS II può arrivare a una Resolution Advisory, indicando una manovra verticale o una limitazione della velocità verticale per aumentare o mantenere la separazione.

In estrema sintesi: Il TCAS prima osserva la relazione tra le traiettorie di due aerei, poi ne valuta l’evoluzione e, solo quando vengono raggiunte determinate condizioni, passa dall’avviso alla risposta.

Fin qui, parliamo di detection e reaction (passatemi la semplificazione).

E, in termini di parallelismo con la cyber security, ciò che accade si fa più interessante quando i due aerei dell’esempio hanno entrambi a bordo il TCAS – perché si “parlano” e coordinano le rispettive Resolution Advisories, adottando risoluzioni complementari “nel senso verticale”. Ovvero: se per un aeromobile viene selezionata una risposta verso l’alto, per l’altro il sistema restringe la scelta a una risposta compatibile verso il basso. Ma resta il fatto che ciascun sistema determina autonomamente l’intensità della propria Resolution Advisory in funzione della geometria del conflitto.

E sapete perché? Perché due sistemi che individuano correttamente lo stesso problema ma reagiscono indipendentemente, potrebbero prendere decisioni che, combinate, non lo risolvono. 

Non basta capire che sta accadendo qualcosa, nè basta decidere rapidamente di intervenire. 
La risposta ha reale valore soltanto se tiene conto di ciò che sta accadendo intorno e delle conseguenze che produrrà sul sistema nel suo complesso.

A questo punto il collegamento con la cybersecurity diventa meno strano di quanto sembrasse all’inizio.

Quando pensiamo alle infrastrutture IT /OT ci viene subito “semplice” cercare un’anomalia: un accesso, una connessione, un processo e qualsiasi altro elemento “anomalo”.

Ma – solo per fare un esempio – una credenziale valida che accede a una risorsa autorizzata può essere perfettamente legittima, così come può esserlo una comunicazione tra due sistemi. Poi, però, se mettiamo insieme identità, asset, origine della connessione, orario, sequenza delle operazioni e comportamento precedente e quella stessa attività, il quadro potrebbe cambiare, e così il suo significato.

Un po’ come i due aerei: presi singolarmente, nessun problema, ma la loro relazione ci potrebbe raccontare un’altra storia.

Andiamo più a fondo nel parallelismo con il TCAS.

Bloccare un processo, interrompere una comunicazione, isolare un endpoint o impedire un accesso: queste sono tutte azioni perfettamente sensate in caso di attacco.
Peccato, però, che nell’ecosistema del mondo OT, quello che succede dopo può essere importante quanto quello che stiamo cercando di fermare.

Una comunicazione può essere utilizzata per un movimento laterale e, contemporaneamente, essere necessaria a un processo operativo; un dispositivo compromesso deve essere contenuto, ma, prima di isolarlo, sarebbe utile sapere che cosa controlla e cosa accadrà al resto dell’infrastruttura se sarà impossibile da raggiungere.

Vedere e bloccare non è sempre la combo perfetta. 
Vedere e reagire con la logica dell’OT compromesso – come farebbe un tecnico specializzato che conosce quella specifica infrastruttura e quello specifico endpoint OT, si: questa è la combo perfetta. 

È una delle ragioni per cui nella piattaforma di Automated Cyber Resilience IT/OT/IoT AGGER abbiamo lavorato sulla possibilità di personalizzare detection e reaction fino al singolo endpoint: asset diversi possono avere funzioni diverse e la stessa minaccia non deve necessariamente produrre la stessa risposta ovunque.

Il TCAS, in fondo, fa qualcosa di molto intelligente: non si limita a capire che due aerei si stanno avvicinando troppo. Quando deve intervenire, evita che la soluzione dell’uno diventi il problema dell’altro.

Da una reaction automatica, soprattutto in OT, pretenderei esattamente questo.