Come stimare il costo della vulnerabilità di un'applicazione?

Il costo non deriva dalla vulnerabilità ma dal rischio . Vale a dire:

• Una vulnerabilità è quella che può essere potenzialmente sfruttata per mettere a rischio le tue risorse informative (ad esempio un buffer overflow).
• Una minaccia è un elemento di contesto che tenterà di indagare o danneggiare le tue risorse informative (ad esempio un gruppo esistente di aggressori che trarrebbero vantaggio da tali azioni in qualche modo).
• Un rischio è quando una minaccia incontra una vulnerabilità, e vanno d'accordo, si sposano e hanno una prole.

Il costo è applicato a qualsiasi cosa tu faccia con il rischio. Ad esempio, il costo di ignorare il rischio è, approssimativamente, il costo del danno derivante dall'attualizzazione del rischio. D'altra parte, il costo di fissare un buffer overflow è puramente di sviluppo e amp; costo di implementazione, dal momento che rimuove la vulnerabilità. L'arte della gestione del rischio consiste nel trovare il giusto equilibrio tra azioni correttive e accettazione (il "giusto equilibrio" è relativo agli obiettivi di gestione del rischio, che dipendono dall'organizzazione).

Bottom-line: il costo riguarda ciò che fai e dipende da molti elementi contestuali, in particolare da minacce. Non è possibile stimare alcuna nozione significativa di costo senza tenere conto del contesto. Non è possibile allegare un costo a una vulnerabilità o persino a un rischio ; il costo è una proprietà di un insieme di azioni (poiché "fare nulla" è un tale insieme, alcuni costi sono sempre sostenuti).

Puntare un costo su un exploit di solito coinvolgerà (molti) incontri con utenti business e alla fine è solo un'ipotesi plausibile. Potresti essere in grado di stimare il costo di un'interruzione dell'attività di 4 ore a causa di un attacco denial of service, tuttavia per qualcosa come un defacement del sito web dovresti avere una chat con la direzione e / o le persone delle pubbliche relazioni per determinare il danno arrecato al reputazione e il costo di fissarlo. Un'altra cosa da guardare non è solo il costo dell'attacco, ma la frequenza. Se è un attacco facile, potrebbe accadere ogni giorno o ogni ora, quindi dovresti moltiplicare il costo dell'attacco per la frequenza per ottenere un costo reale.

Non includerei il costo di rilevamento di una vulnerabilità come costo di una violazione. Dovresti cercare attivamente i buchi di sicurezza, indipendentemente dal fatto che dovrebbero trovarsi in un bucket diverso come IT o uno specifico per Information Security

Dipende da chi sta facendo la stima.

Se sei il produttore del software, il costo è il costo per correggere la vulnerabilità. Se ti stai sforzando per una pratica di gestione del rischio matura, aggiungi il costo degli affari persi se la vulnerabilità danneggerà le tue vendite. Ignora i costi nel paragrafo successivo, a meno che non ci sia un regime assicurativo o regolamentare che ti assegnerà tali costi.

Se sei il consumatore, allora una probabilità semplice e semplicistica x l'impatto può essere adeguato (sebbene grossolano e poco elegante, ma adeguato). Calcola il costo della violazione: cosa accadrebbe se la vulnerabilità venisse sfruttata dall'avversario (questo sarà un intervallo, a seconda del caso peggiore e del caso più probabile). Quindi la probabilità che l'avversario sia in grado di sfruttare la vulnerabilità. Ad esempio, anche la peggiore vulnerabilità ha un impatto limitato se si verifica solo su un server airgapped. Moltiplicare il valore in dollari x probabilità per calcolare un intervallo di esposizione al rischio.

Se ti stai sforzando per una prassi di gestione del rischio matura, dovresti avere (o raccogliere attivamente) dati per supportare l'analisi nel paragrafo precedente.

Se ti trovi nella comunità della salute o della sicurezza, dovresti già disporre di metodi consolidati per calcolarlo.