Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner

Articoli

Icona delle News




La scansione ad hoc non è sufficiente

13/07/21 CoreTech Blog

Banner

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.

Perché sei bloccato con la scansione ad hoc?

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.

 

Nessuno spazio per la scansione ad hoc

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.

 

Bassa efficacia della 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.

 

Come usare il tuo scanner di vulnerabilità

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.


Articoli su Sicurezza

La cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft