Questa guida dettagliata spiega perché i team di sicurezza sono sopraffatti dalle vulnerabilità, il pericolo che si nasconde dietro la doppia segnalazione di vulnerabilità e come mitigare tali vulnerabilità utilizzando strumenti di patching attivi come KernelCare.
Sappiamo che la minaccia alla sicurezza informatica sta crescendo, con una crescita corrispondente negli sforzi per cercare di mitigare la minaccia e i costi associati. Ma l'evidenza suggerisce che la mitigazione non sta procedendo abbastanza rapidamente.
Secondo un'analisi congiunta eseguita da McAfee e il Centro di studi strategici e internazionali , nel 2020 il costo globale della criminalità informatica aumenterà oltre $ 1 trilione segnare per la prima volta:un massiccio aumento del 50% rispetto al totale del 2018. Questo è un tasso di cambiamento che supera chiaramente qualsiasi metrica comparabile come la crescita del PIL o la crescita della spesa IT.
La consapevolezza non è il problema:dopotutto, le aziende stanno spendendo ingenti somme per difendersi dalle minacce informatiche.
Invece, in questo articolo, sosteniamo che gli attori della sicurezza informatica sono essenzialmente sopraffatti dalle sfide che devono affrontare. Indichiamo come prova evidente un recente verificarsi della doppia segnalazione di vulnerabilità note.
Continua a leggere per scoprire perché i team di sicurezza sono sopraffatti dalle vulnerabilità, in che modo influiscono sulle patch e cosa possono fare i team per applicare patch in modo coerente di fronte a un assalto incessante di vulnerabilità ed exploit.
Ancora un'altra vulnerabilità?
Nella seconda metà dello scorso anno è stata scoperta e segnalata una vulnerabilità del kernel Linux. Gli è stata assegnata una C comune V ulnerabilità e E numero xpossures (CVE), CVE-2020-29369 e la vulnerabilità è stata corretta come previsto. Finora niente di insolito.
Non c'era niente oltre l'ordinario nemmeno nella vulnerabilità stessa. In qualsiasi sistema operativo, il kernel deve gestire con attenzione la memoria, assegnando (mappando) lo spazio di memoria quando un'applicazione ne ha bisogno e rimuovendo correttamente le allocazioni e riassegnando la memoria libera quando un'applicazione non ne ha più bisogno.
Tuttavia, questo processo di gestione dello spazio di memoria può essere soggetto a problemi. Se codificati senza le cure necessarie, i processi di gestione della memoria del kernel possono offrire un'opportunità ai criminali informatici. Nel caso di CVE-2020-29369, il problema si è verificato nella funzione mmap utilizzata per la mappatura della memoria in Linux.
La natura della vulnerabilità significava che due applicazioni distinte potevano richiedere l'accesso allo stesso spazio di memoria, provocando un arresto anomalo del kernel.
Se un utente malintenzionato giocasse correttamente le proprie carte, in altre parole, progettasse un exploit, l'attaccante sarebbe in grado di acquisire dati che altrimenti sarebbero protetti dal kernel. Potrebbero essere dati completamente innocui o qualcosa di più prezioso, come dati personali preziosi o password.
Una storia di due segnalazioni di vulnerabilità
Quindi possiamo vedere che una tipica vulnerabilità è stata segnalata e accettata secondo le normali procedure. Ma dopo è successo qualcosa di sconcertante.
Solo pochi mesi dopo, è stata segnalata esattamente la stessa vulnerabilità. Anche in questo caso, è stato assegnato un numero CVE, questa volta CVE-2020-20200 . Tuttavia, si è presto scoperto che il nuovo avviso di vulnerabilità era un duplicato di un'altra vulnerabilità:CVE-2020-29369.
I ricercatori che hanno "trovato" la vulnerabilità una seconda volta per un motivo o per l'altro non sono riusciti a trovare la prima istanza della vulnerabilità prima di richiedere un'altra prenotazione CVE per ciò che avevano scoperto. Una delle intenzioni primarie dei database CVE è evitare la doppia segnalazione, ma in questo caso particolare è stato comunque richiesto un altro CVE.
Questo caso di ciò che viene chiamato "doppia segnalazione" non è la prima o l'unica istanza di una vulnerabilità segnalata due volte. Peggio ancora, quando le indagini su una vulnerabilità arrivano al punto in cui è stato assegnato un CVE, la vulnerabilità sarà già stata esaminata da numerosi esperti di sicurezza altamente qualificati.
Anche i ricercatori di sicurezza possono confondere le cose
In questo esempio di doppia segnalazione è chiaro che i ricercatori di sicurezza avrebbero dovuto essere a conoscenza della vulnerabilità esistente o avrebbero dovuto trovare il CVE esistente se avessero studiato a sufficienza la "nuova" vulnerabilità prima di richiedere un nuovo numero CVE.
È un pensiero preoccupante. Questa vulnerabilità della mappatura della memoria è al centro del kernel Linux, ma i ricercatori di sicurezza apparentemente non ne erano a conoscenza, da qui il doppio elenco. Peggio ancora, non è che ogni quotazione fosse distante un decennio o addirittura anni:le singole inserzioni con la stessa vulnerabilità sono state fatte a pochi mesi di distanza, una ad agosto 2020 e una a novembre 2020.
I ricercatori della sicurezza sono negligenti? No. I ricercatori sulla sicurezza sono semplicemente completamente sopraffatti dall'enorme volume di sfide alla sicurezza informatica. Ecco perché, in questo esempio, gli esperti di sicurezza del kernel Linux hanno perso un rapporto esistente di una vulnerabilità potenzialmente critica.
Il pericolo nascosto dietro la doppia segnalazione di vulnerabilità
Prove evidenti che la minaccia alla sicurezza informatica è in aumento, combinate con esempi in cui anche gli esperti di sicurezza sbagliano, suggeriscono che la doppia segnalazione ha implicazioni maggiori di quanto sembri avere a prima vista.
Non suggerisce che gli esperti di sicurezza di Linux siano inclini a errori e sviste. Suggerisce semplicemente che il lavoro di gestione delle vulnerabilità della sicurezza è diventato così incredibilmente difficile che persino gli esperti faticano a tenere il passo.
Prendi in considerazione per un momento un tipico team tecnologico interno che ha un mandato completo:sì, inclusa la sicurezza, ma copre anche la manutenzione, le operazioni e un numero infinito di altre responsabilità.
Anche laddove i team aziendali dispongono di esperti di sicurezza dedicati, è probabile che le competenze debbano essere applicate a una vasta gamma di minacce e strumenti tecnologici. Sarebbe estremamente raro anche per una grande azienda impiegare un esperto di sicurezza del kernel Linux. E anche se lo facessero, come abbiamo visto, questi esperti di sicurezza possono sbagliare.
I team IT devono affrontare tempi difficili
I team in loco gestiranno sempre le vulnerabilità della sicurezza in una certa misura. Rispondendo alle notizie di importanti exploit, ad esempio, e applicando le patch di conseguenza. Anche gli avvisi dei fornitori possono guidare l'azione e la maggior parte dei buoni reparti IT disporrà di un qualche tipo di regime di patch che garantisce che le patch vengano applicate a intervalli prestabiliti.
Ma come possono realisticamente i team IT tenere il passo con una pila crescente di CVE che interessano le distribuzioni Linux su tutta la linea, che arrivano su base giornaliera. Ad esempio, un regime di patch trimestrale fornisce davvero una sicurezza sufficiente? E sì, l'applicazione delle patch è importante , ma dovrebbe dominare l'attività a scapito di tutto il resto, cosa che può succedere facilmente dato il volume delle patch?
È facile vedere che i team IT avranno difficoltà a tenere il passo con l'elenco sempre crescente di vulnerabilità.
Rendi corretto il tuo regime di patch
La formalizzazione del regime di patching è il primo passo per cercare di far fronte alla montagna di CVE. Le patch ad hoc basate su notizie allarmanti non sono la strada da percorrere - semplicemente ci sono troppe vulnerabilità e relativamente poche diventano ampiamente conosciute - lasciando innumerevoli vulnerabilità nascoste e exploit associati che rappresentano un pericolo.
Tuttavia, uno dei passaggi chiave nella creazione di un regime di patch è l'assegnazione di priorità alle patch. Le vulnerabilità critiche e ampiamente conosciute devono essere corrette rapidamente, senza ritardi e sacrificando la disponibilità se necessario. È possibile programmare patch per vulnerabilità a rischio medio e basso per adattarsi ai carichi di lavoro dei team tecnici o per evitare problemi con la disponibilità.
Un altro passaggio fondamentale è creare un inventario sufficientemente completo dell'hardware e del software che richiede l'applicazione di patch. Alcuni obiettivi per l'applicazione di patch saranno immediatamente evidenti, ma altri possono essere facilmente persi.
Nella creazione del tuo inventario potresti anche identificare un certo ambito di standardizzazione, in altre parole, aggiornare il software alla stessa versione o consolidare i fornitori per semplificare la gestione delle patch.
Infine, vale la pena codificare il tuo regime di patching in una politica di patching formale. L'applicazione di patch è difficile da eseguire in modo coerente e tutto ciò che serve è un singolo errore per aprire la porta al disastro. Un regime di patch codificato può aiutare il tuo team a rimanere in pista con le patch, anno dopo anno.
Il compromesso con le patch
Con qualsiasi regime di patch di solito c'è un compromesso da fare tra disponibilità e sicurezza. Sì, puoi applicare le patch in modo estremamente sicuro, applicando le patch alla stessa velocità con cui vengono rilasciate. Ma l'applicazione di patch ha inevitabilmente un impatto sulla disponibilità poiché l'applicazione di patch richiede spesso il riavvio del server.
In effetti, alcune aziende possono avere requisiti aziendali specifici che impediscono la rimozione di servizi o server per applicare patch anche se viene visualizzato un CVE critico, il che può lasciare i servizi vulnerabili a un nuovo exploit.
Anche quando è possibile portare i server offline per la manutenzione, i servizi vengono degradati e, di conseguenza, l'esperienza dell'utente finale è degradata. Pensa a un rivenditore online con migliaia di clienti online che improvvisamente mettono offline metà dei suoi server per la manutenzione, ad esempio.
Poi c'è anche lo scarico dei team tecnici che inevitabilmente stanno sacrificando il tempo speso in altre attività per dedicare tempo all'applicazione delle patch. I team di sicurezza potrebbero semplicemente essere completamente sopraffatti dall'onere delle patch. C'è un'alternativa, tuttavia.
Considera gli strumenti di patching automatizzati
Abbiamo identificato due problemi chiave alla base dei regimi di patch standard:il tempo e l'impegno richiesti dall'applicazione delle patch e l'interruzione associata all'applicazione delle patch. Una soluzione che vale la pena considerare è l'applicazione di patch automatizzata, e ancor di più se si tratta di applicazione di patch automatizzata senza riavvio che applica le patch senza richiedere il riavvio del server.
Gli strumenti di applicazione automatica delle patch monitorano continuamente le versioni delle patch e le applicano automaticamente senza alcun intervento. Elimina la necessità di dedicare manodopera alle flotte di server di patch:l'applicazione di patch avviene semplicemente in background. Con l'applicazione di patch automatizzata, i team tecnici non sono mai sopraffatti da innumerevoli attività di patch, né i team tecnici devono cercare di prevedere quali patch sono più importanti. Invece, tutte le patch vengono applicate in modo uniforme, uniforme e coerente.
Alcuni strumenti automatici di patch come KernelCare può applicare patch al volo - patching live, mentre una macchina è in esecuzione e senza richiedere un riavvio. L'applicazione di patch in tempo reale limita l'interruzione poiché le macchine non vengono messe offline per elaborare una patch. Quando c'è un rischio minimo di interruzione, è probabile che la coerenza delle patch migliori.
In altre parole, il giusto strumento di patch automatizzato può risolvere due dei maggiori problemi che le aziende devono affrontare con l'applicazione di patch:sforzo richiesto e interruzione.
L'applicazione delle patch è fondamentale, indipendentemente da come scegli di farlo
Qualunque cosa la tua azienda faccia per coprire se stessa per le patch o comunque organizzi il tuo regime di patch, l'unica certezza è che le patch sono fondamentali. Le patch devono essere applicate, ma c'è una decisione da prendere su quanto spesso applicare le patch e come applicare le patch.
Data la dimensione della minaccia alla sicurezza informatica, c'è un forte argomento per l'applicazione di patch automatizzata. Sia i team tecnici che i ricercatori della sicurezza sono sempre più sopraffatti e l'applicazione di patch automatizzata supera il problema delle risorse e della disponibilità.
È sempre un'opzione applicare semplicemente più manodopera alla sfida di patching e per alcuni carichi di lavoro potrebbe essere l'unica opzione. Tuttavia, nella maggior parte dei casi, l'applicazione di patch automatizzata e senza riavvio può offrire una grande vittoria contro le enormi sfide di sicurezza informatica di oggi.
Lettura consigliata:
- Applica GRATUITAMENTE patch al kernel Linux Raspberry Pi con KernelCare!
- Rileva le librerie condivise obsolete in memoria con UChecker