Jeff Williams, fondatore di OWASP e fondatore & CTO di Contrast Security – Intervista

Jeff Williams, fondatore di OWASP e fondatore & CTO di Contrast Security, è considerato uno dei personaggi più influenti nella sicurezza delle applicazioni moderne. Nel corso degli ultimi decenni, ha contribuito a plasmare il modo in cui le organizzazioni affrontano lo sviluppo di software sicuro, la gestione delle vulnerabilità e la protezione delle applicazioni in fase di esecuzione. Williams ha svolto un ruolo centrale nella costruzione di OWASP da un piccolo progetto di volontariato in una fondazione di sicurezza non profit riconosciuta a livello globale, contribuendo a progetti di rilievo come OWASP Top Ten, WebGoat, ESAPI, ASVS e la scheda di riferimento per la prevenzione degli attacchi XSS. Prima di fondare Contrast Security nel 2014, ha anche fondato Aspect Security, una delle prime società dedicate esclusivamente alla consulenza sulla sicurezza delle applicazioni, formazione, test di penetrazione e pratiche di sviluppo sicuro per le organizzazioni aziendali.

OWASP è una fondazione non profit che si concentra sul miglioramento della sicurezza del software attraverso progetti open-source, collaborazione della comunità globale, educazione e standard dell’industria. Fondata nel 2001, l’organizzazione è diventata una delle autorità più importanti nella sicurezza delle applicazioni, con centinaia di capitoli locali, migliaia di contributori e risorse ampiamente adottate utilizzate da sviluppatori, professionisti della sicurezza, aziende e governi di tutto il mondo. OWASP è nota per progetti come OWASP Top Ten, che identifica i rischi di sicurezza più critici per le applicazioni web, oltre a numerosi framework di sicurezza, strumenti di testing, progetti di documentazione e iniziative di formazione. L’organizzazione opera con una filosofia di neutralità nei confronti dei fornitori, rendendo le sue risorse educative e le linee guida sulla sicurezza liberamente accessibili alla comunità tecnologica globale.

Contrast Security è un’azienda di sicurezza delle applicazioni che si concentra sulla protezione del software dall’interno dell’applicazione in esecuzione, piuttosto che affidarsi esclusivamente a strumenti di scansione esterni. La piattaforma dell’azienda utilizza la tecnologia di strumentazione in fase di esecuzione per fornire visibilità in tempo reale sulle vulnerabilità, gli attacchi, le API, le dipendenze open-source e il comportamento dell’applicazione negli ambienti di sviluppo e produzione. Le offerte dell’azienda coprono aree come Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) e analisi della composizione del software. Contrast Security si è posizionata intorno all’integrazione della sicurezza direttamente nei flussi di lavoro DevSecOps moderni, consentendo ai developer, ai team di sicurezza delle applicazioni e ai team di operazioni di sicurezza di identificare e risolvere le vulnerabilità più rapidamente, mantenendo al contempo cicli di consegna del software rapidi.

Dopo aver contribuito a plasmare la sicurezza delle applicazioni moderne attraverso il tuo lavoro con il progetto Open Web Application Security (OWASP), quale lacuna nell’industria ti ha portato a fondare Contrast Security, e come è stata confermata la tua tesi originale man mano che le sfide di sicurezza sono evolute?

L’industria era sommersa da riscontri teorici statici e non riusciva a concentrarsi sui problemi che realmente contavano. I team di sicurezza avevano scanner che generavano enormi backlogs senza sapere quali vulnerabilità fossero raggiungibili, sfruttabili o sotto attacco in produzione. Abbiamo fondato Contrast su un’idea semplice: le decisioni di sicurezza dovrebbero provenire dall’osservazione diretta delle applicazioni in esecuzione, non dal semplice tentativo di indovinare dall’esterno.

Ultimamente, spero che l’industria progredisca fino al punto in cui possiamo smettere di correre sulla ruota dei roditori nel trovare problemi, risolverli e trovare altri problemi per sempre. Spero che possiamo iniziare a creare software che abbia una solida architettura di sicurezza e un argomento solido che abbia le difese giuste per le minacce attese. La combinazione di sicurezza in fase di esecuzione e intelligenza artificiale ha il potenziale, ma siamo anni lontani.

Hai descritto l’emergere di “vulnerabilità di livello mitologico”. Cosa definisce questa nuova classe di rischi, e perché sono così difficili da rilevare per gli strumenti di sicurezza convenzionali?

Le vulnerabilità di livello mitologico sono difetti che emergono dalla complessità degli stack di software moderni. L’interazione tra il comportamento dei framework, le dipendenze e i modelli architettonici è così complessa che spesso gli sviluppatori non la comprendono appieno. Gli strumenti convenzionali sono ancora ottimizzati per modelli noti relativamente semplici e eventi osservabili. Le vulnerabilità di stile mitologico spesso richiedono una comprensione del comportamento dell’applicazione, del flusso di esecuzione e del contesto di esecuzione a un livello molto più profondo.

Perché intere categorie di vulnerabilità non generano allarmi negli ambienti di sicurezza operativa (SOC) moderni, e cosa rivela questo sulla misura del rischio attuale da parte dei team di sicurezza?

La maggior parte dei SOC è costruita intorno a eventi osservabili: log, firme, traffico di rete, attività di endpoint. Ma molti attacchi a livello di applicazione non producono segnali significativi in questi sistemi. Lo sviluppatore non sapeva che c’era una vulnerabilità e non ha aggiunto alcun logging che avrebbe rivelato uno sfruttamento. Quindi la maggior parte degli exploit delle applicazioni è completamente invisibile nei log. I team SOC possono rispondere solo a ciò che possono vedere. Quindi, man mano che il livello di applicazione e API diventa sempre più importante, è fondamentale assicurarsi di strumentare con sensori di sicurezza che possano rilevare e segnalare comportamenti anomali.

Le architetture di applicazioni moderne come microservizi, API e sistemi serverless sono evolute rapidamente. Dove queste architetture superano gli approcci di sicurezza basati sulla rilevazione attuali?

Queste architetture hanno frantumato il vecchio modello di perimetro. Le richieste ora attraversano decine di servizi, funzioni effimere, API, code e dipendenze di terze parti prima di completare una transazione. La maggior parte dei sistemi di rilevazione vede ancora frammenti invece del percorso di esecuzione completo. Possono ispezionare pacchetti o log, ma non possono capire l’intento, il flusso di dati o se il codice pericoloso è stato effettivamente eseguito. La sicurezza riguarda il contesto, quindi dobbiamo costruire un modello, un gemello digitale, della nostra infrastruttura di applicazioni che ci consenta (o agli agenti di intelligenza artificiale) di ragionare su ciò che stiamo vedendo.

L’OWASP Top Ten continua a evidenziare problemi come progettazione non sicura e componenti vulnerabili. Perché questi rischi persistono nonostante la consapevolezza e la strumentazione diffusa?

La consapevolezza non risolve gli incentivi o la complessità. La maggior parte delle organizzazioni misura ancora il successo in base al volume di scansioni, alla chiusura dei biglietti o alle liste di controllo di conformità, piuttosto che alla riduzione effettiva dell’esposizione.

Allo stesso tempo, le catene di approvvigionamento del software sono esplose in termini di dimensioni. Gli sviluppatori assemblano applicazioni da migliaia di componenti che non hanno scritto e che certamente non hanno valutato per la sicurezza. I team di sicurezza sono sopraffatti nel tentativo di triare rischi teorici e non possono concentrarsi sull’1-2% che realmente conta. Senza prove in fase di esecuzione, la priorità si rompe. E con l’emergere di potenti modelli di intelligenza artificiale e attacchi, il volume sta aumentando esponenzialmente.

Come dovrebbero le organizzazioni ripensare la loro dipendenza dai log e dagli allarmi quando alcune delle vulnerabilità più critiche non lasciano segnali osservabili?

I log sono la prova di ciò che le applicazioni scelgono di segnalare, non necessariamente la prova di ciò che è realmente accaduto. Questa è una distinzione pericolosa. Le organizzazioni devono passare dall’osservazione indiretta all’osservazione diretta. Invece di sperare che uno sfruttamento crei un artefatto rilevabile, i sistemi di sicurezza dovrebbero identificare il comportamento vulnerabile e il comportamento di attacco in fase di esecuzione. Se il codice pericoloso viene eseguito, il sistema dovrebbe saperlo immediatamente — indipendentemente dal fatto che esista o meno un log.

Hai sostenuto la visibilità in fase di esecuzione come soluzione. Cosa significa la vera visibilità in fase di esecuzione nella pratica, e come cambia il modo in cui i team di sicurezza operano quotidianamente?

La vera visibilità in fase di esecuzione significa comprendere cosa sta realmente facendo l’applicazione in produzione: quali route sono esposte, quali librerie sono attive, dove fluiscono i dati sensibili, quale codice è stato eseguito e se un attacco ha raggiunto la funzionalità vulnerabile. Operativamente, cambia la sicurezza da un’esercizio di caccia reattiva in una disciplina di precisione. I team smettono di inseguire enormi backlogs di vulnerabilità e iniziano a concentrarsi sulla piccola percentuale di esposizioni che sono raggiungibili, critiche e attivamente mirate. Ciò migliora drasticamente il rapporto segnale/rumore e la velocità di risposta. In media, solo il 38% delle librerie open-source impacchettate in un’applicazione viene effettivamente caricato in memoria ed eseguito. E non tutto il codice in questo subset viene utilizzato. Quindi una cosa semplice che la sicurezza in fase di esecuzione consente è una concentrazione sul codice che effettivamente viene eseguito, e non su tutte le librerie e funzioni inutilizzate che accompagnano un’applicazione.

Come si confronta la sicurezza basata sulla strumentazione con gli approcci tradizionali come SAST, DAST o monitoraggio del perimetro in termini di efficacia e scalabilità?

Gli strumenti tradizionali inferiscono il rischio dall’esterno. La strumentazione osserva la realtà osservando il codice effettivo mentre viene eseguito. La strumentazione può vedere percorsi di esecuzione reali, comportamento dei framework, contesto di autenticazione, flusso di dati e successo dell’exploit in tempo reale. Elimina enormi categorie di falsi positivi ed espone vulnerabilità che gli strumenti di perimetro mancano completamente.
A scala, quella precisione diventa critica. Le organizzazioni non possono più triare manualmente milioni di riscontri teorici. Le prove in fase di esecuzione stanno diventando l’unico filtro sostenibile. La fase di esecuzione funziona in tempo reale, quindi è una migliore corrispondenza per i flussi di lavoro di sviluppo e CI/CD rispetto alla scansione e alla triage. E la fase di esecuzione è continua, quindi non si è limitati a una visione istantanea della sicurezza.

Man mano che i sistemi di intelligenza artificiale e le applicazioni autonome diventano più diffusi, queste vulnerabilità invisibili diventano più pericolose, e come dovrebbero prepararsi i team?

L’intelligenza artificiale rende le vulnerabilità invisibili molto più pericolose perché accelera entrambi i lati del problema. Gli sviluppatori generano software più velocemente, e gli attaccanti trovano e sfruttano le debolezze più velocemente. Ma la maggior parte dei programmi di sicurezza si affida ancora a processi che coinvolgono gli esseri umani e che non possono operare alla velocità dell’intelligenza artificiale. I team dovrebbero prepararsi in due modi. Primo, costruire difese più solide in fase di esecuzione che possano rilevare, bloccare e contenere gli attacchi in produzione mentre le vulnerabilità vengono risolte. Ciò dà alle organizzazioni una copertura. Secondo, utilizzare l’intelligenza artificiale e l’automazione per scrivere codice più sicuro fin dall’inizio — con una progettazione migliore, testing, revisione e verifica. Altrimenti, stiamo creando rischi più velocemente di quanto possiamo gestirli.

Se stessi consigliando un leader di un moderno Centro di operazioni di sicurezza (SOC) oggi, quali sarebbero i primi passi concreti che dovrebbe intraprendere per colmare questa lacuna di visibilità prima che porti a una violazione importante?

Primo, accettare che la telemetria del perimetro da sola è insufficiente per la sicurezza delle applicazioni moderne. In effetti, è impossibile vedere o fermare molti attacchi a livello di applicazione e API al perimetro. Il SOC ha bisogno di visibilità all’interno delle applicazioni in esecuzione, non solo dell’infrastruttura che le ospita. Secondo, dare priorità alle prove in fase di esecuzione rispetto ai riscontri teorici. Concentrarsi sulle vulnerabilità che sono in codice attivo, identificare percorsi di attacco attivi e servizi esposti effettivamente in esecuzione in produzione. Infine, unificare la sicurezza delle applicazioni e l’ingegneria di rilevamento. Il futuro SOC non può più trattare le applicazioni come scatole nere opache. Le applicazioni sono ora la superficie di attacco principale e necessitano di visibilità di prima classe in fase di esecuzione.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare OWASP o Contrast Security.