Blog Perché la tua strategia di patch management deve cambiare ora | Insight

Gli exploit oggi si muovono in ore, non in giorni. La domanda non è se subirai un'interruzione, ma se questa avverrà alle tue condizioni o a quelle di chi ti attacca.

Qualche settimana fa ero nel bel mezzo di una riunione quando il mio laptop ha deciso che non aveva più intenzione di aspettarmi. Avevo rimandato lo stesso aggiornamento della patch una volta di troppo e, proprio a metà di una frase, si è spento. Niente più "ricordamelo più tardi". Nessuna opzione per rimandare.

E il punto è questo: non potevo nemmeno arrabbiarmi. Ho preso il telefono, sono rientrato nella chiamata e ho continuato. Perché quella politica (quella che ha appena interrotto la mia chiamata) è la stessa che continuo a suggerire ai responsabili della sicurezza di adottare: imporre l'interruzione alle proprie condizioni, non a quelle di qualcun altro.

Applicare le patch "a orario" significa trattare le vulnerabilità critiche come incidenti attivi, misurati in ore per la risposta, non in giorni prestabiliti su un calendario.

E se ho intenzione di chiedere ai nostri clienti di rivedere il modo in cui applicano le patch, è meglio che io stesso viva secondo questo principio.

Ecco quindi come ho impostato il discorso con i responsabili della sicurezza.

Lo slider nella mia testa

Questa immagine mi è venuta in mente durante un pranzo con un responsabile della sicurezza al Cisco Live e da allora non riesco a smettere di pensarci. Immagina uno slider. A un'estremità c'è l'impatto operativo: il rischio di interrompere il tuo business. All'altra estremità c'è un incidente di sicurezza: il rischio di subire una violazione. Ogni organizzazione si trova in un punto di questa barra, che se ne renda conto o meno, e la posizione in cui si trova ti dice tutto su come pensa al rischio.

Ecco cosa hanno segnalato per anni la maggior parte delle organizzazioni. Quando applichi un ciclo di patch di 90 giorni (e, ad essere onesto, era il nostro ritmo qui in Insight non troppo tempo fa), stai facendo una scommessa. Stai dicendo: "Preferisco rischiare un incidente di cybersecurity piuttosto che rischiare di bloccare la produzione per applicare una patch." Hai posizionato saldamente il tuo slider dal lato della protezione delle operazioni. Hai la sensazione che una violazione sia l'esito meno probabile, quindi ottimizzi contro l'interruzione che vedi arrivare.

Capisco perfettamente questo istinto. Amiamo i nostri processi. Amiamo le nostre finestre di change, le revisioni del CAB, i nostri controlli; esistono per tenerci al sicuro e per rendere prevedibili le operazioni IT. Ma Mythos, e altri modelli AI di frontiera come lui, hanno spostato silenziosamente le probabilità di questa scommessa, e molti responsabili non hanno ancora reagito spostando il proprio slider del rischio.

Il punto che tutti si perdono

Ecco cosa ha cambiato il mio modo di pensare. Quando la finestra temporale tra la divulgazione di una vulnerabilità e la comparsa di un exploit nel mondo reale si riduce da giorni a ore (e, a un certo punto in un futuro non troppo lontano, a minuti), la violazione non è più l'esito improbabile. Diventa quello imminente.

E qui c'è il punto su cui vorrei davvero che ti fermassi a riflettere: una violazione è anch'essa un'interruzione della produzione. Non puoi evitare l'interruzione semplicemente non applicando la patch. Stai solo scambiando un tipo di interruzione con un altro.

Quando applichi le patch alle tue condizioni, l'interruzione è pianificata e controllata. L'hai programmata. Hai il tuo personale pronto. Hai gli strumenti di rollback preparati. Se qualcosa va storto, lo risolvi e vai avanti.

Quando subisci una violazione, hai comunque un'interruzione, ma ora è imprevista. È inaspettata, colpisce alle 2 di notte quando non hai il personale di cui avresti bisogno, ed è malevola. Chi l'ha causata ha un interesse diretto nel mantenerti fermo, non nell'aiutarti a rialzarti. Ecco il vero cambio di prospettiva: pianificata e controllata contro inaspettata e malevola.

Non stai più scegliendo se subire un'interruzione. Stai solo scegliendo alle condizioni di chi avverrà.

Due modalità, stessa vulnerabilità

Ecco perché ho iniziato a parlare di applicare le patch come un incidente piuttosto che come un'attività di manutenzione. Stesso CVE, ma con un approccio completamente diverso.

Nel modello di manutenzione, la domanda che ci poniamo è "Questa patch romperà la produzione?". Misuriamo il successo in base alla percentuale di asset che abbiamo coperto, e l'orologio scorre in settimane o mesi. Nel modello a incidente, la domanda si ribalta in "Qual è il raggio d'impatto se non applichiamo questa patch?". Misuriamo il successo in base al tempo medio di rimedio, e l'orologio scorre in ore. Quando lo sfruttamento richiede ore, una finestra di manutenzione mensile non è più un processo, è una passività che aumenta la tua esposizione al rischio operativo.

Ora stiamo parlando di distribuire le patch attraverso lo stesso tipo di workflow che ti aspetteresti da un incidente di cybersecurity tradizionale: rilevare, valutare, contenere, rimediare, validare. Rileviamo la divulgazione tramite una gestione continua dell'esposizione alle minacce, individuiamo ogni punto in cui è presente nel patrimonio IT, utilizziamo il machine learning per valutare quanto sia probabile che venga effettivamente sfruttata nel tuo specifico ambiente, e lo validiamo con test di penetrazione continui. Se si tratta di una vulnerabilità alta o critica, parte un orologio SLA e i nostri team di risposta si attivano immediatamente.

Non si tratta di applicare patch a tutto nel momento stesso in cui viene divulgata una vulnerabilità. Si tratta di individuare il piccolo sottoinsieme di vulnerabilità che rappresentano un rischio reale e sfruttabile nel tuo ambiente, e trattarle con l'urgenza tipica di un incidente.

Quindi, come si presenta tutto questo in un martedì mattina qualsiasi?

Invece di aspettare il ciclo di patch successivo, una vulnerabilità critica esposta esternamente attiva un workflow immediato: la sicurezza la segnala, ne valida l'esposizione e avvia l'applicazione della patch nel giro di ore, esattamente come faresti con un incidente attivo.

Il vantaggio controintuitivo

Ora, se sei un responsabile delle operazioni, il tuo allarme si sta attivando: applicare patch più di frequente significa più interruzioni, giusto?

In realtà è l'esatto contrario, e questo è l'argomento che vorrei che i CISO portassero ai loro colleghi delle operazioni e del business. Uno dei motivi principali per cui le finestre di patch esplodono è che lasciamo che le patch si accumulino, per poi distribuirne decine in decine di sottosistemi tutte insieme. Quando passi a rispondere in tempo reale, applichi la patch a un solo modulo interessato, da solo. Le probabilità di una brutta sorpresa a cascata si riducono drasticamente. Stai facendo passi più piccoli, più controllati, più mirati, e riducendo il rischio operativo nel processo.

Questo è un cambiamento nel modo in cui operi

Non farò finta che la tecnologia sia la parte difficile. Non lo è. La parte difficile è organizzativa. Devi essere disposto a rompere lo schema con cui hai sempre affrontato l'applicazione delle patch, e devi costruire una vera alta disponibilità nei tuoi sistemi, perché non puoi far funzionare grandi applicazioni monolitiche secondo questo modello senza rischiare quell'applicazione critica ogni singolo giorno. È un modo diverso di pensare all'architettura, ed è una conversazione che deve arrivare ben oltre il team di sicurezza.

Ti lascio con la stessa domanda a cui continuo a tornare. Subirai comunque qualche interruzione; questo non è più opzionale. L'unica cosa che puoi decidere è se sarà pianificata e alle tue condizioni, oppure non pianificata e alle condizioni di qualcun altro.

In Insight, ci siamo posti come client zero per questo cambiamento radicale nell'approccio all'applicazione delle patch sui sistemi IT. Abbiamo affrontato lo stesso cambiamento esistenziale che tutti gli altri stanno affrontando, abbiamo ricostruito il nostro modo di approcciare la sicurezza e le operazioni IT attorno a questo, e solo dopo lo abbiamo portato ai nostri clienti. Perché non importa davvero chi abbia accesso a Mythos. Esiste. Ed esiste con il rilascio all'orizzonte di modelli con capacità simili, alcuni dei quali non vengono sviluppati dai "buoni".

Quello che conta è se hai riconosciuto che il modo in cui difendi il tuo business è cambiato radicalmente, e che sposti il tuo slider prima che qualcun altro lo sposti per te.