Le pratiche di sviluppo del software stanno cambiando rapidamente, così come i metodi utilizzati dagli avversari per colpire le applicazioni personalizzate. L'aumento delle applicazioni loosely coupled, insieme all’aumento vertiginoso della velocità di deployment del codice, ha generato una crescente superficie di attacco con un'architettura di software più ampia e dipendenze importate. I team di application security (AppSec) sono spesso in minoranza rispetto agli sviluppatori di software e faticano a tenere il passo con le frequenti modifiche del codice.

Tutti questi fattori creano nuove opportunità per gli avversari, che sfruttano gli effetti collaterali della rapidità di sviluppo del software per fare breccia nelle applicazioni personalizzate. È importante quindi esaminare i problemi che i team di application security devono affrontare e le misure che devono adottare per allinearsi con i software engineer, per difendere le applicazioni personalizzate.

Analizzare le modifiche al codice, i flussi di dati e le API

I tentativi di attacco continueranno probabilmente a estendersi oltre i moduli di login e gli input di dati infetti. Le API sono il metodo principale di trasporto dei dati in un'architettura a microservizi. Con il numero crescente di servizi cloud adottati dalle aziende, l'abbondanza di API ha ampliato la superficie di attacco su Internet. I team che si occupano di sicurezza delle applicazioni devono vedere e comprendere i parametri e la postura di sicurezza di tutte le API nel loro ecosistema.

Quando le applicazioni software trasmettono dati tramite API, questi vengono suddivisi in molteplici parametri. Utilizzando un modulo di input come esempio, i parametri comuni possono includere "nome", "cognome" ed "email". Risulta difficile catalogare e tracciare tutti i parametri passati tramite API in un backend a microservizi. Comunemente, gli sviluppatori tracciano le proprie API manualmente utilizzando OpenAPI, ma qualsiasi lavoro manuale è soggetto a errori - specialmente considerando che le API evolvono nel tempo. La documentazione automatica delle API, inclusa la rilevazione dei parametri sensibili, risulta quindi vitale.

Una mappatura delle API eseguita con i tool Bionic

Le pratiche di sviluppo software rappresentano un altro problema. Molti team di sviluppo creano API a scopo di test, e talvolta questi prototipi finiscono accidentalmente in produzione, e successivamente a disposizione di tutti. Senza una rilevazione automatica delle API in produzione, queste interfacce non registrate esistono come "API ombra", ovvero API sconosciute al livello aziendale.

Come diretta conseguenza della proliferazione delle API, sono emerse gravi violazioni causate da errori banali, come l'assenza di autenticazione e malfunzionamenti del sistema di autorizzazione nelle API. Alcuni di questi errori occorrono al momento del deploy iniziale, mentre altri vengono introdotti nelle versioni future. I team di application security devono mantenere sotto costante controllo quali API siano responsabili di funzionalità aziendali critiche o contengano dati sensibili per affrontare questo problema. Man mano che il software cambia nel tempo, i team di application security devono assicurarsi che le loro API più importanti siano regolarmente testate ed analizzate.

Mantenere una distinta base del software

Una software bill of materials (SBOM), un argomento ricorrente nell’era moderna dei software, è una lista completa dei framework e delle librerie software importate all’interno di un'applicazione software. Queste librerie e framework sono progetti di codice importati dagli sviluppatori per "astrarre" porzioni di logica di business. Utilizzare codice preesistente consente agli sviluppatori di concentrarsi su nuovi problemi anziché reinventare qualcosa che già esiste.

Un concetto importante da comprendere in relazione alle SBOM è l'idea delle "dipendenze transitive". Queste sono componenti software importate indirettamente come risultato di un altro framework o libreria dipendente da esse. Quando un singolo pacchetto software viene introdotto in un'applicazione, può portare con sé un'enorme quantità di altri pacchetti software. Questo concetto di ereditarietà transitiva può introdurre una lunga lista di librerie software eseguibili in memoria - molte delle quali rimangono ignote allo sviluppatore di software e all’azienda in generale.

L'inclusione di questi pacchetti software, sia conosciuti che sconosciuti, diventa rapidamente pericolosa quando vulnerabilità di cui non si era a conoscenza vengono scoperte ed esposte, introducendo rischi di cui le organizzazioni non sono consapevoli. Le organizzazioni devono mantenere SBOM accurate per comprendere facilmente quando vulnerabilità zero-day presentano un rischio immediato per i loro asset. Questo è particolarmente critico man mano che l'architettura del software delle organizzazioni si espande e le dipendenze importate aumentano, creando una maggiore superficie di attacco da monitorare.

Limitare e patchare le vulnerabilità sotto attacco

È fondamentale per i team di sicurezza riconoscere le Common Vulnerabilities and Exposures (CVE) che vengono sfruttate nel mondo reale, in modo da poter valutare la propria esposizione e applicare le patch conseguentemente. Molte aziende in passato hanno dato priorità alla correzione delle vulnerabilità utilizzando il Common Vulnerability Scoring System (CVSS), che stima l'entità del danno che un attaccante può infliggere sfruttando la vulnerabilità.

La sicurezza delle applicazioni è sempre più slegata dai punteggi CVSS grezzi a favore di alternative che comprendono le stime di probabilità di attacco. Ad esempio, è possibile osservare il punteggio Exploit Prediction Scoring System (EPSS), che utilizza l'apprendimento automatico per prevedere se una CVE in particolare sarà sfruttata. Il governo degli Stati Uniti conserva un catalogo Known Exploited Vulnerability (KEV) che elenca vulnerabilità note per essere sfruttate nel mondo reale. Inoltre, le aziende di sicurezza informatica utilizzano dati interni provenienti dai team di intelligence e sicurezza per identificare le vulnerabilità sfruttate pubblicamente. Ad esempio, la piattaforma di sicurezza cloud di CrowdStrike utilizza il punteggio ExPRT.AI per classificare la gravità delle vulnerabilità, inclusa la probabilità che una vulnerabilità venga sfruttata o presa di mira da specifici gruppi avversari.

I team di application security possono combinare le informazioni EPSS, KEV e integrare quelle fornite dai fornitori di threat intelligence per isolare le vulnerabilità sfruttate attivamente all’interno del proprio ambiente. Con un gran numero di vulnerabilità in circolazione, incluse quelle attinenti alle librerie, risulta importante per i team di application security utilizzare misure appropriate per dare priorità alle vulnerabilità che richiedono più attenzione.

Una strategia moderna per i tool di sicurezza delle applicazioni

Gli strumenti di sicurezza delle applicazioni tradizionali - inclusi i test statici di sicurezza delle applicazioni (SAST), i test dinamici di sicurezza delle applicazioni (DAST) e l'analisi della composizione del software (SCA) - sono progettati per individuare singole vulnerabilità. Questi strumenti sono efficaci per individuare le vulnerabilità; tuttavia, non sono realizzati per comprendere l'architettura del software e non sono efficaci nel valutare le priorità sulle vulnerabilità in base al rischio aziendale.

È qui che entra in gioco la gestione della postura di sicurezza delle applicazioni (Application Security Posture Management, ASPM). Gli strumenti ASPM analizzano l'architettura del software, insieme a tutti i flussi di dati e le API in produzione, generando informazioni su ciascun rischio rilevato. Queste capacità consentono agli strumenti ASPM di dare priorità alle vulnerabilità basandosi su tre criteri: la gravità dell'impatto di una vulnerabilità (ad esempio, valutazione CVSS), la probabilità di sfruttamento (ad esempio, microservizio esposto su Internet), l'impatto commerciale materiale (ad esempio, esposizione di informazioni personalmente identificabili)

Inoltre, gli strumenti ASPM determinano i pacchetti software presenti in produzione, consentendo ai team di application security di ottenere uno SBOM completo per le loro applicazioni sviluppate su misura.

Combinando l'esperienza nella ricerca di vulnerabilità tramite strumenti consolidati come SAST, DAST e SCA con le capacità di prioritizzazione di ASPM, i team di application security possono ottenere una postura di sicurezza delle applicazioni migliore. Implementando questi strumenti e aggiungendo la protezione in tempo reale per fermare gli attacchi, nel 2024 i team di application security potranno rafforzare la loro strategia per la sicurezza delle applicazioni.

Jacob Garrison è Technical Marketing Manager CrowdStrike