La safe remediation trasforma le correzioni urgenti in modifiche verificate
La safe remediation è un processo controllato per testare una risposta di sicurezza, applicare la modifica approvata e verificare che abbia funzionato. Affronta un problema operativo comune: un avviso critico può avere una correzione nota, ma il ticket può rimanere in coda perché i team responsabili di mantenere disponibili le applicazioni hanno bisogno di evidenze che dimostrino che la modifica non causerà interruzioni alle attività aziendali.
Questa cautela riflette rischi reali negli ambienti di produzione. Un intrusion prevention system (IPS), che esamina il traffico di rete e può bloccare gli attacchi sospetti, potrebbe bloccare anche visitatori legittimi. Una modifica alla configurazione potrebbe interrompere un servizio, mentre una nuova policy per gli endpoint potrebbe interferire con un’applicazione importante. Un endpoint è un dispositivo dell’utente, come un computer desktop o portatile. La safe remediation mira a fornire ai team di sicurezza, infrastruttura e applicazioni evidenze sufficienti per prendere insieme la decisione, anziché affidarsi a una raccomandazione priva di riscontri.
Il problema non è sempre la mancanza di tecnologie di sicurezza. Molte organizzazioni dispongono di protezioni che rimangono inattive o funzionano soltanto in Detect mode, in cui le attività sospette vengono registrate ma non bloccate. I team possono ritardarne l’applicazione a causa dei false positives, cioè attività innocue erroneamente identificate come dannose, nonché per timori relativi alla capacità di ispezione e alla continuità operativa. Nel tempo, le applicazioni e i modelli di traffico cambiano, le eccezioni si accumulano e si sviluppa il configuration drift, ossia le impostazioni si allontanano gradualmente dallo stato previsto dall’organizzazione.
Un white paper di Check Point sulla safe remediation riferisce che il 47% delle organizzazioni esaminate aveva attivato meno del 50% delle protezioni disponibili. Ciò non significa che ogni controllo inattivo debba essere attivato immediatamente. Ogni modifica può creare rischi operativi e i team devono individuare quale controllo affronti una specifica esposizione e stabilire come si comporterà nell’attuale ambiente di produzione.
Il framework suddivide il processo in quattro fasi: Observe, Prove, Act e Confirm. L’osservazione utilizza le informazioni già generate dai sistemi di sicurezza e IT, tra cui i risultati delle analisi delle vulnerabilità, il traffico IPS, l’utilizzo dei dispositivi, le policy per gli endpoint e gli stati delle configurazioni. Nel loro insieme, questi record mostrano le condizioni tecniche che circondano una modifica proposta prima che qualcuno ne approvi l’applicazione.
La prova deve essere adeguata alla tecnologia che viene modificata. Una protezione IPS può monitorare il traffico reale di produzione in Detect mode, in modo che i team possano valutare i possibili false positives e gli effetti sulle prestazioni prima di passare alla Prevent mode, in cui il traffico corrispondente viene bloccato. L’hardening del sistema operativo, che consiste nel modificare le impostazioni per ridurre le opportunità di attacco, può iniziare con un gruppo di test selezionato. Ogni host, cioè ogni singolo computer o sistema, può quindi essere nuovamente controllato dopo la modifica. Le impostazioni degli endpoint possono inoltre essere valutate rispetto alla baseline di hardening del fornitore, un insieme raccomandato di opzioni di configurazione più sicure.
Queste evidenze assegnano a ogni team un ruolo definito. Il personale addetto alla sicurezza può spiegare la protezione che si aspetta dall’azione proposta, mentre i responsabili dell’infrastruttura e delle applicazioni ne valutano il probabile effetto sui sistemi che gestiscono. Le procedure di revisione e approvazione possono essere inserite ovunque l’organizzazione le richieda, mantenendo la decisione legata alle evidenze provenienti da quello specifico ambiente, anziché considerare automaticamente sicura una raccomandazione generica.
Il patching rimane necessario perché affronta la vulnerabilità sottostante. Tuttavia, i programmi di test, coordinamento e deployment possono ritardare l’arrivo di una patch nell’ambiente di produzione. Durante questo intervallo, una signature IPS esistente, cioè un modello utilizzato per riconoscere uno specifico traffico dannoso, oppure una virtual patch possono contribuire a bloccare la relativa via di attacco. Una virtual patch è una regola di sicurezza che intercetta un exploit senza modificare direttamente il software vulnerabile.
La correlazione tra le informazioni sulle vulnerabilità e la copertura dei controlli esistenti può mostrare se è disponibile una protezione appropriata e se questa è inattiva, effettua il monitoraggio in Detect mode oppure è già applicata. Un controllo in attesa di attivazione può essere testato e abilitato tramite la safe remediation. Se non è presente alcun compensating control, cioè una protezione temporanea utilizzata mentre il problema di fondo persiste, la situazione può richiedere un patching urgente o un’altra risposta. I record devono distinguere chiaramente la protezione provvisoria dalla riparazione permanente, poiché la vulnerabilità originale rimane aperta finché non viene corretta.
Dopo la valutazione, un’organizzazione può richiedere l’approvazione dell’azione e del relativo ambito oppure consentirne l’esecuzione attraverso un workflow automatizzato configurato. La modifica viene quindi inviata attraverso il sistema che già gestisce la tecnologia pertinente. Gli aggiornamenti IPS possono passare attraverso il server di gestione della sicurezza, l’hardening del sistema operativo può utilizzare l’infrastruttura esistente per la gestione delle patch e le modifiche supportate agli endpoint possono essere effettuate tramite l’application programming interface (API) del fornitore, un metodo definito che consente ai sistemi software di scambiarsi istruzioni.
La conferma è la fase finale. Il completamento dell’installazione di una policy può mostrare che una protezione IPS è entrata in applicazione. I controlli degli host possono verificare che una modifica di hardening abbia avuto effetto. I record di esecuzione possono identificare le azioni non riuscite o ancora in sospeso, insieme all’utente responsabile, all’ora dell’azione e all’esposizione associata. Anche gli eventi di sicurezza registrati successivamente possono mostrare se il controllo appena applicato abbia bloccato attività correlate a tale esposizione.
Negli ambienti analizzati per il white paper, le azioni di remediation hanno registrato un tasso di successo dichiarato del 99,5%. Nel corso di un mese, le protezioni applicate tramite la remediation hanno successivamente bloccato 703,56 milioni di attacchi, di cui 21 milioni entro 24 ore dalla remediation. Check Point presenta questi dati come risultati provenienti dagli ambienti esaminati, a dimostrazione del fatto che i controlli non erano stati semplicemente configurati, ma avevano in seguito registrato il blocco di attività pertinenti.
La safe remediation estende quindi l’exposure management, il processo di individuazione e definizione delle priorità delle debolezze, fino a includere modifiche controllate negli ambienti di produzione. La definizione delle priorità individua da dove dovrebbe iniziare il lavoro, mentre osservazione, validazione, esecuzione e conferma stabiliscono che cosa è stato modificato e se la protezione prevista sia diventata attiva. Check Point afferma che Check Point Exposure Management collega queste fasi attraverso tecnologie di sicurezza già implementate all’interno di un’organizzazione.
Per le aziende che cercano assistenza nella più ampia sfida operativa del coordinamento di modifiche sicure all’infrastruttura, AEU-I offre servizi IT, infrastrutturali e di consulenza incentrati innanzitutto sulla sicurezza. Qualunque sia il modello di supporto utilizzato, la disciplina essenziale rimane la stessa: i controlli temporanei devono rimanere chiaramente identificati come tali, le correzioni permanenti devono comunque essere completate e ogni azione approvata deve concludersi con evidenze che dimostrino che sia stata effettivamente applicata.