Il panorama delle minacce per la sicurezza delle applicazioni web (AppSec) è in costante evoluzione. Le vulnerabilità che si celano all’interno delle applicazioni software costituiscono una porta d’ingresso per chiunque voglia compromettere i sistemi di un’azienda o lanciare attacchi e malware.
Quando si tratta di sicurezza delle applicazioni, la maggior parte degli esperti raccomanda l’uso di Dynamic Application Security Testing (DAST) e Static Application Security Testing (SAST) come approcci complementari per una robusta AppSec. Ma come mettere in atto questi approcci in modo complementare?
Individuare le vulnerabilità delle applicazioni
I punti deboli delle applicazioni e le vulnerabilità del software sono il mezzo più comune con cui i criminali informatici compiono attacchi esterni.
In Intellisync usiamo SAST, DAST, SCA, e Pen Testing come i quattro pilastri della nostra strategia di difesa per fornire una metodologia AppSec “Secure-by-design” attraverso l’intero ciclo di vita dello sviluppo del software.
L’adozione di un Secure Software Development Life Cycle (SSDLC) e di un approccio “Security-By-Design” permette di implementare opportune attività di sicurezza nel corso di tutte le fasi del ciclo di vita del software ed è necessario per rispondere efficacemente alle problematiche di sicurezza e per ridurre i costi che comporterebbe trascurarle.
Penetration testing manuale
La maggior parte delle organizzazioni inizia il loro percorso AppSec eseguendo Penetration Test manuali (MPT). I Penetration Test sono necessari per individuare le vulnerabilità, come i problemi di autorizzazione, che non possono essere individuate solo attraverso valutazioni automatizzate. I nostri pen tester esperti possono esaminare un intero ambiente o solo un’applicazione, e possono seguire o interrompere i flussi di lavoro in un modo che è difficile da replicare per l’automazione.
Tuttavia, il pen testing è solo uno dei metodi che possono essere utilizzati e ha il lato negativo di rallentare la velocità di sviluppo in quanto si tratta di un processo eseguito manualmente.
Figura 1. Penetration Testing come metodologia per l’AppSec
Come funziona il Dynamic Application Security Testing?
Il test dinamico delle applicazioni Web (in inglese, DAST) è un approccio AppSec che permette di osservare in dettaglio come si comporta l’applicazione quando è in esecuzione, per scovarne imperfezioni o vulnerabilità prima che si prosegua con le fasi successive del ciclo di vita del software e senza analizzare in profondità il codice sorgente.
I risultati della scansione dinamica aiutano a dare priorità alla correzione delle vulnerabilità sfruttabili e a ridurre immediatamente il rischio AppSec man mano che vengono risolte. Tuttavia, può essere difficile individuare l’esatta linea di codice su cui lavorare usando solo DAST. Questa valutazione, se usata da sola, è limitata da ciò che si sceglie di testare, perché se l’oggetto della scansione non viene configurato correttamente, si possono perdere d’occhio le vulnerabilità e incorrere in una fallace sensazione di sicurezza.
Inoltre, poiché l’applicazione viene scansionata verso la fine dell’SDLC, i team di sviluppo subiranno una pressione maggiore per rimediare rapidamente alle vulnerabilità; questo è di solito il punto in cui l’attrito tra lo sviluppo e la sicurezza aumenta.
Figura 2. Dynamic Application Security Testing come metodologia per l’AppSec
Come funziona lo Static Application Security Testing?
Il test statico della sicurezza delle applicazioni (in inglese, SAST) è una metodologia AppSec che testa le applicazioni dall’interno verso l’esterno, esamina il codice binario e il codice sorgente delle applicazioni senza mandarle in esecuzione, cioè non eseguendole. Di solito si rivolge al codice sorgente, al codice byte e al codice binario e agisce in una fase precedente dell’SDLC, di modo che gli sviluppatori possano trovare problemi di sicurezza prima che l’applicazione venga completata. Il SAST fornisce anche un feedback di sicurezza in tempo reale durante la codifica, rendendolo un metodo più proattivo per correggere rapidamente le falle. Questo approccio può aiutare a ridurre il debito tecnico di sicurezza al costo più basso.
Il lato negativo di procedere soltanto con una metodologia SAST è l’uso inefficiente che si fa delle risorse. Infatti, poiché la scansione non viene eseguita in un ambiente in esecuzione, può essere difficile determinare quali falle sono immediatamente sfruttabili.
Figura 3. Static Application Security Testing come metodologia per l’AppSec
Analisi della composizione del software (SCA)
Il Software Composition Analysis (SCA) è una metodologia di testing utilizzata per analizzare i componenti open source e di terze parti in uso in un’applicazione, le loro vulnerabilità di sicurezza e le restrizioni di licenza.
Ottenere funzionalità sul mercato più velocemente della concorrenza richiede quasi sempre che i team di sviluppo usino almeno una libreria open-source nel loro codice. Il codice di terze parti è dunque una necessità nello sviluppo del software moderno e lo stesso vale per la sua sicurezza. Un dato significante è la stima secondo cui il 75% delle falle conosciute può essere risolto con un aggiornamento di versione.
Figura 4. Software Composition Analysis (SCA) come metodologia per l’AppSec
Le soluzioni di Intellisync scansionano automaticamente le tue librerie per scovare vulnerabilità delle applicazioni e aiutarti a risolverle.
La difesa in profondità
Cosa succederebbe se si usasse solo uno degli approcci sopra menzionati?
- Se si conducesse solo SCA non si proteggerebbe l’intera base di codice
- Se si conducesse solo SAST, si incorrerebbe in inefficienze legate alle risorse nell’SDLC durante la remediation
- Se si conducesse solo MPT o DAST, le falle e vulnerabilità verrebbero evidenziate in una fase successiva e l’intero processo risulterebbe più costoso. Inoltre, si presenterebbe una maggiore pressione sui team di sviluppo per trovare la falla nel codice sorgente e porvi rimedio rapidamente.
Al contrario, per assicurarsi di ottenere il massimo valore da un programma AppSec, si dovrebbero usare i risultati DAST per configurare le politiche SAST e per informare le attività SAST. Questo assicura di non fare affidamento solo su una metodologia per prevenire un attacco.
Oltre a ciò, è fondamentale continuare a eseguire Penetration Testing per proteggere le vulnerabilità che l’automazione non riesce a trovare. Questo approccio complementare consente di visionare tutta la gerarchia dell’architettura per essere sicuri che si sta facendo tutto il possibile per proteggere ogni livello. Rende inoltre più facile trovare le falle sfruttabili, porvi rimedio rapidamente e persino imparare la codifica sicura per prevenirle in futuro.
Nell’attuale panorama delle minacce in espansione, DAST, SAST, SCA e MPT forniscono ai team DevSecOps un mezzo per proteggere il loro codice e rafforzare i loro programmi AppSec prima che sia troppo tardi.
Rimanere aggiornati su AppSec
OWASP Foundation si occupa di rilasciare periodicamente una lista di vulnerabilità più critiche delle applicazioni web (AppSec) e il National Institute of Standards and Technology (NIST) ha recentemente rilasciato le proprie linee guida di sicurezza per lo sviluppo sicuro del software.
Secondo l’undicesima edizione del rapporto State of Software Security di Veracode, le aziende che eseguono la scansione sia con SAST che con DAST sono in grado di rimediare al 50% delle loro falle, 24,5 giorni più velocemente rispetto alla scansione con una sola tecnologia.
Non è difficile capire perché: vedendo come un attacco può essere sfruttato in fase di esecuzione, gli sviluppatori riescono a capire come pensa un attaccante e possono anche essere più motivati a correggere altre vulnerabilità.
