Sono interessato a sapere quali minacce rappresenta, se il codice sorgente di una suite di sicurezza è trapelato. Mi è venuto in mente dopo aver letto i seguenti URL:
Quale sarebbe la minaccia se il codice sorgente fosse aggiornato e in che modo si può essere sicuri che durante l'utilizzo di tale prodotto, la sicurezza sia al minimo rischio (confrontando con la situazione in cui non vi sono perdite di codice sorgente) .
Probabilmente esiste un potenziale di minaccia a breve termine, in quanto è possibile garantire che gli hacker scorrano attraverso il codice per trovare punti deboli, tuttavia ci saranno anche un certo numero di cappelli bianchi che fanno lo stesso, così come i team di revisione del codice delle organizzazioni che usano Kaspersky, quindi è probabile che si verifichino problemi, ma il risultato finale sarà probabilmente un codice più sicuro di quello che altrimenti sarebbe stato il caso.
Molti occhi e tutto il resto.
Tuttavia, il rischio relativo è difficile da stimare, perché è altamente probabile che gli autori degli attacchi abbiano già eseguito il reverse engineering e disattivato il codice AV, quindi in questo caso l'aggiunta dei buoni al pool di revisione potrebbe ridurre il rischio verso il basso .
Non è questa la vecchia domanda se l'open source riduce la sicurezza o no? La teoria popolare tra i professionisti della sicurezza, almeno, è che se si sta facendo affidamento sul fatto che il proprio codice non è accessibile per fornire sicurezza, tutto ciò che si ha è la sicurezza dall'oscurità. Questo è il motivo per cui gli unici algoritmi di crittografia considerati affidabili sono quelli in cui il codice è stato aperto e ampiamente analizzato da un gran numero di persone per un certo numero di anni. Non vedo davvero perché il software di sicurezza in questo caso Kapensky dovrebbe essere diverso.
Detto questo ho fatto il seguente punto nel mio post su open source:
Anche la metodologia di valutazione del rischio OWASP ha facilità di rilevazione e facilità di sfruttamento come fattori di vulnerabilità che aumentano il rischio complessivo. Le aziende hanno un sacco di codice mainframe che sono sicuro di avere molte vulnerabilità di sicurezza, ma quando si calcola il punteggio di rischio deve essere inferiore a una vulnerabilità cross-site scripting esistente nell'ultimo CMS open source appena scaricato. Ora puoi considerare che questo è un pugnale che ti cade sopra la testa, è solo questione di tempo prima che qualcuno lo trovi e lo sfrutti (ad esempio Stuxnet e SCADA). Una visione alternativa è che con risorse limitate, la costruzione di controlli di sicurezza approfonditi e la riservatezza del codice sorgente sono una strategia di mitigazione del rischio legittima.
Con ogni probabilità l'effetto sarà minimo in entrambi i modi.
Certamente, se la sicurezza del tuo sistema dipende in modo critico dalla segretezza del codice, allora questo è un problema in sé. Non dimenticare che esistono strumenti per produrre automaticamente il codice sorgente da immagini compilate e ci sono anche persone che possono decompilare il codice macchina in lingue di alto livello il più rapidamente possibile.
Penso che il rischio principale affrontato in tali eventi sia un rischio aziendale: l'azienda percepisce il suo codice sorgente come l'asset che gli conferisce un vantaggio rispetto ai suoi concorrenti, solo che ora i concorrenti hanno pari accesso a quel bene. In secondo luogo, c'è ovviamente un danno alla reputazione dell'azienda: una società di sicurezza che non può nemmeno proteggere i propri processi aziendali?
Sì, è probabile che esistano vulnerabilità che possono essere scoperte più facilmente con l'accesso alla fonte, ma il danno principale è per l'azienda. Come altri hanno indicato, trovare una vulnerabilità è un potere che può essere usato sia per il bene che per il male.
Un punto importante qui ... solo perché il codice sorgente è "trapelato" non significa che sia paragonabile a Free / Open Source. Se fosse effettivamente trapelato (cioè disseminato illegalmente e ancora coperto da brevetti, copyright, NDAs, ecc.), C'è una base giuridica discutibile e al meglio per i bravi ragazzi a controllarla. Secondo me, una volta trapelate, i proprietari / autori dovrebbero almeno legalmente accettare di non perseguire / citare in giudizio chiunque controlli il codice ora pubblico.
Sono uno sysadmin / sviluppatore, che si occupa quasi esclusivamente di open source, e trascorro un po 'del mio tempo a collo alto nel codice che eseguiamo. Per quanto riguarda la domanda Open Source che è stata sollevata qui, sappiamo tutti che gli aggressori sono impegnati nella verifica delle penne e nella decompilazione del software proprietario. Ha senso permettere anche ai bravi ragazzi di dare un'occhiata. Se per nessun altro motivo preferirei avere tutti allertati su una vulnerabilità (in un modo sperabilmente responsabile) piuttosto che far sapere agli aggressori di ciò fino a quando il venditore non deciderà di rivelare.
Leggi altre domande sui tag source-code data-leakage disclosure incident-response