La tecnologia continua ad avanzare a un ritmo senza precedenti. Lo sviluppo e l’utilizzo di API (Application Programming Interface) sono un esempio particolarmente degno di nota.
Gli ultimi Salt Labs State of API Security report ha rilevato che il traffico API complessivo è aumentato del 168% in 12 mesi, con un aumento del traffico di attacchi API del 117% nello stesso periodo di tempo. Forse è comprensibile che molti CISO facciano fatica a tenere il passo.
Secondo lo stesso rapporto, il 94% delle organizzazioni ha subito un incidente di sicurezza API nell’arco di 12 mesi. In questo raggruppamento sono inclusi nomi familiari come Experian, Peloton e Starbucks. Perfino Lego ha avuto una chiamata ravvicinata, rettificando una vulnerabilità API potenzialmente catastrofica alla fine dell’anno scorso. Grandi aziende, con ingenti budget per la sicurezza, subiscono costantemente incidenti di sicurezza delle API. Chiaramente, le tradizionali tecniche di sicurezza delle applicazioni semplicemente non sono all’altezza quando si tratta di proteggere le API.
Con questo in mente, abbiamo parlato con Yaniv Balmas, vicepresidente della ricerca presso Salt Security per chiarire alcune delle domande più frequenti sulla sicurezza delle API.
BN: L’architettura zero trust può proteggere le API?
YB: Sfortunatamente, molti rischi legati alle API non possono essere mitigati da zero trust. L’obiettivo di zero trust è limitare l’accesso, mentre le API hanno bisogno dell’accesso per funzionare. La maggior parte delle API sono pubbliche o aperte, progettate per essere utilizzate da Internet nel suo complesso e da un’ampia base di clienti, presentando sfide uniche per Zero Trust.
Inoltre, gli attacchi API si verificano in genere in canali attendibili e sessioni autenticate. Gli aggressori sanno che se possono ottenere le chiavi o le credenziali di un utente autorizzato, possono accedere a dati preziosi. Effettuando il piggyback o il dirottamento di sessioni autenticate con cookie di sessione attiva rubati, token di autenticazione, sfide di autenticazione a due fattori, chiavi API e altro materiale di autenticazione, gli hacker non sono ostacolati dall’architettura zero trust. Tieni presente che, secondo il rapporto sullo stato della sicurezza delle API, uno sbalorditivo 94% degli exploit si verifica contro le API autenticate.
Quando si tratta di zero trust, le organizzazioni devono andare oltre i principi di autenticazione e autorizzazione. Richiedono la protezione del runtime API per convalidare continuamente l’accesso e i comportamenti di un utente autorizzato rispetto alle risorse API, individuare le anomalie e individuare i malintenzionati.
BN: Le offerte di sicurezza cloud possono proteggere le API?
YB: Sebbene alcuni fornitori di sicurezza cloud forniscano strumenti come la gestione delle API o i gateway API, prodotti puntuali come questi non sono sufficienti per proteggere le aziende dagli attacchi alle API. Questi strumenti hanno funzionalità di sicurezza API limitate sia a livello di applicazione che di API, lasciando le API sottoprotette. Gli attacchi alle API sono effettivamente exploit zero-day, il che significa che gli strumenti di sicurezza progettati per cercare comportamenti”cattivi”noti, ad esempio firme o IP nella lista nera, non saranno mai in grado di proteggere adeguatamente le API. Vale anche la pena notare che poiché le API sono la logica dell’applicazione, i clienti cloud hanno la responsabilità ultima di proteggerle all’interno del modello di responsabilità condivisa per la sicurezza.
BN: Perché IAM, WAF o API non possono i gateway proteggono le API?
YB: Sebbene IAM, WAF e gateway API siano tutti strumenti necessari e importanti nello stack di sicurezza di ogni organizzazione, non riescono a proteggere le API, soprattutto perché non lo fanno fornire la visibilità o i controlli di sicurezza necessari.
Gli aggressori aggirano costantemente i controlli di accesso, oltre a raccogliere chiavi e token. Gli hacker contemporanei sono esperti nell’eludere i controlli di accesso, nel piggyback su una sessione utente autenticata o nella raccolta di materiale di autenticazione dal traffico, dall’archiviazione del dispositivo o dal codice dell’applicazione. Queste tecniche di attacco non possono essere rilevate dalle soluzioni IAM, API o WAF.
Questi strumenti inoltre non riescono a rilevare i problemi specifici delle API, ad esempio l’abuso della logica aziendale e gli exploit di autorizzazione, perché si basano su firme e regole per il rilevamento degli attacchi. A peggiorare le cose, anche i componenti di gestione delle API ad essi inerenti potrebbero essere sfruttabili.
Inoltre, IAM, WAF e gateway API si basano tutti sul proxy. Poiché i modelli proxy rallentano la comunicazione API, le organizzazioni in genere non riescono a mediare ogni API in uso con un gateway o WAF, in particolare per le API interne o interne. Ciò si traduce in una mancanza di visibilità su come vengono utilizzate tali API.
BN: Le API possono essere protette con la protezione del carico di lavoro?
YB: Sicurezza del carico di lavoro le protezioni offrono molti vantaggi. Tra le altre cose, aiutano a fornire la sicurezza dell’infrastruttura per garantire che non si stiano eseguendo carichi di lavoro su versioni software vulnerabili e sono anche utili per bloccare l’accesso a un carico di lavoro a utenti esterni. Tuttavia, non riescono a fornire l’API o il contesto a livello di applicazione, non riuscendo così a proteggere le API stesse.
BN: Quanto è efficace lo spostamento a sinistra per proteggere le API?
YB: Sebbene l’implementazione della sicurezza nella fase di sviluppo sia una pratica utile, il supporto con spostamento a sinistra non significa che ogni API sarà protetta in fase di pre-produzione. Gli strumenti di test per sviluppatori semplicemente non sono in grado di identificare tutte le vulnerabilità. Molti problemi di sicurezza delle API comuni non possono essere identificati come parte di scansioni automatiche di progettazione, sviluppo e build con strumenti di analisi e test di sicurezza comuni: i difetti della logica aziendale non possono essere individuati a meno che le API non vengano esercitate.
Credito fotografico: Panchenko Vladimir/Shutterstock