In che modo i rapporti di pentest possono contribuire a soluzioni strutturali per le vulnerabilità?

Question

In che modo i rapporti di pentest possono contribuire a soluzioni strutturali per le vulnerabilità?

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

0

Quando esegui un pentito, qual è la tua raccomandazione al cliente su come gestire / interpretare il rapporto?

Quello che vedo spesso è che i problemi identificati, in particolare quelli relativi al software sviluppato autonomamente, non sono corretti. L'esempio più semplice è l'XSS, che viene "risolto" da s /// (sostituisci esattamente la stringa XSS dal rapporto con niente).

Questa correzione ovviamente non è buona, da un lato perché esiste ancora l'XSS e dall'altro perché questo bug è una chiara indicazione che il concetto di gestione dell'input dell'utente non è sicuro in alcun modo. Dal mio punto di vista questo significa che sono presenti altre vulnerabilità XSS anche se non le ho trovate. Supponendo che un tester trovi tutte le vulnerabilità è, a mio avviso, irrealistico.

Come faccio a pensare al cliente in questo modo? Ad esempio, voglio che il cliente dica "Oh, hai trovato un XSS! Probabilmente abbiamo bisogno di un po 'di tecnologia / processo / adattamento dell'architettura ... per eliminare il più possibile questa roba. Forse usiamo qualche framework web e introduciamo un Soluzione SAST. "

Ho appreso che i blocchi di testo di rimedio generici alla fine di ogni rapporto non sono affatto sufficienti. Ciò che si è dimostrato molto efficace sono i seminari di riparazione, in pratica discutendo dei risultati in un workshop di 2-3 giorni e poi supportando gli sviluppatori durante l'implementazione. Certamente, solo una piccola quantità di clienti è disposta a pagare per questo (e io non ho davvero le risorse).

process penetration-test

posta pinas 13.11.2018 - 16:45

fonte

2 risposte

Leggi altre domande sui tag process penetration-test

Decifra AES 128 CTR con IV (contatore) ma non la chiave Posso scaricare file server specificare quale logo avrà il file sul computer dell'utente?

score 2 · Answer 1

In definitiva, la responsabilità di implementare le raccomandazioni di un test di penetrazione / revisione della sicurezza è a carico dei proprietari del sistema.

In qualità di consulente, puoi formulare raccomandazioni, così come con XSS puoi raccomandare che il cliente si assicuri che utilizzi una robusta combinazione di validazione dell'input e codifica dell'output per mitigare adeguatamente il rischio e puoi segnalare i punti deboli del filtro della lista nera o altre soluzioni naive come sbarazzarsi di caratteri specifici.

Tuttavia, alla fine della giornata, non puoi impedire ai clienti di adottare questo approccio contro i tuoi consigli.

Naturalmente, se sei interno all'organizzazione hai più opzioni in cui puoi provare e ottenere standard di sicurezza per i tuoi team di sviluppo che definiscono il modo corretto per evitare / ridurre l'incidenza dei problemi di sicurezza.

score 1 · Answer 2

Questo è un problema in generale con i test.

Se sai perché il test è stato fatto per cominciare, usa quello.

Per il software auto-sviluppato, prova a guidarli in framework ed elenchi come OWASP, in modo che possano vedere di più l'intera immagine / problema. Dà un suggerimento a dove possono andare e insegnare loro stessi di più. I costi sono spesso un problema. Quindi pagare per il workshop per educarli, potrebbe non essere un'opzione. (Ma includilo alla fine!)

In riferimento agli obblighi legali o agli standard come la famiglia ISO 27000, a volte aiuta. O se conosci la legge e gli standard locali.

Ricorda, sei un tecnico, non legale, quindi conosci i tuoi limiti. "Problema noto nel framework OWASP [this and that], e potrebbe essere una violazione degli obblighi legali forniti in ISO 27001 [più o meno specifici, a seconda del problema]. La correzione raccomandata include la revisione di [più grande problema, così come la piccola correzione.] ".

C, Tester.