Payment Card Industry (PCI) Data Security Standard. Versione 1.1

Payment Card Industry (PCI) Data Security Standard Versione 1.1 Release: settembre 2006

Costruire e mantenere una rete protetta 1 requisito: Installare e mantenere una configurazione con firewall per proteggere i dati dei titolari delle carte 2 requisito: Non utilizzare password di sistema predefinite o altri parametri di sicurezza impostati dai fornitori Proteggere i dati dei titolari delle carte 3 requisito: Proteggere i dati dei titolari delle carte memorizzati 4 requisito: Cifrare i dati dei titolari delle carte quando vengono trasmessi attraverso reti pubbliche aperte Rispettare un programma per la gestione delle vulnerabilità 5 requisito: Utilizzare e aggiornare con regolarità il software antivirus 6 requisito: Sviluppare e mantenere applicazioni e sistemi protetti Implementare misure forti per il controllo dell'accesso 7 requisito: Limitare l'accesso ai dati dei titolari delle carte solo se effettivamente indispensabili per lo svolgimento dell'attività commerciale 8 requisito: Assegnare un ID univoco a ogni utente che ha accesso ai computer 9 requisito: Limitare la possibilità di accesso fisico ai dati dei titolari delle carte Monitorare e testare le reti con regolarità 10 requisito: Monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte 11 requisito: Eseguire test periodici dei processi e dei sistemi di protezione Adottare una Politica di Sicurezza 12 requisito: Adottare una Politica di Sicurezza 1.1 1

Prefazione In questo documento sono illustrati i 12 requisiti previsti dallo standard PCI DSS (Payment Card Industry Data Security Standard. I requisiti PCI DSS sono stati raggruppati in 6 categorie logiche, definite obiettivi di controllo. Nella seguente tabella sono illustrati gli elementi comunemente utilizzati riguardanti i dati dei titolari delle carte e i dati sensibili per l'autenticazione, se è consentita o vietata la memorizzazione di ciascun elemento e se ciascun elemento è sottoposto a protezione. La tabella non esaurisce l'argomento, tuttavia consente di illustrare i diversi requisiti che si applicano a ciascun elemento. I requisiti PCI DSS si applicano se un Numero Account Primario (Primary Account Number, PAN) viene memorizzato, elaborato o trasmesso. Se invece il PAN non viene memorizzato, elaborato o trasmesso, i requisiti PCI DSS non trovano applicazione. Elemento Memorizz. permessa Protezione richiesta PCI DSS Req. 3.4 Dati dei titolari delle carte Numero account primario (PAN) Sì Sì Sì Nome del titolare* Sì Sì* No Codice di servizio* Sì Sì* No Data di scadenza* Sì Sì* No Dati sensibili per l'autenticazione** Striscia magnetica intera No N/P N/P CVC2/CVV2/CID No N/P N/P PIN / Blocco PIN No N/P N/P * Questi elementi devono essere protetti se memorizzati insieme al PAN. Il livello di protezione deve essere conforme ai requisiti PCI DSS per la protezione generale dell'ambiente dati del titolare. È inoltre possibile che altre normative (ad esempio leggi sulla protezione dei dati personali dei consumatori, sul diritto alla privacy, sul furto dell'identità o sulla sicurezza dei dati) prevedano misure specifiche per la protezione degli stessi dati e persino la pubblica divulgazione delle pratiche aziendali per quanto concerne la raccolta dei dati personali dei consumatori a fini commerciali. I requisiti PCI DSS non trovano tuttavia applicazione qualora i PAN non vengano memorizzati, elaborati o trasmessi. ** I dati sensibili per l'autenticazione non devono essere conservati dopo l'avvenuta autorizzazione (neppure se cifrati). Tali requisiti per la sicurezza si applicano a tutti i componenti del sistema, dove per componenti del sistema si intende qualunque componente, server o applicazione della rete che faccia parte o sia collegato all'ambiente dati dei titolari delle carte. L'ambiente dati dei titolari delle carte è quell'area della rete in cui sono custoditi i dati dei titolari delle carte o i dati sensibili per l'autenticazione. Un'adeguata segmentazione della rete, in cui i sistemi per la memorizzazione, elaborazione e trasmissione dei dati dei titolari delle carte siano sufficientemente isolati, può ridurre le dimensioni dell'ambiente dati dei titolari delle carte. I componenti della rete includono, tra gli altri, firewall, switch, router, access point di tipo 1.1 2

wireless, dispositivi di rete e altri dispositivi di sicurezza. I server possono essere di vari tipi, ad esempio: Web, database, autenticazione, posta, proxy, NTP (Network Time Protocol) e DNS (Domain Name Server). Le applicazioni comprendono tutte le applicazioni acquistate e personalizzate, comprese le applicazioni ad uso interno o esterno (Internet). 1.1 3

Costruire e mantenere una rete protetta 1 requisito: Installare e mantenere una configurazione con firewall per proteggere i dati dei titolari delle carte I firewall sono sistemi che controllano il traffico tra i computer da e verso la rete di un'azienda, nonché il traffico diretto verso le aree più sensibili della rete interna di un'azienda. Il firewall esamina tutto il traffico in rete e blocca le trasmissioni che non rispondono ai criteri di sicurezza specificati. È indispensabile proteggere tutti i sistemi contro eventuali accessi non autorizzati da Internet, sia che avvengano sotto la forma di e-commerce, di navigazione in Internet dai browser dei dipendenti o di invio e ricezione della posta elettronica dei dipendenti. Percorsi apparentemente insignificanti da e verso Internet possono spesso comportare passaggi non protetti all'interno di sistemi chiave. I firewall rappresentano un meccanismo di protezione fondamentale per tutte le reti di computer. 1.1 Adottare standard per la configurazione dei firewall adottando le seguenti misure: 1.1.1 Un processo formale sia per l'approvazione e il collaudo di tutte le connessioni esterne alla rete, sia per la modifica della configurazione dei firewall. 1.1.2 Un diagramma aggiornato della rete, con tutte le connessioni ai dati dei titolari delle carte, comprese le eventuali reti wireless. 1.1.3 Obbligo di utilizzo di un firewall per ogni connessione Internet e tra tutte le zone demilitarizzate (DMZ) e la zona della rete interna. 1.1.4 Descrizione di gruppi, ruoli e responsabilità per la gestione dei componenti della rete. 1.1.5 Elenco documentato dei servizi e delle porte necessarie per l'attività commerciale. 1.1.6 Giustificativi e documentazione per tutti i protocolli disponibili, diversi dagli standard HTTP (hypertext transfer protocol), SSL (secure sockets layer), SSH (secure shell) e VPN (virtual private network). 1.1.7 Giustificativi e documentazione per tutti i protocolli rischiosi di cui è consentito l'uso: ad esempio, lo standard FTP (file transfer protocol) che includa la motivazione per cui viene utilizzato ciascun protocollo e le funzioni di sicurezza implementate. 1.1.8 Revisione trimestrale delle regole fissate per i firewall e i router. 1.1.9 Standard per la configurazione dei router. 1.2 Costruire una configurazione dei firewall che impedisca il traffico da reti e host untrusted, tranne che per i protocolli indispensabili per l'ambiente dati dei titolari delle carte. 1.3 Costruire una configurazione dei firewall che limiti le connessioni tra i server di pubblico accesso e tutti i componenti del sistema in cui sono custoditi i dati dei titolari delle carte, comprese le eventuali connessioni a reti wireless. Una configurazione dei firewall di questo tipo dovrebbe prevedere quanto segue: 1.3.1 Limitazione del traffico Internet in entrata agli indirizzi IP (Internet Protocol) entro la zona DMZ (filtri in ingresso). 1.3.2 Divieto per gli indirizzi interni di passare da Internet alla zona DMZ. 1.3.3 Attuazione di un meccanismo di "dynamic packet filtering", che consenta cioè soltanto alle connessioni già stabilite di accedere alla rete. 1.3.4 Collocazione del database in una zona della rete interna nettamente separata dalla zona DMZ. 1.3.5 Limitazione del traffico in entrata e in uscita a quello indispensabile per l'ambiente dati dei titolari delle carte. 1.1 4

1.3.6 Protezione e sincronizzazione dei file di configurazione del router. Ad esempio, i file di configurazione in esecuzione (per il regolare funzionamento dei router) e i file di configurazione eseguiti all'avvio (quando i dispositivi vengono riavviati) dovrebbero avere la stessa configurazione. 1.3.7 Divieto di tutto il restante traffico in entrata e in uscita, se non autorizzato in modo specifico. 1.3.8 Installazione di firewall perimetrali tra le reti wireless e l'ambiente dati dei titolari delle carte; configurazione dei firewall affinché impediscano tutto il traffico proveniente dall'ambiente wireless o controllino il traffico qualora questo sia necessario ai fini del business. 1.3.9 Installazione di firewall personali (software) su tutti i computer portatili e i computer di proprietà dei dipendenti (ad esempio, i laptop dei dipendenti) che possono connettersi direttamente a Internet e che vengono utilizzati per accedere alla rete dell'organizzazione. 1.4 Vietare l'accesso pubblico diretto tra le reti esterne e i componenti del sistema in cui sono custoditi i dati dei titolari delle carte (ad esempio, database, log e trace file). 1.4.1 Predisporre una zona DMZ per filtrare e analizzare tutto il traffico, bloccando inoltre ogni percorso diretto per il traffico Internet in entrata e in uscita. 1.4.2 Limitare il traffico in uscita dalle applicazioni delle carte di pagamento verso gli indirizzi IP della zona DMZ. 1.5 Implementare l'ip-masquerading per impedire che gli indirizzi interni vengano tradotti o svelati in Internet. Utilizzare le tecnologie che implementano lo spazio indirizzi RFC 1918, ad esempio le tecnologie PAT (port address translation) e NAT (network address translation). 2 requisito: Non utilizzare password di sistema predefinite o altri parametri di sicurezza impostati dai fornitori Spesso gli hacker (esterni o interni a un'azienda) utilizzano le password predefinite e le altre impostazioni dei fornitori per compromettere i sistemi. Queste password e impostazioni sono note alle comunità di hacker e sono facilmente reperibili in quanto informazioni pubbliche. 2.1 Cambiare sempre le impostazioni predefinite dei fornitori prima di installare un sistema in rete: ad esempio, aggiungere password, stringhe di comunità SNMP (simple network management protocol) ed eliminare gli account superflui. 2.1.1 Per gli ambienti wireless, cambiare le impostazioni predefinite del fornitore wireless, tra le quali, ad esempio: chiavi WEP (wired equivalent privacy), identificativi SSID (default service set identifiers), password e stringhe di comunità SNMP. Disattivare l'annuncio dei SSID. Abilitare le tecnologie di accesso protetto WiFi (WPA e WPA2) per la cifratura e l'autenticazione (se la tecnologia WPA è disponibile). 2.2 Sviluppare standard di configurazione per tutti i componenti del sistema. Assicurarsi che tali standard affrontino tutte le vulnerabilità della sicurezza note e siano coerenti con gli standard di System Hardening che sono accettati, ad esempio, da enti quali il SysAdmin Audit Network Security Institute (SANS), il National Institute of Standards Technology (NIST) e il Center for Internet Security (CIS). 2.2.1 Implementare una sola funzione primaria per server (ad esempio, utilizzare server diversi per svolgere funzioni di server Web, server di database e server DNS). 2.2.2 Disattivare tutti i servizi e i protocolli non protetti che non sono strettamente necessari (cioè quei servizi e protocolli che non servono direttamente per eseguire la funzione specifica di un dispositivo). 1.1 5

2.2.3 Configurare i parametri di protezione del sistema in modo da prevenire eventuali abusi. 2.2.4 Rimuovere tutte le funzionalità superflue, quali script, driver, sottosistemi, file system e server Web non utilizzati. 2.3 Cifrare tutto l'accesso amministrativo che non è originato dalla console. Utilizzare tecnologie quali SSH, VPN o SSL/TLS (transport layer security) per la gestione basata sul Web e altri tipi di accessi amministrativi che non sono originati dalla console. 2.4 I provider di hosting sono obbligati a proteggere tutti gli ambienti e i dati delle entità che ospitano e a rispondere agli specifici requisiti delineati nell'appendice A: Applicabilità dello standard PCI DSS per i provider di hosting. 1.1 6

Proteggere i dati dei titolari delle carte 3 requisito: Proteggere i dati dei titolari delle carte memorizzati La cifratura è un componente fondamentale della protezione dei dati dei titolari delle carte. Anche nel caso in cui un hacker riuscisse a superare gli altri meccanismi di controllo della rete e ad acquisire l'accesso ai dati cifrati, se non è in possesso delle chiavi crittografiche giuste non sarà in grado né di leggere, né di utilizzare i dati. Vi sono altri metodi di protezione dei dati che dovrebbero essere presi in considerazione come ulteriori misure di riduzione dei rischi. Ad esempio, altri modi di ridurre i rischi sono: non memorizzare i dati dei titolari delle carte se non è strettamente necessario; troncare i dati dei titolari delle carte se il PAN completo non serve; non inviare il PAN in messaggi di posta elettronica non cifrati. 3.1 Ricorrere alla memorizzazione dei dati dei titolari delle carte nella misura minore possibile. Sviluppare politiche per la conservazione e l'eliminazione dei dati. Limitare la quantità di dati memorizzati e il periodo di conservazione al minimo necessario per fini commerciali, legali e/o legislativi, come definito nelle politiche per la conservazione dei dati. 3.2 Non conservare i dati sensibili per l'autenticazione dopo l'avvenuta autorizzazione, neppure se cifrati. La natura dei dati sensibili per l'autenticazione è descritta nei punti da 3.2.1 a 3.2.3. 3.2.1 Non conservare il contenuto completo di nessuna traccia della striscia magnetica (che si trova sul retro della carta, in un chip o in altre posizioni). I dati in questione sono denominati traccia completa, traccia, traccia 1, traccia 2 e dati della striscia magnetica. Nel normale corso degli affari, potrebbe essere necessario conservare i seguenti elementi della striscia magnetica: nome del titolare dell'account, numero account primario (PAN), data di scadenza e codice di servizio. Per ridurre i rischi al minimo, conservare soltanto gli elementi che sono effettivamente necessari per la propria attività commerciale. NON conservare MAI elementi quali il codice CVC o CVV o il PIN Verification Value. Nota: per maggiori informazioni, consultare il Glossario. 3.2.2 Non conservare il codice CVC o CVV (un numero a tre o a quattro cifre stampato sul fronte o sul retro di una carta di pagamento) utilizzato per verificare le transazioni in cui non è materialmente presente la carta. Nota: per maggiori informazioni, consultare il Glossario. 3.2.3 Non conservare il PIN (personal identification number) o il blocco PIN cifrato. 3.3 Mascherare il PAN quando è visibile (non dovrebbero essere visibili più di sei cifre all'inizio e quattro cifre alla fine). Nota: questo requisito non può essere applicato ai dipendenti e ad altri soggetti che devono necessariamente visualizzare il PAN completo, né può sostituirsi ad altri requisiti più severi relativi alla visualizzazione dei dati dei titolari delle carte (ad esempio, nelle ricevute di pagamento POS). 3.4 Rendere quantomeno illeggibile il PAN in qualunque punto esso sia memorizzato (compresi i dati su supporti digitali portatili, supporti di backup, log e i dati ricevuti da o conservati nelle reti wireless) adottando le seguenti misure: Funzioni forti di hash one-way (indici hash) Troncatura Token e pad indicizzati, con i pad custoditi in luoghi sicuri Crittografia forte con relativi processi e procedure di gestione delle chiavi. Il PAN è l'informazione MINIMA relativa all'account che deve essere resa illeggibile. 1.1 7

Se per qualsiasi ragione un'azienda non fosse in grado di cifrare i dati dei titolari delle carte, consultare l'appendice B, Informazioni generali sui controlli compensativi. 3.4.1 Se si utilizza la cifratura su disco (anziché la cifratura del database a livello di file o colonna), l'accesso logico deve essere gestito indipendentemente dai meccanismi nativi di controllo dell'accesso al sistema operativo (ad esempio, evitando di utilizzare gli account del sistema locale o di Active Directory). Le chiavi di decifratura non devono essere legate agli account utente. 3.5 Proteggere le chiavi di cifratura utilizzate per cifrare i dati dei titolari delle carte da qualunque tentativo di divulgazione e di uso improprio. 3.5.1 Limitare l'accesso alle chiavi al minor numero possibile di soggetti fidati. 3.5.2 Conservare le chiavi in sicurezza nel minor numero possibile di luoghi e formati. 3.6 Documentare dettagliatamente e implementare tutti i processi e le procedure principali di gestione delle chiavi per la cifratura dei dati dei titolari delle carte, tra cui: 3.6.1 Generazione di chiavi forti 3.6.2 Distribuzione protetta delle chiavi 3.6.3 Memorizzazione protetta delle chiavi 3.6.4 Sostituzione periodica delle chiavi Sulla base delle direttive e i suggerimenti dell'applicazione associata (ad esempio, rekeying); preferibilmente in modo automatico. Almeno una volta all'anno. 3.6.5 Distruzione delle chiavi usate. 3.6.6 Uso della procedura di Split Knowledge e definizione del controllo duale, di modo che per ricostruire una chiave intera servano due o tre persone, ciascuna a conoscenza di una sola parte. 3.6.7 Prevenzione di tentativi di sostituzione non autorizzata delle chiavi. 3.6.8 Sostituzione di chiavi che si sospetta siano state compromesse. 3.6.9 Revoca di chiavi usate o non più valide. 3.6.10 Obbligo per i custodi delle chiavi di firmare una dichiarazione in cui accettano e confermano di conoscere le proprie responsabilità. 4 requisito: Cifrare i dati dei titolari delle carte quando vengono trasmessi attraverso reti pubbliche aperte Le informazioni sensibili devono essere cifrate quando vengono trasmesse attraverso reti che possono renderle facilmente intercettabili, modificabili e dirottabili dagli hacker. 4.1 Utilizzare la crittografia forte e protocolli di sicurezza quali SSL/TLS (secure sockets layer/transport layer security) e IPSEC (Internet protocol security) per salvaguardare i dati sensibili relativi ai titolari delle carte durante la trasmissione su reti pubbliche aperte. Esempi di reti pubbliche aperte che rientrano nell'ambito degli standard PCI DSS sono la rete Internet, le reti WiFi (IEEE 802.11x), le reti GSM (global system for mobile communications) e le reti GPRS (general packet radio service). 4.1.1 Per la trasmissione dei dati dei titolari delle carte attraverso reti wireless, cifrare le trasmissioni utilizzando le tecnologie WPA o WPA2 (WiFi protected access), IPSEC VPN o SSL/TLS. Per la protezione della riservatezza e l'accesso a una rete LAN wireless, evitare di affidarsi in modo esclusivo alla tecnologia WEP (wired equivalent privacy). Se si utilizza la tecnologia WEP, è necessario: 1.1 8

Utilizzare almeno una chiave di cifratura di 104 bit e un valore di inizializzazione di 24 bit. Utilizzarla SOLO contestualmente alle tecnologie WPA o WPA2 (WiFi protected access), VPN o SSL/TLS. Adottare una rotazione trimestrale (o automatica, se la tecnologia lo consente) delle chiavi WEP. Adottare una rotazione delle chiavi WEP ogniqualvolta vi sia un cambio del personale con accesso alle chiavi. Limitare l'accesso in base all'indirizzo MAC (media access code). 4.2 Non inviare mai PAN non cifrati tramite posta elettronica. Rispettare un programma per la gestione delle vulnerabilità 5 requisito: Utilizzare e aggiornare con regolarità il software o i programmi antivirus Molti virus e applicazioni dannose penetrano la rete sfruttando le attività di scambio della posta elettronica dei dipendenti. È necessario utilizzare un software antivirus in tutti i sistemi che possono essere colpiti dai virus per prevenire l'infezione ad opera di software dannoso. 5.1 Installare il software antivirus in tutti i sistemi che possono essere colpiti dai virus (in particolare, PC e server). Nota: in genere non sono colpiti dai virus i mainframe o i sistemi operativi basati su UNIX. 5.1.1 Assicurarsi che i programmi antivirus installati siano in grado di rilevare, rimuovere e difendere i sistemi da altre forme di software dannoso, compresi spyware e adware. 5.2 Assicurarsi che tutti i meccanismi antivirus siano aggiornati ed eseguiti correttamente e che generino gli audit log. 6 requisito: Sviluppare e mantenere applicazioni e sistemi protetti Soggetti privi di scrupoli utilizzano delle vulnerabilità per conquistare l'accesso privilegiato ai sistemi. Gran parte di queste vulnerabilità possono essere corrette utilizzando le patch di sicurezza dei fornitori. È indispensabile che in tutti i sistemi siano installate le patch software più aggiornate per prevenire attività indesiderate da parte di dipendenti, hacker esterni e virus. Nota: le patch software che vengono distribuite devono essere state prima valutate e testate sufficientemente per assicurare la non conflittualità con le configurazioni di sicurezza esistenti. Nel caso di applicazioni sviluppate in loco dagli utenti, è possibile evitare numerose vulnerabilità se si utilizzano processi standard di sviluppo e tecniche di programmazione sicura. 6.1 Assicurarsi di installare tutte le patch di protezione disponibili per i componenti del sistema e i programmi software in uso. Installare le patch di protezione entro un mese dalla loro pubblicazione. 6.2 Adottare misure utili ad identificare immediatamente le vulnerabilità non appena diventano note al pubblico (ad esempio, attraverso un abbonamento a servizi di informazione disponibili gratuitamente in Internet). Aggiornare gli standard per risolvere i nuovi problemi di vulnerabilità. 6.3 Sviluppare applicazioni software che siano basate sulle migliori pratiche del settore e che garantiscano la protezione delle informazioni per l'intero ciclo di vita dello sviluppo del software. 6.3.1 Devono essere eseguiti test su tutte le patch di sicurezza e le modifiche apportate alla configurazione di sistemi e del software prima della distribuzione. 6.3.2 Gli ambienti dedicati allo sviluppo, al collaudo e alla produzione devono essere nettamente separati. 1.1 9

6.3.3 I compiti svolti negli ambienti dedicati allo sviluppo, al collaudo e alla produzione devono essere nettamente separati. 6.3.4 I dati della produzione (PAN attivi) non devono essere impiegati nelle fasi di collaudo e sviluppo. 6.3.5 I dati e gli account impiegati per i test devono essere rimossi prima dell'attivazione dei sistemi di produzione. 6.3.6 Dati quali account, nomi utente e password delle applicazioni personalizzate devono essere rimossi prima che le applicazioni in questione vengano attivate o distribuite ai clienti. 6.3.7 Il codice sviluppato deve essere analizzato prima di essere distribuito alla produzione e ai clienti, in modo da poter identificare le possibili vulnerabilità. 6.4 Seguire le procedure di controllo previste per la modifica della configurazione del software e del sistema. Tali procedure devono comprendere: 6.4.1 La documentazione dell'impatto. 6.4.2 L'approvazione formale del management delle parti interessate. 6.4.3 Il collaudo delle funzionalità operative. 6.4.4 Le procedure di back-out (che consentono di tornare indietro). 6.5 Sviluppare tutte le applicazioni per il Web attenendosi a linee guida di programmazione sicura, ad esempio le linee guida Open Web Application Security Project. Esaminare il codice delle applicazioni personalizzate per identificare eventuali vulnerabilità. Per prevenire eventuali vulnerabilità nella programmazione, durante i processi di sviluppo del software verificare i seguenti punti: 6.5.1 Input non validato 6.5.2 Violazione del controllo dell'accesso (ad esempio, uso improprio degli ID degli utenti) 6.5.3 Violazione della gestione delle autenticazioni e delle sessioni (uso delle credenziali degli account e dei cookie nelle sessioni) 6.5.4 Attacchi XSS (cross-site scripting) 6.5.5 Buffer overflow 6.5.6 Injection flaw, ad esempio iniezione SQL (structured query language) 6.5.7 Cattiva gestione degli errori 6.5.8 Memorizzazione non sicura 6.5.9 DoS (Denial of service) 6.5.10 Gestione non sicura della configurazione 6.6 Assicurarsi che tutte le applicazioni per il Web siano al riparo dagli attacchi più comuni adottando uno dei seguenti metodi: Incaricando un'organizzazione specializzata in sicurezza delle applicazioni di esaminare tutto il codice delle applicazioni personalizzate alla ricerca delle vulnerabilità più comuni. Installando un firewall a livello di applicazione davanti a ogni applicazione Web. Nota: questo metodo è da considerarsi migliore pratica fino al 30 giugno 2008, dopodiché da tale data diventerà un requisito. 1.1 10

Implementare misure forti per il controllo dell'accesso 7 requisito: Limitare l'accesso ai dati dei titolari delle carte solo quando effettivamente indispensabili per lo svolgimento dell'attività commerciale Questo requisito garantisce che l'accesso ai dati critici sia riservato al personale autorizzato. 7.1 Limitare l'accesso alle risorse informatiche e ai dati dei titolari delle carte ai soli soggetti che, per esercitare le loro mansioni, non possono farne a meno. 7.2 Per i sistemi multiutente, mettere a punto un meccanismo di restrizione dell'accesso in base all'effettiva necessità di conoscenza; scegliere l'impostazione deny-all per impedire ogni accesso che non sia specificamente consentito. 1.1 11

8 requisito: Assegnare un ID univoco a ogni utente che ha accesso ai computer L'assegnazione di un identificativo univoco (ID) a ciascun soggetto con accesso al sistema assicura che tutte le operazioni che vengono eseguite su dati e sistemi critici siano imputabili a utenti autorizzati noti. 8.1 Identificare tutti gli utenti assegnando a ciascuno un nome utente univoco prima di autorizzare l'accesso ai componenti del sistema o ai dati dei titolari delle carte. 8.2 Oltre ad assegnare un ID univoco, autenticare gli utenti adottando almeno una delle seguenti misure: Password Dispositivi token (ad esempio SecureID, certificati o chiavi pubbliche) Biometrica 8.3 Implementare l'autenticazione a due fattori per l'accesso remoto alla rete da parte di dipendenti, amministratori e terze parti. Utilizzare tecnologie quali RADIUS (remote authentication and dial-in service) o TACACS (terminal access controller access control system) con i token, oppure VPN (basata su SSL/TLS o IPSEC) con i certificati individuali. 8.4 Cifrare tutte le password durante la trasmissione e la memorizzazione nei componenti del sistema. 8.5 Predisporre una gestione adeguata delle autenticazioni e delle password per gli utenti non consumatori e per gli amministratori in tutti i componenti del sistema, adottando i seguenti accorgimenti: 8.5.1 Controllare l'aggiunta, l'eliminazione e la modifica di ID utenti, credenziali e altri oggetti identificativi. 8.5.2 Verificare l'identità dell'utente prima di reimpostare le password. 8.5.3 Impostare le password per il primo accesso ad un valore diverso per ciascun utente e richiedere la sostituzione di tali password subito dopo il primo accesso. 8.5.4 Revocare immediatamente l'accesso a tutti gli utenti non più attivi. 8.5.5 Rimuovere gli account degli utenti inattivi almeno ogni 90 giorni. 8.5.6 Abilitare la gestione remota degli account dei fornitori soltanto per il periodo di tempo strettamente necessario. 8.5.7 Comunicare le procedure e le politiche relative alle password a tutti gli utenti che hanno accesso ai dati dei titolari delle carte. 8.5.8 Non utilizzare account e password di gruppo, condivisi o generici. 8.5.9 Cambiare le password degli utenti almeno ogni 90 giorni. 8.5.10 Impostare una lunghezza minima di sette caratteri per la password. 8.5.11 Utilizzare password contenenti sia caratteri numerici, sia caratteri alfabetici. 8.5.12 Non approvare la scelta di una nuova password identica a una delle ultime quattro password già utilizzate dallo stesso soggetto. 8.5.13 Limitare tentativi di accesso ripetuti bloccando l'id utente dopo non più di sei tentativi. 8.5.14 Impostare un blocco della durata di trenta minuti o finché l'amministratore non riattiva l'id utente. 8.5.15 Trascorsi 15 minuti di inattività durante una sessione, obbligare l'utente a immettere nuovamente la password per riattivare il terminale. 8.5.16 Autenticare tutti gli accessi ai database contenenti i dati dei titolari delle carte. Sono inclusi gli accessi da parte di applicazioni, amministratori e tutti gli altri utenti. 1.1 12

9 requisito: Limitare la possibilità di accesso fisico ai dati dei titolari delle carte Qualunque possibilità di accedere fisicamente ai dati o ai sistemi che custodiscono i dati dei titolari delle carte rappresenta un'opportunità di accedere a dispositivi o informazioni e di rimuovere sistemi o copie cartacee, pertanto deve essere opportunamente impedita. 9.1 Adottare controlli adeguati all'ingresso degli edifici per limitare e monitorare l'accesso fisico ai sistemi in cui i dati dei titolari delle carte sono memorizzati, elaborati o trasmessi. 9.1.1 Utilizzare videocamere di sorveglianza nelle zone sensibili. Esaminare i dati raccolti ed eseguire altri controlli incrociati. Conservare per almeno tre mesi, salvo diverse disposizioni di legge. 9.1.2 Limitare l'accesso fisico ai connettori di rete accessibili pubblicamente. 9.1.3 Limitare l'accesso fisico ad access point di tipo wireless, gateway e dispositivi portatili. 9.2 Mettere a punto delle procedure per il personale, in modo da distinguere velocemente i dipendenti dai visitatori, in particolar modo nelle zone in cui sono accessibili i dati dei titolari delle carte. Per dipendente si intende una persona assunta a tempo pieno o a tempo parziale, una persona con contratto a tempo determinato o un consulente che svolga la sua prestazione in loco nell'edificio. Per visitatore si intende un fornitore, un ospite di un dipendente, un tecnico dell'assistenza o chiunque abbia la necessità di entrare nell'edificio per un breve periodo, in genere non più di un giorno. 9.3 Assicurarsi che tutti i visitatori siano gestiti nel seguente modo: 9.3.1 Ricevano un'autorizzazione prima di entrare nelle zone in cui i dati dei titolari delle carte sono elaborati o custoditi. 9.3.2 Ricevano un token (ad esempio, una tessera magnetica o un altro dispositivo d'accesso) dotato di una scadenza e di informazioni che identifichino i visitatori come non dipendenti. 9.3.3 Restituiscano il token prima di lasciare l'edificio o alla scadenza. 9.4 Utilizzare un registro dei visitatori per mantenere una traccia (Audit Trail) delle attività dei visitatori. Conservare il registro per almeno tre mesi, salvo diverse disposizioni di legge. 9.5 Conservare le copie di backup dei supporti in un luogo sicuro, preferibilmente in un edificio distaccato, come un magazzino. 9.6 Proteggere fisicamente tutti i supporti elettronici e cartacei che contengono i dati dei titolari delle carte: computer, dischi, componenti hardware per il networking e le comunicazioni, linee di telecomunicazione, ricevute cartacee, documenti e fax. 9.7 Esercitare controlli severi su qualsiasi trasferimento interno o esterno di qualsiasi tipo di supporto contenente i dati dei titolari delle carte, ad esempio: 9.7.1 Classificando i supporti affinché siano facilmente identificabili come "riservati". 9.7.2 Spedendo i supporti con un corriere assicurato o con un altro mezzo di consegna rintracciabile. 9.8 Assicurarsi che il trasferimento di qualsiasi supporto da una zona protetta sia approvato preventivamente dal management (in particolare quando il supporto viene affidato ad individui). 9.9 Esercitare controlli severi sulla conservazione e l'accessibilità dei supporti contenenti i dati dei titolari delle carte. 9.9.1 Inventariare con precisione tutti i supporti e assicurarsi che siano conservati in un luogo protetto. 9.10 Distruggere i supporti contenenti i dati dei titolari delle carte quando non sono più necessari per l'attività commerciale o per scopi legali, procedendo nel seguente modo: 1.1 13

9.10.1 Tagliare a strisce, bruciare o strappare il materiale cartaceo. 9.10.2 Cancellare, smagnetizzare o distruggere in altro modo i supporti elettronici per impedire che i dati dei titolari delle carte possano essere ricostruiti. 1.1 14

Monitorare e testare le reti con regolarità 10 requisito: Monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte È fondamentale avere a disposizione meccanismi di registrazione delle attività degli utenti. La presenza di log in tutti gli ambienti consente di tenere traccia delle cose che accadono e di analizzarne le cause in dettaglio. Senza i log delle attività del sistema è particolarmente difficile risalire alla causa di una compromissione. 10.1 Mettere a punto un processo che colleghi tutti gli accessi ai componenti del sistema (specialmente gli accessi con privilegi amministrativi) ai singoli utenti. 10.2 Implementare Audit Trail automatizzati per tutti i componenti del sistema, in modo da ricostruire i seguenti eventi: 10.2.1 Tutti i singoli accessi di un utente ai dati dei titolari delle carte 10.2.2 Tutte le azioni svolte da un soggetto con privilegi di utente root o amministratore 10.2.3 Accessi a tutti gli Audit Trail 10.2.4 Tentativi non validi di accesso logico 10.2 5 Uso dei meccanismi di identificazione e autenticazione 10.2.6 Inizializzazione degli audit log 10.2.7 Creazione ed eliminazione degli oggetti a livello di sistema. 10.3 Per ogni evento, registrare almeno le seguenti voci di audit trail per tutti i componenti del sistema: 10.3.1 Identificazione dell'utente 10.3.2 Tipo di evento 10.3.3 Data e ora 10.3.4 Indicazione di successo o fallimento 10.3.5 Origine dell'evento 10.3.6 Identità o nome dell'elemento interessato (dati, componente del sistema o risorsa). 10.4 Sincronizzare tutti gli orologi e gli orari critici del sistema. 10.5 Proteggere gli audit trail da eventuali alterazioni. 10.5.1 Limitare la visualizzazione degli audit trail al personale con competenze specifiche. 10.5.2 Proteggere i file di audit trail da modifiche non autorizzate. 10.5.3 Creare copie di backup dei file di audit trail su un server dei log centralizzato o su un supporto che è difficile alterare. 10.5.4 Copiare i log delle reti wireless su un server dei log o nella rete LAN interna. 10.5.5 Utilizzare un meccanismo di monitoraggio dell'integrità dei file e un software di rilevamento delle modifiche per i log, in modo da assicurare che vengano generati allarmi ad ogni tentativo di modifica dei dati dei log esistenti (ma non per l'aggiunta di nuovi dati). 10.6 Esaminare almeno una volta al giorno i log per tutti i componenti del sistema. Nell'esaminare i log, è necessario prendere in considerazione i server che svolgono funzioni per la sicurezza come i servizi antintrusione (IDS), i server di autenticazione, i server di autorizzazione e i server AAA (ad esempio, RADIUS). Nota: la raccolta dei log, il parsing e gli strumenti per la generazione di allarmi devono essere utilizzati ai fini della conformità al Requisito 10.6. 1.1 15

10.7 Conservare la storia degli audit trail per almeno un anno, con un minimo di tre mesi di visibilità online. 1.1 16

11 requisito: Eseguire test periodici dei processi e dei sistemi di protezione Nuove vulnerabilità vengono scoperte continuamente da hacker e ricercatori e vengono introdotte da nuovi programmi software. È necessario eseguire test frequenti sui sistemi, i processi e i programmi software, in modo da garantire un livello di protezione al passo con i tempi e con i cambiamenti del software. 11.1 Eseguire ogni anno i test sui controlli della sicurezza, sulle limitazioni, sulle connessioni di rete e sulle restrizioni, così da poter identificare e bloccare con sufficiente efficacia i tentativi di accesso non autorizzato. Almeno una volta ogni tre mesi utilizzare un analizzatore di reti wireless per identificare tutti i dispositivi wireless in uso. 11.2 Eseguire scansioni interne ed esterne delle vulnerabilità almeno una volta ogni tre mesi e dopo ogni cambiamento significativo apportato alla rete, ad esempio: l'installazione di un nuovo componente nel sistema, un cambiamento della topologia della rete, una modifica delle regole del firewall o l'aggiornamento di un prodotto. Nota: le scansioni esterne delle vulnerabilità devono essere eseguite trimestralmente da un ASV approvato dalla PCI. Le scansioni dopo le modifiche della rete possono essere eseguite dal personale interno dell'azienda. 11.3 Eseguire i test di penetrazione almeno una volta all'anno e dopo ogni aggiornamento o modifica significativi apportati all'infrastruttura o a un'applicazione, ad esempio: un aggiornamento del sistema operativo o l'aggiunta di una subnet o di un server Web all'ambiente. I test di penetrazione devono includere: 11.3.1 Test di penetrazione al livello di rete 11.3.2 Test di penetrazione al livello di applicazioni. 11.4 Utilizzare i sistemi antintrusione presenti nella rete e basati sugli host per sorvegliare tutto il traffico della rete e segnalare i rischi al personale addetto. Mantenere aggiornati tutti i moduli antintrusione. 11.5 Installare un programma software di monitoraggio dell'integrità dei file per segnalare al personale addetto la modifica non autorizzata di file di sistema o con contenuti critici. Configurare inoltre tale programma software in modo che esegua un confronto settimanale tra i file. I file critici non sono soltanto quelli che contengono i dati dei titolari delle carte. Ai fini del monitoraggio dell'integrità dei file, i file critici sono quelli che non cambiano con frequenza, ma la cui modifica potrebbe indicare la compromissione di un sistema o il rischio di compromissione. Di solito, i prodotti per il monitoraggio dell'integrità dei file sono preconfigurati con i file critici per il sistema operativo in uso. Altri file critici, ad esempio quelli per le applicazioni personalizzate, devono essere valutati e definiti dall'entità interessata (l'esercente o il provider di servizi). 1.1 17

Adottare una Politica di Sicurezza 12 requisito: Adottare una Politica di Sicurezza rivolta a dipendenti e lavoratori a contratto Le politiche di sicurezza sono forti se sono diffuse nell'intera azienda e se indicano ai dipendenti quali comportamenti tenere. Occorre sensibilizzare tutti i dipendenti sull'importanza dei dati e sulla loro responsabilità di proteggerli. 12.1 Mettere a punto, diffondere, rispettare e divulgare politiche di sicurezza che conseguano i seguenti obiettivi: 12.1.1 Rispondano a tutti i requisiti descritti. 12.1.2 Includano un processo annuale per identificare le minacce e le vulnerabilità e giungere a una valutazione dei rischi formale. 12.1.3 Includano un controllo almeno annuale e venga aggiornata quando l'ambiente cambia. 12.2 Sviluppare procedure operative giornaliere per la sicurezza che siano coerenti con i requisiti descritti (ad esempio, procedure per la manutenzione degli account utente e procedure per il controllo dei log). 12.3 Sviluppare politiche di utilizzo delle tecnologie critiche a disposizione dei dipendenti (ad esempio, modem e dispositivi wireless) in modo da definire l'uso corretto di tali tecnologie per tutti i dipendenti e i lavoratori a contratto. Assicurarsi che queste politiche prevedano i seguenti obblighi: 12.3.1 Approvazione esplicita del management 12.3.2 Autenticazione per l'uso della tecnologia 12.3.3 Elenco di tutti i dispositivi di questo tipo e dei dipendenti con accesso ad essi 12.3.4 Etichettatura dei dispositivi con proprietario, informazioni per contattarlo e scopo 12.3.5 Usi accettabili delle tecnologie 12.3.6 Ubicazioni in rete accettabili per le tecnologie 12.3.7 Elenco dei prodotti approvati dall'azienda 12.3.8 Disconnessione automatica delle sessioni modem dopo il periodo di inattività indicato 12.3.9 Attivazione dei modem per i fornitori solo su richiesta dei fornitori e con immediata disattivazione dopo l'uso 12.3.10 In caso di accesso remoto ai dati dei titolari delle carte tramite modem, divieto di memorizzazione dei dati dei titolari delle carte su dischi rigidi locali, dischi floppy o altri supporti esterni. Divieto dell'impiego di funzioni di copia-incolla e stampa durante l'accesso remoto. 12.4 Assicurarsi che le regole e le procedure per la sicurezza definiscano in modo chiaro le responsabilità di tutti i dipendenti e i lavoratori a contratto in materia di protezione delle informazioni. 12.5 Assegnare a un individuo o a un gruppo di individui le seguenti competenze per la gestione della protezione delle informazioni: 12.5.1 Mettere a punto, documentare e distribuire le regole e le procedure per la sicurezza. 12.5.2 Monitorare e analizzare gli avvisi e le informazioni sulla sicurezza e distribuirli al personale interessato. 1.1 18

12.5.3 Mettere a punto, documentare e distribuire le procedure di risposta e di escalation in caso di violazioni della sicurezza, per assicurare una gestione precisa e puntuale di tutte le situazioni. 12.5.4 Amministrare gli account degli utenti, comprese aggiunte, eliminazioni e modifiche. 12.5.5 Sorvegliare e controllare tutti gli accessi ai dati. 12.6 Implementare un programma formale per sensibilizzare i dipendenti sul problema della sicurezza e per ricordare loro che hanno la responsabilità di proteggere i dati dei titolari delle carte. 12.6.1 Educare i nuovi assunti e i vecchi dipendenti almeno una volta all'anno, ad esempio tramite lettera, poster, promemoria, riunioni e promozioni. 12.6.2 Richiedere ai dipendenti di firmare un documento che attesti che hanno letto e compreso le regole e le procedure aziendali per la sicurezza. 12.7 Eseguire uno screening dei potenziali assunti per ridurre al minimo i rischi provenienti da fonti interne. Per i dipendenti che hanno accesso a un solo numero di carta alla volta per facilitare una transazione (ad esempio, i cassieri di un negozio), questo non è un requisito ma una raccomandazione. 12.8 Se si condividono i dati dei titolari delle carte con i provider di servizi, per contratto sono previsti i seguenti obblighi: 12.8.1 Adesione dei provider di servizi ai requisiti PCI DSS. 12.8.2 Contratto in cui il provider di servizi attesti di essere responsabile della sicurezza dei dati dei titolari delle carte. 12.9 Implementare un piano di risposta agli incidenti. Prepararsi a rispondere immediatamente a una violazione del sistema. 12.9.1 Creare il piano di risposta agli incidenti da attuare in caso di compromissione del sistema. Assicurarsi che il piano si occupi, almeno, di procedure specifiche di risposta agli incidenti, di procedure per il ripristino e la continuità dell'attività commerciale, di processi di backup dei dati, di ruoli e responsabilità e di strategie di comunicazione e contatto (ad esempio, informando gli Acquirenti e le associazioni delle carte di credito). 12.9.2 Collaudare il piano almeno una volta all'anno. 12.9.3 Nominare personale specifico che deve essere a disposizione 24 ore al giorno, 7 giorni su 7 in caso di emergenza. 12.9.4 Addestrare il personale per reagire adeguatamente alle situazioni di violazione della sicurezza. 12.9.5 Includere allarmi dai sistemi antintrusione e dai sistemi di monitoraggio dell'integrità dei file. 12.9.6 Sviluppare un processo che consenta di correggere e migliorare il piano di risposta agli incidenti tenendo conto delle lezioni apprese e degli ultimi sviluppi nel settore. 12.10 Tutti i provider di servizi e i processor devono adottare e seguire regole e procedure atte a gestire le entità connesse, comprese le seguenti attività: 12.10.1. Conservare e aggiornare un elenco delle entità connesse. 12.10.2. Assicurare che tutte le procedure siano rispettate prima di connettere un'entità. 12.10.3. Assicurarsi che l'entità rispetti lo standard PCI DSS. 12.10.4. Connettere e disconnettere le entità seguendo un processo consolidato. 1.1 19

Appendice A: Applicabilità dello standard PCI DSS per i provider di hosting Requisito A.1: I provider di hosting proteggono l'ambiente dati dei titolari delle carte Come citato nel Requisito 12.8, tutti i provider di servizi con accesso ai dati dei titolari delle carte (compresi i provider di hosting) devono dare la loro adesione allo standard PCI DSS. Inoltre il Requisito 2.4 prevede che i provider dei servizi di hosting proteggano l'ambiente e i dati dell'entità che ospitano. Di conseguenza, i provider di hosting devono prestare particolare attenzione ai seguenti punti: A.1 Proteggere l'ambiente e i dati dell'entità ospitata (esercente, provider di servizi o altro), nei modi previsti nei punti da A.1.1 a A.1.4: A.1.1 Assicurare che ciascuna entità abbia accesso soltanto al proprio ambiente dati dei titolari delle carte. A.1.2 Limitare l'accesso e i privilegi di ciascuna entità all'ambiente dati dei titolari delle carte di propria competenza. A.1.3 Assicurarsi che le funzioni di audit trail e di generazione dei log siano abilitate e siano univoche per l'ambiente dati dei titolari delle carte di ciascuna entità, e che siano altresì coerenti con il Requisito 10 dello standard PCI DSS. A.1.4 Abilitare processi idonei a consentire un'indagine legale puntuale in caso di compromissione di un esercente o un provider di servizi ospitato. Il provider di hosting è tenuto a soddisfare questi requisiti, oltre agli altri punti dello standard PCI DSS. Nota: anche se un provider di hosting soddisfa tutti questi requisiti, la conformità del soggetto che utilizza tale provider di hosting non è automaticamente garantita. Ciascuna entità deve ottenere una dichiarazione valida di conformità allo standard PCI DSS nelle modalità opportune.

Appendice B: Controlli compensativi Informazioni generali sui controlli compensativi Esiste la possibilità di adottare dei controlli compensativi per molti requisiti PCI DSS qualora un'entità non sia in grado di soddisfare una specifica tecnica di uno di questi requisiti, ma abbia ridotto in modo sufficiente il rischio associato. Per una definizione dei controlli compensativi, si rimanda alla relativa sezione del Glossario PCI DSS. L'efficacia di un controllo compensativo dipende dalle specifiche dell'ambiente in cui il controllo viene implementato, dai controlli di sicurezza circostanti e dalla configurazione del controllo in questione. Le società devono considerare che un determinato controllo compensativo potrebbe non essere efficace in tutti gli ambienti. Per garantirne l'efficacia, è necessario valutare attentamente ciascun controllo compensativo dopo la sua implementazione. Di seguito vengono forniti alcuni suggerimenti per i controlli compensativi che possono essere adottati da società non capaci di rendere illeggibili i dati dei titolari delle carte (Requisito 3.4). Controlli compensativi per il Requisito 3.4 Nel caso di società che non siano in grado di assicurare l'illeggibilità dei dati dei titolari delle carte (ad esempio, tramite cifratura) per palesi limiti o ostacoli tecnici, è possibile prendere in considerazione alcuni controlli compensativi. Possono ricorrere ai controlli compensativi ai fini della conformità agli standard soltanto quelle società che abbiano intrapreso un'analisi seria dei rischi e che vi siano obbligate da vincoli commerciali documentati o da limiti tecnici legittimi. Le società che intendono ricorrere ai controlli compensativi per rendere illeggibili i dati dei titolari delle carte devono dimostrare la consapevolezza del rischio a cui espongono tali dati conservandoli. In generale i controlli devono apportare un ulteriore livello di protezione per controbilanciare il rischio aggiuntivo costituito dalla conservazione dei dati dei titolari delle carte. I controlli presi in considerazione devono inoltre aggiungersi a quelli già previsti dallo standard PCI DSS e devono necessariamente soddisfare la definizione di Controlli compensativi fornita nella relativa sezione del Glossario PCI DSS. I controlli compensativi possono corrispondere in pratica a un dispositivo o a una combinazione di dispositivi, applicazioni e verifiche che soddisfino tutte le seguenti condizioni: 1. Fornire un'ulteriore segmentazione/astrazione (ad esempio, al livello di rete). 2. Limitare l'accesso ai dati dei titolari delle carte o ai database sulla base dei seguenti criteri: Indirizzo IP/Mac Applicazione/servizio Account di utenti e gruppi Tipo di dati (filtro pacchetti) 3. Limitare l'accesso logico al database. Devono controllare l'accesso logico al database indipendentemente da Active Directory o LDAP (Lightweight Directory Access Protocol). 4. Impedire/rilevare i comuni attacchi alle applicazioni o ai database (ad esempio, iniezione SQL).