Come valutare un processo di patch management

Alla luce delle crescenti preoccupazioni che contornano la conformità alle prescrizioni legali, diventa sempre più importante l'aver attivato un processo affidabile per la gestione delle patch. Dopo tutto, la maggior parte delle questioni di sicurezza può essere risolta "patchando" i sistemi operativi di rete. Colin Buechler della Shavlik Technologies offre una guida passo-passo dall'implementazione all'audit di questo processo.

I bachi (in inglese: bugs), o problemi tecnici, sono comuni nei sistemi IT complessi e possono essere critici per le attività aziendali: per questo motivo le organizzazioni devono essere in grado di rispondere con un software provvisorio efficace - la patch - fino a quando il problema non potrà essere risolto alla radice. Una patch viene talvolta chiamata anche fix ed è essenzialmente un intervento di "rattoppo" rapido per una parte del programma.

Secondo il CERT, istituto di ricerca americano sulla sicurezza di internet , il 95% delle violazioni della sicurezza potrebbe essere evitato mantenendo i sistemi aggiornati con le patch appropriate: si tratta, in altre parole, di "vulnerabilità conosciute od errori di configurazione per i quali sono disponibili delle contromisure". Inoltre, le norme sulla sicurezza delle informazioni quali la ISO/IEC 27001 ed il CobiT (Control Objectives for Information and related Technology), richiedono un processo formale per la valutazione delle patch prima della loro implementazione su una rete per assicurare al meglio la stabilità e la disponibilità del sistema.

Nel considerare tutte le misure che potrebbero essere adottate nella valutazione delle patch e nel loro impiego in reti diverse è facile trascurare tre semplici fasi che sono al centro di qualsiasi preoccupazione riguardo la sicurezza delle informazioni: valutazione, remediation (risoluzione dei problemi) e gestione. Tutte e tre queste fasi sono fondamentali per mettere in atto un processo di gestione del rischio connesso alle patch e sono tutte essenziali al processo di audit per assicurare che un'organizzazione abbia adottato le misure adeguate per la gestione di questo rischio.

Ecco alcuni suggerimenti pratici da tener presente per ciascun elemento.

Suggerimenti per il processo di valutazione:

• creare una mappa che raffiguri come dovrebbe risultare l'implementazione andata a buon fine di una patch;
• individuare quali sistemi operativi sono presenti in rete e stabilire a quale livello ciascun sistema è stato "patchato";
• sebbene le patch mancanti non dovrebbero essere implementate alla cieca nei sistemi - alcune patch potrebbero non essere state installate per un motivo valido - è fondamentale valutare il rischio associato a ciò: questo permetterà di stabilire se il rischio di non adottare la patch superi o meno il rischio di installarla;
• nonostante alcune organizzazioni preferiscano che siano altri a provare le patch sulla loro pelle per evidenziare qualsiasi problema piuttosto che rischiare l'instabilità nei propri ambienti, dovrebbero essere adottate delle salvaguardie quando una vulnerabilità di tipo 0-day richiede l'utilizzo immediato delle patch;
• tener presente che se già nella fase di valutazione si evidenzia l'esistenza di punti deboli, aumenta la possibilità che sia il remediation che la gestione del processo di patch abbiano anch'essi fallito nel raggiungere gli obiettivi aziendali.

Suggerimenti per il processo di remediation:

• ricordare che il remediation è guidato dal processo di valutazione;
• di solito, gli elementi che presentano il rischio maggiore per un'organizzazione sono gli elementi dei quali ci si occupa per primi;
• se è possibile patchare velocemente - ma in modo sicuro ed efficace - un alto numero di sistemi, fatelo: potrebbe andare a beneficio della strategia globale di gestione del rischio dell'organizzazione, anche se sono presenti rischi minimi;
• potrebbe non essere possibile affrontare contemporaneamente tutti i problemi di rischio elevato, ma un approccio alto rischio / basso rischio potrebbe essere perfettamente plausibile sulla base dell'esperienza e della presenza di personale IT: questo ridurrà rapidamente il rischio globale alla sicurezza delle informazioni di un'organizzazione;
• nel prevenire le vulnerabilità ad alto rischio, potrebbe essere necessario rimuovere alcune patch (processo di roll back) ove queste si siano rivelate fonte di interruzione dei processi aziendali; cosa che, in genere, può essere evitata testando in modo appropriato le patch prima di utilizzarle;
• disporre di un processo che permette di "fare marcia indietro" assicura che si possa rapidamente ritirare un aggiornamento per la sicurezza ove questo causi problemi ad un processo operativo chiave, e possono essere istituiti dei mitigating control (controlli mitiganti) per meglio proteggere quel sistema;
• assicurare che si tenga traccia sulla carta del percorso procedurale di ogni modifica alla configurazione del sistema e relativo periodo di test, in quanto essenziale al processo di remediation.

Suggerimenti per il processo di gestione:

• ricordare che la gestione è fondamentale per l'audit e per mantenere adeguatamente una posizione di sicurezza; le organizzazioni semplicemente potrebbero valutare ed effettuare il remediation su base settimanale o mensile per sapere se i propri sistemi siano adeguatamente patchati, ma questo non incide molto sulla riduzione del rischio generale associato alle procedure patch per l'intera rete. Instaurando un processo ripetibile con metodi definiti per la valutazione e l'attuazione del processo di remediation, si possono assicurare attività adeguate sia a livello di gestione che di audit del processo;
• spesso per le organizzazioni vale la pena sottoporsi ad un audit interno prima del riesame da parte di un auditor esterno, in modo da evitare risultati negativi di un audit procedurale;
• riesaminare ogni passo definito dal processo per assicurare che le procedure siano state rispettate e siano stati mantenuti dei livelli di rischio accettabili: non esiste un indicatore migliore del rischio residuo presente in un'organizzazione di quello del processo di audit;
• per garantire che la procedura di gestione delle patch funzioni , è fondamentale assicurare che le modifiche alla configurazione del sistema siano state eseguite ed approvate anche dal team della sicurezza delle informazioni;
• soprattutto, ricordare che è fondamentale essere in grado di produrre questa documentazione durante un audit del processo, che spieghi le ragioni per le eccezioni ed attesti che i mitigating control erano stati approvati dalla direzione.

Solo costruendo un processo definito e ripetibile per la gestione delle patch è possibile gestire al meglio i rischi aziendali associati al patchaggio dei sistemi e creare un programma totalmente auditabile.

L'autore:

Colin Buechler è consulente senior per la sicurezza alla Shavlik Technologies, il leader del mercato nella semplificazione di configurazioni di reti aziendali complesse, conformità e sicurezza. Per ulteriori informazioni, visitare il sito: www.shavlik.com

Shavlik saranno presenti all'Infosecurity Europe 2007 il 24-26 aprile 2007 a Londra. Maggiori informazioni al sito: www.infosec.co.uk