Sicurezza delle API nell’adozione Zero Trust: ecco problemi e raccomandazioni

Le Application Programming Interface (API) costituiscono l’infrastruttura portante della maggior parte del traffico Internet odierno.

Tuttavia, le vulnerabilità derivanti da difetti di progettazione, errori di implementazione o logiche applicative inadeguate hanno reso le API un obiettivo primario per gli attori malevoli.

Ecco il ruolo fondamentale della sicurezza delle API nell’ambito delle architetture Zero Trust, analizzando le principali vulnerabilità, le sfide di implementazione e le strategie di mitigazione e focalizzando l’attenzione sull’integrazione tra la sicurezza delle API e i principi Zero Trust, sull’importanza del monitoraggio continuo e sul ruolo emergente del machine learning nella protezione delle API.

Le API nelle infrastrutture organizzative

Le Application Programming Interface (API) costituiscono le componenti fondamentali dell’ecosistema digitale moderno, fungendo da connettori tra servizi, applicazioni e sistemi distribuiti (Fielding & Taylor, 2002).

La crescente adozione di architetture basate su microservizi e l’espansione di Internet of Things (IoT) hanno fatto aumentare esponenzialmente il numero e la complessità delle API implementate nelle infrastrutture organizzative (Newman, 2015).

Parallelamente, l’evoluzione del panorama delle minacce informatiche ha portato alla formulazione del paradigma Zero Trust, che postula l’assenza di fiducia implicita in qualsiasi entità, a prescindere dalla sua posizione rispetto al perimetro di rete (Rose et al., 2020).

L’intersezione tra la sicurezza delle API e il paradigma Zero Trust rappresenta un ambito di ricerca emergente e di crescente importanza per la sicurezza informatica aziendale.

Fondamenti delle API e vulnerabilità intrinseche

Le principali vulnerabilità che caratterizzano le API riguardano caratteristiche architetturali delle API, superficie di attacco estesa, cascading failures nei microservizi e vulnerabilità delle integrazioni di terze parti.

Caratteristiche architetturali delle API

Le API moderne implementano principalmente i pattern REST (Representational State Transfer) o GraphQL e operano come interfacce standardizzate per l’accesso alle risorse e alle funzionalità di sistema (Rodriguez et al., 2016).

Le funzioni tipiche includono l’autenticazione, la gestione delle sessioni, l’accesso ai database e la comunicazione machine-to-machine (M2M).

Superficie di attacco estesa

L’implementazione delle API aumenta significativamente la superficie di attacco di un’infrastruttura di rete. Ogni punto di accesso API rappresenta un potenziale vettore di ingresso per attacchi quali injection, autenticazione difettosa ed esposizione dei dati (OWASP, 2023).

La moltiplicazione degli endpoint è particolarmente critica nelle architetture a microservizi, in cui la suddivisione dei servizi in unità più piccole genera una
proliferazione di interfacce di comunicazione.

Cascading failures nei microservizi

Le architetture a microservizi, sebbene offrano vantaggi in termini di modularità e scalabilità, introducono il rischio di cascading failure (Nygard, 2018). L’eccessiva interconnessione tra le API può generare un effetto a catena per cui il fallimento di un singolo servizio si propaga all’intera infrastruttura, compromettendo la disponibilità dell’intero sistema.

I pattern Circuit Breaker e Bulkhead sono stati proposti come meccanismi di contenimento (Richardson, 2018).

Vulnerabilità delle integrazioni di terze parti

L’uso di API di terze parti o di codice fornito da esterni introduce rischi significativi per la sicurezza della supply chain (Ohm et al., 2020).

L’opacità dei processi di implementazione e delle dipendenze transitive può nascondere vulnerabilità non documentate, come dimostrato dall’attacco SolarWinds (Sudhakar, 2021).

Zero Trust architecture e API security

Cerchiamo di capire quali peculiarità della Zero Trust Architecture possono mitigare le vulnerabilità intrinseche del mondo API.

Principi fondamentali dello Zero Trust

Il modello Zero Trust si basa su tre principi fondamentali: la verifica esplicita di ogni richiesta, l’applicazione del principio del least privilege access e l’assunzione della compromissione (Rose et al., 2020).

A differenza dei modelli tradizionali basati sul perimetro, il modello Zero Trust considera la rete interna potenzialmente ostile quanto quella esterna.

Convergenza tra API Security e Zero Trust

Le API rappresentano una manifestazione naturale dei principi Zero Trust applicati alla comunicazione tra applicazioni.

Ogni chiamata API dovrebbe essere autenticata, autorizzata e validata, a prescindere dalla sua origine (Buck et al., 2021). Questo approccio è particolarmente rilevante per le API che operano esclusivamente all’interno del perimetro organizzativo e che, nelle architetture legacy, sono tradizionalmente considerate “affidabili”.

I pilastri della Zero Trust Architecture – identità, dispositivi, applicazioni, dati e
infrastruttura – trovano nelle API un elemento trasversale che richiede una protezione stratificata (Kindervag, 2010).

L’implementazione di API gateway con capacità di applicazione delle policy rappresenta un componente architetturale essenziale.

Maturità Organizzativa

L’implementazione efficace della sicurezza delle API nell’ambito Zero Trust richiede un elevato livello di maturità organizzativa.

Mentre aspetti quali l’Identity and Access Management (IAM) e la micro-segmentazione sono oggetto di offerte commerciali consolidate, la sicurezza delle API richiede competenze specialistiche nell’ambito della sicurezza delle applicazioni e della governance architetturale che sono difficilmente reperibili sul mercato (Gartner, 2022).

Criticità implementative: la progettazione insufficiente

La letteratura evidenzia come le implementazioni di bassa qualità delle API si manifestino attraverso tempi di risposta inconsistenti, una disponibilità ridotta e un’esposizione a rischi per la sicurezza (Gartner, 2022).

Questi fattori minano la fiducia degli sviluppatori e ostacolano l’adozione delle API aziendali.

La progettazione efficace richiede:

• design for purpose: le API devono essere progettate con obiettivi di business chiari, tenendo in considerazione i requisiti funzionali e non funzionali (Jacobson et al., 2011);
• secure coding practices: l’applicazione di principi quali la validazione degli input, l’encoding degli output e la gestione sicura delle sessioni (OWASP, 2021);
• testing rigoroso: l’implementazione di strategie di testing multidimensionali che includono unit testing, testing di integrazione, testing end-to-end e fuzz testing (Takanen et al., 2008).

Deficit documentale

La documentazione inadeguata delle API rappresenta una vulnerabilità critica spesso sottovalutata.

Le API non documentate o “shadow API” possono rimanere esposte senza i necessari controlli di sicurezza, creando delle falle nella postura di sicurezza organizzativa (Salt Security, 2023).

L’adozione di standard come l’OpenAPI Specification (OAS) facilita la documentazione strutturata e la gestione del ciclo di vita.

Insufficiente focus sulla security

La scarsa attenzione alla sicurezza delle API espone le organizzazioni a rischi con impatti finanziari e di reputazione significativi (Gartner, 2022).

La reputazione organizzativa è un asset intangibile, ma critico, che risulta particolarmente vulnerabile in seguito a data breach causati da vulnerabilità delle API.

Monitoring, logging e analytics

Come anticipato, uno dei pilastri fondamentali delle architetture Zero Trust è rappresentato dal monitoraggio continuo dei sistemi di sicurezza. Come diceva uno spot famoso: “La potenza è nulla senza controllo”. Perciò, l’efficacia delle API dipende anche dal controllo della sicurezza.

Requisiti di visibilità

Nel contesto Zero Trust, la visibilità completa è un requisito imprescindibile. Ogni richiesta API deve essere oggetto di un log completo che includa: l’origine della richiesta, i parametri di input, l’orario, l’esito dell’operazione e i dati di risposta (quando appropriato dal punto di vista della privacy) (Scarfone & Mell, 2007).

Integrazione con Siem

L’integrazione delle API con i sistemi Security Information and Event Management (SIEM) consente di correlare gli eventi provenienti da diverse fonti e di individuare eventuali anomalie (Nicolett e Kavanagh, 2011).

La centralizzazione del logging è particolarmente critica nelle architetture distribuite, in cui le API costituiscono i punti di orchestrazione.

API gateway e policy enforcement

I gateway API fungono da piano di controllo centralizzato e implementano funzionalità quali il rate limiting, l’autenticazione/autorizzazione, la trasformazione e il logging (Indrasiri e Siriwardena, 2018).

L’architettura gateway consente di applicare in modo uniforme le policy di sicurezza a tutto il portafoglio di API.

Machine learning per API Security

In un contesto ad alta intensità innovativa e tecnologica come quello delle API, l’adozione del machine learning per elevare il livello di sicurezza è imprescindibile.

Limiti degli approcci tradizionali

I metodi tradizionali di cybersecurity si basano principalmente su approcci statici, quali la rilevazione basata su firme e il filtraggio basato su regole (Sommer e Paxson, 2010).

Questi approcci presentano significative limitazioni nel rilevamento degli attacchi zero-day e nella gestione dei modelli di attacco in continua evoluzione.

Anomaly detection dinamica

Gli algoritmi di machine learning consentono di implementare sistemi di rilevazione delle anomalie dinamici che apprendono i modelli comportamentali normali e identificano le deviazioni indicative di attività malevole (Chandola et al., 2009).

Tecniche quali il clustering, la classificazione supervisionata e il deep learning (che in modo simile al machine learning, prende decisioni sulla base di modelli passati, modificando in maniera autonoma) hanno dimostrato la loro efficacia nel settore della sicurezza delle API (Buczak e Guven, 2016).

Behavioral analysis

L’analisi comportamentale basata sul ML consente di costruire profili di utilizzo normale per utenti, applicazioni e servizi e di rilevare anomalie che potrebbero indicare compromissioni o abusi (Sommer & Paxson, 2010).

Questo approccio si è rivelato particolarmente efficace per il rilevamento di attacchi sofisticati come il credential stuffing e l’account takeover.

API Security nel Cots

Il mercato del software ha ormai da tempo adottato il modello di acquisizione denominato Commercial Off-The-Shelf (COTS).

In pratica, prima di sviluppare un componente, si cerca se qualcuno lo ha già realizzato e lo mette a disposizione di altri. Le API sono entrate a far parte di questo modello di business.

Evoluzione degli Acquisition models

Molte grandi aziende hanno progressivamente orientato le proprie strategie di acquisizione verso l’adozione di prodotti Commercial Off-The-Shelf (COTS), spinte da obiettivi di riduzione dei costi e di accelerazione del time-to-deployment (GAO, 2021).

Integrazione multi-vendor

Gli scenari Cots prevedono tipicamente l’integrazione di soluzioni di vari fornitori
specializzati in domini specifici quali, ad esempio, le tecnologie per i droni, l’edge computing e la gestione dei dati aziendali.

Le API costituiscono il tessuto connettivo di queste architetture composite, ma introducono complessità in termini di sicurezza, governance e interoperabilità (Hossain et al., 2009).

API-to-API communication

L’emergere di modelli di comunicazione API-to-API e API-to-Machine rappresenta una deviazione dagli usi tradizionali delle API, storicamente orientate all’interazione human-to-machine (Fielding e Taylor, 2002).

Questo paradigma richiede l’implementazione di robusti meccanismi di autenticazione e autorizzazione reciproca, quali il flusso client credentials di OAuth 2.0 e la mutua TLS (mTLS) (Hardt, 2012).

API e AI Agents

Tra i fruitori delle API non potevano mancare gli AI Agent. Si tratta di agenti che chiedono ad altri agenti di risolvere un problema tramite un’API.

Large language models e API orchestration

I Large Language Models (LLM) contemporanei integrano la capacità di chiamare funzioni che consentono l’orchestrazione dinamica delle API per l’esecuzione di task complessi (OpenAI, 2023).

Questa convergenza tra IA e API amplifica sia le opportunità che i rischi
per la sicurezza.

Chain-of-Thought e API composition

Gli agenti AI possono comporre catene di chiamate API in cui l’output di un LLM alimenta l’input di un servizio specializzato per l’analisi o il trattamento ulteriore dei dati (Wei et al., 2022).

Questo modello richiede un’attenzione particolare alla propagazione del contesto di sicurezza e al controllo degli accessi lungo la catena di esecuzione.

Requisiti di logging e auditability

Le interazioni tra gli agenti AI e le API richiedono meccanismi di log estesi per garantire la verificabilità e l’analisi forense.

La natura non deterministica degli LLM introduce ulteriori sfide in termini di riproducibilità e spiegabilità (Ribeiro et al., 2016).

Buone pratiche e raccomandazioni

Sulla base dell’analisi condotta e delle criticità evidenziate, si propongono una serie di raccomandazioni per l’adozione di API in contesti Zero Trust:

• implementare l’API discovery continuo: utilizzare strumenti automatizzati per l’identificazione di tutte le API esposte, incluse le shadow API;
• adottare API-first design: integrare security requirements nella fase di design attraverso threat modeling e security reviews (McGraw, 2006);
• applicare i principi Zero Trust: implementare l’autenticazione e l’autorizzazione granulare per ogni chiamata API, indipendentemente dalla sua origine;
• centralizzare la governance: stabilire un framework di governance delle API che definisca standard, processi di approvazione e gestione del ciclo di vita;
• implementare il monitoraggio completo: integrare il log delle API con il SIEM e implementare l’alerting basato su ML per la rilevazione delle anomalie;
• mantenere la documentazione aggiornata utilizzando standard quali OpenAPI Specification e automatizzandone la generazione;
• effettuare test di sicurezza regolari: implementare programmi di penetration
  testing specifici per le API e integrare i test di sicurezza nella pipeline CI/CD;
• gestione del rischio di dipendenza: implementare l’analisi della composizione del software (SCA) per identificare le vulnerabilità nelle dipendenze di terze parti.

La convergenza tra la sicurezza delle API e il modello Zero Trust

La sicurezza delle API rappresenta una componente critica e spesso sottovalutata delle architetture Zero Trust.

L’aumento delle superfici di attacco, la complessità delle architetture a microservizi e l’emergere di nuovi modelli di utilizzo, come gli agenti AI e l’integrazione COTS, rendono necessaria l’adozione di approcci strutturati alla sicurezza delle API.

La convergenza tra la sicurezza delle API e il modello Zero Trust non rappresenta semplicemente una giustapposizione di tecnologie, ma richiede un ripensamento architetturale che ponga la verifica continua e il principio del minimo privilegio al centro della progettazione delle applicazioni.

L’integrazione di tecniche di machine learning può migliorare significativamente le capacità di rilevazione e risposta, ma richiede investimenti in termini di competenze specialistiche e infrastrutture di monitoraggio.

Le organizzazioni che intendono implementare efficacemente la sicurezza delle API nel contesto Zero Trust devono perseguire la maturità organizzativa attraverso una governance strutturata, l’adozione di best practice per lo sviluppo sicuro e un impegno costante nel monitoraggio e nel miglioramento continuo.

Solo adottando un approccio olistico è infatti possibile mitigare i rischi intrinseci delle API e sfruttarne appieno il potenziale in qualità di abilitatori della trasformazione digitale.

Riferimenti

• Buck, C., Olenberger, C., Schweizer, A., Völter, F., & Eymann, T. (2021). Never trust, always verify: A multivocal literature review on current knowledge and research gaps of zero-trust. Computers & Security, 110, 102436.
• Buczak, A. L., & Guven, E. (2016). A survey of data mining and machine learning methods for cyber security intrusion detection. IEEE Communications Surveys & Tutorials, 18(2), 1153-1176.
• Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly detection: A survey. ACM Computing Surveys, 41(3), 1-58.
• Fielding, R. T., & Taylor, R. N. (2002). Principled design of the modern web architecture.
• ACM Transactions on Internet Technology, 2(2), 115-150.
• Gartner. (2022). How to Avoid the Top 5 API Adoption Pitfalls. Gartner Research.
• GAO. (2021). Defense Acquisitions: DoD’s Use of Other Transaction Authority. Government Accountability Office Report.
• Hardt, D. (2012). The OAuth 2.0 Authorization Framework (RFC 6749). Internet Engineering Task Force.
• Hossain, E., Karim, A., & Jamalipour, A. (2009). Multi-vendor interoperability for network virtualization in wireless networks. IEEE Wireless Communications, 16(5), 60-67.
• Indrasiri, K., & Siriwardena, P. (2018). Microservices for the Enterprise: Designing, Developing, and Deploying. Apress.
• Jacobson, I., Booch, G., & Rumbaugh, J. (2011). The Unified Software Development Process. Addison-Wesley.
• Kindervag, J. (2010). No More Chewy Centers: Introducing the Zero Trust Model of Information Security. Forrester Research.
• McGraw, G. (2006). Software Security: Building Security In. Addison-Wesley.
• Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O’Reilly Media.
• Nicolett, M., & Kavanagh, K. M. (2011). Magic Quadrant for Security Information and Event Management. Gartner Research.
• Nygard, M. T. (2018). Release It!: Design and Deploy Production-Ready Software (2nd ed.). Pragmatic Bookshelf.
• Ohm, M., Plate, H., Sykosch, A., & Meier, M. (2020). Backstabber’s knife collection: A review of open source software supply chain attacks. Detection of Intrusions and Malware, and Vulnerability Assessment, 23-43.
• OpenAI. (2023). Function Calling and Other API Updates. OpenAI Blog.
• OWASP. (2021). OWASP Secure Coding Practices Quick Reference Guide. OWASP Foundation.
• OWASP. (2023). API Security Top 10. OWASP Foundation. Ribeiro, M. T., Singh, S., & Guestrin, C. (2016). “Why should I trust you?” Explaining the predictions of any classifier. Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 1135-1144.
• Richardson, C. (2018). Microservices Patterns. Manning Publications.
• Rodriguez, A., Fernandez-Medina, E., & Piattini, M. (2016). A BPMN extension for the modeling of security requirements in business processes. IEICE Transactions on Information and Systems, 90(4), 745-752.
• Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (NIST Special Publication 800-207). National Institute of Standards and Technology.
• Salt Security. (2023). State of API Security Report Q1 2023. Salt Security.
• Scarfone, K., & Mell, P. (2007). Guide to Intrusion Detection and Prevention Systems (IDPS) (NIST Special Publication 800-94). National Institute of Standards and Technology. Sommer, R., & Paxson, V. (2010). Outside the closed world: On using machine learning for network intrusion detection. 2010 IEEE Symposium on Security and Privacy, 305-316.
• Sudhakar, S. (2021). SolarWinds hack: A wake-up call for supply chain security. Computer Fraud & Security, 2021(3), 6-8.
• Takanen, A., Demott, J. D., & Miller, C. (2008). Fuzzing for Software Security Testing and Quality Assurance. Artech House.
• Wei, J., Wang, X., Schuurmans, D., Bosma, M., Chi, E., Le, Q., & Zhou, D. (2022). Chain of thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35, 24824-24837.