Otto giorni. Sei incendi.
Il 14 ottobre, Palo Alto Networks ha divulgato una vulnerabilità in PAN-OS che consente a un attaccante autenticato di ottenere i privilegi di root sul firewall tramite l'interfaccia di gestione. Era già stata sfruttata come zero-day. Il 17 ottobre, un ricercatore ha dimostrato che otto autorità di certificazione intermedie gestite da eMudhra avevano chiavi private recuperabili da chiunque in meno di un secondo. Una di quelle chiavi era il numero 4. Il 19 ottobre, Unit 42 ha segnalato che gruppi ransomware, tra cui Qilin, sfruttavano una vulnerabilità di GlobalProtect per aggirare l'MFA senza alcun ostacolo.
Il 21 ottobre, PHP ha rilasciato patch d'emergenza per PHP2Shell, una vulnerabilità che consente l'esecuzione di codice non autenticato su ogni installazione PHP che serve richieste web, dopo che i dettagli erano trapelati un giorno prima del previsto. Lo stesso giorno, Node.js ha rilasciato dieci CVE, inclusa una vulnerabilità di esecuzione remota di codice nel decoder Brotli. Il 22 ottobre, Palo Alto ha confermato che PHP2Shell è presente in ogni versione di PAN-OS e Panorama, senza patch disponibile né data di rilascio. Le versioni corrette sono ora stimate tra il 26 e il 30 ottobre, a seconda del ramo di rilascio.
Se si gestisce una funzione di sicurezza, quella settimana non si è risolta applicando patch. Si è usciti facendo scelte, oppure qualcuno le ha fatte al posto vostro.
I punteggi non hanno deciso nulla
Allineiamo i numeri.
L'exploit root su PAN-OS, usato contro firewall reali: 8.6. Il bypass di GlobalProtect, nelle mani di operatori ransomware: 7.8. Il collasso di eMudhra, una CA fidata le cui chiavi di firma chiunque poteva ricalcolare, definito da un ingegnere crittografico di Mozilla come un incidente con il massimo impatto possibile: l'incidente in sé non ha alcun punteggio, e l'unico CVE a valle che CISA ha valutato ha ottenuto un 5.4. PHP2Shell: 9.2 secondo PHP, e classificato da Palo Alto come un problema di disponibilità sui propri firewall.
Il giorno prima di tutto questo, Microsoft ha rilasciato più di 1.400 CVE in un unico Patch Tuesday. Sessantanove erano classificati Critical. Quello già in fase di sfruttamento attivo era classificato Important.
Un punteggio CVSS descrive quanto una vulnerabilità potrebbe essere grave sulla carta. Non sa nulla su chi la stia sfruttando in questo momento, se sia esposta a Internet nel vostro perimetro, né cosa ci sia dietro. Questa settimana, queste tre variabili erano l'intera storia.
La vostra policy di patching avrebbe pianificato il vettore ransomware per il mese prossimo
Aprite la vostra policy di gestione delle vulnerabilità. Scommetto che recita più o meno così: Critical entro 7 giorni, High entro 30, Medium entro 90.
Fate passare la settimana attraverso di essa. PHP2Shell finisce nel bucket a 7 giorni, bene. La vulnerabilità root su PAN-OS già sfruttata è High: 30 giorni. Il bypass di GlobalProtect che i gruppi ransomware stanno usando attivamente: High, 30 giorni. eMudhra: Medium, 90 giorni, ammesso che qualcuno abbia anche solo aperto un ticket.
La vostra stessa policy avrebbe classificato le due cose che gli attaccanti stavano effettivamente usando come lavoro di seconda priorità, e avrebbe dato a un'autorità di certificazione compromessa un trimestre per sistemare la situazione.
Da auditor, è quello che verbalizzerei. Essere lenti è un rilievo. Un processo documentato che vi rende lenti quando applicato alla lettera è un rilievo peggiore, e si tratta di una non conformità A.8.8 a carico di una policy che fa esattamente ciò per cui è stata scritta.
Le responsabilità decisionali si assegnano in tempo di pace
Questa è la domanda che ha separato le organizzazioni nel corso di quella settimana. Chi poteva togliere un'interfaccia di gestione firewall da Internet alle 23:00, senza aspettare il CAB del giovedì?
PAN-OS ha fornito due motivi in otto giorni per smettere di esporre quell'interfaccia. Le indicazioni di Palo Alto sulla prima vulnerabilità prescrivono di limitare l'accesso alla gestione a indirizzi interni affidabili, e per la seconda si specifica che il rischio è massimo quando l'interfaccia accetta connessioni da Internet. Si tratta di una modifica di configurazione che un tecnico competente effettua in pochi minuti. Nella maggior parte delle organizzazioni, nessuno è autorizzato a farla da solo.
Amazon ha registrato un tentativo di sfruttamento di PHP2Shell il 17 ottobre, quattro giorni prima della divulgazione pubblica. CISA ha concesso alle agenzie federali statunitensi tre giorni sulla vulnerabilità PAN-OS. Il vostro CAB si riunisce settimanalmente. I conti non tornano, e nessun livello di competenza tecnica colma un gap di governance.
Il percorso d'emergenza deve esistere prima dell'emergenza. Persone nominate. Le azioni precise che possono intraprendere senza chiedere autorizzazione. Come le registrano. Chi informano in seguito. Lo si scrive in un tranquillo martedì, lo si prova una volta, e sarà disponibile il sabato quando serve.
eMudhra è stato il vero banco di prova
PAN-OS e PHP hanno patch disponibili, o le avranno. eMudhra non ha nulla da installare.
I browser hanno reagito rapidamente. Chrome e Firefox hanno bloccato gli otto intermediari il 17 ottobre, Microsoft e Apple hanno seguito nel giro di pochi giorni. eMudhra li ha revocati, e il 22 ottobre ha annunciato di abbandonare del tutto il business dei certificati TLS.
I vostri browser sono a posto. I vostri container, VM, appliance, Java keystore e ogni ambiente Python che porta la propria copia di certifi sono un discorso diverso. Node.js ha dovuto includere la sfiducia nel proprio security release. Go ha rilasciato nuove versioni per gestirlo.
La domanda a cui la vostra organizzazione ha effettivamente dovuto rispondere era questa: dove accordiamo fiducia alle autorità di certificazione, e chi può modificarla ovunque in una volta sola? La maggior parte non riesce a rispondere alla prima metà. È un problema di inventario, e l'inventario smette di essere un'incombenza IT nel momento in cui un regolatore lo richiede. Ai sensi di NIS2, l'organo di gestione approva le misure di gestione del rischio e ne risponde.
L'ordine delle decisioni
Prima del punteggio, ponete quattro domande.
- È in corso di sfruttamento? KEV, l'advisory del fornitore, la vostra threat intel. Se sì, salta la coda indipendentemente dal punteggio.
- È esposta? Esposta a Internet batte interna. Le interfacce di gestione battono quasi tutto il resto.
- Cosa tocca? Identità, fiducia, i sistemi che custodiscono i vostri dati, i sistemi da cui tutti gli altri dipendono.
- Qual è il punteggio? Usatelo per classificare ciò che rimane.
Bruxelles è arrivata alla stessa conclusione. Dall'11 settembre, i produttori soggetti al Cyber Resilience Act devono segnalare le vulnerabilità attivamente sfruttate. Lo sfruttamento è il trigger, e il punteggio non compare da nessuna parte.
Suggerimento: Riscrivete i vostri SLA attorno a queste domande. Sfruttata ed esposta: ore. Sfruttata o esposta: giorni. Nessuna delle due: il vostro ciclo ordinario, con il punteggio a fare da criterio di spareggio. Poi consegnate al vostro auditor una policy che potete effettivamente rispettare.
Cosa deve sentirsi dire il vostro comitato esecutivo questa settimana
Tre frasi.
Se siamo esposti a qualcosa di tutto questo, sì o no. Cosa abbiamo fatto, e quando. Cosa abbiamo scelto di rimandare per ora, e chi ha validato quella decisione.
Un conteggio di CVE non fornisce loro nulla su cui possano agire. La terza frase è quella che conta. Ai sensi dell'Articolo 20 di NIS2, l'organo di gestione approva le misure di gestione del rischio in materia di cybersecurity, ne supervisiona l'attuazione e può essere ritenuto responsabile in caso di fallimenti. Se non viene mai informato di ciò che è stato differito, non può assumersene la responsabilità, e avrete silenziosamente preso una decisione che spettava a loro.
Il backlog è una decisione. Firmatela.
Non risolverete tutto. Non lo fate da anni. Il volume rende semplicemente impossibile continuare a fingere.
Ciò che è in attesa è stato accettato, che qualcuno l'abbia scritto o meno. Quindi scrivetelo. Un responsabile nominato, il motivo, il controllo compensativo se presente, e una data per rivederlo. Una vulnerabilità differita con una firma è una decisione di rischio. Senza, è un'omissione che dovrete spiegare in seguito.
Considerazione finale
Settimane come questa continueranno ad arrivare. La scoperta delle vulnerabilità accelera più velocemente di quanto chiunque possa applicare patch, e ogni sistema di scoring continuerà a produrre liste in cui tutto sembra urgente.
Le organizzazioni che hanno affrontato bene questa settimana avevano una cosa in comune. Sapevano chi era autorizzato a decidere, in quale ordine, e come comunicare ai livelli superiori ciò che era rimasto sul tavolo. I loro scanner erano gli stessi di tutti gli altri.
Questo è lavoro di leadership. Nessun altro in azienda lo farà al vostro posto.
Queste sono le competenze alla base di tre dei nostri corsi. Certified CISO by PECB per le responsabilità decisionali e il dialogo con il comitato esecutivo. NIS 2 Directive Lead Implementer per l'Articolo 20 e ciò di cui il vostro organo di gestione deve ora rispondere. ISO 27001 Lead Implementer per una policy sulle vulnerabilità che potete effettivamente rispettare, e un'accettazione del rischio che regge all'audit.
Scegliete quello che corrisponde al gap che questa settimana ha messo in luce.