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.
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.
Regola n. 5: Protezione da malware
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à:
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:
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.
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.
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.
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.