White-box vs. Black-box

Qui ci sono alcune risposte davvero valide, ma alcuni punti aggiuntivi che ritengo siano importanti da aggiungere:

• Come @atdre ha menzionato, non dovrebbe essere / o, si tratta di due creature diverse e misurano cose diverse. Se possibile, dovresti fare entrambe le cose.
• Anche come ha detto @atdre, testare - anche whitebox + blackbox - non è abbastanza. Ci sono altre cose che devi fare per essere sicuro, incluso tutto un SDL olistico, con una corretta gestione dei rischi, analisi, ecc.
• Al punto ... Il Blackbox è solitamente più veloce, spesso per ordine di grandezza. Whitebox (inclusa la revisione del codice) di solito richiede molto più lavoro.
• Blackbox (vale a dire pentesting) di solito ha un costo inferiore rispetto a whitebox, non solo in totale ma anche per ora.
• Ci sono più fornitori di blackbox di terze parti di qualità rispetto a whitebox - non in totale, ma contando solo quelli che veramente sanno cosa stanno facendo. (O è solo la mia percezione?)
• WB trova spesso vulnerabilità molto più profonde di BB.
• WB può spesso trovare filtri difettosi, che BB non è stato in grado di bypassare (fino a sapere come è costruito il filtro, un altro punto verso la casella grigia test).
• Ci sono molti tipi di difetti che BB non è nemmeno in grado di testare, ad es. log di audit, difetti crittografici, backend hardening, ecc.
• BB può testare l'intero sistema, con tutte le protezioni non codificate (ad esempio WAF, IPS, hardening del sistema operativo, ecc.) in cui WB è solo a livello di applicazione (ad esempio codice / design, ecc.). Nota che questo può andare in entrambe le direzioni - a volte ti viene impedito di completare una scansione BB, anche se una volta conosciuto il vettore potresti ignorare le protezioni.
• Allo stesso modo, BB può scoprire interazioni difettose tra sottosistemi, dove WB di solito lo mancherà. Consideralo come test unitario e test di sistema.
• I WB possono spesso essere eseguiti molto prima che il sistema sia completo, BB deve essere compilato, compilato, installato e funzionante (e preferibilmente la maggior parte dei bug funzionali scossi). Questo può rendere un SDL più efficiente, quando le recensioni possono essere fatte all'inizio del ciclo di vita.
• D'altra parte, se un sistema è già attivo, è semplice avviare un BB, ma se vuoi fare WB (fallo bene) devi iniziare a cercare tutti i codici sorgente, le librerie, gli strumenti, ecc. Spesso, non hai nemmeno il codice sorgente perché è di terze parti, COTS, ecc.

Credo che questa domanda sia meglio affrontata nel capitolo 4 di The Art of Software Security Assessment , un libro di Mark Dowd, Justin Schuh e John McDonald.

Senza di esso come riferimento, posso tranquillamente dirti che il metodo migliore è usare i dati di runtime insieme al codice sorgente mentre si determinano i "colpi" (o tracce, copertura aka) usando il test black-box - ma solo dopo un Il modello di minaccia e l'architettura generale del sistema sono ben noti.

Gli autori sembrano anche gradire l'analisi sicura del codice statico quando combinati con le strategie del punto di vista, anche se è mia opinione che questi possano variare selvaggiamente assumendo che le seguenti non siano vere:

• La lingua e le sue librerie di classi di base devono essere supportate dallo strumento di analisi statica sicura
• L'intero sistema deve essere solitamente disponibile. Cioè deve includere codice sorgente compilabile che includa tutti i componenti di terze parti / contrib e librerie esterne, possibilmente anche per includere il compilatore di sistema, la VM o altri artefatti del sistema originale
• Tutte le componenti / librerie esterne che non fanno parte delle librerie della classe base devono avere origini e sink definiti nel database source-sink-passthru dello strumento di analisi statica sicura. Le complessità di alcuni passthrus (cioè i filtri) possono variare a seconda dell'implementazione o dell'implementatore e quindi richiedono quasi sempre una configurazione personalizzata
• L'uso aggiuntivo di determinati modelli o elementi di codice architettonico potrebbe causare altre variazioni, che potrebbero richiedere una personalizzazione che non è possibile con la maggior parte dei moderni strumenti di analisi statica sicura

Per le ragioni di cui sopra, così come i motivi esposti negli studi NIST SATE (fatti da NIST SAMATE), trovo difficile raccomandare molti strumenti di analisi statica sicura da usare nell'analisi della scatola bianca. È quasi sempre semplicemente meglio usare le strategie di comprensione del codice che molto probabilmente implicano la lettura del codice sorgente dall'alto verso il basso, che è davvero molto importante se si cercano i rootkit di codice gestito e simili.

Invece di testare e audire / valutare le applicazioni, adotterei un approccio diverso che è in gran parte molto indipendente dalla tecnologia. Il mio suggerimento sarebbe quello di implementare un portale di gestione dei rischi per la sicurezza delle applicazioni che includa un inventario di app insieme ai controlli di sicurezza delle applicazioni attualmente implementati. Dopo una previsione iniziale, i controlli di sicurezza delle applicazioni devono essere valutati rispetto agli standard del settore come MITER CWE, SAFEcode e OWASP ASVS. Un'analisi delle lacune (si noti che si tratta di un termine di gestione del rischio standard e funziona meglio se implementata in un programma di gestione della sicurezza delle informazioni basato su ISO 27001 o simile) può quindi essere utilizzata per determinare i controlli di sicurezza delle applicazioni ottimali, nonché un percorso per ottenere dai controlli attualmente implementati a quelli richiesti.

È necessario implementare questo portale di gestione dei rischi prima di eseguire attività di valutazione del rischio come test white-box o black-box per ottenere risultati migliori e misurare il successo del programma.

Casella nera

• professionisti: test semplici, rapidi e semplici
• contro: a volte non è possibile testare alcune parti dell'applicazione (per controllare algoritmi di hash, entropia id di sessione, ...); non puoi essere sicuro che tutta l'applicazione sia stata testata

Casella bianca

• pros: possibilità di controllare i codici sorgente (risparmia tempo - non è necessario testare l'iniezione SQL se si riesce a vedere che i parametri vengono utilizzati in modo sicuro ovunque); puoi testare parti di applicazioni che non sono accessibili / testabili usando la GUI
• contro: i test possono diventare davvero complessi

In generale, i test white box ti permettono di immergerti nel codice sorgente ed eseguire test di penetrazione completi, ma può richiedere molto tempo, mentre la scatola nera è facile, veloce e semplice. Preferisco i test gray box - utilizzando metodi black box e intervistando gli sviluppatori / controllando il codice sorgente solo su parti specifiche dell'applicazione (autenticazione, gestione delle sessioni, gestione della configurazione, ...).