Le API stanno alimentando le iniziative di trasformazione digitale in corso presso le aziende di tutto il mondo. Tale è la richiesta da parte delle aziende per una migliore esperienza digitale che i fornitori hanno visto un’esplosione nell’aumento del traffico API attraverso le loro piattaforme negli ultimi anni. Per esempio, il servizio di piattaforma API di Google Apigee ha recentemente notato un aumento del 46% del traffico API a 2,2 trilioni di chiamate.
Sfortunatamente, questo aumento del consumo di API ha portato ad un altrettanto aumento degli attacchi alle infrastrutture API. Ad esempio, marchi noti come LinkedIn, Peloton e Facebook, tra gli altri, hanno subito violazioni dei dati a causa di attacchi alle loro API. Questa tendenza è destinata a continuare; Gartner ha stimato che gli abusi delle API passeranno dal vettore di attacco poco frequente a quello più frequente entro il prossimo anno, con conseguente aumento del rischio di violazioni dei dati per le applicazioni web aziendali.
Perché sorgono problemi di sicurezza delle API
Lo sviluppo delle applicazioni sta cambiando: è passato un po’ di tempo da quando le applicazioni sono state create utilizzando librerie sviluppate in casa in modo monolitico. In tali scenari, un livello lato server controllava la logica, proteggeva tutti i dati e determinava cosa poteva e cosa non poteva essere esposto al client. Con le architetture basate su API, le applicazioni sono composte orchestrando centinaia di servizi interni ed esterni. La logica di controllo avviene principalmente sul lato client e viene totalmente ignorata se le API vengono invocate direttamente.
I team di sviluppo sono più agili che mai: gli sviluppatori hanno accesso a ricchi framework di sviluppo in molte lingue, potenti IDE e molti strumenti open source e commerciali a loro disposizione per aumentare la produttività. Siamo passati dal rilascio di applicazioni ogni sei mesi al rilascio più volte al giorno. D’altra parte, i team di sicurezza delle applicazioni dipendono ancora principalmente da processi manuali per testare le API.
La sicurezza è considerata troppo tardi: i team di sviluppo sono, prima di tutto, concentrati sulla fornitura di funzionalità. Nella maggior parte delle aziende, la sicurezza non è un obiettivo primario; piuttosto, è un collo di bottiglia obbligatorio (spesso temuto!) nel processo di sviluppo. Il controllo delle vulnerabilità della sicurezza è talvolta considerato noioso, con strumenti di analisi che generano centinaia di falsi positivi che gli sviluppatori devono esaminare.
Questi tre problemi creano una combinazione esplosiva: API aumentate fornite a un ritmo frenetico e abbinate a processi manuali guidati da team AppSec che sono ampiamente superati dagli sviluppatori.
Protezione dei dati, non dei perimetri
Ogni volta che un’azienda espone un’API, sta effettivamente “perforando un buco” nel perimetro aziendale per esporre i dati.
Ciò significa che l’obiettivo della sicurezza delle applicazioni deve spostarsi dalla protezione del perimetro dell’organizzazione alla protezione dei dati ovunque siano archiviati e accessibili. Le tradizionali soluzioni per la sicurezza delle applicazioni, come i Web Application Firewall (WAF) generalmente implementati all’edge, non sono più ottimali per proteggere le architetture moderne.
Blocco degli attacchi API: è tutta una questione di contesto
Gli strumenti necessitano di informazioni contestuali per decidere di bloccare il traffico API. Ad esempio, uno scenario in cui diversi attacchi tipici alle API implicano l’uso di termini impropri (ad esempio chiamare GET /tokens invece di POST /tokens) o la manipolazione dei dati stessi (ad esempio l’iniezione di dati tramite l’assegnazione di massa o la perdita di dati). Per un WAF, quelle chiamate sono solo chiamate HTTP valide. Il WAF non ha un contesto per decidere che POST è buono ma GET no, o che /tokens sono validi mentre /admin/tokens non lo sono.
Il contesto può essere statico o dinamico (ad esempio, costruito in base al traffico), ma in ogni caso gli strumenti necessitano di contesto per prendere decisioni appropriate. Il contesto definisce le singole chiamate valide, le impostazioni di sicurezza richieste, le regole di autorizzazione, il flusso di lavoro valido delle chiamate e il flusso di dati attraverso l’API. Le informazioni di contesto possono essere ugualmente utilizzate al momento del test o dell’esecuzione.
Senza contesto, gli strumenti devono ricorrere a un modello di sicurezza negativo e, poiché non dispongono di informazioni sul traffico, la tua unica soluzione è descrivere ciò che ritieni inaccettabile tramite regole e schemi. Man mano che sorgono nuovi exploit, è necessario scrivere nuove regole.
Contesto della costruzione in fase di progettazione
Fortunatamente, con le API, possiamo descrivere il contratto API con standard di fatto come OpenAPI o AsyncAPI. Ancora meglio, possiamo farlo prima di scrivere qualsiasi codice, in fase di progettazione.
Il contratto API diventa una parte fondamentale del contesto richiesto per testare la sicurezza dell’API, ma è anche fondamentale per proteggere l’API in fase di esecuzione. Consente un approccio positivo al modello di sicurezza che è stato a lungo un obiettivo della sicurezza. Se sai quale deve essere il traffico, puoi negare l’accesso a tutto tranne il traffico previsto e non è necessario creare manualmente regole per rilevare il traffico dannoso o sfruttare tecnologie come l’apprendimento automatico per indovinare quale dovrebbe essere il traffico.
Una descrizione leggibile dalla macchina dell’API consente inoltre l’automazione in ogni fase del ciclo di vita dell’API, inclusa l’analisi automatizzata dei contratti, test funzionali automatizzati, convalida automatizzata dei dati e test di sicurezza automatizzati migliorati. Ciò significa che i team di sicurezza delle applicazioni possono concentrarsi su complessi scenari di pen-test e adattarli ai livelli di agilità dei team di sviluppo.
Preparati a proteggere, preparati a vincere
Abbiamo visto come i professionisti della sicurezza stanno tentando di sfruttare le tecnologie esistenti che vengono tradizionalmente distribuite per proteggere le applicazioni e adattarle per proteggere le API. Sfortunatamente, sono basati su un modello di sicurezza negativo e con ogni nuova API che rappresenta un percorso di attacco potenzialmente unico nei sistemi di un’azienda, queste soluzioni non si adatteranno per affrontare la sfida.
È emersa una nuova generazione di soluzioni di sicurezza API progettate per affrontare un approccio del modello di sicurezza positivo e negativo alla protezione delle API. Gli agenti di sicurezza, come parte del loro processo decisionale, devono decidere quale sia il loro obiettivo finale. Si tratta di incorporare la sicurezza nel ciclo di vita dell’API, dalla progettazione alla produzione? O sta implementando patch in fase di esecuzione per risolvere problemi noti? O una miscela di entrambi? Quello che è certo è che con una superficie di attacco API in continua crescita, il professionista della sicurezza deve considerare attentamente le proprie esigenze di sicurezza API e assicurarsi che le soluzioni selezionate siano in linea con la strategia per la posizione di sicurezza che intendono adottare per oggi e domani
L7 Defense è pioniera nell’applicazione di una nuova tecnologia di “apprendimento senza supervisione” denominata Ammune ™, che si distingue per la sua eccezionale precisione differenziando il traffico Internet “buono” da quello “cattivo”, in tempo reale. Ammune ™, che ha origine dal modello del sistema immunitario, protegge dagli attacchi botnet più avanzati attualmente potenziati dall’IA.