Le best practice per garantire la conformità delle API allo standard di sicurezza PCI DSS v4.0

I requisiti della versione originale riguardano principi di sicurezza che sono importanti oggi come lo erano quando sono stati pubblicati nel 2006, come ad esempio:

• monitoraggio e controllo dell'accesso di tutti gli account amministrativi su qualsiasi sistema IT che elabori o archivi dati di titolari di carta;

• assegnazione dell'accesso al sistema e ai dati dei titolari di carta solo a chi ne ha necessità per motivi lavorativi e definizione dei requisiti di accesso in base al ruolo.

Il problema è che il panorama odierno delle minacce è più complesso di quello del 2006.

Per quanto le organizzazioni debbano ancora far fronte a criminali che tendenzialmente puntano ad account privilegiati e ad utenti con autorizzazioni eccessive, devono anche adattare i loro programmi di conformità per contrastare quelli che mirano alle migliaia di API che risiedono all'interno delle tecnologie di pagamento. Questi criminali sanno che le API sono facili da sfruttare e rendono più semplice il furto dei dati dei titolari di carta.

Pertanto, per essere conformi allo standard PCI DSS v4.0, la vostra organizzazione dovrà comprendere e contrastare le minacce alle API. In questo articolo del blog condivideremo informazioni su rischi, requisiti e modalità per essere a norma.

In generale, lo standard PCI DSS v4.0 è incentrato su quattro obiettivi chiave:

1. Continuare a soddisfare le esigenze di sicurezza del settore dei pagamenti

2. Sostenere la sicurezza come processo continuo

3. Dare alle aziende la possibilità di soddisfare i requisiti in modo flessibile (ad esempio, nuovi strumenti, nuovi controlli)

4. Ottimizzare metodi e processi di convalida

Lo standard PCI DSS v4.0 definisce esplicitamente le API come un aspetto importante che richiede visibilità e protezione. Tutti e quattro gli obiettivi contribuiscono alla soddisfazione di questo requisito, ma il numero tre (la possibilità di utilizzare nuovi strumenti e controlli) è particolarmente importante, considerati i rischi unici delle API. Ad esempio:

• Le API sono il fulcro dei prodotti e servizi digitali rivolti ai clienti. A seconda delle sue dimensioni, un'azienda conta in media tra le 15.000 e le 25.000 API, tutte progettate per facilitare uno scambio di dati ininterrotto. 

• Questi dati includono informazioni sensibili sui clienti. Per ogni pagamento digitale, è disponibile un'API "dietro le quinte", che trasmette dati tra applicazioni, sistemi, terze parti e molto altro.

• È sufficiente una sola API compromessa per riuscire a rubare, tenere in ostaggio o divulgare pubblicamente in tutto il mondo milioni di dati. Le API vulnerabili o non correttamente configurate sono diffuse, facili da violare e spesso non protette, non viste e non gestite.

Le autorità di regolamentazione sono consapevoli del rischio che grava sulle API, per cui la vostra azienda deve dimostrare di avere la visibilità e i controlli necessari per evitare che i dati vengano compromessi.

I dati delle carte di pagamento vengono compromessi in più di un terzo (37%) delle violazioni, secondo il Rapporto delle indagini sulle violazioni dei dati 2023 di Verizon. Lo standard PCI DSS v4.0 include nuovi requisiti relativi all' autenticazione multifattore e alla lunghezza delle password al fine di proteggere l'elemento umano della superficie di attacco del settore dei pagamenti.

Tuttavia, è importante ricordare che le violazioni dei dati non accadono solo per via di metodi di attacco ben pubblicizzati e incentrati sull'essere umano, come il phishing delle password dei dipendenti.

Ad esempio, il 18% degli attacchi alle aziende di e-commerce usa codice dannoso incorporato nelle pagine web che elaborano le carte. Gli autori delle minacce di oggi sono sempre più sofisticati e puntano a componenti non umani automatizzati dell'ambiente IT, che spesso non sono protetti correttamente, come le API.

Il 78%  delle aziende ha subito un incidente relativo alla sicurezza delle API, secondo quanto emerso dalla nostra ricerca. Per sottolineare l'urgenza delle minacce alle API, lo standard PCI DSS v4.0 incorpora nuove regole, linee guida e best practice per la sicurezza delle API. Per saperne di più, esaminiamo innanzitutto il Requisito 6.2.3.

Il Requisito 6.2.3 impone alle organizzazioni di rivedere il loro codice applicativo personalizzato (ad esempio, applicazioni sviluppate da un fornitore di terze parti, ma non le applicazioni commerciali preconfezionate standard) per garantire di non immettere vulnerabilità in produzione.

Questo requisito include indicazioni che servono a confermare che il software di un'organizzazione utilizzi le funzioni di componenti esterni (librerie, framework, API, ecc.) in modo sicuro, il che dice molto sul ruolo chiave delle API nella catena di fornitura dei software in generale e su che cosa serve per proteggerle.

Le API sono diventate il metodo predefinito per la connettività e lo scambio di dati negli ambienti applicativi moderni. Tenendo conto di ciò, proteggere le API sia con un approccio in pre-produzione (Shift-Left) che in post-produzione (Shield-Right) è essenziale per rendere le vostre attività digitali resilienti agli attacchi.

Riportiamo di seguito sei best practice per la sicurezza delle API che aiutano a essere conformi al Requisito 6.2.3.

1. Verificare l'utilizzo di componenti basati su API e il relativo sistema di sicurezza (ad esempio, individuare eventuali configurazioni errate che portano a vulnerabilità, incluso l'uso di crittografia debole come indicato nello standard)

2. Convalidare i comportamenti normali e previsti di utilizzo delle API e implementare i controlli necessari per impedire a eventuali criminali sospetti di violare i propri sistemi (ad esempio, verificare il comportamento dell'applicazione per rilevare eventuali vulnerabilità logiche)

3. Individuare i framework di terze parti utilizzati per implementare le API e determinare se sono obsoleti e vulnerabili

4. Creare un inventario completo di tutte le API, incluse le diverse versioni delle API in esecuzione, per ottenere informazioni su potenziali funzionalità e backdoor non documentati che devono essere gestiti

5. Verificare la sicurezza del codice delle API ed evitare di immettere in produzione vulnerabilità legate alle API

6. Implementare best practice di codifica protetta delle API, che consentiranno di adottare un approccio programmatico per la distribuzione sicura del codice su base continua

Nel protocollo PCI DSS v4.0, il PCI SSC ha aggiunto anche altre due sezioni che riguardano la sicurezza delle API. Riportiamo qui in sintesi due requisiti aggiuntivi da soddisfare.

• Requisito 6.3.2: si applica alla creazione di un inventario dei software personalizzati e dei componenti software di terze parti incorporati in software personalizzati, al fine di facilitare la gestione delle vulnerabilità e delle patch.

• Requisito 6.2.2: riguarda la formazione del personale di sviluppo dei software che lavora su software personalizzati. Impone agli sviluppatori di aggiornarsi almeno una volta ogni 12 mesi sulla sicurezza che attiene alla loro mansione lavorativa, il che comprende la progettazione di software sicuri e le tecniche di codifica sicura. Questi corsi trattano degli strumenti da usare per i test di sicurezza e di come utilizzarli per rilevare le vulnerabilità nei software.