Progettare un ambiente open banking sicuro
This post is also available in:
Inglese 
Francese 
Tedesco 
Portoghese, Brasile 
Spagnolo 
Russo
Molti di noi usano prodotti innovativi come Mint, Chime o Venmo senza sapere che sono costruiti su API Open Banking.
L’iniziativa Open Banking è principalmente guidata dal regolamento europeo Payment Services Directive 2 (PSD2) per aprire i dati chiusi e proprietari dei clienti delle banche a fornitori terzi esterni (TPP) in modo sicuro attraverso API pubblicamente disponibili. L’obiettivo è quello di stimolare l’innovazione e favorire la competizione. A differenza del banking tradizionale dove tutti i dati dei clienti sono controllati dalla banca madre, nell’open banking i dati dei clienti sono esposti in modo sicuro ai TPP mediante API e previo consenso da parte del cliente. Gartner prevede che entro il 2022 gli attacchi alle API (application programming interface) diventeranno il vettore di attacco più frequente, causando violazioni di dati per le applicazioni web aziendali. La sfida posta dalla sicurezza delle API richiede una copertura delle minacce, una facile integrazione e una visibilità completa sia per le API documentate che per quelle non documentate.
Uno studio Celent del 2018 prevede che il numero di istituzioni finanziarie (IF) statunitensi con portali open banking per facilitare l’accesso dei TPP ai dati finanziari e di altro tipo dei consumatori aumenterà da 20 a oltre 200 entro la fine del 2021. Nel primo trimestre del 2020 c’erano oltre 300 TPP registrati nel Regno Unito. Altri paesi, come l’India e l’Australia, hanno seguito l’approccio dell’UE e hanno un fiorente ecosistema open banking.
API open banking – Cosa potrebbe andare storto?
Prima dell’Open Banking, molti innovativi fornitori FinTech usavano lo screen scraping per accedere ai dati dei clienti, comprese le credenziali utente, senza che la banca madre ne venisse a conoscenza. Le API Open Banking mirano a semplificare le implicazioni legali della condivisione delle credenziali e delle informazioni dei clienti attraverso le API, il consenso e l’autorità di regolamentazione,
Per quanto le API diano importanti vantaggi, esse introducono anche problemi di disponibilità e sicurezza quali:
- Interruzione del servizio: servizi API non disponibili a causa di errori di sicurezza, rete e configurazione delle applicazioni, attacchi API denial of service o interruzioni delle applicazioni o dell’infrastruttura di autenticazione.
- Problemi di fiducia: molte soluzioni per l’OB sono costruite su un’infrastruttura cloud-only o ibrida. Tuttavia, la migrazione sui cloud pubblici genera problemi di fiducia a causa dell’incompatibilità delle soluzioni di sicurezza, problemi di configurazione in ambienti diversi, configurazioni errate e problemi intorno alle policy e ai profili di sicurezza delle applicazioni.
- Maggiore superficie di attacco: i diversi tipi di attacco alle API sono piuttosto comuni. Un’indagine effettuata da Radware ha rivelato che, almeno una volta al mese, il 55% delle aziende sperimenta un attacco DoS, il 48% una qualche forma di attacco injection e il 42% una manipolazione di elementi/attributi. Altri attacchi includono attacchi di autenticazione e autorizzazione API, attacchi embedded come SQL injection, cross-site scripting (XSS) e attacchi bot.
- Attacchi bot alle API: gli attacchi bot sono programmi automatici sviluppati per entrare negli account degli utenti, rubare identità, effettuare frodi di pagamento, scraping di contenuti, prezzi, coupon o dati, diffondere spam o propaganda e incidere negativamente sulle attività aziendali.
- Furto di dati: molte API trattano informazioni sensibili di identificazione personale (PII). La combinazione tra informazioni sensibili e riservate e mancanza di visibilità su come API e applicazioni di terze parti operano è un incubo per la sicurezza in caso di violazione.
- API non documentate ma pubblicate: le API non documentate possono accidentalmente esporre dati sensibili se non testate ed essere aperte a manipolazioni ed exploit di vulnerabilità.
Il mio gateaway API e WAF non sono sufficienti?
Data la variabilità delle minacce, la sicurezza delle API richiede una combinazione di controlli, tra i quali:
- Controlli dell’accesso API per autenticazione, autorizzazione e gestione dell’accesso
- Protezione dagli attacchi BOT alle API
- Protezione da attacchi DDoS e attacchi che minano la disponibilità dei servizi
- Protezione da attacchi embedded, vulnerabilità API e manipolazioni API
- Prevenzione di perdite di dati PII ed eccessive esposizioni di dati
- Protezione da frodi e truffe di phishing
Tradizionalmente, la protezione DDoS, i WAF e i gateaway API sono stati gli strumenti primari di sicurezza usati per la protezione API. Per quanto i gateaway API offrano gestione API e integrazione con capacità di autenticazione e autorizzazione, le loro capacità di sicurezza API, protezione da bot e protezione delle applicazioni web sono limitate o assenti. La maggior parte dei WAF non comprende le differenze tra API e normali applicazioni web. Anche se capiscono tale differenza, essi non ispezionano o rilevano i rischi di sicurezza reali associati alle API.
[Ti potrebbe interessare anche: 4 domande da fare sulla compliance Open Banking]
I bot non sono sempre amichevoli o visibili!
Anche le API sono esposte ad attacchi bot. Secondo Forrester, più di un quarto delle richieste web provengono da bot malevoli. Bot di questo tipo sono stati osservati mentre tentavano attacchi automatizzati ad API, come account takeover, denial of service, abuso di dati di pagamento e denial of inventory. Proteggere le API dagli attacchi automatici non è come proteggere le applicazioni web e mobile, semplicemente perché i comportamenti dei bot, il flusso di navigazione e gli indicatori sono diversi.
La mancanza di appositi strumenti per la gestione dei bot nella maggior parte delle aziende mette queste organizzazioni a maggior rischio di potenziali attacchi lanciati con successo da attori malevoli attraverso le API, per es. credential stuffing, brute force e tentativi di scraping.
Cosa serve per mettere al sicuro le API Open Banking?
La soluzione Radware è progettata per proteggere le API da hacker e attacchi su scala nazionale. Tale soluzione protegge le API delle applicazioni da attacchi denial of service, attacchi a livello di applicazione e attacchi bot oltre che da vulnerabilità e manipolazioni delle API, previene le interruzioni di servizio e risolve i dubbi di fiducia e sicurezza dei clienti che migrano verso un’implementazione multi-cloud o ibrida.
Conclusione:
Per quanto l’open banking sia ancora all’inizio, sta crescendo molto rapidamente. L’open banking apre i dati dei clienti a fornitori terzi attraverso le API, al fine di fornire servizi innovativi. Per contro, ciò implica una superficie di minaccia più ampia che deve essere protetta da abusi e intenzioni malevole. Per prosperare in questo ambiente, banche e fintech dovranno offrire soluzioni che incoraggiano la fiducia dei clienti attraverso soluzioni sicure. Per maggiori informazioni su come Radware può aiutarti, visita Frictionless Security At The Pace of Innovation | Radware
Prakash Sinha è un dirigente tecnologico ed evangelista per Radware con oltre 29 anni di esperienza in strategia, gestione prodotti, marketing prodotti e progettazione. Ha fatto parte dei team esecutivi di quattro startup di software e infrastrutture di rete tutte acquisite. Prima di Radware, Prakash ha guidato la gestione dei prodotti per Citrix NetScaler ed è stato determinante nell’introduzione sul mercato delle linee di prodotti NetScaler multi-tenant e virtualizzati. Prima di Citrix, ha ricoperto posizioni di leadership in architettura, ingegneria e gestione dei prodotti presso aziende tecnologiche leader come Cisco, Informatica e Tandem Computers. Ha conseguito una laurea in ingegneria elettrica presso BIT, Mesra e un MBA presso la Haas School of Business della UC Berkeley.
