Riferimento all'elenco delle severità del rischio standard del software?

Question

Riferimento all'elenco delle severità del rischio standard del software?

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

1

C'è qualche materiale di riferimento là fuori per la gravità dei risultati della sicurezza del software standard? E.g SQL Injection è severity 1, l'intestazione mancante è severity 4?

Comprendo che la valutazione del rischio dipende da molti fattori e differenze ambientali, ma c'è ancora una guida approssimativa che può essere seguita?

La mia azienda di software riceve regolarmente lamentele da un singolo cliente che effettua test di penetrazione economici ogni volta che prende una patch. Rifiutano di pagare le bollette e portano il software offline finché non affrontiamo i problemi, in quanto la società di test di penetrazione solleva scoperte di tipo informativo come "ad alto rischio". Il rischio più grave che hanno identificato era che un file CSS era visibile alla fonte, ma non avevano alcuna prova da supportare se fosse sfruttabile. La loro giustificazione era che il codice sorgente non dovrebbe essere visibile.

Come posso difenderlo e cercare di portarlo agli interessi dei clienti così come ai nostri che questi Penetration Testers sono dei bugiardi?

risk-management penetration-test

posta Cyassin 09.08.2017 - 03:36

fonte

2 risposte

Leggi altre domande sui tag risk-management penetration-test

File system crittografato in un sistema Linux ospitato Esiste un modo passivo per verificare le implementazioni DKIM (a livello di DNS) senza attivare un evento email effettivo?

score 1 · Answer 1

Stabilisci il tuo livello standard di classificazione del rischio e invita il tuo cliente ad accettarlo.

Inizia valutando il rischio che l'app pone all'organizzazione. Ad esempio, se il sistema gestisce dati regolamentati (PCI, HIPAA, GLBA, PHI, PII, ecc.) O se è rivolto verso l'esterno o se è di importanza critica, definirlo come un sistema ad alto rischio e qualsiasi cosa la penna i tester troveranno una classificazione ad alto rischio che deve essere affrontata immediatamente. Ma se non è un sistema ad alto rischio, solo i risultati dimostrabili e sfruttabili saranno considerati vulnerabilità ad alta gravità che richiedono una riparazione immediata. Forse è possibile identificare ulteriormente una classe di applicazioni a rischio "molto basso" che possono essere esentate da costosi test di penna.

I tuoi clienti hanno solo tanti dollari di sicurezza da spendere. È tua responsabilità aiutarli a spenderli dove hanno le migliori possibilità di produrre risultati significativi.

score 1 · Answer 2

Non conosco alcun framework che tu possa implementare da solo che è da un lato così vasto, che tocca ogni possibile problema di sicurezza che potrebbe emergere in un test di penetrazione ed è attivo l'altra mano così specifica, che fornisce un sistema di punteggio esatto.

I understand risk assessment depends on many factors and environmental differences, but is there still a rough guide that can be followed?

C'è almeno un altro fattore importante da considerare, e questa è la "propensione al rischio" delle organizzazioni. Un rischio specifico è un "Rischio elevato" per un'organizzazione e un "Rischio medio" per un'altra. Se la tua azienda tende a prendere decisioni commerciali ad alto rischio su base regolare, potrebbe accettare rischi che altri non vogliono.

Il tuo esempio dato era un file CSS visibile. Sembra che tu voglia dire: "Ehi, finché non è sfruttabile ora, qual è il danno? Non è un rischio alto!". Il ragionamento alla base della loro giustificazione è (forse): "Potrebbe non essere sfruttabile ora, ma non vogliamo che il codice sorgente sia visibile, quindi gli aggressori non hanno idee su COME sfruttarlo in futuro." (Il che è un ragionamento che sostengo di essere onesto.)

IMHO, ci sono due cose che puoi fare.

Provenendo da un punto di vista metodico, utilizza il Sistema di valutazione delle vulnerabilità comuni (CVSS) e confronta i loro risultati a vulnerabilità nei database di vulnerabilità che sono pubblicamente disponibili, come questo . (Cerca Sec.SE per un sacco di domande su questo argomento.) Questo ti darà un'idea di quanto sia seria una vulnerabilità e ti condurrà anche a una migliore valutazione dei risultati dei test di penetrazione.
Venendo da un punto di vista aziendale, mettiti in contatto con i tester di penetrazione e fai domande. Sfida i loro risultati e scopri quali sono le motivazioni alla base della loro valutazione. Se hai la sensazione che ogni rischio identificato finisca per essere un "Rischio elevato", suggerisci un altro tester di penetrazione al tuo cliente.