Security non fa rima con compliance

Security non fa rima con compliance

Il compito di soddisfare i requisiti normativi non coincide con quello di fornire una reale sicurezza che mitighi di fatto il rischio. Consideriamo come il focalizzarsi esclusivamente sulla compliance possa compromettere la sicurezza.

La maggior parte di noi dell’IT Security sa che compliance e security non sono la stessa cosa. La compliance ha a che fare con una mentalità rivolta agli audit, alle scartoffie, alle checklist. La sicurezza invece riguarda una mentalità tattica, di cybersecurity reale e di riduzione del rischio. La compliance si pone la domanda “Abbiamo un programma di patch management che applica le patch critiche al momento giusto, sì o no?” La sicurezza è trovare quali patch applicare e quando, applicare queste patch critiche e quindi verificare che siano state bene applicate. La prima ti aiuta a superare un audit. La seconda ti protegge davvero.

Generalmente si pensa che entrambe tendano al medesimo scopo: ridurre il rischio cyber. Ma la compliance è così inadatta a questo che non sono sicuro che riesca affatto a ridurre un rischio reale. Ecco perché:

1. La compliance è binaria

I rischi per la sicurezza non sono binari, ma la compliance riguarda domande e risposte binarie, sì o no. Hai o non hai fatto così e così? Non permette grande spazio a un modo di ragionare out-of-the-box o, ancor peggio, ad una migliore sicurezza. Per esempio, la maggior parte delle regolamentazioni relative alla compliance richiedono password complesse che siano di 8 o più caratteri. Sebbene una password non complessa di 20 caratteri sia indubitabilmente più difficile da indovinare e più semplice da usare, probabilmente non potresti usarla nella maggior parte delle organizzazioni.

Altro esempio. Molte regolamentazioni richiedono una policy che blocchi un account utente dopo che sia stata digitata la password sbagliata per un determinato numero di volte. Se richiedi password sufficientemente lunghe ma significative, non avrai bisogno di questa policy e correrai rischi minori.

Aumentare la forza di default delle tue password non ti libererà dal requisito di abilitare le policy di blocco. In certi scenari queste policy possono accrescere il rischio di denial of service. I worm di password-guessing spesso tentano 100 e più password casuali, cosa che impedirà l’accesso agli utenti sotto attacco. Oppure gli hacker proveranno ad indovinare le password di un portale online, di nuovo lasciando fuori gli utenti.

2. La compliance non è rilevante

La social engineering ed il phishing sono responsabili del 70/90% degli incidenti di sicurezza, ma ancora adesso puoi essere in difficoltà a trovare una frase che riguardi il security awareness training o la social engineering in qualunque guida normativa. Il patching è il problema numero 2, che attualmente causa il 20 o 40% degli incidenti, ma di solito gli si dedicano parecchi paragrafi. La crittografia ferma davvero pochi attacchi, ma anch’essa trova abitualmente spazio nelle raccomandazioni.

Se tu leggessi un qualunque regolamento e ti provassi a difendere in base al numero di righe dedicate ad un particolare soggetto, penseresti che la cifratura dovrebbe essere la tua preoccupazione più grande. Le regolamentazioni non sono intese essere delle misure del rischio, ma sembra che ci sia uno squilibrio se devi conformarti a 200 cose che fanno veramente poco per ridurre realmente il rischio piuttosto che alla sola cosa che potrebbe avere l’effetto più grande.

3. Le regolamentazioni cambiano lentamente

La modifica dei regolamenti generalmente richiede tempo quando spuntano fuori nuove raccomandazioni in tema di sicurezza. Nei documenti relativi alla compliance trovi su sacco di riferimenti a firewall a tre connessioni, DMZ e floppy disk. Non trovare molte informazioni su come proteggere al meglio i suoi servizi cloud o su autenticazione a più fattori, ransomware, quantum computing, rischi dei venditori di terze parti, attacchi nation-state e gestione della supply chain. Il mondo si sta muovendo e sta cambiando, l’IT security si sta muovendo e sta cambiando, ma i regolamenti no.

4. La compliance vince sempre

Il problema è che quando security e compliance entrano in conflitto, la compliance vince sempre. I CEO e i capi sono personalmente responsabili di verificare che l’organizzazione soddisfi tutti i requisiti di compliance. Non vogliono ascoltarti quando spieghi loro di presentare una domanda di eccezione perché le tue password sono più forti e migliori di quello che le guide richiedono, perché così facendo non risultereste compliant con la maggior parte dei regolamenti. Ogni minuto in cui qualcuno lavora per accertarsi che una casella sia spuntata su una checklist di compliance è un minuto in cui non si lavora sulla reale sicurezza.

5. Son tutte bubbole!

Questo è il più grande imbroglio. Tutti sanno che la compliance è una grande falsità. Tutti.

Basta fare qualche esempio. Tutti i regolamenti richiedono che gli utenti facciano il backup dei sistemi critici e lo verifichino periodicamente. Bene o male in ogni audit a cui ho partecipato l’ente sottoposto ad audit dichiara di farlo. La realtà è che quasi nessuno lo fa, come stanno rivelando tutti gli attacchi ransomware che hanno successo.

Sì, la maggior parte delle organizzazioni fa il backup dei loro sistemi ma quasi nessuno verifica se questi backup siano in grado di ripristinare effettivamente un sistema. Chi ne ha il tempo? Chi ha lo staff per farlo? Il management non assegna abbastanza risorse all’IT per farlo. Non chiede di farlo. E non gliene importa…finché non è troppo tardi. Scommetto che il 99% dell’universo IT ha testato i backup soltanto poche volte nella storia di una compagnia, e tuttavia entrambe le parti di un audit concordano sul fatto che sia stato portato a termine. La stessa cosa accade per la ‘regolare verifica dei controlli’. Tutti sostengono di farla, ma pochi la fanno davvero.

Lascia che ti faccia un altro esempio illuminante. Ogni regolamento sostiene che tutte le patch critiche dovrebbero essere applicate in modo puntuale (qualunque cosa ciò significhi). Nella mia ultratrentennale carriera non ho mai trovato una singola entità che fosse a posto, che avesse cioè applicano le debite patch in modo completo. Non ho mai visto un singolo router Cisco cui fossero state applicate le patch adeguate in modo puntuale. E la stessa cosa vale per i server.

Tutti credono che il patching sia completo. Ma quello che intendono davvero è che tutte le patch di Microsoft sono applicate, ed anche questo raramente è vero. Perfino se le patch di sistema sono state applicate, il software di server management non è aggiornato. Qualche video encoder non è aggiornato. Alcuni strumenti di server management che hanno installato non sono aggiornati. Per non aggiornati intendo che contengono qualche vulnerabilità nota che può essere sfruttata da remoto per prendere il controllo dei server.

Oppure dicono agli auditor che hanno applicato il 99% delle patch e lo dimostrano con i loro report. Quello che non dicono è che il restante 1% privo di patch è quello che può con maggiore probabilità essere sfruttato da un criminale. Scusa se mi ripeto, su centinaia di compagnie e migliaia di computer che ho verificato, nessuna aveva un patching completo. E, tuttavia, tutti dicono di averlo fatto nei loro report.

Lascia che ti racconti un’altra comune menzogna riguardo alla compliance. Ogni regolamento dice che tutti i log devono essere esaminati regolarmente. Alcuni regolamenti dicono addirittura ogni giorno. Molte compagnie non sono affatto sicure di dove si trovino i loro, e ancor meno li prendono in mano e li analizzano. Il computer medio ha decine di log, la maggior parte dei quali contiene informazioni rilevanti per la sicurezza o le applicazioni. Non ho mai visto più di una manciata di log esaminati sulla maggior parte dei computer. Quasi tutti vengono persi e non analizzati.

Nessuno analizza regolarmente alcun log. Puoi immaginare? Gente dedicata a scorrere riga per riga i log del firewall ogni giorno? Da morir dal ridere al solo pensiero. Nessuno ha tempo. Così, quello che praticamente tutti intendono per ‘analizzare i log ogni giorno’ nella realtà significa che prendono in considerazione alcuni dei log di alcune machine e lasciano che qualche sistema automomo di analisi li verifichi per loro, cercando eventi critici predefiniti e inviando alert se qualcosa richiede attenzione. Nuovamente, soltanto alcuni log e alcuni dispositivi. L’idea che qualcuno analizzi regolarmente tutti i file di log è un inutile ed irrealizzabile sogno. Ma tutti noi lo permettiamo.

In ogni audit che ho condotto, la squadra sottoposta ad audit sa che la loro rete è piena zeppa di numerose falle di sicurezza. Credono che il loro ambiente sia un mazzo di carte e, se l’auditor (o un attaccante), estrae la carta giusta, l’intero sistema crollerà. Il gruppo auditato tenta di far indagare l’auditor sulle falle ammesse. Pregano che l’audit finisca prima che l’auditor ponga la giusta domanda o, non voglia il cielo, verifichi davvero i controlli.

Gli auditor sanno come vanno le cose. Fanno semplicemente il proprio lavoro e non vogliono farsi odiare dal cliente. Si sentono come se avessero vinto alcune battaglie e guadagnato il proprio denaro soltanto se finiscono con l’inserire un po’ di cose nel loro report. Nessuno sentirebbe che fosse denaro ben speso se gli auditor non trovassero almeno qualcosa.

"Il problema più grande con la compliance è che non si indaga abbastanza in profondità sul rischio cyber che si suppone dovrebbe ridurre."

Ma, soprattutto, la compliance è una menzogna.

Posso pensare a molte ragioni per cui la compliance fa torto alla sicurezza, come la fatica sprecata cercando di riconciliare numerosi requisiti di compliance, ciascuno leggermente differente. Oppure il modo in cui alcune linee guida siano eccessivamente dettagliate ed altre abbiano a malapena qualche dettaglio. Il problema più grande con la compliance è che non si indaga abbastanza in profondità sul rischio cyber che si suppone essa dovrebbe ridurre. È un peccato che non si dia maggiore credito all’implementazione di una reale sicurezza: sarebbe meglio se la security potesse vincere almeno ogni tanto quando compliance e security entrano in conflitto.

Tratto dell’articolo di Roger A. Grimes
Columnist, CSO

https://www.csoonline.com/article/3398698/5-ways-compliance-hurts-security.html

 

No Comments
Post a Comment