Le policy di sicurezza perfette non esistono non perché siano difficili da scrivere, ma perché rispecchiano male la realtà. C’è una bella differenza tra una policy scritta e una policy scritta che sia applicabile.
La maggior parte delle policy non è pensata per reggere il ritmo e i continui cambiamenti del contesto in cui ci troviamo. Vengono scritte con le migliori intenzioni, ma crollano perché descrivono stati “ideali” e scenari perfetti.
Perché le buone policy falliscono nella pratica
Ai tempi in cui ero sysadmin e mi occupavo di patch management, sono caduto esattamente in questa trappola. Avevo introdotto quella che sembrava una policy lineare: tutte le patch critiche devono essere distribuite entro 30 giorni dal rilascio. Era una metrica chiara, facile da misurare e, soprattutto, in linea con i requisiti normativi e di conformità che dovevamo soddisfare.
Sulla carta era perfetta, esattamente come dovrebbe essere una buona sicurezza. O forse no? Nella pratica è andata in pezzi quasi subito.
Dato che facevo parte anche del team responsabile del monitoraggio e dell’installazione delle patch su endpoint e server, senza accorgermene avevo appena azzerato tutto il mio tempo libero. Nel tempo necessario per individuare cosa andava aggiornato e quando, testare le patch all’interno dell’IT (eravamo sempre noi le cavie), pianificare le finestre di manutenzione per il resto dell’organizzazione e infine distribuirle, erano già passati quasi 30 giorni. Poi il ciclo ricominciava. E a me non restava tempo per fare altro che fare da balia alle patch.
Come se non bastasse, facevamo svolgere un penetration test, e i risultati del pentest erano molto diversi da quelli delle nostre scansioni delle vulnerabilità. I pentester ci spingevano a correggere quanto avevano rilevato, ma alcune vulnerabilità non erano classificate come “Critical”. Così quei problemi ad alto rischio sono rimasti senza correzione per parecchio tempo dopo quelli critici.
Non è stato un problema di intenzioni. Non sbagliavo a volere un patching tempestivo. La policy ha fallito perché non teneva conto dell’ambiente reale, del rischio effettivo per l’organizzazione o delle priorità in conflitto tra loro. È qui che la maggior parte delle policy di sicurezza crolla. Sono progettate per condizioni perfette che negli ambienti IT reali non esistono e spesso non prevedono decisioni realmente basate sul rischio. Alla fine, policy di questo tipo non vengono seguite: vengono aggirate o ignorate del tutto.
Non sono solo le policy sviluppate internamente a cadere in questa trappola. Anche standard di settore ampiamente riconosciuti possono fallire se applicati senza considerare le specificità della tua organizzazione e del tuo ambiente.
Quando lo “standard di settore” smette di essere utile
Gli standard di settore esistono per ottime ragioni. Si basano sulle lezioni apprese da incidenti di sicurezza e violazioni dei dati e rappresentano la competenza collettiva dei professionisti della sicurezza. Forniscono una baseline che funziona per la maggior parte delle organizzazioni nella maggior parte dei casi. Il problema è che “la maggior parte delle organizzazioni nella maggior parte dei casi” lascia comunque ampio margine di fallimento.
Il team IT di un’azienda manifatturiera l’ha imparato a sue spese quando ha deciso di applicare l’hardening ai propri server Windows usando i benchmark CIS Level 1. I CIS Benchmark sono ottimi punti di partenza: sono molto apprezzati, aggiornati con regolarità e raccomandati da auditor e professionisti della sicurezza. Non era questo il problema.
Il problema è stato pensare di poterli applicare in modo uniforme a ogni sistema dell’ambiente. Peccato che i sistemi di controllo della linea di produzione non siano tipici sistemi per utenti finali. Hanno uno scopo preciso e requisiti specifici, diversi da quelli di ambiti come la contabilità, per esempio.
I benchmark hanno disabilitato diversi protocolli e servizi legacy su cui i loro macchinari industriali di 15 anni facevano affidamento per comunicare con il server. Il risultato è stato il fermo della produzione per quasi tutta la giornata (6 ore), mentre si correva ai ripari per annullare le modifiche. L’impatto economico non è stato trascurabile. Non al punto da mettere a rischio l’azienda, ma ha causato parecchia preoccupazione e confusione nei team IT e di produzione.
Applicare i benchmark CIS non era l’approccio sbagliato. Sono progettati per ambienti IT moderni, con sistemi operativi attuali e apparecchiature aggiornate. Ma restano un punto di partenza, e non tutte le impostazioni previste dal benchmark sono necessariamente adatte a un ambiente di tecnologia operativa, dove aggiornare è molto più complicato e i tempi di inattività possono avere pesanti conseguenze economiche.
È qui che seguire alla cieca gli “standard di settore” può farti male. Questi benchmark si basano su presupposti riguardo al tuo ambiente, alle tue risorse e alle tue operazioni. Quando quei presupposti non corrispondono al tuo ambiente reale – perché usi sistemi legacy, operi in un settore specializzato o devi fare i conti con altri vincoli che i benchmark non considerano – seguire ciecamente le best practice può creare più problemi di quanti ne risolva.
I benchmark sono uno strumento utile e vanno usati. Troppo spesso, però, le policy ne impongono l’adozione solo per spuntare una casella di conformità, senza prima capire quali siano i requisiti specifici del proprio ambiente.
Come progettare policy che funzionano davvero
Dopo il fallimento della mia policy originale di patching a 30 giorni, io e il mio team l’abbiamo riprogettata attorno ai risultati anziché alle scadenze. La nuova policy era incentrata sul rischio. C’erano molte integrazioni, ma questa è quella che rende meglio l’idea:
“Le vulnerabilità critiche che interessano asset esposti su internet con evidenza di sfruttamento attivo devono essere mitigate entro 72 ore. Le vulnerabilità critiche per cui è disponibile codice proof-of-concept devono essere corrette entro 7 giorni. La riduzione del rischio può avvenire tramite patching, controlli compensativi o isolamento temporaneo del servizio. Tutte le azioni e le eccezioni devono essere documentate con l’accettazione del rischio da parte del CISO (direttore del dipartimento per la sicurezza informatica).”
Il vero cambiamento non riguardava solo le tempistiche. Abbiamo iniziato a dare priorità a vulnerabilità e patch in base all’esposizione reale: se i sistemi fossero esposti su internet, se esistessero exploit già in circolazione e quali dati quei sistemi trattassero.
Ma, cosa altrettanto importante, abbiamo capito che la visibilità è fondamentale per l’IT. Abbiamo implementato una scansione automatizzata delle vulnerabilità che confluiva direttamente nella nostra dashboard di patch management. Quando un sistema usciva dai parametri di conformità e gli mancavano patch critiche, lo sapevamo subito. Abbiamo iniziato a poter monitorare le nostre metriche nel tempo, per capire quanto bene (o male) stessimo lavorando e su cosa dovessimo migliorare.
Abbiamo anche riconosciuto che a volte applicare le patch entro i tempi previsti non era possibile, per i motivi più diversi. In quei casi servivano controlli compensativi, servivano documentazione e serviva l’approvazione del management.
Nel caso della policy sui CIS Benchmark la lezione è stata simile, ma il team IT l’ha affrontata da un’altra prospettiva. Non ha abbandonato del tutto i benchmark, né li ha rimossi dalla policy. Ha invece aggiornato la policy per richiedere valutazioni di hardening CIS per ogni tipo di sistema presente in azienda, così da stabilire una baseline di quali benchmark avrebbero compromesso i componenti di produzione e quali no. Il team IT ha documentato quali benchmark si applicavano a ciascun tipo di sistema, quali entravano in conflitto con i requisiti di quel tipo di sistema e quali controlli compensativi erano stati adottati. I sistemi di produzione hanno ottenuto una baseline di hardening dedicata, e lo stesso è avvenuto per i sistemi degli utenti finali e per i server.
Come procedere da qui in avanti
Come sappiamo, nell’IT e nella sicurezza non c’è praticamente nulla di ideale. L’innovazione e il progresso tecnologico corrono sempre più veloci della sicurezza.
Il nostro compito, come professionisti IT e della sicurezza, è sfruttare al meglio ciò che abbiamo a disposizione: progettare sistemi, processi e policy abbastanza sicuri da permettere a utenti, reparti e funzioni aziendali di lavorare nel modo più sicuro possibile, senza ostacolare troppo le loro attività.
Dobbiamo accettare che la sicurezza perfetta non esiste e capire che le policy che pretendono la perfezione sono destinate a fallire.
La sicurezza funziona meglio quando fa parte del modo in cui l’IT lavora ogni giorno, non quando viene aggiunta a posteriori. Funziona meglio quando è anche l’opzione più efficiente e più comoda. Quando ostacola il lavoro il meno possibile.
Se il tuo team deve scegliere tra portare a termine il lavoro e rispettare una policy di sicurezza, sceglierà sempre di portare a termine il lavoro. Progetta le tue policy in modo che le due cose coincidano.
