Vulnerability, exploit e patching sono tre termini di riferimento nella sicurezza informatica che dovrebbero andare a braccetto, ma tante evidenze ci dicono che non è così.
L’importanza del patching dei sistemi informatici è nota dalla “notte dei tempi” e su esso sono state scritti innumerevoli testi: eppure, lo stato di esercizio di tante infrastrutture sembra negarne l’applicazione.
A fine giugno 2020, il team di Microsoft – ATP Defender ha pubblicato una guida dal titolo “Defending Exchange servers under attack” per il contrasto agli attacchi verso i server mail Exchange. Nel documento si cita una crescita notevole di hacking malevolo utilizzando le shell web sui server Exchange locali e numerosi attacchi che utilizzano tecniche senza file. Questo comporta un maggiore livello di complessità quando si tratta di rilevare e prevenire attacchi, come è accaduto (e forse sta ancora accadendo) per lo sfruttamento di vulnerabilità rilevate e già risolte come nel caso della CVE-2020-0688.
L’aspetto suggestivo di questo particolare caso, citato a titolo esemplificativo, è che la patch con cui si risolvono queste criticità è già disponibile da diversi mesi, ciò nonostante un’elevata percentuale dei server Exchange non è ancora protetto.
Lo stato di insicurezza dei sistemi informatici è spesso frutto di sottovalutazione del rischio da parte degli amministratori di sistema, in alcuni casi è dovuto alla loro impreparazione o non adeguata competenza, ma in altri casi i motivi sono da ricercare nel quanto sia decisamente complicato tenere aggiornati tali ambienti.
Se a questo poi aggiungiamo che gli attacchi degli hacker malevoli ormai non sono più target oriented ma vulnerability oriented, il quadro di molte spiacevoli realtà è completo.
Indice degli argomenti
Vulnerability, exploit e patching: alcuni dati
Probabilmente nessuno è in grado di riferire il numero esatto delle vulnerabilità conosciute ma, senza alcun dubbio, il valore è molto elevato visto che il National Vulnerability Database (NVD) ne ha registrati in totale 138.569 (fino a luglio 2020), 5.342 negli ultimi tre mesi e 51.572 negli ultimi tre anni (il motore di ricerca precisa che le vulnerabilità del kernel Linux sono classificate separatamente dalle vulnerabilità in specifiche distribuzioni Linux). NVD è il repository del Governo statunitense in cui sono registrati i dati sulla gestione delle vulnerabilità basati su standard. L’NVD include nel suo database riferimenti a liste di controllo di sicurezza, difetti del software relativi alla sicurezza, configurazioni errate, nomi di prodotti e metriche di impatto.
Da un’altra fonte, Common Vulnerabilities and Exposures (CVE), apprendiamo che le vulnerabilità registrate sono 12.174 nel 2019. CVE è un database contenente i dettagli delle singole vulnerabilità della cyber security pubblicamente note e rappresentate da un numero di identificazione, una descrizione e almeno un riferimento pubblico.
In un interessante studio dal titolo “The Etiology of Vulnerability Exploitation” presentato a marzo 2019 all’RSA Conference di San Francisco, si divulgano diverse informazioni tra cui la conferma dell’imponente crescita delle CVE pubblicate, come si evince nel grafico seguente.
- l’exploiting, ovvero l’azione volta a sfruttare una vulnerabilità per violare un sistema, avviene prevalentemente a ridosso (alcuni giorni prima o dopo) della pubblicazione CVE;
- quanto detto al punto precedente, implica la necessità di installare le patch tempestivamente, se già disponibili. Purtroppo, questo non avviene visto che solo il 25% delle vulnerabilità sono risolte installando le patch entro un mese dalla loro scoperta, mentre occorrono circa tre mesi per eliminare la metà delle vulnerabilità e, ad un anno di distanza, il 25% di esse risultano ancora presenti;
- buona parte (1/3) delle patch non applicate riguardano prodotti appartenenti a Oracle, Microsoft e Adobe. Il prodotto in assoluto meno “patchato” è Java.
Come forma di consolazione, rileviamo tre buone notizie, tra tante pessime: il 77% del totale delle vulnerabilità non viene sfruttato (o meglio, non sono noti exploit), solo 1/3 delle CVE è presente in ambienti reali e solo il 5% delle CVE esistenti ha degli exploit.
Vulnerability, exploit e patching: una corretta strategia
Già solo questi elementi ci permettono di evidenziare l’importanza di individuare una strategia di patching adeguata che non sia quella del provare a “patchare” tutto nel tempo limite previsto, con il risultato di non riuscirci sia per la quantità di rimedi da apportare sia per la quantità di sistemi coinvolti. In altri termini questa è una “non-strategia”.
Un criterio di patching molto diffuso è basato sul CVSS Common Vulnerability Scoring System, che è un sistema di valutazione delle vulnerabilità disponibile nella forma aperta e gratuita per la valutazione delle loro caratteristiche e gravità per la sicurezza del sistema informatico, in cui si indicano, tenendo conto di diverse variabili, le priorità con un punteggio con valori da 0 a 10 (quest’ultimo è il livello di gravità più elevato).
Per fare un esempio di questo tipo di valutazione del CVSS, citiamo la scoperta, resa nota il 14 luglio 2020, di una falla di sicurezza nei servizi DNS di Windows, identificata come SIGRed (CVE-2020-1350) e dichiarata vulnerabilità wormable e critica (punteggio CVSS di 10). Interessa le versioni di Windows Server dal 2003 al 2019 e può essere sfruttata ottenendo i diritti di amministratore di dominio, compromettendo l’intera infrastruttura aziendale.
Una patch correttiva è già in distribuzione con il Patch Tuesday e, vista la gravità, nel caso non sia possibile aggiornare i sistemi immediatamente, Microsoft ha messo a disposizione anche una soluzione temporanea attraverso la modifica di una chiave di registro del sistema.
Quindi, un punteggio CVSS di 10.0 dovrebbe far scattare un allarme da pronto intervento. Per meglio comprendere la gravità, si consideri che WannaCry, il famigerato, ransomware fu valutato 8,5.
Un approccio ragionato prevede di installare tutte le patch per quelle vulnerabilità con punteggio CVSS pari o superiore a 7, che è una buona soluzione, ma potrebbe risultare inefficiente e quindi inefficace perché le attività potrebbero comunque richiedere molto tempo per il numero di patch interessate.
Talvolta si aggiunge a queste valutazioni anche il criterio di eseguire il patching sui sistemi più noti, confidando che quelli che lo sono meno siano meno esposti. Purtroppo, alcune sottovalutazioni di questo tipo possono costare molto care.
Altra domanda da porsi è: come bisogna regolarsi con vulnerabilità di bassa criticità ma che interessano servizi core per l’azienda? Anche in questo caso, non esiste una risposta valida per tutto e tutti. La conoscenza dettagliata dei propri ambienti e le modalità di utilizzo devono far emergere la soluzione più appropriata.
Gli amministratori di sistema, nell’eseguire le attività di patching per i sistemi che gestiscono, devono fare i conti non solo con i problemi tecnici, ma anche con quelli operativi: ad esempio, tempi di inattività dei server, pianificare gli interventi concordandoli con le funzioni aziendali interessate, verificare gli impatti delle modifiche eccetera.
Disporre di una linea guida per queste attività è opportuno, qualsiasi sia lo strumento di patching che si sta usando tra quelli disponibili sul mercato.
Best practice per il patching in ambienti Windows server
È fondamentale verificare e adottare una strategia specifica per ogni contesto, tenendo conto che gli ambienti informatici sono eterogenei per definizione e richiedono valutazioni e scelte specifiche spesso non trasferibili tra i vari sistemi.
Proviamo a definire in questa sezione alcuni elementi di best practice per il patching di ambienti Windows server.
Le patch di sicurezza e gli aggiornamenti cumulativi di Windows Server sono i due elementi con cui Microsoft fornisce il proprio contributo per proteggere tali sistemi da attacchi esterni, correggere i bug identificati nelle versioni precedenti e migliorare prestazioni e stabilità.
Tempi di fermo macchina
È uno dei fattore chiave nell’attività di patching considerando che i tempi di fermo macchina possono generare tempi di inattività delle attività di produzione. Lasciare indefinito questo aspetto organizzativo, può produrre ricorrenti problemi visto che il patching è un’attività “continua”.
Quindi, avendo ben presente gli obiettivi di ridurre gli sforzi tecnici e minimizzare al massimo i tempi di inattività del business, è importante condividere con le varie funzioni aziendali il proprio piano di patching con illustrazione delle ricadute operative ed ottenere le adeguate approvazioni dei vertici.
In termini teorici il momento più favorevole per eseguire il patching è quello di farlo coincidere con la stessa finestra di manutenzione standard degli impianti, se prevista. Potrebbe essere quella notturna o del fine settimana in cui i vari servizi applicativi possono essere fermati e i server riavviati con il minor impatto possibile.
In alternativa, è necessario comunque prevedere a calendario un tempo stabilito che sia condiviso e pre-autorizzato da utilizzare per l’esecuzione delle sole attività di patching, che sia molto vicino al momento di diffusione delle patch Microsoft.
Per i fortunati amministratori di sistema che dispongono di cluster failover di Windows, il tema dei tempi di fermo è sicuramente meno sentito.
Sintetizzando il fattore chiave dei tempi di fermo macchina possiamo dire di puntare tutto su concertazione, condivisione e approvazione.
Programmazione attività patching ricorrente
La preparazione di un programma delle attività è un altro aspetto determinante che dovrà tener conto di alcuni aspetti oltre a quello di allineamento con i tempi di fermo concordati e autorizzati:
- la frequenza: Microsoft rilascia le patch il secondo martedì di ogni mese per cui l’esecuzione delle patch di Windows deve essere eseguita mensile. Sembrerà una precisazione pleonastica e banale, ma è giustificata, ad esempio, dal fatto che non è infrequente sentire nel settore che i server vengono patchati trimestralmente;
- elencare i server suddividendoli in base agli ambienti esistenti: Sviluppo, Test, Produzione, Repliche Disaster Recovery ecc.;
- iniziare il patching dagli ambienti meno critici (ad. es. Test) può permettere l’affiorare di problematiche che sarebbe meglio non scoprire in Produzione;
- la pianificazione deve tener conto dei tempi di preavviso e condivisione con tutti gli interessati interni all’azienda o esterni (ad es. fornitori di applicativi). La notifica, oltre a ricordare l’imminente attività di patching, è utile per eseguire le verifiche preliminari e successive (ad es. compatibilità con le applicazioni di terze parti). Gli amministratori di sistema spesso trascurano l’impatto del patching sulle componenti di terze parti, mentre invece dovrebbero sempre coinvolgere i produttori delle applicazioni, sia nella fase preliminare, sia post completamento dell’attività di patching, in modo da assicurarsi che le applicazioni ospitate sul server funzionino come dovuto;
- nella finestra temporale stabilita vanno previsti tempi per i test da eseguire prima e dopo il patching, verificando che non vi siano errori nei registri eventi, che l’agent del tool di patching sia attivo, che tutti i servizi automatici siano in esecuzione, che le prestazioni del server siano normali, ecc.;
- preferibilmente non si escludano mai dei server dalla programmazione patch, a meno che non sia realmente una improrogabile necessità aziendale.
Patching Microsoft zero day
Microsoft definisce “out-of-band” le patch che risolvono vulnerabilità zero days. Sono distribuite in modo estemporaneo una volta effettuata la valutazione del rischio da parte del loro team di sicurezza. Microsoft consiglia di distribuire queste patch con particolare premura per evitare attacchi informatici. Un tempo ragionevolmente breve è: entro le successive 48 ore dalla distribuzione.
In questo scenario salta ogni tipo possibile di pianificazione e conta solo poter identificare velocemente i server che hanno in esecuzione il prodotto interessato dalla vulnerabilità. Disporre di uno strumento di gestione delle patch, distribuzione del software, inventari hardware e software è fondamentale, in modo da poter creare, tramite una query specifica, un report che individui i server interessati.
In casa Microsoft il sistema che ha queste funzionalità è Microsoft Endpoint Configuration Manager (precedentemente System Center Configuration Manager).
Se non si dispone di alcuno strumento, è necessario utilizzare qualsiasi metodo di scripting per ricavare i dati richiesti oppure, come ultima spiaggia, verificare manualmente ogni singolo server.
Questa condizione di emergenza talvolta viene trascurata e si decide di aspettare le finestre di aggiornamento disponibili e pre-autorizzate. Le conseguenze dovute a questo rischio sono immaginabili.
È anche utile verificare se il software antivirus installato sui server sia già in grado di mitigare la vulnerabilità scoperta. In questo caso è possibile rimandare l’applicazione della patch sui server alla pianificazione prevista.
Valutare prima di agire
Microsoft aiuta gli amministratori di sistema a comprendere il rischio associato a ciascuna vulnerabilità fornendo i seguenti dati:
- impatto: vulnerabilità che rappresentano minacce alla sicurezza;
- gravità: massimo impatto potenziale dell’attacco;
- punteggio CVSS: Common Vulnerability Scoring System;
- se già divulgata pubblicamente: indica una vulnerabilità che è stata divulgata pubblicamente prima del rilascio dell’aggiornamento della sicurezza;
- se già sfruttata: la vulnerabilità è stata sfruttata prima del rilascio dell’aggiornamento della sicurezza;
- Microsoft Exploitability Index: il potenziale di sfruttamento di ogni vulnerabilità indicata con gravità Importante o Critica, associata a un aggiornamento della sicurezza di Microsoft.
Vulnerability, exploit e patching: tenersi aggiornati
Per un amministratore di sistema di ambienti Microsoft, “tenersi aggiornato sugli aggiornamenti” non è solo un gioco di parole ed è possibile farlo collegandosi ad uno dei seguenti canali di comunicazione:
- servizi di notifica di sicurezza tecnica Microsoft: questo servizio è mensile e gratuito con cui sono forniti collegamenti ad aggiornamenti software relativi alla sicurezza e notifica di aggiornamenti di sicurezza di nuovo rilascio;
- avvisi sul blog Microsoft Security Response Center (MSRC): vengono diffuse comunicazioni di sicurezza importanti; aggiornamenti durante le prime fasi di incidenti di sicurezza e pubblicazioni regolari per il ciclo di rilascio delle vulnerabilità;
- MSRC Twitter: @msftsecresponse – canale Twitter.
