Che cos'è lo standard PCI DSS?

Significato PCI DSS

PCI DSS è un insieme di standard di sicurezza stabiliti nel 2004 dalle principali società di carte di credito perché, non sorprende che le applicazioni che elaborano i pagamenti siano obiettivi altamente attraenti per hacker e malintenzionati. 

La missione di PCI DSS è quella di proteggere le transazioni con carte di credito e debito non solo per limitare le perdite per le banche e il settore delle carte di pagamento, ma anche per aumentare la fiducia e la sicurezza dei consumatori. Ciò si ottiene attraverso una serie di controlli di sicurezza che proteggono la riservatezza, l'integrità e l'accuratezza dei dati della carta. Questo standard di conformità si applica a tutte le organizzazioni che archiviano, elaborano e trasmettono i dati delle carte di credito. A differenza del NIST, che è un framework fortemente incoraggiato ma non obbligato a seguire, è assolutamente necessario rispettare gli standard PCI DSS.

Requisiti PCI DSS

PCI DSS è costituito da 12 requisiti raggruppati in sei obiettivi di controllo, garantendo alle organizzazioni che elaborano, archiviano o trasmettono i dati delle carte di credito un ambiente sicuro. La conformità aiuta a proteggere le informazioni dei titolari di carta e a rafforzare le misure di sicurezza complessive.

Obiettivo n. 1: Costruire una rete sicura

  • Regola n. 1: Installazione e manutenzione di un firewall 
  • Regola n. 2: Non utilizzare password o configurazioni predefinite del fornitore

Obiettivo n. 2: Protezione dei dati dei titolari di carta

  • Regola n. 3: Protezione dei dati dei titolari di carta memorizzati 
  • Regola n. 4: Crittografia dei dati dei titolari di carta trasmessi

Obiettivo n. 3: Mantenere un programma di gestione delle vulnerabilità

  • Regola n. 5: Protezione da malware 

  • Regola n. 6: Sviluppare e mantenere sistemi sicuri 

Obiettivo n. 4: Gestione del controllo degli accessi  

  • Regola n. 7: Limita l'accesso ai dati dei titolari di carta 
  • Regola n. 8: Identifica in modo univoco tutti coloro che hanno accesso ai dati dei titolari di carta 
  • Regola n. 9: Limita l'accesso fisico ai dati dei titolari di carta

Obiettivo n. 5: Monitoraggio e test delle reti  

  • Regola n. 10: Traccia e monitora tutti gli accessi ai dati dei titolari di carta 
  • Regola n. 11: Verifica la sicurezza del sistema

Obiettivo n. 6: Mantenere una politica di sicurezza delle informazioni

  • Regola n. 12: Creare e applicare una politica di sicurezza delle informazioni all'interno dell'organizzazione

Ci sono anche quattro livelli di conformità, a seconda del numero annuale di transazioni con carta di credito/debito elaborate. La classificazione determina ciò che l'organizzazione deve fare per mantenere la conformità: 

  • Livello 1: Oltre 6 milioni di transazioni all'anno - Requisito: Audit interno annuale condotto da un revisore PCI autorizzato. Inoltre, devono completare la scansione PCI da parte di un fornitore di scansioni approvato (ASV) una volta al trimestre. 
  • Livello 2: 1-6 milioni di transazioni all'anno: - Requisito: Completare una valutazione annuale utilizzando un questionario di autovalutazione (SAQ). Potrebbe essere necessaria una scansione PCI trimestrale. 
  • Livello 3: 20.000-1 milione di transazioni all'anno - Requisito: Autovalutazione annuale e potenzialmente una scansione PCI trimestrale. 
  • Livello 4: Meno di 20.000 transazioni/anno - Requisito: Autovalutazione annuale e potenzialmente una scansione PCI trimestrale.

Perché la conformità PCI DSS è importante

Tutti all'interno dell'organizzazione svolgono un ruolo nel mantenimento della conformità. Inizia in cima ai CISO e poi si sposta verso i team SecOps e DevOps. In un mondo DevSecOps ideale, non esiste una gerarchia della responsabilità di sicurezza tra entrambi i team: lavorano di concerto. SecOps deve aiutare i team DevOps a capire cosa devono fare e gli sviluppatori devono eseguire questa operazione a livello di applicazione. 

Seguendo i 12 requisiti PCI DSS, ecco alcuni esempi di come la conformità continua sia uno sforzo di squadra: 

  • Regola n. 6: Gli sviluppatori devono creare sistemi tenendo a mente la sicurezza 
  • Regola n. 8: La gestione delle identità e degli accessi deve assegnare a ogni utente un ID utente univoco - requisito otto 
  • Regola n. 9: Il dipartimento di sicurezza fisica deve garantire che l'accesso all'edificio e alle sale server sia controllato 
  • Regola n. 10: Le operazioni di sicurezza devono garantire la creazione dei registri per registrare e monitorare l'accesso ai dati dei titolari di carta 
  • Regola n. 11: I team operativi e di sviluppo devono collaborare per testare server e software 
  • Regola n. 12: La dirigenza deve sviluppare politiche e documenti associati per descrivere in dettaglio il livello di sicurezza e conformità delle informazioni che deve essere raggiunto nella propria azienda 

Tutto questo per dire: tutti svolgono un ruolo nel mantenere la conformità. Non solo per il bene dell'organizzazione, ma anche per creare e distribuire in modo efficiente e con la certezza che non riceverai 10.000 avvisi SOS Slack dopo il lancio dell'app. 

Come abbiamo detto, la tua responsabilità è principalmente a livello di applicazione. Ciò include l'utilizzo di codice sorgente sicuro, la garanzia di configurazioni corrette per la pipeline CI/CD e altro ancora. Potresti pensare: Va bene, ma come dovrei sapere come farlo? La buona notizia è che non è necessario essere un frusta per la sicurezza o la conformità, proprio come non è necessario essere un neurochirurgo per mettere un Band-Aid su un taglio. Si tratta di conoscere e applicare le risorse appropriate (come un Band-Aid invece di nastrare un tovagliolo sulla ferita). 

Per evitare configurazioni errate, è possibile consultare il sito della documentazione per il provider di servizi cloud (CSP). Tuttavia, leggere tutte queste informazioni potrebbe richiedere troppo tempo. Se questo è il caso tuo, ti suggeriamo (piuttosto, consigliamo vivamente) di utilizzare una soluzione di sicurezza con automazione.

Violazioni correlate agli standard PCI DSS

La prima violazione che potrebbe venire in mente è l'hacking di Capital One che ha esposto 106 milioni di richieste di carte di credito e ha portato a una multa di 80 milioni di dollari da parte delle autorità di regolamentazione statunitensi. Diamo un'occhiata ad altre violazioni e a come avrebbero potuto essere evitate facendo riferimento alle regole e agli obiettivi PCI DSS.

Lobby hobby

All'inizio del 2021, Hobby Lobby è stata hackerata. Un ricercatore indipendente che utilizza l'handle Boogeyman ha identificato la violazione. Ha scoperto un database pubblicamente accessibile su Amazon Web Services (AWS) che conteneva informazioni sensibili di oltre 300.000 clienti di Hobby Lobby. Il database aveva una dimensione di 138GB e aveva nomi, indirizzi, numeri di telefono e dettagli parziali della carta di credito dei clienti. Stranamente nello stesso database c'era il codice sorgente per l'app dell'azienda, che è un altro problema del tutto. 

La violazione è stata il risultato di un database cloud mal configurato e accessibile pubblicamente. Si tratta di una chiara violazione delle regole PCI DSS n. 3, n. 7 e n. 9, poiché i dati della carta di pagamento venivano archiviati su un server aperto. Hobby Lobby non ha inoltre rispettato la regola n. 10, che stabilisce che l'accesso ai dati dei titolari di carta e alle risorse di rete pertinenti deve essere monitorato e monitorato. Questo chiaramente non stava accadendo, altrimenti la configurazione errata sarebbe stata risolta e l'intera impresa alla fine sarebbe stata evitata.

Macy’s

Il principale rivenditore ha subito una violazione nell'ottobre 2019, che ha esposto i numeri delle carte di pagamento, i codici di sicurezza e le date di scadenza dei clienti che hanno utilizzato il sistema di check-out online con la pagina My Account wallet. Mentre Macy's non ha rivelato il numero di clienti interessati, il rivenditore ha registrato 55,7 milioni di visite online mensili fino ad aprile di quell'anno. E per essere franchi, rubare le informazioni di un solo cliente è una preoccupazione. 

La violazione si è verificata a causa di un attacco mirato di Magecart che ha iniettato malware nelle pagine di pagamento e del portafoglio. Macy's era evidentemente in violazione di una serie di regole PCI DSS e ciò che è più preoccupante è il fatto che Magecart è ben nota. Infatti, Macy's è stata solo una delle molte vittime di quell'anno, tra cui FILA, Ticketmaster, British Airways e altre ancora. I precedenti attacchi ad altri importanti rivenditori dovrebbero aver motivato Macy's a eseguire audit di sicurezza e a porre rimedio a eventuali vulnerabilità come richiesto da PCI DSS.

PCI DSS Compliance

Related Articles