Siamo tutti a conoscenza dell’importanza del penetration test nella ricerca di falle nel sistema di protezione perimetrale della rete aziendale. Spesso, però, si tende a ritenere che questa certificazione di bontà della sicurezza perimetrale sia parte attiva nella sicurezza stessa. In realtà non è proprio così, è solo un indicatore sullo stato corrente e non ha parte attiva nella sicurezza: se le risultanze di un penetration test evidenziano delle vulnerabilità gravi, allora si devono affrontare come un incidente e non come un normale ticket per attivare il processo di change o di patch management.
Indice degli argomenti
L’approccio corretto al penetration test
Affidarsi al penetration test come parte integrante del sistema di sicurezza semplicemente per velocizzare la ricerca delle proprie vulnerabilità non è l’approccio corretto. Il penetration test deve letteralmente stupire con la scoperta di una situazione totalmente inattesa. Va sempre vissuto come una sfida tra il corretto lavoro interno teso ad eliminare tutte le debolezze contro l’ingegnosità di un potenziale sfidante esterno.
Deve essere visto come un’inutile perdita di tempo perché non ci dovrebbe mai far conoscere nulla di nuovo (in realtà è proprio questo il miglior risultato atteso) in quanto già noto e gestito.
Per sua natura non può essere uno strumento del lavoro quotidiano di protezione e non è possibile aspettare il penetration test per creare la mappa delle proprie vulnerabilità da valutare e a cui porre rimedio che però potrebbe arrivare troppo tardi.
Le vulnerabilità scoperte vanno gestite come se fossero un incidente e analizzate per individuare un loro eventuale sfruttamento malevolo.
Ci sono due momenti fondamentali nei quali si creano le condizioni che favoriscono l’aumento del rischio di avere delle vulnerabilità. Quando il processo di patch management non è stato ottimizzato e quando il processo di change management non è basato sul rischio.
Le vulnerabilità nel nostro ambiente le introduciamo noi con il nostro comportamento progettuale e implementativo oppure sono già intrinseche nei prodotti che utilizziamo ma magari ancora non lo sappiamo. Il primo si risolve ragionevolmente con il patch management, mentre nel secondo caso serve un rigoroso rispetto delle best practice del change management.
In entrambi i casi si utilizza un sistematico vulnerability assessment per individuare le debolezze nel nostro sistema, in modo iterativo perché la vulnerabilità si potrebbe manifestare solo nel futuro. Questi processi sono le leve in mano all’azienda per rendere esigue le possibilità di vulnerabilità scoperte solo durante il penetration test.
L’importanza del patch management
Il patch management deve operare su tutti i sistemi e le applicazioni installate come pure basarsi su un regolare vulnerability assessment inteso come controllo continuativo della sua efficacia. Il lavoro richiesto non è assolutamente da considerarsi gravoso in termini di risorse impegnate perché può e deve essere automatizzato. Solo se la criticità del sistema lo richiede, prima di installare la patch, si può configurarlo per attendere la conferma manuale a procedere.
Inoltre, non è neppure economicamente oneroso in quanto la disponibilità di strumenti open source è molto ampia e questo incide positivamente sul costo considerando la solita euristica, maggiori competenze interne, minori costi di licenze e consulenze professionali.
Gli strumenti disponibili nell’open source richiedono delle competenze tecniche superiori ai prodotti commerciali in quanto spesso sono meno elaborati nell’interfaccia utente che potrebbe non risultare semplice e intuitiva. Generalmente il voler enfatizzare la forza del proprio strumento spinge gli sviluppatori ad agire sulla numerosità e complessità delle opzioni di configurazione possibile e questo non gioca a favore della chiarezza espositiva dell’interfaccia utente.
La personalizzazione, sia del vulnerability assessment che del piano di installazione delle patch, ai fini di una ottimizzazione e semplificazione progettuale, richiede la disponibilità del disegno aggiornato della rete ed una completa conoscenza delle caratteristiche tecniche e dell’importanza per il business dei server presenti.
Di contro, l’assenza di conoscenza si paga con la necessità di dover adottare strumenti più potenti nella scansione, in grado di analizzare e operare su tutte le tipologie di vulnerabilità conosciute e conseguentemente di dover installare tutte le patch generali consigliate o rinviare l’installazione ad un’analisi manuale.
Il rischio dell’eccessiva automatizzazione senza conoscenza adeguata di ambiente tecnico e obiettivi aziendali è di compromettere l’ottimizzazione dei server, installando più del necessario e logicamente aumentando l’insicurezza.
Il change management e l’analisi del rischio
Il change management è un momento delicato dal punto di vista delle conseguenze per la sicurezza. Non può essere orientato alle sole performance del sistema, deve essere attentamente valutato nelle sue implicazioni verso la sicurezza e questo può avvenire solo se è guidato dall’analisi di rischio (la quale è allineata agli obiettivi aziendali).
Quest’ultimo passo è quello che permette di identificare i soli servizi necessari e avere i razionali per eliminare o limitare tutti gli altri. Inoltre, ridurre il perimetro di applicabilità della protezione ai soli elementi di valore per l’azienda (spostando gli altri fuori perimetro per evitarne lo sfruttamento), aiuta a creare ambienti omogenei in termini di livello di sicurezza da garantire e idonei all’applicazione di medesime regole di protezione.
Per definire il valore degli elementi inclusi nel perimetro di protezione è necessario considerarli non solo dal punto di vista dell’impatto rispetto al verificarsi di un’intrusione (come pura conseguenza tecnica) ma è necessario determinare il valore della indisponibilità dei relativi servizi (fattore organizzativo legato agli obiettivi aziendali).
Dall’analisi dell’impatto sulla continuità del servizio, per ogni singola applicazione, si possono ricavare tutti i parametri necessari per valutare la criticità dei sistemi ed anche, nella prospettiva di attacco, le modalità in cui dovremmo difenderci. Esempio di parametri, frequenza del vulnerability assessment e sua profondità, policy di installazione automatica di patch, livello di ridondanza, livello di protezione (IDS, honeypot) e così via.
Un’ulteriore esempio su come affrontare un change, non solo come processo di pura modifica tecnica ma con un attenzione organizzativa alla sicurezza, può arrivare dall’inventario degli asset IT. Se a fronte di ogni cambio applicativo, viene aggiornata la lista delle porte necessarie in uso su ciascun server, è possibile, chiudere quelle non indispensabili e monitorare la presenza nel tempo di eventuali porte aperte non autorizzate. Il tutto per tramite di semplici comandi automatici o applicazioni di monitoraggio con produzione di alert o report per le analisi comparative tra la realtà rilevata e quella attesa.
L’esempio serve unicamente a fare capire che è possibile ricorrere anche a metodi artigianali nel caso non ci si voglia, o economicamente non ci si possa, affidare ad un unico strumento di vulnerability assessment, completo di tutte le funzioni possibili anche se probabilmente non tutte necessarie. Tali strumenti, pur con ottime performance, richiedono frequentemente la necessità di risorse dedicate, vincoli implementativi sulla rete ed anche una complessità di manutenzione significativa.
Patch e change management: la reportistica di qualità
Differenti e semplici applicazioni, dedicate a singoli compiti ben circostanziati è un approccio concorrenziale all’unico tool che miete migliaia di test per volta, ma non sempre il suo output risulta di facile lettura o consente la giusta evidenza alle vulnerabilità di maggior impatto per quell’ambiente.
La qualità della reportistica non è legata alla numerosità delle segnalazioni contenute ma dall’avere la capacità di riuscire ad evidenziare le informazioni utili per intervenire in tempo con misure correttive proporzionate al valore delle risorse per l’azienda.
Uno strumento di diagnostica completo, con una reportistica dettagliata che poi non siamo in grado di prioritizzare ha uno scarso valore. Meglio allora qualche cosa di più semplice, nessun pregiudizio se artigianale o con poche funzioni ma mirato principalmente alle risorse critiche e con un output di immediata comprensione.
Tutto il lavoro fatto va sempre registrato e condiviso per creare una completa conoscenza delle misure in atto con lo scopo di contrastare le minacce ed acquisire una concreta consapevolezza dei rischi. Si deve eliminare la possibilità di aver introdotto una “vulnerability by design” legata ad un lavoro approssimativo o ad una progettazione non olistica. Quindi, il penetration test deve risultare interessante quanto la lettura del giornale della settimana prima. Nessuna nuova, buona nuova.
