Lo scenario attuale - Criticità
La sicurezza SDN sta compiendo attualmente i suoi primi passi e molte delle sfide mostrate sopra non sono ancora state affrontate completamente dall'industria.
Il vantaggio di Securechain rispetto ai tradizionali approcci alla sicurezza è che la sua programmabilità intrinseca può essere agnostica rispetto alla tecnologia e al fornitore e può quindi interfacciarsi con qualsiasi fornitore di SDN e con la tecnologia e le API di diversi fornitori.
Securechain è basata su blockchain, funziona ovunque e non può essere neutralizzata. Le sue regole per accettare o rifiutare elementi non possono essere alterate senza modificare la blockchain ed essendo le registrazioni salvate nella blockchain, fornisce un registro di eventi non modificabile e dimostrabile in modo scientifico.
I casi d’uso sviluppati e l'architettura della soluzione
Qui di seguito sono mostrati due casi d’uso, per aiutare a comprendere il funzionamento di Securechain.
- AGGIUNTA DI UN DISPOSITIVO ALL’SDN:
Un caso d’uso base è l’aggiunta di un dispositivo alla Software Defined Network. La prima cosa che accade è che il pannello di commando o un altro organismo di fiducia invia la richiesta alla Blockchain da un ‘portafoglio di comando’ approvato al ‘portafoglio SDN’. Questa richiesta viene poi salvata nella blockchain, che agisce come unico gateway nell’SDN. Il codice che interfaccia la blockchain con il mondo esterno richiede nuove istruzioni e dopo aver visto una richiesta valida, ne elabora il contenuto. In questo scenario la transazione/richiesta è arrivata da un portafoglio approvato, con un’istruzione valida, quindi l'istruzione può essere implementata e l'elemento di rete valido può essere aggiunto. NB – Nella pratica questo codice si troverebbe all'interno dell'Ethereum Blockchain stessa, ma qui è visualizzato esternamente per agevolare la comprensione. La rete informerà il controller SDN per consentire l'avvio del funzionamento dell'apparecchio e l'elemento sarà quindi parte dell'SDN.
- RIFIUTO DI UN ELEMENTO CORROTTO:
Il secondo caso d’uso è il rifiuto di un elemento corrotto. In questo caso un hacker con un’istruzione valida, ma con un indirizzo portafoglio non approvato e/o senza codice corretto al suo interno, sta inviando un messaggio alla Blockchain per tentare di aggiungere un dispositivo corrotto. Poiché questa istruzione è partita da un hacker, il sistema la rifiuta e il dispositivo non viene aggiunto all'SDN. Contemporaneamente viene inviato un allarme all'amministratore di rete per informarlo del tentativo di hackeraggio, fornendo dettagli chiave dell'ID del portafoglio dell'hacker e il timestamp. Inoltre la richiesta di corruzione è memorizzata in modo permanente nella blockchain e questo permette un audit di sicurezza successivo, senza possibilità di alterazione alcuna.