Esiste un modo pratico per identificare le vulnerabilità di sicurezza che sono state pubblicate in seguito a una politica di divulgazione completa?

Question

Esiste un modo pratico per identificare le vulnerabilità di sicurezza che sono state pubblicate in seguito a una politica di divulgazione completa?

#1 da (4 voti)
#2 da (1 voti)

1

Sto conducendo uno studio sulle diverse politiche di divulgazione delle vulnerabilità nel tentativo di determinare quanto tempo impiega un determinato fornitore a pubblicare una correzione / patch, a seconda di come è stata divulgata una determinata vulnerabilità. Il problema è che ho difficoltà a identificare le vulnerabilità "completamente divulgate" (il venditore non era stato informato prima della divulgazione pubblica). Sembra che la divulgazione responsabile sia la norma al giorno d'oggi, al punto che quando un ricercatore della sicurezza non informa il venditore e rivela completamente una vulnerabilità, la gente impazzisce per questo (questo tweet e tutti gli articoli che seguono). Nota che non sono un sostenitore di nessuna delle due politiche, sto semplicemente conducendo ricerche il più obiettivamente possibile.

Qualcuno sa se è possibile recuperare tutte le vulnerabilità che sono state pubblicate in seguito a una politica di divulgazione completa? Forse qualcuno là fuori ha fatto questo lavoro apparentemente noioso ed è disposto a condividerlo :) O c'è un sito web / strumento che non so che fa proprio questo.

In caso contrario, suppongo che dovrei esaminare ogni voce di vulnerabilità (per un determinato fornitore, ovviamente), analizzare la tempistica di divulgazione (se presente), scoprire quando è stata emessa la patch e se divulgazione e patch di vulnerabilità il rilascio risulta essere lo stesso giorno - > divulgazione responsabile e se la versione della patch è in un secondo momento - > completa divulgazione (o il venditore ha superato la scadenza di 45 giorni dal CERT, ad esempio). Richiede tempo? Decisamente. Realistico? Probabilmente no. Ma i risultati sarebbero accurati secondo te?

Grazie!

vulnerability disclosure zero-day cve vulnerability-markets

posta AleVe 27.06.2016 - 19:42

fonte

2 risposte

Leggi altre domande sui tag vulnerability disclosure zero-day cve vulnerability-markets

Email di phishing inusuale Come funzionano le chiavi SSH? [duplicare]

score 4 · Answer 1

Uno dei metodi che puoi usare per creare una linea di base sarebbe andare su siti come PacketStorm trovare dicono le ultime 50 vulnerabilità / exploit divulgate , quindi scoprire se hanno o meno CVE emessi su Mitra . Una linea di base ti darà proprio questo, una media di base. Ci sono alcune cose da tenere in considerazione:

Non tutti gli exploit / vulnerabilità vengono sempre comunicati dai ricercatori o venditori
Non tutte le vulnerabilità / exploit finiscono con un CVE

Riguardo al n. 1, mi sono stati rilasciati CVE per le vulnerabilità che, sebbene il fornitore abbia corretto le patch, non ho visto la necessità di iniziare a scrivere rivelazioni sulle vulnerabilità da inviare a divulgazione completa, bugtraq o altri siti simili. Questo di solito è per alcune ragioni 1) Sono troppo occupato per essere disturbato 2) non c'è correzione e quindi non c'è bisogno di aumentare il livello degli attacchi (se qualcun altro lo trova, così sia) 3) i venditori possono essere 'duri ' avere a che fare con. Una volta ho segnalato una vulnerabilità a un produttore di apparecchiature di rete e ci sono voluti 2 anni per risolverlo. Questo consisteva in settimane alla fine di me che lasciavano passare il tempo libero a spiegare le cose, a ripetere i test e così via.

Come per gli altri commenti: "Patch per lo stesso giorno" è inesistente. Qualunque azienda intenzionata a produrre un cerotto in un giorno lo farebbe in modo avventato. I programmatori devono garantire che le applicazioni legacy possano ancora funzionare e che le cose non vengano interrotte con una patch / aggiornamento / correzione. Questo è un processo che richiede molto tempo e qualsiasi casa di sviluppo di applicazioni ha processi e politiche che seguono rigorosi test / correzioni. Per quanto riguarda la divulgazione del '45 giorno ', questa non è una pietra miliare:

Q: Will all vulnerabilities be disclosed within 45 days? A: No. There may often be circumstances that will cause us to adjust our publication schedule. Threats that are especially serious or for which we have evidence of exploitation will likely cause us to shorten our release schedule. Threats that require "hard" changes (changes to standards, changes to core operating system components) will cause us to extend our publication schedule. We may not publish every vulnerability that is reported to us. http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm?

Buona fortuna con la tua ricerca, nella migliore delle ipotesi posso vederti solo con una linea di base. Ci sono troppe variabili e l'output potrebbe essere contaminato. Ad esempio: Microsoft, Cisco e altri grandi nomi possono essere considerati come "stellari" o "poco attraenti", ma a cosa li stai confrontando? myjoomlasoftware.v1 o myhomebackedGitHubProject2.0? Open source, closed source, grande fornitore, piccolo venditore, petproject, githhub? Queste sono cose da tenere in considerazione, ognuna delle quali può distorcere i tuoi dati immensamente.

score 1 · Answer 2

Onestamente dipende davvero dalla compagnia. Ogni azienda gestisce le proprie vulnerabilità in modo diverso, anche alcuni ricercatori che seguono il processo ne vengono fregati, proprio come questo ragazzo che ha presentato un bug per Instagram .

Per coloro che sono entrati attraverso il programma bug bounty (se ne hanno uno), pubblicheranno generalmente le informazioni sul loro sito o e-mail alla catena di utenti iscritti al programma. Altrimenti dovrai seguire rigorosamente molte aziende per ottenere queste informazioni.

Puoi anche provare a inviare un'email ai loro team per vedere se ti forniranno un elenco come ricercatore, a seconda del livello di informazioni richiesto, alcuni team lo faranno se è nella loro cultura, ma molti vedranno questo come Social Engineering, e può rifiutare la tua richiesta.

Vorrei anche dare un'occhiata a BugCrowd , che fornisce un elenco di aziende con programmi di bug bug e i collegamenti direttamente alle pagine appropriate.

Se qualcuno ha fatto questo lavoro, sarebbe fantastico, ma ci sono molte informazioni da considerare così buone!