Per alcuni professionisti dell’IT, la linea di demarcazione tra sicurezza e conformità è piuttosto sfuocata e l’obiettivo è un bersaglio mobile difficile da cogliere. Vediamo se è possibile costruire un programma di sicurezza efficace basato solo sugli obblighi di conformità.
Indice degli argomenti
Sicurezza e conformità: il dibattito
Le opinioni sul tema non sono sempre concordi: CISO, DPO, security manager, compliance manager e auditor hanno visioni spesso discordanti basate sui differenti obiettivi che ciascuno si pone. Eppure, la conformità agli standard porta una indubbia serie di vantaggi:
- consente di evitare pesanti sanzioni (e non è poco!);
- protegge la reputazione dell’azienda in quanto la obbliga ad organizzare e tracciare le informazioni sensibili che riguardano i propri clienti, sviluppando le modalità per accedere e modificare tali dati nella maniera più agevole proteggendone la segretezza, l’integrità e la disponibilità;
- migliora la gestione del patrimonio informativo degli utenti, dimostrando di essere organizzati per ottemperare, ad esempio, alla richiesta di cancellazione dei dati senza ritardi;
- permette un controllo strutturato sugli accessi e sull’Accountability.
Sul versante opposto però, esiste un certo scetticismo riguardo l’efficacia delle sole normative nell’assicurare una reale sicurezza nell’organizzazione.
Provo a fare un esempio mettendomi nei panni di un IT manager “dubbioso”. Dal punto di vista della mentalità, la compliance è soprattutto audit, mentre la sicurezza è decisamente più tattica.
L’essere “conforme alla norma” è in fin dei conti la spunta di una checklist sulla carta. Per ogni persona dedicata al controllo delle conformità, ce n’è una in meno che fa sicurezza. Il management spesso è più preoccupato di prendere una non conformità piuttosto che di farsi “bucare” da un attaccante.
La compliance è manichea, binaria, non ammette sfumature né alternative, non si pone in relazione al contesto da proteggere. Dovrebbe essere focalizzata alla riduzione del rischio, ma ha poco a che fare con esso.
Le eccezioni, anche minime, vengono spesso considerate un fallimento su tutta la linea.
Il caso: la lunghezza delle password
Ma alla compliance non interessa. Prendiamo ad esempio alcune considerazioni banali sulla lunghezza delle password: citando l’iconica striscia di xkcd, “in vent’anni di sforzi abbiamo insegnato a creare password difficili da ricordare per gli umani, ma facili da indovinare per i computer”.
Per essere conformi, si parla solitamente di una lunghezza minima di otto caratteri con un certo grado di complessità, ma le norme non considerano l’efficacia di una password in una condizione reale.
Leggiamo suggerimenti generalizzati come nel GDPR che parla di “adottare buone pratiche per le password” e imprecisati “criteri di complessità”, la ISO27001 che non richiede specifici requisiti di complessità e parla di controlli tecnici best effort, la ISO27002 che suggerisce di promuovere l’adozione di password di qualità (specificare “qualità”, grazie) e altre norme di buon senso come il non visualizzare la password in chiaro quando viene digitata.
PCI-DSS che si occupa di scrivere gli standard per i sistemi di pagamento online, fornisce qualche dettaglio in più suggerendo una lunghezza minima di sette caratteri, una combinazione alfanumerica, la scadenza della password ogni novanta giorni, l’history di quattro password, il blocco dell’utente dopo sei tentativi errati.
Il NIST americano, che fornisce linee guida cyber per le agenzie federali, nella sua Special Publication 800-63 invece richiede che le password abbiano lunghezza minima di otto caratteri, suggerisce l’uso di tutti i caratteri ASCII senza raccomandarlo come un obbligo e non si preoccupa di imporre un termine di scadenza.
In questo caso, a fronte di una serie di precetti disarmonici e a volte contraddittori cosa è più corretto fare? Meglio essere conforme alla ISO27001? O alla PCI-DSS? Le linee guida del NIST sono troppo rigide? troppo flessibili? poco dettagliate?
Sicurezza e conformità: il rischio relativo
La scarsa efficacia dei controlli dei framework deriva dal fatto che non siano ponderati per il mondo reale, ovvero non esprimono un grado di rischio effettivo e contestualizzato, non mettono in relazione l’importanza del singolo rischio con gli altri e a volte creano un disallineamento tra controllo e mitigazione.
Ad esempio, statisticamente il social engineering e il phishing rappresentano le principali cause dei mal di testa per gli addetti ai lavori, il patch management è anch’esso un’altra fonte di vulnerabilità e attacchi, la cifratura dei backup è un requisito importante ma che statisticamente non rientra tra i punti più attaccabili di una organizzazione.
Eppure, le norme spendono fiumi di parole sull’importanza della cifratura e molto meno sulle contromisure per il phishing. L’awareness e i controlli anti-social-engineering guadagnano poco spazio in gran parte degli standard confermando che la compliance non dà una importanza relativa al rischio in uno scenario reale e non assegna delle priorità a chi deve occuparsi di sicurezza.
La logica “ingessata” basata su checklist ON/OFF non consente delle valutazioni qualitative articolate e l’organizzazione, pur essendo compliant, non solo non trova nelle norme degli efficaci strumenti di valutazione, ma neppure i metodi per verificare che le azioni correttive siano realistiche e applicabili ad un costo sostenibile.
La lentezza delle procedure
Altro esempio. All’appendice “A.3 Complexity“ della NIST SP800-63, si suggeriscono delle linee guida sulla complessità delle password, descrivendo la frustrazione e la preoccupazione degli utenti che devono affrontare l’impresa di crearne una nuova per l’accesso ad un servizio.
Spesso queste password vengono rifiutate perché contengono spazi e caratteri speciali che potrebbero essere utilizzati per attacchi di SQL injection.
A parte il fatto che (prosegue il NIST) l’hash di una password non transiterebbe in chiaro, l’impossibilità di utilizzare gli spazi rende più complicata l’adozione di una passphrase che sarebbe di gran lunga più difficile da attaccare e più semplice da ricordare.
Inoltre, l’obbligo di password molto complesse e non facilmente memorizzabili introduce un altro tipo di vulnerabilità: l’utente medio probabilmente le annoterà su carta o le memorizzerà elettronicamente in modo non sicuro.
Lo stesso documento pone anche l’attenzione sull’opportunità di far scadere la password. Nella Sezione 5.1.1.2 al paragrafo 9 si afferma che “non si dovrebbe impostare un cambio arbitrario di password (ad esempio periodicamente).
Si dovrebbe invece forzarne il cambio nel caso si abbia evidenza di una compromissione.” Anche in questo caso il NIST motiva la scelta sostenendo che gli utenti tendono a impostare password più deboli sapendo che saranno costretti a modificarle in futuro (stringa complessa, non posso scriverla e appiccicarla sul monitor, tanta fatica per memorizzarla e poi la cambio dopo novanta giorni).
Il più delle volte si aggiunge un numero progressivo modificandone solo alcuni caratteri, il che la rende facilmente prevedibile e quindi vulnerabile.
Queste pillole di buon senso sono di giugno 2017 ma in questi anni quanti framework hanno recepito anche lontanamente tali indicazioni? Per non parlare degli attacchi alla blockchain attraverso il quantum computing; il NIST lavora già da tempo sul tema ma ancora nessuno sviluppo all’orizzonte dal punto di vista normativo.
Conclusione
Solo perché la compliance non garantisce la soluzione di molte esigenze di sicurezza non significa che sia un male, ma che bisogna fare di più.
Essere conformi alle norme spuntando tutte le caselle è una utile base di riferimento, ma non sufficiente a mitigare i rischi nel mondo reale.
Sicurezza e conformità sono componenti differenti di un unico sistema. Conoscere come ciascuna di esse sia collegata alla protezione dei dati è fondamentale.
Con molto lavoro e un po’ di elasticità, la presenza dei requisiti di conformità in simbiosi con l’adozione di misure di sicurezza pensate e pesate in funzione del rischio, manterrà i dati al sicuro garantendo che l’integrità e la reputazione dell’organizzazione rimangano intatte.
