La sicurezza delle API integrata nel sistema di conformità alle normative: sei esempi di cui tenere conto
D: Perché le aziende vengono sanzionate se si verificano problemi di sicurezza alle API?
R: Perché gli enti di controllo iniziano a capire ciò che i criminali già sanno bene: Le API vulnerabili o non correttamente configurate sono prevalenti, facili da violare e spesso non protette.
È sufficiente una sola API vulnerabile
Ogni volta che un cliente, un partner o un vendor interagisce con la vostra azienda in modo digitale, c'è un' API "dietro le quinte" che facilita un rapido scambio dei dati, spesso sensibili. Oggi, i criminali sanno che non sempre devono utilizzare schemi complessi che richiedono più operazioni per rubare i vostri dati, anzi, sanno che possono bypassare eventuali componenti che ostacolano il loro cammino, come ad esempio, le vostre applicazioni, e puntare direttamente alle API.
Fa differenza se un documento normativo di 200 pagine descrive esplicitamente, implica sottilmente o indica vagamente che la protezione delle API è importante? Non proprio. Poiché una violazione di dati è sempre un evento grave, non importa come o dove è stata eseguita. È sufficiente una sola API vulnerabile per riuscire a violare, rubare o divulgare pubblicamente i vostri dati.
Le violazioni di dati si verificano mentre aspettate
La sicurezza delle API può aspettare che voi diate priorità alle minacce su cui si focalizza l'attenzione degli enti di controllo, come i ransomware? Sfortunatamente, no. Le API diventano sempre più numerose e rischiose man mano che le aziende implementano nuovi prodotti e servizi digitali.
Il 76% delle organizzazioni oggetto della nostra indagine ha riscontrato un problema di sicurezza delle API e la maggior parte di esse non ha messo in atto controlli o strumenti tali da bloccarlo. Contemporaneamente, il costo medio di una violazione dei dati aumenta del 12,6% (pari a 5,05 milioni di dollari) se un'organizzazione risulta non conforme alle normative in modo significativo.
Se adottate un approccio proattivo nell'intento di individuare tutte le API, valutarne i rischi associati e proteggerle da eventuali violazioni, riuscirete a salvaguardare i vostri dati proprio dalle minacce che gli enti di controllo stanno cercando di evitare.
In che modo questo approccio influisce sul vostro programma di conformità?
Se adottate un approccio proattivo nell'intento di individuare tutte le API, valutarne i rischi associati e proteggerle da eventuali violazioni, riuscirete a salvaguardare i vostri dati proprio dalle minacce che gli enti di controllo stanno cercando di evitare.
In questo blog, vengono esaminate in modo dettagliato sei normative e linee guida relative alla necessità di proteggere le API con alcuni esempi sui modi con cui ottemperare a questi requisiti.
I 6 modelli e le normative principali
1. PCI DSS (Payment Card Industry Data Security Standard) versione 4.0
Il PCI DSS è diventato uno standard globale per la protezione dei dati di pagamento. Se la vostra azienda accetta le principali carte di credito e si occupa di elaborare, archiviare o trasmettere i dati dei titolari di carte di credito in modo elettronica, deve ottemperare a questo standard.
Il requisito 6.2.3 del PCI DSS 4.0 si incentra sulla necessità per le organizzazioni di esaminare il proprio codice delle applicazioni personalizzate per garantire che non vengano rilasciate vulnerabilità nella fase di produzione. Specifico per le API, questo requisito offre indicazioni utili per verificare che il software di un'organizzazione utilizzi le funzioni di componenti esterni (librerie, modelli, API, ecc.) in modo sicuro.
Uno dei vari modi per ottemperare a questo standard: Verificare i comportamenti normali e previsti di utilizzo delle API e implementare i controlli necessari per impedire ad eventuali criminali sospetti di violare i propri sistemi (ad es., verificare il comportamento dell'applicazione per rilevare eventuali vulnerabilità logiche).
2. Regolamento generale sulla protezione dei dati (GDPR)
Il GDPR è una legge dell'Unione europea che mira a rafforzare e unificare la protezione dei dati delle persone all'interno dell'UE. L'obbligo di conformità al GDPR, tuttavia, non è limitato alle aziende che operano nell'Unione europea, ma riguarda tutte le organizzazioni che offrono beni o servizi all'interno dell'UE.
L'articolo 25 del GDPR si basa sul principio del privilegio minimo, che richiede alle aziende di implementare misure tecniche e organizzative tali da garantire che, per impostazione predefinita, vengano trattati solo i dati personali necessari per ogni scopo specifico. A loro volta, gli sviluppatori delle API sono tenuti ad implementare adeguati controlli di autenticazione e autorizzazione degli utenti per salvaguardare i dati sensibili che vengono distribuiti tramite le API.
È questo un esempio eccellente di come la sicurezza delle API rientri nei programmi di sicurezza e conformità aziendali. Concetti come il privilegio minimo non sono rilevanti solo per gli uomini: anche alle API, è necessario consentire solo l'accesso richiesto per svolgere le loro funzioni.
3. DORA (Digital Operational Resiliency Act)
In totale, più di 22.000 istituzioni finanziarie e provider di servizi IT dell'Unione europea sono obbligati ad ottemperare ai requisiti imposti dal DORA, che sono stati concepiti per aiutare le organizzazioni a resistere e a riprendersi dagli attacchi informatici.
In che modo la sicurezza delle API si inserisce nel DORA? Esaminiamo la natura dell'articolo 3 del DORA , che richiede alle organizzazioni di utilizzare processi e soluzioni ICT in grado di:
Minimizzare i rischi correlati ai dati, gli accessi non autorizzati e i difetti tecnici
Impedire la mancata disponibilità e la perdita dei dati, oltre alle violazioni di integrità e riservatezza
Garantire la sicurezza nel trasferimento dei dati
Poiché lo scopo principale delle API è trasferire i dati, è essenziale verificare regolarmente la presenza di vulnerabilità nelle API, inclusa la mancanza di controlli di autenticazione e di visibilità non prevista sull'Internet pubblico. Eseguendo test tempestivi delle API, potete impedire alle vulnerabilità di raggiungere la fase di produzione.
4. HIPAA (Health Insurance and Portability and Accountability Act)
L'HIPAA si focalizza sulla privacy dei dati e sulle regole di sicurezza per salvaguardare le informazioni sanitarie protette (PHI) presenti nelle cartelle cliniche elettroniche e nei sistemi IT sanitari. Le aziende sanitarie, gli amministratori di piani assicurativi o i centro di smistamento che si occupano di archiviare o trasmettere le PHI in modo elettronico devono conformarsi ai principi dell'HIPAA.
La regola sulla privacy dell'HIPAA specifica che le entità interessate devono sviluppare e implementare policy e procedure tali da restringere l'accesso e l'utilizzo delle informazioni sanitarie protette sulla base degli specifici ruoli svolti dai membri della propria forza lavoro.
Pertanto, gli sviluppatori delle API di un'organizzazione devono incorporare misure di protezione tecniche, come l'autenticazione, ID utente univoci e controlli degli accessi basati sui ruoli per garantire l'implementazione del principio del privilegio minimo.
5. Direttiva NIS2 (Network and Information Security)
L'Unione europea ha adottato la versione 2.0 della direttiva NIS a gennaio 2023 sulla base delle linee guida della versione originale allo scopo di proteggere l'infrastruttura IT e segnalare eventuali problemi.
Da notare che la NIS2 include una nuova enfasi sulla supply chain: ora, le aziende devono valutare i rischi e proteggere le proprie supply chain IT, nonché le loro relazioni con i fornitori di terze parti.
Poiché le API sono spesso utilizzate per integrare servizi esterni, dai fornitori di software ai provider di servizi cloud, garantire la loro sicurezza è fondamentale per mostrare agli enti di controllo che la vostra organizzazione protegge i dati dei propri clienti e la più ampia supply chain dagli attacchi.
6. FFIEC (Federal Financial Institutions Examination Council)
Il FFIEC si occupa di stilare le linee guida e gli standard adottati dagli enti di controllo statunitensi per vigilare sul settore finanziario negli Stati Uniti, tra cui il Federal Reserve e il FDIC. Il Consiglio si propone di proteggere clienti e investitori da frodi, abusi e atti di cattiva condotta.
Dall'esame delle linee guida del FFIEC, emerge come la protezione delle API possa aiutare le organizzazioni a salvaguardare i consumatori da frodi e furti di identità. Ad esempio, il FFIEC consiglia alle aziende di stilare un inventario di tutti i sistemi informativi (incluse le API) che richiedono controlli di autenticazione e accesso.
Anche l'autorizzazione svolge un ruolo fondamentale: il FFIEC consiglia di implementare una sicurezza stratificata, ad esempio, monitorando, registrando e generando rapporti sulle attività necessarie per identificare e tenere traccia degli accessi alle API non autorizzati.
La protezione delle API significa anche salvaguardare la fiducia dei clienti
Le sei normative e le linee guida discusse in questo blog hanno una cosa in comune: proteggere i dati che vi sono stati affidati da altri.
Come sapete, la probabilità che si verifichi una violazione dei dati non è solo una questione di sanzioni. La fiducia dei clienti e la reputazione dell'azienda sono a rischio per clienti, dipendenti ed enti di controllo del settore. Gli enti di controllo devono verificare che un'azienda stia applicando la giusta combinazione di persone, processi e strumenti per bloccare il verificarsi di attacchi simili a questo tipo.
Ulteriori informazioni
Volete scoprire in dettaglio i requisiti relativi alle API per le sei normative trattate in questo post?