Diventa Autore per CoreTech | Scopri di più
13/07/21 CoreTech Blog
Uno scanner di vulnerabilità web è generalmente percepito come uno strumento ad hoc. Inizialmente, tutti gli scanner di vulnerabilità erano tali strumenti e le attuali soluzioni di sicurezza delle applicazioni Web open source seguono ancora quel modello. Tuttavia, con un notevole aumento della complessità e della disponibilità delle tecnologie Web, il modello ad-hoc è diventato obsoleto e non soddisfa le esigenze di sicurezza della maggior parte delle aziende odierne.
Gli scanner di vulnerabilità sono stati creati per i penetration tester come strumenti di supporto. In origine, sarebbe stato il tester di penetrazione a eseguire una scansione delle vulnerabilità per trovare rapidamente le vulnerabilità tipiche. Potrebbero quindi approfondire i risultati della scansione, ad esempio, per confermare le vulnerabilità ed eseguire anche test più avanzati, come quelli che coinvolgono la logica aziendale.
In origine, la maggior parte delle aziende di solito si affidava ai servizi di tester di penetrazione di terze parti (liberi professionisti o società di servizi). Un'azienda potrebbe ordinare un test di penetrazione, ad esempio, una volta al trimestre e quindi non eseguire alcun test di sicurezza per i prossimi tre mesi. Pertanto, tutte le scansioni di vulnerabilità, che facevano parte dei test di penetrazione, erano originariamente viste come attività ad hoc, non come misure di sicurezza continue.
Il tempo è passato e gli scanner di vulnerabilità sono diventati molto più avanzati. Gli scanner professionali di oggi si affidano ancora a un motore di scansione, ma fanno molto di più. Sono diventati strumenti automatizzati per la valutazione della vulnerabilità e la gestione della vulnerabilità. Tuttavia, molti acquirenti sono ancora abituati ai "vecchi modi" e percepiscono la sicurezza come un esercizio ad hoc e, di conseguenza, perdono i vantaggi chiave delle moderne soluzioni DAST.
Non è solo la tecnologia di scansione delle vulnerabilità che è cambiata notevolmente negli ultimi anni. È anche la percezione di dove dovrebbero essere collocati gli scanner di vulnerabilità nel ciclo di vita dello sviluppo del software e chi deve utilizzare tale software.
In origine, come accennato in precedenza, gli scanner di vulnerabilità erano strumenti creati esclusivamente per i penetration tester. Tuttavia, le aziende si sono presto rese conto di poter eseguire scansioni di vulnerabilità internamente e quindi esternalizzare i test di penetrazione. In questo modo, i test di sicurezza automatizzati potrebbero essere eseguiti ad hoc ma a intervalli più brevi, mentre i test di penetrazione manuali complessi e costosi potrebbero essere eseguiti meno spesso. Questo è stato il momento in cui gli scanner di vulnerabilità sono passati dalle mani dei tester di penetrazione alle mani dei team di sicurezza interni.
L'ultima e migliore tendenza è quella di integrare completamente gli scanner di vulnerabilità nei sistemi automatizzati in modo che nessun essere umano debba eseguirli manualmente. Questo grazie a DevSecOps e SecDecOps , che spostano gli scanner di vulnerabilità nelle mani degli sviluppatori. Una volta che uno sviluppatore esegue il commit delle modifiche all'applicazione e tenta di crearla, la pipeline di compilazione e test include anche una scansione delle vulnerabilità ed è lo sviluppatore che ottiene il rapporto di scansione. In uno scenario perfetto, il personale di sicurezza interno, che oggigiorno sta diventando una risorsa preziosa a causa del divario di competenze in materia di sicurezza informatica, non deve essere affatto coinvolto. In uno scenario del genere, non c'è spazio per la scansione ad hoc.
Una scansione ad-hoc, specialmente combinata con un test di penetrazione manuale, ti consente di valutare la tua attuale posizione di sicurezza delle applicazioni web. Tuttavia, di per sé, non fa assolutamente nulla per migliorare questa posizione.
Dopo aver eseguito una scansione ad hoc, viene visualizzato un elenco di vulnerabilità in un determinato momento, ma non si avvia automaticamente un processo di eliminazione di tali vulnerabilità. Con un semplice scanner, devi valutare l'impatto e l'importanza di ogni singola vulnerabilità che è stata trovata (spesso in centinaia o migliaia). Quindi, devi creare manualmente una sorta di processo o una pipeline per correggere la vulnerabilità, ad esempio, creare un problema Jira. Ora, immagina quanto questo diventi impossibile per un'azienda con molte applicazioni Web e API complesse.
Quando la vulnerabilità viene segnalata come risolta dallo sviluppatore, non hai modo di verificare se la vulnerabilità non è più presente o se la correzione ha introdotto un'altra vulnerabilità. Molti sviluppatori evitano la sicurezza e trovano solo modi semplici per eludere un particolare tipo di scansione, ad esempio, utilizzare un semplice filtro invece di query parametrizzate per eliminare le vulnerabilità di SQL injection. Molte vulnerabilità segnalate come fisse in realtà non sono state risolte affatto.
Ancora peggio, quando viene eseguita la scansione ad hoc successiva, non ha alcuna connessione con le scansioni precedenti. Pertanto, è necessario allineare manualmente ogni vulnerabilità della nuova scansione con la stessa vulnerabilità della scansione precedente per vedere se le vulnerabilità vengono effettivamente risolte. Questo diventa un altro compito impossibile.
Tutto sommato, una scansione automatica delle vulnerabilità fa risparmiare un po' di tempo per il tester di penetrazione, ma se invece di farlo ad hoc, utilizzi effettivamente le capacità di valutazione e gestione delle vulnerabilità di strumenti moderni puoi risparmiare molto più tempo, non solo per i penetration tester, ma anche per responsabili della sicurezza, project manager, proprietari di prodotti e servizi e sviluppatori.
Non è solo un po' di guadagno, è una rivoluzione.
Non ci sono dubbi: il modo migliore per utilizzare il tuo scanner di vulnerabilità è all'inizio del ciclo di vita dello sviluppo del software. Prima è meglio è. Tuttavia, non tutte le aziende possono raggiungere questo obiettivo, solo quelle con pipeline DevOps agili completamente automatizzate. Ciò non significa, tuttavia, che la tua unica altra scelta sia andare ad hoc. C'è un vasto spettro di modi efficienti per incorporare la scansione delle vulnerabilità nel tuo SDLC.
Ad esempio, indipendentemente dal tipo di metodologia SDLC utilizzata, è possibile rendere la scansione delle vulnerabilità Web un processo continuo come parte del ciclo di rilascio. Puoi farlo anche se non sviluppi software da solo e ti affidi invece a strumenti di terze parti come WordPress o Magento. Non importa da dove provenga il tuo software, sicuramente utilizzi una sorta di ambiente di staging ed esegui i test QA lì. In tal caso, è qui che dovresti includere la scansione continua.
Non eseguire solo una scansione con ogni versione principale. Invece, rendilo un elemento regolare del tuo ciclo di stadiazione. Utilizza le funzionalità di gestione e valutazione delle vulnerabilità, oltre a semplici opzioni di integrazione per creare automaticamente ticket per ogni vulnerabilità che supera una determinata soglia di gravità. Ritesta automaticamente le vulnerabilità dopo che il software è stato modificato dagli sviluppatori e ridistribuito in fase di staging.
Anche se decidi che il tuo rilascio non può essere ritardato e che alcune vulnerabilità (ad esempio, quelle valutate automaticamente come di media o bassa gravità) non possono essere eliminate immediatamente, sarai in grado di monitorare i loro progressi nel periodo antecedente. Avrai ticket che coprono più versioni e sarai in grado di ritestare se le vulnerabilità sono state effettivamente eliminate.
