A cura di Lori MacVittie, Principal Technical Evangelist di F5 Networks
Da inizio anno abbiamo già assistito a 5 casi documentati di organizzazioni clienti che esponevano i propri dati privati a causa di un’errata configurazione di bucket S3 o di database cloud.
A dire la verità, dovremmo parlare di errate configurazioni intenzionali, perché per consentire a utenti non autorizzati la tipologia di accesso necessaria per visualizzare i bucket S3 o accedere ai database, qualcuno deve avere intenzionalmente rimosso o degradato le impostazioni di sicurezza di default.
Parlare di errata configurazione implica uno sbaglio, che capita a tutti ogni tanto, e che può essere perdonato. Ma, in questo caso, non abbiamo a che fare con errori; queste risorse sono state intenzionalmente aperte per consentire l’accesso a chiunque.
I ricercatori degli F5 Labs hanno analizzato i dati delle organizzazioni clienti le cui risorse cloud sono state esposte dal 2017 a oggi a causa di questa insicurezza intenzionale. Il tasso di crescita dal 2017 al 2018 è stato del 200% e nel 2019, considerando che fino ad oggi la media è di 2,5 violazioni al mese, prevediamo di assistere a oltre 30 violazioni. Tuttavia, il tasso di crescita dal 2017 al 2018 ci indica che la nostra stima per il 2019 è probabilmente molto ottimistica.
Se la crescita dovesse continuare con un tasso di incremento del 200%, entro la fine dell’anno assisteremo a 90 violazioni della sicurezza del cloud. Quel che è peggio è che le liste compilate dalle nostre organizzazioni rappresentano solamente la punta dell’iceberg!
Si tratta di una situazione che non è più tollerabile, non solo perché vengono esposti dati di privati, ma soprattutto per le ripercussioni potenziali, a volte estremamente dannose, per le persone alle quali i dati effettivamente appartengono, chiunque essi siano.
Nessun settore può dirsi al sicuro: governi, fornitori di servizi, industria, politica, finanza, intrattenimento, tutti concorrono al gran gioco di “”Chi perderà il maggior numero di dati a causa della scarsa sicurezza?”. È un concorso però che nessuno vorrebbe vincere, e al quale se possibile nessuno vorrebbe nemmeno partecipare!
I casi sono tantissimi: recentemente, un’azienda di analisi dei dati che gestisce società finanziarie ha fatto trapelare 24 milioni di record relativi ai prestiti negli Stati Uniti per colpa di un database esposto senza password.
Siamo saldamente radicati nell’era dell’economia digitale, ma i bit e i byte che la alimentano non rappresentano solo dollari, euro o yen. Rappresentano esseri umani, persone che possono essere effettivamente colpite da queste violazioni, in modi che noi non potremmo mai conoscere de tutto, perché non vengono segnalati.
Come siamo arrivati a questo punto?
Perché qualcuno dovrebbe intenzionalmente compromettere la propria sicurezza durante la configurazione dei bucket S3 o database cloud, rendendoli pubblici? In base alla mia esperienza, i colpevoli hanno raramente a che fare con le operation: gli ingegneri di rete, amministratori di database, ingegneri di sistema e ingegneri della sicurezza sanno fare di meglio.
Gli ingegneri di rete, tipicamente responsabili della gestione dell’accesso ai sistemi sulla rete e di definire quali sistemi siano rivolti al pubblico, non consentirebbero che un database divenga pubblico. Gli amministratori di database, a loro volta, come responsabili della gestione dell’accesso al database e delle autorizzazioni dell’account, non permetterebbero che un accesso ai database non richieda l’autenticazione; avrebbero adottato policy per le password aziendali con requisiti di complessità standard senza abilitare l’utilizzo di password deboli.
Infine, gli ingegneri di sistema, responsabili per definizione della gestione delle applicazioni secondo standard rigidi e predefiniti, gestirebbero un server web rispetto al database pubblico assicurandosi che sia protetto correttamente con un web application firewall.
Gli ingegneri di sicurezza, inoltre, di norma effettuano assessment indipendenti di tutti i sistemi e della rete per garantire la conformità alle policy di sicurezza.
Capita però che a livello di sviluppo del prodotto si decida di non incorporare le funzionalità di sicurezza che già esistono, in molti casi perché non si vuole che queste interferiscano con il flusso dei ricavi, ritardano magari la tempistica o introducendo potenzialmente nuovi bug.
Il passaggio al cloud consente agli sviluppatori di aggirare i ruoli tradizionali dell’IT aziendale, che sono ovviamente necessari se consideriamo il crescente numero di violazioni del cloud. Si tratta di una tempesta perfetta dal punto di vista della sicurezza, con gli sviluppatori liberi di distribuire sistemi con funzionalità di sicurezza configurate in modo non corretto, non perché vogliano deliberatamente arrecare danni, ma perché magari non comprendono pienamente le conseguenze o presumono che sia improbabile che si verifichi davvero una violazione.
Come evitare le violazioni nel cloud
Come risolvere questo problema? Di certo nessuno vuole tornare all’epoca dei lunghi ed estenuanti ritardi nell’implementazione dei sistemi, ma forse è tempo che si inizi a parlare seriamente di DevSecOps come disciplina in grado di infondere buone pratiche di sicurezza nello sviluppo.
Per riuscire a ottenere questo risultato, tutti i team devono essere inclusi nella conversazione, perché i report di sicurezza nei deployment cloud pubblici predefiniti sono spesso incompleti; nella maggior parte dei casi, le organizzazioni devono acquistare strumenti di controllo della sicurezza del cloud di terze parti per produrre i report che il team di sicurezza farebbe semplicemente ottenuto dalle controparti interne.
È vero, la sicurezza è sempre più complessa e a volte rallenta le cose. Ma ignorarla o declassarla intenzionalmente perché è più conveniente o perché così si accelera il processo è inaccettabile e anche poco etico. Le persone reali, che si affidano quotidianamente alle aziende, e che non sono solo dati digitali da maneggiare, possono subire delle ripercussioni, e non solo finanziariamente.
È quindi arrivato il momento di smettere di parlare di errate configurazioni nell’esposizione di questi dati e di iniziare a definirle per quello che sono: scelte di insicurezza intenzionali e deliberate.
I professionisti della sicurezza delle informazioni devono iniziare a combattere queste pratiche carenti in modo deciso, avendo sempre ben presente come tali comportamenti si ripercuotano sulle persone e non solo sui processi.
