Application security testing: come orientarsi fra SAST, DAST o IAST?

La sicurezza è un aspetto sempre più importante nella progettazione delle applicazioni. Anche per questo è, e rimane, il più arduo da affrontare. I potenziali pericoli che gli application team incontrano sono numerosi: un coding scadente, i difetti del sistema operativo, le integrazioni fragili (tipo API non sicure) e le immancabili azioni dannose di hacker e utenti maldestri. Un problema in più arriva dall’enorme offerta di application security testing tool, tanto ampia da aumentare la confusione al momento della scelta.

Application security testing

Application security testing è il sistema a cui si affidano gli sviluppatori per identificare i difetti di sicurezza del software prima del rilascio. In questo articolo proviamo una sintesi dei suggerimenti che arrivano dagli esperti per la scelta dello strumento più adatto, a beneficio dei team di sviluppo delle applicazioni. Il primo di questi consigli è di selezionare gli strumenti di security testing con gli stessi criteri che si utilizzerebbero per altri componenti in una pipeline di continuous integration e continuous delivery (CICD). Questo significa che, valutate le funzionalità, l’usabilità, i costi e il supporto del fornitore, alla fine, sarà difficile, e forse impossibile, trovare una risposta completa in un unico strumento.

SAST vs DAST vs IAST

I tre principali approcci tecnologici alla base dei test di sicurezza a cui si affidano gli sviluppatori per identificare i difetti (di sicurezza) del software prima del rilascio sono identificati dagli acronimi SAST, DAST e IAST.

• Static application security testing (SAST). Consente agli sviluppatori di rilevare i difetti comuni prima della compilazione di una build. Un team di sviluppo potrebbe utilizzare anche più strumenti SAST per supportare vari linguaggi o piattaforme di sviluppo.
• Dynamic application security testing (DAST). Consente agli esperti di test di sicurezza di sondare una build in esecuzione e individuare problemi con configurazione, gestione degli errori, input e output dell’applicazione e così via. SAST e DAST sono regolarmente utilizzati assieme.
• Interactive application security testing (IAST). Combina le tecniche SAST e DAST, cercando i vantaggi di entrambe.

La cosa che si capisce leggendo le analisi, i pareri e le recensioni, è che ognuna di queste tecnologie ha esigenze e limiti specifici. Tutte aiutano nel security testing, ma nessuna da sola è sufficiente a garantire la completa sicurezza delle applicazioni. In pratica, è necessaria una varietà di strumenti (correttamente utilizzati) per creare un ambiente di security testing davvero completo.

Static application security testing

SAST comprende gli strumenti e le tecnologie progettate per verificare la presenza di difetti e vulnerabilità nel codice statico. Questo metodo è una forma di test strutturale (white box testing) che indaga eventuali problemi nati nella fase di coding.

Uno strumento SAST, ad esempio, potrebbe identificare un codice debole di generazione di numeri casuali, trovare potenziali buffer overflow, individuare possibilità di SQL injection, segnalare difetti di scripting tra siti e identificare altri potenziali punti problematici che dei malintenzionati potrebbero sfruttare. I team di sviluppo utilizzano regolarmente gli strumenti SAST per imporre la conformità con formati e standard di codifica stabiliti.

Gli strumenti SAST funzionano scansionando il codice a riposo, cioè mentre nessun essere umano o programma esegue il codice. Lo strumento ricerca il codice statico riga per riga e istruzione per istruzione, confrontandolo con un insieme stabilito di regole ed errori noti. Gli strumenti SAST, in genere, includono un’ampia gamma di errori noti confrontabili, e ulteriori problemi possono essere definiti in base alle esigenze e aggiunti al regime di test. Gli strumenti SAST vengono generalmente selezionati tenendo conto di:

• il linguaggio di sviluppo (se il team di sviluppo programma l’applicazione in un determinato linguaggio, lo strumento SAST deve scansionare quel linguaggio);
• l’elenco delle vulnerabilità coperte dallo strumento e la possibilità di aggiungere criteri personalizzati;
• l’accuratezza (numero di falsi positivi) dello strumento;
• la compatibilità dello strumento con continuous integration (CI) esistenti o altri set di strumenti di sviluppo.

Gli strumenti SAST sono generalmente inclusi nei set di sviluppo e i fornitori di ambienti di sviluppo integrato (integrated development environment IDE) in alcuni casi tali strumenti nelle piattaforme. Gli sviluppatori dovrebbero chiedere il supporto dei SAST quando scrivono il codice, così facendo scopriranno le vulnerabilità della sicurezza all’inizio del ciclo di sviluppo prima che qualsiasi essere umano o programma esegua il software. C’è tuttavia il problema dei falsi positivi. Per questo motivo, dicono gli esperti, gli utenti SAST dovrebbero avere sufficiente conoscenza di codifica, progettazione e sicurezza per riconoscere i falsi positivi o, in alternativa, saper apportare modifiche adeguate al codice per evitare i falsi positivi.

Il vantaggio dei SAST nello sviluppo delle applicazioni è che spostano i test di sicurezza nella prima fase del ciclo di sviluppo del software. Gli errori in questa fase iniziale sono spesso il risultato di semplici errori di codifica o di altre vulnerabilità comuni. In genere possono essere riparati in modo semplice ed economico in fase di codifica.

SAST, tuttavia, è solo per il codice statico. Il metodo non può gestire tutte le vulnerabilità e non è adatto a vulnerabilità di runtime (operative) o di configurazione come l’autorizzazione e l’autenticazione. Di conseguenza, i team di sviluppo utilizzano spesso SAST insieme ad altri strumenti di test di sicurezza. Va aggiunto che il problema dei falsi positivi, ne parlavamo, può essere ricorrente e far perdere parecchio tempo agli sviluppatori nella rincorsa a falsi allarmi. Questo lavoro extra può mettere a dura prova il team di sviluppo, specialmente in ambienti di sviluppo rapido in cui il tempo è prezioso.

Gli strumenti SAST più noti sono Coverty di Synopsys, HCL AppScan Source, SonarQube, Kiuwan Code Security, AttackFlow e Micro Focus Fortify Static Code Analyzer.

Dynamic application security testing

DAST rappresenta l’insieme di strumenti e tecniche utilizzati per verificare la presenza di vulnerabilità nelle applicazioni in esecuzione, che sono spesso app basate sul Web. Questo metodo è un tipo di test della black box. A differenza di SAST, che vede la base del codice, DAST non conosce il codice sottostante. Invece, lo strumento DAST è progettato per iniettare o fornire dati difettosi o dannosi al software.

DAST è adatto per trovare problemi di configurazione e autenticazione del server, oltre a difetti che diventano visibili solo quando un utente effettua l’accesso. Ad esempio, lo strumento potrebbe tentare di eseguire script tra siti o provare a fornire input alfanumerici alle finestre di dialogo che prevedono input numerici. L’obiettivo è vedere come il software gestisce gli errori.

DAST testa il software dall’esterno verso l’interno, testando una build di software in esecuzione nello stesso modo in cui un hacker potrebbe sondare i punti deboli sfruttabili. Sebbene la parola “dynamic” nel nome indichi che l’app è in esecuzione, l’applicazione viene eseguita in un ambiente di staging, cioè non in produzione.

Gli strumenti DAST sono fondamentalmente simulatori di input. Forniscono input predeterminati al software in prova. Se c’è una differenza tra il risultato previsto e quello effettivo (o l’app risponde a un input quando non dovrebbe), il software potrebbe presentare un difetto che richiede ulteriori indagini.

DAST non esamina il codice sottostante, quindi il metodo non può puntare a punti specifici nel codice, ma riferisce su azioni, input e output per indicare possibili vulnerabilità. Ad esempio, DAST è estremamente popolare nei test delle applicazioni Web e i team utilizzano abitualmente il metodo per iniettare dati dannosi al fine di scoprire possibili difetti. Inoltre, DAST simula comportamenti casuali degli utenti per verificare vulnerabilità impreviste. Gli strumenti DAST, di solito, vengono selezionati considerando:

• il livello di automazione fornito dallo strumento (la sua capacità di automatizzare, programmare ed eseguire scansioni manuali come desiderato);
• l’ambito delle vulnerabilità coperte dallo strumento (come il supporto per le vulnerabilità OWASP Top 10);
• il livello di personalizzazione (configurazione dello strumento per test specifici o complessi);
• la compatibilità dello strumento con CI/CD esistenti o altri set di strumenti di sviluppo.

Gli strumenti DAST possono richiedere più tempo e competenze in materia di sicurezza rispetto agli strumenti SAST. Poiché DAST non esegue la scansione nel senso convenzionale, le sue prestazioni non possono essere misurate in linee al secondo o altre metriche oggettive. Lo strumento può invece fornire solo un input o tentare un’azione in punti specifici dell’operazione dell’applicazione, e ci vuole tempo perché le applicazioni vengano caricate, eseguite e raggiungano quei punti specifici in cui può avvenire il sondaggio. Pertanto, il test DAST può richiedere più tempo. E poiché DAST richiede una solida conoscenza dell’applicazione e del suo funzionamento (per configurare e amministrare le condizioni di test), l’uso efficace di DAST spesso si basa su sviluppatori con una vasta esperienza di sicurezza e conoscenza sia dell’applicazione sia delle sue dipendenze.

Gli strumenti DAST possono essere investimenti efficienti. Lo strumento DAST non è specifico della piattaforma, quindi può potenzialmente funzionare per tutte le applicazioni. DAST opera su un software costruito dall’esterno, il che lo rende ideale per trovare errori di configurazione e sviste facili da perdere. Laddove gli strumenti SAST possono produrre un gran numero di falsi positivi, gli strumenti DAST tendono a segnalare un basso numero di falsi positivi perché i test e i criteri di test sono progettati per concentrarsi su vulnerabilità reali e identificabili. Ad esempio, se un utente riesce ad accede a un’applicazione accede con credenziali vuote o errate, non c’è dubbio che si tratti di un difetto di sicurezza.

Tuttavia, gli strumenti DAST soffrono anche di alcune notevoli limitazioni. Per esempio, dipendono da un grande sforzo manuale per scrivere e gestire le condizioni di test. Ciò limita la scalabilità e l’utilizzo di DAST senza un investimento sostanziale e continuo di tempo e impegno per lo sviluppo dei test. Anche il tempo è un problema con DAST: il numero di test e la velocità con cui un’app può essere eseguita significa che le scansioni complete potrebbero richiedere giorni. Infine, i risultati DAST non si riferiscono al codice, ma piuttosto a condizioni e risultati. Di conseguenza, gli sviluppatori devono esaminare e identificare le cause alla base dei difetti del report DAST.

Tra i fornitori DAST ci sono ZAP open source, che è basato su ZAP ed è adatto per flussi di lavoro CI/CD; Detectify; Netsparker; InsightAppSec di Rapid7 e una piattaforma di sicurezza delle applicazioni aziendali di Veracode.

Interactive application security testing

IAST combina alcune delle migliori caratteristiche di SAST e DAST. Il suo obiettivo è fornire test di sicurezza dell’applicazione dall’interno dell’applicazione stessa, spesso mentre l’app è in fase di sviluppo. Se configurato correttamente, uno strumento IAST può:

• accedere a tutto il codice dell’applicazione;
• raccogliere informazioni sul controllo e sul flusso di dati in fase di esecuzione;
• accedere alle informazioni di configurazione;
• supervisionare il traffico web (HTTP);
• accedere ai componenti dell’applicazione, incluse librerie, framework e dati all’interno delle dipendenze di back-end.

IAST offre una visione completa di un’applicazione e del suo ambiente per indirizzare più codice, offrire risultati più affidabili e identificare più falle di sicurezza rispetto a SAST o DAST.

Gli agenti software IAST analizzano il funzionamento di un’applicazione, ricercano le vulnerabilità, controllano le prestazioni e inviano i problemi rilevati direttamente in uno strumento di tracciamento. Poiché un team di sviluppo può applicare tali agenti software ovunque nel ciclo di sviluppo, IAST può funzionare durante lo sviluppo. Potrebbe iniziare all’interno dell’IDE durante la codifica per controllare la base di codice, seguire i test e la convalida del software per segnalare prestazioni e difetti, e continuare mentre l’applicazione creata viene implementata in produzione per il monitoraggio continuo della sicurezza. Gli strumenti IAST, di solito, vengono selezionati dopo un’attenta considerazione di:

• i linguaggi di sviluppo utilizzati dal team (se IAST esegue la scansione del codice, deve comprendere il linguaggio);
• l’ambito della codifica e le vulnerabilità operative coperte dallo strumento (e la possibilità di aggiungere criteri personalizzati);
• prestazioni veloci (spesso operanti in background) e basso tasso di falsi positivi;
• supporto per i principali standard di conformità e sicurezza (come PCI DSS, GDPR, SANS/CWE e altri); e
• facilità di implementazione e integrazione con i flussi di lavoro di sviluppo esistenti e i set di strumenti CI/CD.

Gli strumenti IAST possono essere utili durante l’intero ciclo di sviluppo del software e in produzione. Possono supportar gli sviluppatori che scrivono il codice, i tester che convalidano le build e persino il personale operativo che distribuisce la build. I fornitori di IAST ne sottolineano la facilità di installazione e utilizzo. Anche così, tuttavia, una certa conoscenza della sicurezza è essenziale da parte degli utilizzatori; sia per aiutare a comprendere i risultati dello strumento sia per seguire i problemi risultanti e apportare correzioni rapide.

Come nel caso dei SAST, gli strumenti IAST possono eseguire la scansione del codice. Ciò consente alle tecnologie IAST di supportare la scoperta precoce e la risoluzione dei problemi di codifica, molti dei quali possono essere risolti con costi e ritardi minimi. Ma la cosa più convincente è che IAST può individuare i problemi operativi in ​​modo più specifico rispetto agli strumenti DAST, che sa quando c’è un difetto ma non vede il codice sottostante. IAST vede sia il codice sia il funzionamento del software, consentendo ai report di mostrare l’operazione effettiva o il punto corrispondente nel codice in cui si verifica una vulnerabilità operativa. Questo aiuta a velocizzare la localizzazione e la risoluzione dei problemi operativi nel codice.

La preoccupazione principale con IAST è l’uso di software agents, cioè programmi inseriti in un ambiente che possono agire autonomamente per conto di un altro programma. Sebbene di solito piccoli e spesso innocui, questi segmenti di codice possono potenzialmente influire sul funzionamento di un’applicazione e ridurre le prestazioni. Le applicazioni più sensibili potrebbero avere problemi quando vengono applicati gli strumenti IAST e questa è una preoccupazione da considerare.

Gli strumenti IAST più noti sono Acunetix, Checkmarx CxSAST, Veracode e lo strumento Seeker di Synopsys.