Dove verificare se un OS / servizio specifico è vulnerabile nonostante sia stato riparato, a causa di una decisione del fornitore?

3

Ho bisogno di discutere su come mitigare il rischio di servizi che sono vulnerabili nonostante vengano riparati (in genere perché non sono più gestiti dal venditore, o perché il venditore non vuole rilasciare una patch, o per altri motivi fuori dal controllo ).

  • So come verificare se una macchina è vulnerabile (tramite un sistema di inventario di patch, uno scanner di vulnerabilità, ...)
  • So dove cercare i dettagli relativi alle vulnerabilità (OVAL, CVE, NVD, ...)

Quello che non so è dove controllare se un determinato sistema operativo, servizio o applicazione sarà vulnerabile nonostante sia stato applicato alle patch e indurito, a causa della decisione del fornitore .

Un esempio potrebbe essere Windows Server 2003 che non è più gestito da Microsoft e potrebbe essere vulnerabile alle vulnerabilità a livello di Windows rilevate dopo EOS. Avendo questa conoscenza, è più facile dare la priorità alla contingenza al fine di mitigare il rischio.

C'è una risorsa disponibile?

    
posta WoJ 22.07.2015 - 12:34
fonte

2 risposte

0

Dipende dal venditore e può fare affidamento sull'inferenza. Questo è il motivo per cui utilizziamo gli scanner di vulnerabilità e perché gli scanner di vulnerabilità sbagliano dal presupposto che la colpevolezza abbia fornito prove poco chiare.

Venditore

Almeno un fornitore, Red Hat, mantiene un database di mappatura della vulnerabilità-a-CVE , dove elencano tutti CVE che si applicano al software nella loro distribuzione. Le pagine di dettaglio descrivono quale sia lo stato del loro software rispetto a tale vulnerabilità:

  • Non vulnerabile nella configurazione distribuita da RedHat (vedi CVE-2015-0202 )
  • Indirizzato da Errata di Red Hat Security (RHSA) (vedi CVE-2015-0192 )
  • Non considerato sufficientemente significativo da applicare patch a Red Hat (vedere CVE-2014-2532 per RHEL 5)

Quindi, se stai eseguendo Red Hat, sei bravo. Prendi i CVE di cui sei preoccupato e puoi cercarli e vedere cosa hanno fatto. Tuttavia, la maggior parte dei venditori non è organizzata. (Vedi anche Ciclo di vita di una vulnerabilità legata alla sicurezza ) .

Alcuni venditori hanno anche l'abitudine di rilasciare determinate correzioni solo per pagare i clienti di supporto, a volte anche solo su richiesta specifica. Puoi immaginare come questo complica questa ricerca.

Inference

Poiché MITER cerca di rintracciare gli annunci dei venditori relativi ai CVE, potrebbe essere possibile determinare quali problemi un fornitore ha affrontato osservando i riferimenti "Fonte esterna" all'interno di un CVE. Ad esempio, leggendo i dettagli per CVE-2015-0202 , abbiamo può vedere che OpenSuSE e Mandriva hanno collegamenti. Il collegamento OpenSuSE descrive la versione aggiornata dell'aggiornamento (e il collegamento Mandriva è rotto). Red Hat non è collegato qui; come abbiamo visto sopra, non sono vulnerabili, quindi l'assenza da questo elenco non è una prova di vulnerabilità.

MITER mantiene anche CVE Reference Key / Maps . Ad esempio, il Map for Source MS , fornisce una mappa molto accurata e organizzata di CVE alle patch di Microsoft. Ma, come con tutto il resto,

Note that the list of references may not be complete.

Scanner per le vulnerabilità

Affidarsi alle persone per mantenere i database aggiornati e pubblicati è, dobbiamo farlo, fallibile. Ecco perché utilizziamo gli scanner di vulnerabilità per verificare. Gli scanner di vulnerabilità sono anche fallibili - in particolare, i test eliminati dalle informazioni limitate (come gli annunci sulla versione del banner di servizio) spesso falliscono. Diciamo che OpenSSH-2.3.4 è vulnerabile a CVE-2002-1234, che è patchato in OpenSSH-3.4.5. Red Hat può prendere la patch di sicurezza specifica per tale vulnerabilità e backport, creando OpenSSH-2.3.4p2, che si annuncia ancora come OpenSSH-2.3.4 nel banner di servizio. Poiché lo scanner sta eliminando la versione e non sta effettivamente esercitando il bug per dimostrare che è lì, considererà il sistema vulnerabile.

Quando lo scanner fa ciò, dobbiamo cercare il problema con tutti gli elementi trovati sopra e dimostrare che non è realmente vulnerabile.

Riepilogo

Per ovvi motivi, i venditori non forniscono un elenco ordinato di cose che hanno scelto di non applicare. Onestamente, se gliene importa abbastanza da rintracciarlo, probabilmente si preoccuperebbero abbastanza anche di risolvere i problemi. Ma, di per sé, tutto ciò che una tale lista farebbe è renderli esplicitamente negativi, quindi non c'è molta motivazione a farlo.

Possiamo accontentarci di ciò che forniscono e possiamo dedurre le cose quando effettuiamo ricerche e non siamo in grado di trovare la prova della disponibilità delle patch. Queste non sono soluzioni esatte. Detto questo, ricordo la vita prima che iniziasse il database CVE, e stiamo molto meglio di prima.

    
risposta data 22.07.2015 - 14:53
fonte
0

Questo è esattamente ciò che fanno gli scanner di vulnerabilità. Semplicemente non sono fantastici (nessuno dei quali abbia mai visto rilevare TUTTI i software non supportati, e dubito che lo faranno presto!).

Generalmente tutti i venditori hanno il proprio modo di divulgare queste informazioni, se lo fanno affatto, il che è un grosso problema per i proprietari di risorse e gli esperti di sicurezza. Per le stesse vulnerabilità, trovo che CVE sia una grande risorsa (per esempio attraverso il sito Web di NVD) ma non copre il supporto. Non sono a conoscenza di un repository centrale per queste informazioni.

il dettagli del CVE è un'ottima risorsa per la ricerca di numeri di versione specifici per vulnerabilità note. Tuttavia in questo contesto "non supportato" non è uno di questi.

Un esempio che posso prendere in considerazione in merito a "decisione del fornitore" è CVE-2015-0008 / MS15-011 che rimane non aggiornato su Server 2003 anche se era supportato al momento.

    
risposta data 22.07.2015 - 14:41
fonte