Come posso dimostrare OpenSSH redhat / centos patchlevel agli auditor?

Question

Come posso dimostrare OpenSSH redhat / centos patchlevel agli auditor?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

3

Un problema comune è che la sicurezza dei backports Redhat risolve lasciando OpenSSH con una versione rpm vecchia, ma non vulnerabile e la stringa di versione ssh su Redhat e CentOS. Questo imbroglia auditor.

Apparentemente, la soluzione è di fornire la Redhat SA all'auditor. Ma quali? Come esattamente faccio questo? Devo compilare una SA per ogni vulnerabilità?

(Quello che sto cercando al momento è l'aggiornamento al rpm elencato più recentemente in una SA, quindi solo la SA più recente dovrebbe dimostrare la più recente correzione del pacchetto.)

audit centos

posta DigitalRoss 21.04.2016 - 00:49

fonte

3 risposte

Leggi altre domande sui tag audit centos

Gli utenti dovrebbero aggiornare il proprio avatar usando l'URL invece di caricare un file? Crittografia lato client con chiave pubblica

score 1 · Answer 1

Fornire la SA e la versione dovrebbe essere sufficiente poiché la patch SSH è stata implementata. Se hanno problemi con questo, dovrebbero prenderlo con il controllo della versione di Redhat.

Dopo tutto se puoi dimostrare che l'attacco non funzionerà perché è stato riparato, il numero di versione non significa nulla. È già aggiornato indipendentemente da ciò che dice la versione.

score 0 · Answer 2

Quello che devi risolvere è il problema, e se il problema è stato risolto o se esiste un controllo compensativo per affrontare la vulnerabilità. Se non esiste una patch per una vulnerabilità, si sarebbe fuori di conformità, tuttavia se si dispone di regole che illustrano che è stato bloccato tutto, ma consentito solo fonti attendibili (fonti controllate) ora si dispone di un controllo di compensazione. Quindi, mentre stai facendo affidamento su Redhat per emettere un aggiornamento, a seconda di quale sia il problema con SSH, potresti essere in grado di creare regole in hosts.deny o regole del firewall per minimizzare il rischio. Tutto dipende dal tuo approccio. Non c'è una risposta definitiva. Fornire alle società di Redhat di fare poco da quando potrebbero venire da qualsiasi luogo (qualsiasi sistema, anche una copia pastebin). Mostrare cosa hai fatto per minimizzare il rischio / l'impatto dovrebbe essere sufficiente per gli auditor nel caso in cui una patch non sia disponibile.

score 0 · Answer 3

Redhat fornisce il CVE necessario per il pacchetto di informazioni sulla versione.

Per qualsiasi CVE fornito la versione del pacchetto potrebbe (e come ho riscontrato nella mia esperienza personale) potrebbe non corrispondere alla versione del pacchetto originale. Esempio di origine dallo sviluppatore per il pacchetto ABC è v0.0.3 che indirizza CVE 1.1 dove RedHats RPM di ABC è in v0.0.2x per la release 6 e in v0.0.3 per la release 7.

Il vero problema con un audit di questo tipo richiederebbe un po 'di lavoro in più per garantire la conformità a causa della necessità di cross-refencing della versione RPM con il rilascio dei produttori e le note di sicurezza.

Il metodo più semplice IMHO sarebbe quello di controllare il sistema RPMS per il pacchetto interessato, fare un riferimento incrociato al codice del pacchetto originale che indirizza il CVE e accertarsi che esista nel sistema RPMS.