Efficacia dei test di sicurezza delle applicazioni interattive

Ogni metodo (DAST vs SAST) ha i suoi punti di forza e di debolezza.

Ad esempio, il metodo DAST è molto più adatto a valutare le vulnerabilità del tipo XSS perché è effettivamente in grado di eseguire "sul lato client" per convalidare se l'esecuzione è effettivamente possibile (piuttosto che una riflessione benigna). SAST in questo caso per la maggior parte è limitato a dimostrare che l'input lo ha reso (o ha un percorso possibile) dalla sorgente al sink e può essere riflesso nell'output, ma in genere non sarebbe in grado di confermare che la reflection può essere eseguita per fornire il carico utile XSS. In questo caso DAST presenta alcuni vantaggi rispetto a SAST.

OTOH, l'individuazione di vulnerabilità come l'inserimento di una password scritta in chiaro nel file di registro di backend risulterebbe quasi impossibile per lo scanner DAST, ma un lavoro gestibile per l'analisi SAST.

Quindi IAST (o talvolta indicato come ibrido) può sfruttare i punti di forza di entrambi i metodi e aiutare a gestire / ridurre le debolezze intrinseche dell'altro. Può anche aiutare a ridurre i tassi di rilevamento dei falsi positivi facendo sì che un metodo confermi l'altro (ad esempio nei test dinamici di SQLI che hanno confermato che l'attacco lo ha effettivamente portato a DB); aiuta a velocizzare i test restringendo la superficie di attacco (es. non c'è bisogno di testare una pagina per SQLI se la pagina non esegue SQL), in realtà scopre una superficie di attacco che può essere nascosta (cioè sotto-applicazione o pagine che non sono collegate e non facilmente individuabile nei ciechi), ecc.

Disclaimer: ero abituato a lavorare e sviluppare uno di questi scanner.

How effective are IAST tools at finding vulnerabilities?

HP WIRT, Acunetix con Acusensor, Contrast Security, Quotium e Appscan Enterprise possono trovare più vulnerabilità quando si trovano nello scenario migliore. Sì, ho usato Contrast Security e WIRT per trovare le vulnerabilità più velocemente che senza le funzionalità del lato SAST (si noti che WIRT fornisce feedback a entrambi gli strumenti in-WebInspect tramite gli hook di SecurityScope e rende Fortify compatibile con l'output del registro di SecurityScope) , ma vorrei (e ho) solo utilizzare le loro capacità quando si rivolgono alle app JEE. Per Acusensor, ottieni risultati ancora meno e solo contro le app PHP. Quotium e Appscan Enterprise non aggiungono necessariamente più valore a .NET, JEE o a qualsiasi altro linguaggio che ho incontrato, ma sicuramente hanno anche le loro nicchie, sotto il set e l'impostazione corretti.

HP WIRT/SecScope vs. JEE: 9/10
Contrast Security vs. JEE: 9.5/10
Acusensor vs. PHP: 6/10
Quotium or Appscan benefits: 7 or 8 out of 10
HP WIRT vs. ASP.NET: 8.5 out of 10

Is there any evidence that these can find more or less than a black box application pen test (DAST) or by source code review (SAST)?

Esiste una prova assolutamente conclusiva di ciò, specialmente se si considerano i limiti di tempo e risorse imposti a qualsiasi data valutazione DAST. Permettetemi di essere un gigante vocale quando si tratta di questo argomento: IAST, sia rigoroso (Contrast, Quotium) o liberamente definito (WIRT / SecScope, et al) sono aiuti enormi quando si configurano i casi di test di fault-injection dopo uno strumento cerebrale ibrido comprensione del codice (che normalmente comporta - almeno - la scansione e la scansione del flusso di esecuzione dell'app).

Nel caso di WIRT / SecScope, sono stato in grado di configurare e trovare vulnerabilità che sicuramente mi saremmo perse in diversi scenari: contro le app JEE e .NET, in particolare le app che avevano superato i 20 MLOC con tonnellate di complessità, e specialmente quando includevano servizi Web che erano interfacce SOAP e / o REST.

Personalmente, non toccherei nemmeno una valutazione su app JEE, .NET o PHP create senza considerare IAST come un approccio primario di prima esecuzione. Risparmia così tanto tempo e offre così tanta attenzione.

Confronto da SAST a IAST: IAST è più veloce di SAST e offre attenzione alla gestione dei rischi. Anche con una sola rilevazione IAST che SAST può o non può trovare nel futuro, questo può essere di enorme valore quando si esaminano analisi del gap di controllo o problemi simili di gestione del rischio. Il fatto che un errore di sicurezza sia stato rilevato con IAST rende la vulnerabilità del software posizionata in modo univoco per una maggiore priorità. Inoltre, i risultati IAST, combinati con i risultati SAST (in particolare basati su regole personalizzate) sono sorprendenti per risparmiare tempo quando si tratta di personalizzare ulteriormente le visualizzazioni, comprendere il codice, il design del codice e la combinazione di risorse.

Confronto da DAST a IAST: Nelle mie mani, IAST troverà semplicemente di più e comprenderà le vulnerabilità più profonde che probabilmente porteranno allo sfruttamento o sfruttare il concatenamento più facile / più veloce.

In breve: utilizza IAST ogni volta che è possibile, il prima possibile e fornisci artefatti IAST alle future valutazioni SAST (e SAST personalizzate)

Quale è meglio? un martello o un cacciavite? Tutto dipende dal problema. Dato che non conosci i punti deboli in anticipo, l'approccio raccomandato da IARPA "STONESOUP è utilizzare più strumenti con più approcci.

Paul Black del NIST evidenzia i vantaggi e gli svantaggi dell'analisi statica nel suo CrossTalk March / Articolo di aprile 2009 . "I nuovi test devono essere sviluppati quando vengono scoperti nuovi attacchi o modalità di errore .. Gli analizzatori statici hanno qualche vantaggio in questo caso ..." Soprattutto, gli analizzatori statici hanno il potenziale di trovare eventi rari o porte posteriori nascoste. Poiché considerano il codice indipendentemente da una particolare esecuzione, possono enumerare tutte le possibili interazioni. Il numero di interazioni tende ad aumentare in modo esponenziale, sfidando allo stesso modo l'analisi statica completa e l'esecuzione del test. L'analisi statica può concentrarsi sull'interazione senza la necessità di test di ristabilire le condizioni iniziali o vincolare artificialmente il sistema per produrre l'interazione desiderata. Peggio ancora, i test black-box non possono realisticamente aspettarsi di scoprire, diciamo, una backdoor accessibile quando l'ID utente è "JoshuaCaleb" poiché ci sono un numero quasi infinito di stringhe arbitrarie da testare. "

"I test e l'analisi statica si completano a vicenda: il test ha il vantaggio di rivelare fallimenti completamente inattesi, mentre i sistemi integrati possono essere testati, anche quando è assolutamente impossibile analizzare qualsiasi software che possa essere nascosto in un componente."

"L'analisi statica non è una panacea, ma le vulnerabilità complesse e sottili possono sempre essere sconfiggere il ragionamento in un analizzatore statico. L'assoluta mancanza di un requisito importante, come il controllo o la crittografia, non può essere dedotta ragionevolmente dall'esame degli artefatti di post-produzione. Il software senza resilienza o auto-monitoraggio è aperto a errori di installazione o di funzionamento, ma l'analisi statica può essere una delle ultime linee di difesa contro le vulnerabilità. " ... Operare dall'esposizione dello strumento di analisi statica di giugno 2008 [3] , [4] mostra che gli attuali analizzatori variano molto. Un analizzatore può produrre pochi falsi allarmi per alcuni punti deboli, ma molti falsi allarmi per altre debolezze. Allo stesso modo, il tasso di debolezze mancate varia notevolmente. Gli analizzatori coprono anche solo un sottoinsieme di punti deboli documentati [5] . Pertanto, l'analisi statica più completa risulterebbe da una combinazione di analizzatori utilizzata con cura.

Dr. Il nero guida il SAMATE - Software Metrics and Tool Evaluation del NIST. Consulta la pagina Tool Survey di SAMATE e la pagina SecTool di Shay Chen per Prezzo e funzionalità di confronto di scanner di applicazioni Web. Full disclosure: Sono un ricercatore ospite che supporta il progetto SAMATE.

Sto lavorando per la società che ha scritto il case study Quotium ( link ) ma cercherò di essere obiettivo nella mia risposta!

Il punto non è quello di trovare vulnerabilità, ma di essere in grado di far riparare rapidamente gli sviluppatori quelli che rappresentano un rischio reale per la tua azienda e in particolare i tuoi dati (ambito principale degli hacker).

Perché?

Quando stai sviluppando in un ambiente Agile con cicli di rilascio brevi. Non è possibile interrompere il processo di SAST + DAST, analizzare report, eseguire triage di risultati, correggere problemi in funzioni non utilizzate, analizzare codice (talvolta localizzato in terze parti) per individuare la fonte, capire falsi positivi ecc ... Non c'è tempo!

Il problema principale con SAST e DAST è tempo e competenza . Per entrambi, è necessaria l'analisi dell'impatto e l'analisi della correzione del codice. SAST + DAST non è Agile.

SAST e DAST conoscono solo un lato del sistema, non considerano le vulnerabilità in un contesto globale di minacce e in un contesto di dati. IAST fa, poiché tiene traccia dei dati dal front-end al back-end.

Un vero IAST è uno strumento che è stato creato ex novo appositamente per agire dal punto di vista degli hacker al codice.

IAST ti dà la possibilità di essere meglio integrato nel processo di sviluppo.

Ad esempio, si collega lo strumento IAST in cui si trovano i server di build ... da un lato si collegano gli script di test automatici (selenio per ex.) dall'altro lo strumento di tracciamento dei bug. Hai un processo di test di sicurezza automatizzato che viene eseguito di notte.

Al mattino, gli sviluppatori trovano il loro elenco di codici vulnerabili con la correzione da applicare, un video di riproduzione dell'attacco sull'applicazione testata, il percorso del codice vulnerabile sui diversi componenti per essere in grado di applicare patch alle interfacce di terze parti se il codice sorgente non è disponibile.

• Gli sviluppatori si concentrano solo sulle vulnerabilità dimostrate
• I tester hanno una visione chiara dei rischi di vulnerabilità su misura da OWASP Top 10, SANS / CWE, PCI ecc ... per GO / NO GO

Un grande guadagno di tempo nel processo!

Bene, qui non sono obiettivo ma è come funziona:)

Per essere obiettivi:

Ci sono solo 2 strumenti che sono stati creati per essere IAST: Quotium's Seeker and Contrast from Aspect.

Tutti gli altri venditori, hanno provato a unire strumenti separati per lo scopo marketing ma sono DAST + SAST not IAST!

Abbiamo clienti che hanno implementato l'IAST come processo continuo e continuano a disporre di uno strumento SAST per la verifica.

SAST ti aiuta ad avere una pratica di codifica più sicura. IAST ancora trova vulnerabilità dopo SAST, ma IAST non evidenzierà la pratica di codifica non sicura se il codice non viene toccato da un processo vulnerabile.

Quindi potresti fare meglio IAST + SAST di DAST + SAST!