new payment card industry (pci) data security standard · 2018. 12. 19. · payment card industry...

Payment Card Industry (PCI) Data Security Standard

Procedure di audit sulla sicurezza

Versione 1.1 Release: settembre 2006

Copyright 2006 PCI Security Standards Council LLC. Procedure di audit sulla sicurezza v 1.1 2

Indice generale Procedure di audit sulla sicurezza ................................................................................................................................................................................................. 1 Versione 1.1 ................................................................................................................................................................................................................................... 1

Indice generale ....................................................................................................................................................................................................................... 2 Introduzione ................................................................................................................................................................................................................................... 3 Informazioni sull'applicabilità dello standard PCI DSS .................................................................................................................................................................. 4 Valutazione della conformità ai requisiti PCI DSS ......................................................................................................................................................................... 5

Wireless .................................................................................................................................................................................................................................. 6 Outsourcing ............................................................................................................................................................................................................................ 6 Campionamento ..................................................................................................................................................................................................................... 6 Controlli compensativi ............................................................................................................................................................................................................. 7

Istruzioni e contenuto della Dichiarazione di conformità ............................................................................................................................................................... 7 Riconvalida di elementi aperti ........................................................................................................................................................................................................ 8 Costruire e mantenere una rete protetta ........................................................................................................................................................................................ 9

1° requisito: Installare e mantenere una configurazione con firewall per proteggere i dati dei titolari delle carte ................................................................. 9 2° requisito: Non utilizzare password di sistema predefinite o altri parametri di sicurezza impostati dai fornitori. .............................................................. 13

Proteggere i dati dei titolari delle carte ........................................................................................................................................................................................ 17 3° requisito: Proteggere i dati dei titolari delle carte memorizzati ........................................................................................................................................ 17 4° requisito: Cifrare i dati dei titolari delle carte quando vengono trasmessi attraverso reti pubbliche aperte ..................................................................... 24

Rispettare un programma per la gestione delle vulnerabilità ...................................................................................................................................................... 27 5° requisito: Utilizzare e aggiornare con regolarità il software o i programmi antivirus ........................................................................................................ 27 6° requisito: Sviluppare e mantenere applicazioni e sistemi protetti .................................................................................................................................... 28

Implementare misure forti per il controllo dell'accesso ................................................................................................................................................................ 34 7° requisito: Limitare l'accesso ai dati dei titolari delle carte solo se effettivamente indispensabili per lo svolgimento dell'attività commerciale ............... 34 8° requisito: Assegnare un ID univoco a ogni utente che ha accesso ai computer. ............................................................................................................ 35 9° requisito: Limitare la possibilità di accesso fisico ai dati dei titolari delle carte ................................................................................................................ 40

Monitorare e testare le reti con regolarità .................................................................................................................................................................................... 44 11° requisito: Eseguire test periodici dei processi e dei sistemi di protezione. .................................................................................................................... 48

Adottare una politica per la protezione delle informazioni ........................................................................................................................................................... 51 12° requisito: Adottare una politica per la protezione delle informazioni rivolta a dipendenti e lavoratori a contratto ......................................................... 51

Appendice A: Applicabilità dello standard PCI DSS per i provider di hosting (con procedure e test) ......................................................................................... 58 Requisito A.1: I provider di hosting proteggono l'ambiente dati dei titolari delle carte ......................................................................................................... 58

Appendice B: Controlli compensativi ........................................................................................................................................................................................... 62 Informazioni generali sui controlli compensativi ................................................................................................................................................................... 62 Controlli compensativi per il Requisito 3.4 ............................................................................................................................................................................ 62

Appendice C: Foglio di lavoro sui controlli compensativi / esempio precompilato ...................................................................................................................... 63


Introduzione Le "PCI Security Audit Procedures" sono le procedure di audit sulla sicurezza rivolte a tutti gli ispettori che svolgono i controlli presso gli esercenti e i provider di servizi, i quali devono dimostrare la conformità delle loro attività ai requisiti PCI DSS (Payment Card Industry Data Security Standard). Le procedure di audit e i requisiti descritti nel presente documento fanno riferimento allo standard PCI DSS.

Contenuto del documento:

• Introduzione • Informazioni sull'applicabilità dello standard PCI DSS • Valutazione della conformità ai requisiti PCI DSS • Istruzioni e contenuto della Dichiarazione di conformità • Riconvalida di elementi aperti • Procedure di audit sulla sicurezza APPENDICI • Appendice A: Applicabilità dello standard PCI DSS per i provider di hosting (con procedure e test) • Appendice B: Controlli compensativi • Appendice C: Foglio di lavoro sui controlli compensativi / esempio precompilato


Informazioni sull'applicabilità dello standard PCI DSS 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.

* 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).

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 magneticaintera No N/P N/P

CVC2/CVV2/CID No N/P N/P

PIN / Blocco PIN No N/P N/P


Valutazione della conformità ai requisiti PCI DSS I requisiti per la sicurezza PCI DSS si applicano a tutti i “componenti del sistema”, dove per componente 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. I componenti della rete includono, tra gli altri, firewall, switch, router, access point di tipo 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).

Un'adeguata segmentazione della rete, in cui i sistemi per la memorizzazione, elaborazione e trasmissione dei dati dei titolari delle carte siano sufficientemente isolati dal resto della rete, può ridurre le dimensioni dell'ambiente dati dei titolari delle carte. L'ispettore di audit deve verificare che la segmentazione sia sufficiente a ridurre l'entità dell'audit.

Il provider di servizi o l'esercente può affidare a un soggetto terzo (provider) la gestione di componenti quali router, firewall, database, sicurezza fisica e/o server. In tal caso, va valutato l'impatto sulla sicurezza dell'ambiente dati dei titolari delle carte. I servizi pertinenti, forniti dal provider terzo, devono essere sottoposti a valutazione 1) nel corso dei controlli di audit PCI presso ciascuno dei clienti del provider terzo oppure 2) durante il controllo di audit PCI che si svolge presso il provider terzo.

Per quanto concerne i provider di servizi sottoposti a un'ispezione annuale presso la propria sede, dovranno dimostrare la conformità di tutti i componenti del sistema in cui i dati dei titolari delle carte vengono memorizzati, elaborati o trasmessi, salvo diverse indicazioni.

Per quanto concerne gli esercenti sottoposti a un'ispezione annuale presso la propria sede, dovranno dimostrare la conformità specifica di quei sistemi o componenti del sistema che sono implicati nei processi di autorizzazione delle transazioni e in cui i dati dei titolari delle carte vengono memorizzati, elaborati o trasmessi. Tali componenti includono: • Tutte le connessioni esterne alla rete dell'esercente (ad esempio, accesso remoto di dipendenti e società che emettono

carte di pagamento, accesso di soggetti terzi per l'elaborazione e la manutenzione dei dati). • Tutte le connessioni da e verso l'ambiente di autorizzazione delle transazioni (ad esempio, connessioni per l'accesso di

dipendenti o di dispositivi quali firewall e router). • Tutti gli archivi di dati esterni all'ambiente di autorizzazione delle transazioni, dove vengono custoditi più di 500.000

numeri di account. Nota: anche se alcuni archivi di dati o sistemi vengono esclusi dal controllo di audit, l'esercente è comunque tenuto ad assicurare la conformità allo standard PCI DSS per tutti i sistemi in cui i dati dei titolari delle carte vengono memorizzati, elaborati o trasmessi.

• Un ambiente POS (point-of-sale), ovvero il luogo fisico presso la sede dell'esercente in cui una transazione viene accettata (ad esempio un negozio, un ristorante, un hotel, un distributore di benzina, un supermercato o simile).


• Se non è fornito nessun accesso esterno alla sede dell'esercente (tramite Internet, wireless, rete VPN, ,modem, banda larga o tramite punti vendita e distributori automatici), l'ambiente POS potrebbe essere escluso dal controllo di audit.

Wireless

Se viene utilizzata la tecnologia wireless per memorizzare, elaborare o trasmettere i dati dei titolari delle carte (ad esempio, per le transazioni POS, il “line-busting” o alleggerimento delle code alla cassa) o se una rete LAN wireless è connessa all'ambiente dati dei titolari delle carte o ne fa parte (ad esempio, non è separata nettamente da un firewall), devono essere applicati e rispettati i requisiti e i test eseguiti sugli ambienti wireless. La sicurezza dei sistemi wireless non ha ancora raggiunto livelli di eccellenza, tuttavia i requisiti in questione obbligano ad adottare una serie di misure di protezione wireless minime. Dal momento che le tecnologie wireless non offrono un livello di sicurezza accettabile, prima che una società adotti una tecnologia wireless è necessaria una seria valutazione dei vantaggi e rischi. Un approccio valido potrebbe essere iniziare a implementare la tecnologia wireless solo per la trasmissione di dati non sensibili e attendere che la tecnologia wireless diventi più sicura prima di estenderla ad altre funzioni.

Outsourcing

Nel caso di entità che praticano l'outsourcing, ovvero delegano a terzi (in genere provider di servizi) la memorizzazione, l'elaborazione o la trasmissione dei dati dei titolari delle carte, la Dichiarazione di conformità deve documentare il ruolo svolto da ciascun provider di servizi. Inoltre i provider dei servizi sono tenuti a certificare la propria conformità ai requisiti PCI DSS, indipendentemente dai controlli di audit svolti presso i loro clienti. Gli esercenti e i provider di servizi devono altresì richiedere per contratto che tutti i soggetti terzi ad essi associati, con accesso ai dati dei titolari delle carte, aderiscano allo standard PCI DSS. Per maggiori dettagli, fare riferimento al Requisito 12.8 descritto nel presente documento.

Campionamento

L'ispettore di audit può scegliere di eseguire i test su un campione dei componenti del sistema, che dovrà essere rappresentativo di tutti i tipi di componenti del sistema in uso e dovrà includere le varie combinazioni di sistemi operativi, funzioni e applicazioni comunemente in uso nell'area ispezionata. Ad esempio, l'ispettore può scegliere i server Sun che eseguono Apache WWW, i server NT che eseguono Oracle, i sistemi mainframe che eseguono le applicazioni legacy per l'elaborazione delle carte, i server per il trasferimento dei dati che eseguono HP-UX e i server Linux che eseguono MYSQL. Se tutte le applicazioni sono eseguite su un unico sistema operativo (ad esempio, NT o Sun), il campione dovrà includere diverse applicazioni, ad esempio server dei database, server Web e server per il trasferimento dati.

Nel selezionare i campioni per i negozi degli esercenti o per gli esercenti in franchising, gli ispettori devono considerare quanto segue: • Se sono stati adottati processi PCI DSS standard e ogni negozio è obbligato a seguirli, il campione potrà essere più

piccolo di quanto non sia necessario in assenza dei processi standard, poiché è ragionevole ritenere che ogni negozio sia in linea con gli standard.


• Se i processi standard adottati sono più di uno (ad esempio, uno per ogni tipo di negozio), il campione dovrà essere abbastanza ampio da includere una selezione di negozi per ogni tipo di processo.

• Se non sono stati adottati processi PCI DSS standard e ogni negozio è responsabile dei propri, il campione dovrà essere più ampio e garantire che ogni negozio abbia compreso e implementato i requisiti PCI DSS in modo soddisfacente.

Controlli compensativi

Gli eventuali controlli compensativi devono essere documentati dall'ispettore e comparire nella richiesta di Dichiarazione di conformità, come mostra l'Appendice C – Foglio di lavoro sui controlli compensativi / esempio precompilato.

Per una definizione dei controlli compensativi, si rimanda alla relativa sezione del Glossario PCI DSS.

Istruzioni e contenuto della Dichiarazione di conformità Il presente documento deve essere utilizzato dagli ispettori come modello per la compilazione della Dichiarazione di conformità. L'entità sottoposta al controllo di audit è tenuta al rispetto dei requisiti per le dichiarazioni di conformità previsti dalle singole società che emettono le carte di pagamento, in modo da garantire che ciascuna di esse riconosca lo stato di conformità dell'entità. Contattare le singole società che emettono le carte di pagamento per ricevere i requisiti e le istruzioni per la certificazione. Durante la stesura della Dichiarazione di conformità, tutti gli ispettori sono tenuti a seguire istruzioni specifiche sul formato e sul contenuto:

1. Indirizzi di contatto e data della dichiarazione

• Inserire i dati per contattare l'esercente/il provider di servizi e l'ispettore • Data della dichiarazione

2. Riepilogo esecutivo

Inserire le seguenti informazioni: • Descrizione dell'attività commerciale • Elenco dei provider di servizi e di altre entità con cui la società condivide i dati dei titolari delle carte • Elenco delle relazioni con i processor • Indicare se l'entità è collegata direttamente a una società che emette carte di pagamento • Per gli esercenti, i prodotti POS utilizzati • Tutti le entità di proprietà per le quali è richiesta la conformità allo standard PCI DSS • Tutti le entità internazionali per le quali è richiesta la conformità allo standard PCI DSS • Tutte le reti LAN wireless e/o i terminali POS wireless connessi all'ambiente dati dei titolari delle carte


3. Descrizione della portata del lavoro e approccio seguito

• Versione del documento "Procedure di audit per la sicurezza" utilizzato per condurre l'ispezione • Durata temporale dell'ispezione • Ambiente sul quale si è concentrata l'ispezione (ad esempio, access point del cliente per Internet, rete aziendale interna, punti di

elaborazione per la società che emette le carte di pagamento) • Tutte le aree escluse dall'ispezione • Breve descrizione o diagramma dettagliato della topologia della rete e dei controlli • Elenco delle persone ascoltate • Elenco della documentazione letta • Elenco dei componenti hardware e dei programmi software critici in uso (ad esempio, per database o cifratura) • Se l'ispezione riguarda un MSP (Managed Service Provider), descrivere chiaramente quali dei requisiti elencati nel presente

documento si applicano all'MSP (e sono quindi inclusi nell'ispezione) e quali non sono inclusi nell'ispezione e dovranno invece essere inclusi nelle ispezioni di competenza dei clienti dell'MSP Inserire informazioni su quali indirizzi IP dell'MSP sono stati sottoposti a scansione durante le scansioni trimestrali delle vulnerabilità dell'MSP e quali indirizzi IP dovranno invece essere inclusi nelle scansioni trimestrali di competenza dei clienti dell'MSP

4. Risultati delle scansioni trimestrali

• Riassumere i risultati delle ultime quattro scansioni trimestrali sotto forma di commento al Requisito 11.2 • Le scansioni devono coinvolgere tutti gli indirizzi IP accessibili dall'esterno (visibili sul Web) esistenti presso l'entità

5. Conclusioni e osservazioni

• Tutti gli ispettori sono tenuti ad utilizzare il seguente modello per fornire descrizioni e conclusioni circostanziate per ogni requisito e ogni requisito secondario.

• Se pertinente, devono essere documentati tutti i controlli compensativi ritenuti equivalenti al "controllo implementato" • Per una definizione dei controlli compensativi, si rimanda alla relativa sezione del Glossario PCI DSS.

Riconvalida di elementi aperti Come riscontro della conformità è necessario un report dei “controlli implementati”. Se il report iniziale del controllore/ispettore contiene alcuni “elementi aperti”, l'esercente/il provider di servizi dovrà trovare una soluzione per tali elementi per poter completare l'iter della certificazione. Il controllore/ispettore dovrà quindi riverificare la soluzione adottata e certificare che tutti i requisiti sono stati soddisfatti. Dopo avere verificato che il sistema è pienamente conforme, l'ispettore rilascerà una nuova Dichiarazione di conformità e la presenterà coerentemente con le istruzioni ricevute (vedere paragrafo precedente).


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.

REQUISITI PCI DSS TEST ESEGUITI RISPETTATI NON RISPETTATI

ULTIMA DATA UTILE /

COMMENTI 1.1 Fissare standard per la configurazione dei firewall adottando le seguenti misure:

1.1 Richiedere e ispezionare gli standard di configurazione dei firewall e altra documentazione specificata più avanti per verificare che gli standard siano completi. Completare tutte le voci in questa sezione.

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.1 Verificare che gli standard di configurazione dei firewall includano un processo relativo a tutte le modifiche dei firewall, compresi il collaudo e l'approvazione del management di tutte le modifiche apportate alle connessioni esterne e alla 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.2.a Verificare che esista un diagramma aggiornato della rete e che in esso siano documentate tutte le connessioni ai dati dei titolari delle carte, comprese le reti wireless.

1.1.2.b Verificare che il diagramma venga aggiornato regolarmente.

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.3 Verificare che gli standard di configurazione dei firewall prevedano l'uso obbligatorio di un firewall in corrispondenza di ogni connessione a Internet e tra la zona DMZ e Intranet. Verificare che il diagramma della rete disponibile sia coerente con gli standard di



ULTIMA DATA UTILE /

COMMENTI configurazione dei firewall.

1.1.4 Descrizione di gruppi, ruoli e responsabilità per una gestione logica dei componenti della rete.

1.1.4 Verificare che gli standard di configurazione dei firewall includano una descrizione dei gruppi, dei ruoli e delle responsabilità per una gestione logica dei componenti della rete.

1.1.5 Elenco documentato dei servizi e delle porte necessarie per l'attività commerciale.

1.1.5 Verificare che gli standard di configurazione dei firewall includano un elenco documentato dei servizi/delle porte utilizzati 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.6 Verificare che gli standard di configurazione dei firewall includano i giustificativi e la documentazione relativa a tutti i protocolli disponibili oltre a HTTP e SSL, SSH e VPN.

1.1.7 Giustificativi e documentazione per tutti i protocolli rischiosi di cui è consentito l'uso: ad esempio, lo standard FTP (file transfer protocol) include la motivazione per cui viene utilizzato questo protocollo e le funzioni di protezione implementate.

1.1.7.a Verificare che gli standard di configurazione dei firewall includano i giustificativi e la documentazione relativa a tutti i protocolli rischiosi di cui è consentito l'uso: ad esempio, il protocollo FTP include la motivazione per cui viene utilizzato e le funzioni di protezione implementate.

1.1.7.b Esaminare la documentazione e le impostazioni di ciascun servizio in uso a dimostrazione della necessità e della sicurezza del servizio.

1.1.8 Revisione trimestrale delle regole fissate per i firewall e i router.

1.1.8.a Verificare che gli standard di configurazione dei firewall prevedano una revisione trimestrale delle regole per i firewall e i router.

1.1.8.b Verificare che le regole vengano effettivamente riviste ogni tre mesi.

1.1.9 Standard di configurazione dei router

1.1.9 Verificare l'esistenza degli standard di configurazione per firewall e router.

1.2 Costruire una configurazione dei firewall che impedisca il traffico da reti e host di dubbia provenienza (untrusted), tranne che per i protocolli

1.2 Selezionare un campione di firewall/router 1) tra Internet e la zona DMZ e 2) tra la zona DMZ e la rete interna. Il campione dovrebbe includere il router interno (choke) per Internet, il router e il firewall per la zona



ULTIMA DATA UTILE /

COMMENTI indispensabili per l'ambiente dati dei titolari delle carte.

DMZ, il segmento con i dati dei titolari delle carte nella zona DMZ, il router perimetrale e il segmento interno della rete con i dati dei titolari delle carte. Esaminare le configurazioni dei firewall e dei router per verificare che il traffico in entrata e in uscita sia limitato ai soli protocolli necessari 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. Tale configurazione dei firewall dovrebbe includere:

1.3 Esaminare le configurazioni dei firewall per verificare che le connessioni tra i server di pubblico accesso e i componenti in cui sono custoditi i dati dei titolari delle carte siano limitate, nel seguente modo:

1.3.1 Limitazione del traffico Internet in entrata agli indirizzi IP (Internet Protocol) entro la zona DMZ (filtri in ingresso).

1.3.1 Verificare che il traffico Internet in entrata sia limitato agli indirizzi IP entro la zona DMZ.

1.3.2 Divieto per gli indirizzi interni di passare da Internet alla zona DMZ.

1.3.2 Verificare che gli indirizzi interni non passino da Internet alla zona DMZ.

1.3.3 Attuazione di un meccanismo di "dynamic packet filtering", che consenta cioè soltanto alle connessioni consolidate di accedere alla rete.

1.3.3 Verificare che il firewall esegua il dynamic packet filtering. [Dovrebbero essere consentite solo le connessioni consolidate e solo se associate a una sessione attivata in precedenza (eseguire NMAP su tutte le porte TCP con i bit “syn reset” o ”syn ack” impostati; una risposta significa che i pacchetti sono ammessi anche se non fanno parte di una sessione attivata in precedenza).]

1.3.4 Collocazione del database in una zona della rete interna nettamente separata dalla zona DMZ.

1.3.4 Verificare che il database sia 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.3.5 Verificare che il traffico in entrata e in uscita sia limitato a quello strettamente necessario per l'ambiente dati dei titolari delle carte e che le limitazioni siano documentate.

1.3.6 Protezione e sincronizzazione 1.3.6 Verificare che i file di configurazione dei router



ULTIMA DATA UTILE /

COMMENTI 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.

siano protetti e sincronizzati: 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) hanno 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.7 Verificare che tutto il restante traffico in entrata e in uscita non coperto nei punti 1.2 e 1.3 precedenti sia negato in modo esplicito.

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 per l'attività commerciale.

1.3.8 Verificare che siano installati dei firewall perimetrali tra le reti e i sistemi wireless in cui sono memorizzati i dati dei titolari delle carte e che tali firewall neghino o controllino (se tale traffico è indispensabile per fini commerciali) tutto il traffico proveniente dall'ambiente wireless verso i sistemi in cui sono memorizzati i dati dei titolari delle carte.

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.3.9 Verificare che nei portatili e/o nei computer utilizzati dai dipendenti (ad esempio, i laptop di loro proprietà) con connettività diretta a Internet e con accesso alla rete dell'organizzazione sia installato e attivato un firewall personale. Tale software deve essere configurato dall'organizzazione in base a specifici standard e non deve essere modificabile dal dipendente.

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, registri e file trace).

1.4 Per verificare che sia effettivamente vietato l'accesso diretto tra le reti pubbliche esterne e i componenti del sistema in cui sono memorizzati i dati dei titolari delle carte, eseguire la seguente procedura specifica per la configurazione di firewall/router implementati tra la zona DMZ e la rete interna:

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

1.4.1 Esaminare le configurazioni di firewall/router e verificare che non vi sia nessun percorso diretto in entrata o in uscita per il traffico Internet.



ULTIMA DATA UTILE /

COMMENTI 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.4.2 Esaminare le configurazioni di firewall/router e verificare che il traffico interno in uscita dalle applicazioni con i dati dei titolari delle carte abbia accesso soltanto agli indirizzi IP entro la 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).

1.5 Per costituire il campione di componenti firewall/router di cui sopra, verificare che venga impiegata la tecnologia NAT o un'altra tecnologia basata sullo spazio indirizzi RFC 1918 per limitare la trasmissione degli indirizzi IP dalla rete interna a Internet (IP-masquerading).

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.


ULTIMA DATA UTILE /

COMMENTI 2.1 Cambiare sempre le impostazioni predefinite dei fornitori prima di installare un sistema nella rete: ad esempio, aggiungere password, stringhe di comunità SNMP (simple network management protocol) ed eliminare gli account superflui.

2.1 Scegliere un campione di componenti del sistema, di server critici e di access point di tipo wireless e, con l'aiuto dell'amministratore del sistema, effettuare un tentativo di collegamento ai dispositivi utilizzando gli account e le password predefinite del fornitore, in modo da verificare che sia gli uni che le altre siano stati effettivamente cambiati (utilizzare i manuali dei prodotti e altre fonti reperibili su Internet per trovare le combinazioni di account/password preimpostate dai produttori).



ULTIMA DATA UTILE /

COMMENTI

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 le trasmissioni SSID. Abilitare le tecnologie di accesso protetto WiFi (WPA e WPA2) per la cifratura e l'autenticazione (se la tecnologia WPA è disponibile).

2.1.1 Per quanto riguarda le impostazioni predefinite del fornitore di ambienti wireless, verificare i seguenti punti:

• Le chiavi WEP predefinite sono state cambiate durante l'installazione e vengono cambiate ogniqualvolta un dipendente che le conosce lascia la società o cambia mansione.

• L'identificativo SSID predefinito è stato cambiato.

• La trasmissione dell'identificativo SSID è stata disabilitata.

• Le stringhe di comunità SNMP predefinite sugli access point sono state cambiate.

• Le password predefinite sugli access point sono state cambiate.

• La tecnologia WPA o WPA2 è abilitata (se il sistema wireless supporta la tecnologia WPA).

• Altre impostazioni predefinite del fornitore del sistema wireless sono state cambiate (se disponibili).

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 Network (SANS), il National Institute of Standards Technology (NIST) e il Center for Internet Security (CIS).

2.2.a Esaminare gli standard di configurazione dell'organizzazione per i componenti della rete, i server critici e gli access point di tipo wireless, verificandone la coerenza con gli standard di System Hardening che sono accettati, ad esempio, da enti quali il SANS, il NIST e il CIS.

2.2.b Verificare che gli standard di configurazione del sistema includano tutte le voci descritte più avanti (da 2.2.1 a 2.2.4)

2.2.c Verificare che gli standard di configurazione vengano applicati per la configurazione di tutti i nuovi sistemi.

2.2.1 Implementare una sola funzione primaria per server (ad

2.2.1 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless,



ULTIMA DATA UTILE /

COMMENTI esempio, utilizzare server diversi per svolgere funzioni di server Web, server di database e server DNS).

verificare che per ogni server venga implementata una sola funzione primaria.

2.2.2 Disattivare tutti i servizi e i protocolli non sicuri che non sono strettamente necessari (cioè quei servizi e protocolli che non servono direttamente per eseguire la funzione specifica di un dispositivo).

2.2.2 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, ispezionare i servizi del sistema abilitati, i daemon e i protocolli. Verificare che non siano attivati servizi e protocolli non necessari o non sicuri, altrimenti ne dovrà essere giustificata e documentata la presenza (ad esempio, il protocollo FTP non è utilizzato o è cifrato tramite la tecnologia SSH o altro).

2.2.3 Configurare i parametri di protezione del sistema in modo da prevenire eventuali abusi.

2.2.3.a Fare domande agli amministratori del sistema e /o ai responsabili della sicurezza per verificare che conoscano le impostazioni dei parametri di sicurezza di base per i sistemi operativi, i server dei database, i server Web e i sistemi wireless in uso.

2.2.3.b Verificare che le impostazioni dei parametri di sicurezza di base siano incluse negli standard di configurazione del sistema.

2.2.3.c Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, verificare che i parametri di sicurezza di base siano impostati correttamente.

2.2.4 Rimuovere tutte le funzionalità superflue, quali script, driver, sottosistemi, file system e server Web non utilizzati.

2.2.4 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, verificare che siano state rimosse tutte le funzionalità superflue (ad esempio, script, driver, funzioni, sottosistemi, file system ecc.). Verificare che le funzionalità attivate siano documentate e supportino la configurazione protetta. Verificare inoltre che sui sistemi inclusi nel campione siano presenti solo funzionalità documentate.

2.3 Cifrare tutto l'accesso amministrativo che non è originato dalla console. Utilizzare tecnologie quali SSH, VPN o SSL/TLS (transport

2.3 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, verificare che l'accesso amministrativo non proveniente dalla console sia cifrato:



ULTIMA DATA UTILE /

COMMENTI layer security) per la gestione basata sul Web e altri tipi di accessi amministrativi che non sono originati dalla console.

• Osservando un amministratore mentre effettua l'accesso a ogni sistema, in modo da constatare che viene richiamato un metodo di cifratura (ad esempio, SSH) prima della richiesta di inserimento della password dell'amministratore.

• Esaminando i servizi e i file dei parametri nei sistemi, in modo da constatare che per l'uso interno non sono disponibili Telnet o altri comandi di accesso remoto.

• Verificando che l'accesso dell'amministratore all'interfaccia di gestione wireless è cifrato tramite SSL/TLS. In alternativa, controllare che gli amministratori non possano connettersi in remoto all'interfaccia di gestione wireless (tutta la gestione dell'ambiente wireless avviene solo dalla console).

2.4 I provider di hosting sono obbligati a proteggere tutti gli ambienti e i dati delle entità che ospitano Tali provider devono soddisfare gli specifici requisiti descritti nell'Appendice A: "Applicabilità dello standard PCI DSS per i provider di hosting".

2.4 Eseguire le procedure dalla A.1.1 alla A.1.4 (Appendice A, “Applicabilità dello standard PCI DSS per i provider di hosting (con procedure e test)” per i controlli di audit PCI di provider di hosting condiviso, verificando che i provider di hosting condiviso proteggano l'ambiente e i dati delle entità ospitate (esercenti e provider di servizi).


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 a conquistare 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.


ULTIMA DATA UTILE /

COMMENTI 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.1 Richiedere ed esaminare le politiche aziendali sulla conservazione e la distruzione dei dati, eseguendo le seguenti procedure:

• Verificare che le politiche e le procedure prevedano dei requisiti legali, normativi e commerciali per la conservazione dei dati, inclusi requisiti specifici per la conservazione dei dati dei titolari delle carte (ad esempio, i dati dei titolari delle carte devono essere conservati per il periodo X per le ragioni commerciali Y).

• Verificare che le politiche e le procedure prevedano regole per la distruzione dei dati quando questi non sono più necessari per motivi legali, normativi o commerciali, inclusa la distruzione dei dati dei titolari delle carte.

• Verificare che le politiche e le procedure prevedano regole per tutti i luoghi in cui i dati dei titolari delle carte vengono memorizzati, inclusi i server dei database, i sistemi mainframe, le directory per il trasferimento dei dati, le directory per la copia dei dati (utilizzate per il trasferimento dei dati tra i server) e le directory per la normalizzazione dei dati tra i trasferimenti tra server.



ULTIMA DATA UTILE /

COMMENTI • Verificare che le politiche e le procedure

prevedano un processo programmatico (automatico) per rimuovere, almeno trimestralmente, i dati dei titolari delle carte conservati oltre i termini commerciali previsti o, in alternativa, che includano i requisiti per un controllo di audit almeno trimestrale, mirato a verificare che i dati dei titolari delle carte non siano conservati oltre i termini commerciali previsti.



ULTIMA DATA UTILE /

COMMENTI 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 Se si ricevono dati sensibili per l'autenticazione, richiedere ed esaminare i processi per l'eliminazione di tali e dati e verificare che essi diventino irrecuperabili. Per ogni elemento dei dati sensibili di autenticazione, eseguire la seguente procedura:

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.1 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare quanto segue e verificare che il contenuto di ogni traccia della striscia magnetica sul retro della carta non sia conservato in nessuna circostanza:

• Dati delle transazioni in entrata • Registri delle transazioni • File storici • File Trace • Registri di debug • Vari schemi dei database • Contenuto dei database

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,

3.2.2 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare quanto segue e verificare che il codice a tre o a quattro cifre stampato sul fronte della carta o sul riquadro della firma (dati CVV2, CVC2, CID, CAV2) non venga memorizzato in nessuna circostanza:

• Dati delle transazioni in entrata



ULTIMA DATA UTILE /

COMMENTI consultare il “Glossario”. • Registri delle transazioni

• File storici • File Trace • Registri di debug • Vari schemi dei database • Contenuto dei database

3.2.3 Non conservare il PIN (personal identification number) o il blocco PIN cifrato.

3.2.3 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare quanto segue e verificare che i PIN siano cifrati e che i blocchi PIN cifrati non vengano conservati in nessuna circostanza:

• Dati delle transazioni in entrata • Registri delle transazioni • File storici • File Trace • Registri di debug • Diversi schemi dei database • Contenuto dei database

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.3 Richiedere ed esaminare le politiche scritte e controllare la visualizzazione online dei dati delle carte di credito, allo scopo di verificare che i numeri delle carte siano mascherati (salvo nei casi in cui sia effettivamente necessario visualizzarli).



ULTIMA DATA UTILE /

COMMENTI 3.4 Rendere quantomeno illeggibile il PAN in qualunque punto esso sia memorizzato (compresi i dati su supporti digitali portatili, supporti di backup, registri 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 (i pad

devono essere custoditi in un luogo sicuro)

• Crittografia forte con relativi processi e procedure di gestione delle chiavi

Il PAN è l'informazione MINIMA relativa all'account che deve essere resa illeggibile. Se per qualsiasi ragione un'azienda non fosse in grado di cifrare i dati dei titolari delle carte, consultare l'Appendice B, "Controlli compensativi."

3.4.a Richiedere ed esaminare la documentazione sul sistema utilizzato per proteggere i dati memorizzati, tra cui il fornitore, il tipo di sistema/processo e gli algoritmi di cifratura (se pertinenti). Verificare che i dati siano resi illeggibili tramite uno dei seguenti metodi:

• Hash a senso unico (indici hash) del tipo SHA-1 • Troncatura o masking • Token e PAD indicizzati, con i PAD custoditi in

luoghi sicuri • Crittografia forte, ad esempio Triplo-DES a 128

bit o AES a 256 bit, con le procedure e i processi associati per la gestione delle chiavi.

3.4.b Esaminare varie tabelle da un campione di server dei database per verificare che i dati siano resi illeggibili (cioè che non siano memorizzati sotto forma di testo normale).

3.4.c Esaminare un campione di supporti rimovibili (ad esempio, nastri di backup) per constatare che i dati siano resi illeggibili.

3.4.d Esaminare un campione di registri di audit per constatare che i dati dei titolari delle carte siano stati "depurati" o rimossi dai registri.

3.4.e Verificare che i dati dei titolari delle carte ricevuti da reti wireless siano resi illeggibili in qualunque modo siano conservati.

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

3.4.1.a Se viene utilizzata la cifratura su disco, verificare che l'accesso logico ai file system cifrati sia implementato attraverso un meccanismo distinto da quello dei sistemi operativi nativi (ad esempio, che non utilizzi account locali o account di Active Directory).

3.4.1.b Verificare che le chiavi di decifratura non siano memorizzate nel sistema locale (ad esempio, memorizzare le chiavi in un disco floppy, un CD-ROM ecc. custodito in un luogo sicuro e reperibile solo all'occorrenza).



ULTIMA DATA UTILE /

COMMENTI devono essere necessariamente legate agli account utente.

3.4.1.c Verificare che i dati dei titolari delle carte presenti sui supporti rimovibili siano cifrati in qualunque modo siano conservati (la cifratura su disco spesso non permette di cifrare i supporti rimovibili).

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 Verificare i processi per la protezione delle chiavi di cifratura utilizzate per cifrare i dati dei titolari delle carte, prevenendone la divulgazione e l'uso improprio nel seguente modo:

3.5.1 Limitare l'accesso alle chiavi al minor numero possibile di soggetti fidati.

3.5.1 Esaminare gli elenchi degli accessi degli utenti per verificare che l'accesso alle chiavi di crittografia sia effettivamente limitato a pochi soggetti.

3.5.2 Conservare le chiavi in sicurezza nel minor numero possibile di luoghi e formati.

3.5.2 Esaminare i file di configurazione del sistema per verificare che le chiavi di crittografia siano conservate in un formato cifrato e che le chiavi di cifratura delle chiavi siano custodite separatamente dalle chiavi di cifratura dei dati.

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.a Verificare l'esistenza di procedure per la gestione delle chiavi utilizzate a scopo di cifratura dei dati dei titolari delle carte.

3.6.b Solo per i provider di servizi: se il provider di servizi condivide le chiavi con i propri clienti ai fini della trasmissione dei dati dei titolari delle carte, verificare che il provider di servizi fornisca a ogni cliente la documentazione necessaria con tutte le istruzioni per conservare e cambiare in modo sicuro le chiavi di cifratura del cliente (utilizzate per la trasmissione di dati tra cliente e provider di servizi).

3.6.c Esaminare le procedure di gestione delle chiavi ed eseguire le seguenti operazioni:

3.6.1 Generazione di chiavi forti 3.6.1 Verificare che le procedure di gestione delle chiavi prevedano la generazione di chiavi forti.

3.6.2 Distribuzione protetta delle chiavi

3.6.2 Verificare che le procedure di gestione delle chiavi prevedano la distribuzione protetta delle chiavi.

3.6.3 Memorizzazione protetta delle chiavi

3.6.3 Verificare che le procedure di gestione delle chiavi prevedano la memorizzazione protetta delle chiavi.



ULTIMA DATA UTILE /

COMMENTI 3.6.4 Sostituzione periodica delle chiavi

• Sulla base delle direttive e i suggerimenti dell'applicazione associata (ad esempio, re-keying); preferibilmente in modo automatico.

• Almeno una volta all'anno.

3.6.4 Verificare che le procedure di gestione delle chiavi prevedano la sostituzione periodica delle chiavi e che questa avvenga almeno una volta all'anno.

3.6.5 Distruzione delle chiavi usate. 3.6.5 Verificare che le procedure di gestione delle chiavi prevedano la distruzione delle chiavi usate.

3.6.6 Uso della procedura di Split Knowledge e definizione del doppio controllo, di modo che per ricostruire una chiave intera servano due o tre persone, ciascuna a conoscenza di una sola parte

3.6.6 Verificare che le procedure di gestione delle chiavi siano basate su Split Knowledge e doppio controllo (per ricostruire una chiave intera serviranno 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.7 Verificare che le procedure di gestione delle chiavi prevedano misure per prevenire la sostituzione non autorizzata delle chiavi.

3.6.8 Sostituzione di chiavi che si sospetta siano state compromesse.

3.6.8 Verificare che le procedure di gestione delle chiavi prevedano la sostituzione di chiavi note o probabilmente compromesse.

3.6.9 Revoca di chiavi usate o non più valide.

3.6.9 Verificare che le procedure di gestione delle chiavi prevedano la revoca delle chiavi usate o non valide (in particolare per le chiavi RSA).

3.6.10 Obbligo per i custodi delle chiavi di firmare una dichiarazione in cui accettano e confermano di conoscere le proprie responsabilità

3.6.10 Verificare che le procedure di gestione delle chiavi prevedano che le persone preposte alla custodia delle chiavi sottoscrivano una dichiarazione in cui accettano e riconoscono 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.


ULTIMA DATA UTILE /

COMMENTI 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.a Verificare l'uso della cifratura (ad esempio, SSL/TLS o IPSEC) ogni volta che i dati dei titolari delle carte vengono trasmessi o ricevuti attraverso reti pubbliche aperte.

• Verificare che venga utilizzata la cifratura forte durante la trasmissione dei dati.

• Per le implementazioni SSL verificare che nel browser compaia HTTPS come parte integrante dell'URL (Universal Record Locator) e che non vengano richiesti i dati dei titolari delle carte quando HTTPS non compare nell'URL.

• Selezionare un campione di transazioni in corso di ricezione e osservarle per constatare che i dati dei titolari delle carte siano effettivamente cifrati durante il transito.

• Verificare che vengano accettati soltanto le chiavi e i certificati SSL/TLS.

• Verificare che sia implementata la forza opportuna per la metodologia di cifratura in uso (fare riferimento ai suggerimenti del fornitore/alle migliori pratiche).



ULTIMA DATA UTILE /

COMMENTI 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: • Utilizzare almeno una chiave di

cifratura di 104 bit e un valore di inizializzazione di 24 bit.

• Utilizzare 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.1.1.a Nel caso di reti wireless che trasmettono i dati dei titolari delle carte o che sono collegate a tali ambienti, verificare che vengano utilizzate le metodologie di cifratura opportune per tutte le trasmissioni wireless, ad esempio: Wi-Fi Protected Access (WPA o WPA2), IPSEC VPN o SSL/TLS.

4.1.1.b Se viene utilizzata la tecnologia WEP, verificare che:

• Sia utilizzata con almeno una chiave di cifratura di 104 bit e un valore di inizializzazione di 24 bit.

• Sia utilizzata SOLO contestualmente alle tecnologie WiFi Protected Access (WPA o WPA2), VPN o SSL/TLS.

• Sia eseguita una rotazione delle chiavi WEP almeno una volta ogni tre mesi (o in automatico, se la tecnologia lo consente).

• Sia eseguita una rotazione delle chiavi WEP condivise ogniqualvolta vi sia un cambio del personale con accesso alle chiavi.

• L'accesso sia limitato in base all'indirizzo MAC.

4.2 Non inviare mai PAN non cifrati tramite posta elettronica.

4.2.a Verificare che venga utilizzata una soluzione per la cifratura della posta elettronica ogniqualvolta i dati dei titolari delle carte vengono inviati tramite posta elettronica.



ULTIMA DATA UTILE /

COMMENTI 4.2.b Verificare l'esistenza di regole per cui i PAN non cifrati non possano essere inviati tramite posta elettronica.

4.2.c Parlare con 3-5 dipendenti per scoprire se è richiesto l'uso di un software di cifratura della posta elettronica per i messaggi contenenti i PAN.


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.


ULTIMA DATA UTILE /

COMMENTI 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 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, verificare che sia installato un software antivirus.

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.1.1 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, verificare che i programmi antivirus 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 i registri di audit.

5.2 Verificare che il software antivirus sia aggiornato, sia eseguito in modo attivo e generi i registri.

• Richiedere ed esaminare le regole, verificando che dettino i requisiti e le definizioni del software antivirus.

• Verificare che durante il processo di installazione principale del software siano abilitati aggiornamenti automatici e scansioni periodiche e che queste funzioni siano abilitate per il campione di componenti del sistema, di server critici e di access point di tipo wireless.

• Verificare che sia abilitata la generazione dei registri e che questi siano conservati secondo le regole stabilite dall'azienda.

6° requisito: Sviluppare e mantenere applicazioni e sistemi protetti

Soggetti poco attenti possono rappresentare delle vulnerabilità per conquistare l'accesso privilegiato ai sistemi. Gran parte di queste vulnerabilità possono essere risolte 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 sono 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 per lo sviluppo dei sistemi e tecniche di programmazione sicura.


ULTIMA DATA UTILE /

COMMENTI 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.1.a Per un campione di componenti del sistema, di server critici e di access point di tipo wireless con software correlato, mettere a confronto l'elenco delle patch di protezione installate e l'elenco delle ultime patch disponibili presso il fornitore, verificando che siano installate le versioni più recenti

6.1.b Esaminare le politiche riguardanti l'installazione delle patch di protezione, verificando che sia prevista l'installazione di tutte le patch aggiornate entro 30 giorni dalla loro pubblicazione.



ULTIMA DATA UTILE /

COMMENTI 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.2.a Fare domande al personale responsabile della sicurezza per verificare che siano attuati i processi necessari per l'identificazione delle nuove vulnerabilità.

6.2.b Verificare che i processi per l'identificazione delle nuove vulnerabilità prevedano il ricorso a informazioni esterne sulla sicurezza e l'aggiornamento degli standard di configurazione del sistema (Requisito 2) a mano a mano che emergono nuove 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 Richiedere ed esaminare i processi per lo sviluppo del software verificando che si basino sugli standard del settore e che il problema della sicurezza sia affrontato in ogni fase del ciclo di vita. Da un esame dei processi per lo sviluppo del software, dai colloqui con gli sviluppatori e dallo studio di dati significativi (documentazione sulla configurazione della rete, dati dei test e della produzione ecc.) è possibile verificare quanto segue:

6.3.1 Devono essere eseguiti test su tutte le patch di sicurezza e la configurazione del software e del sistema devono essere modificate solo prima della fase di distribuzione (deployment).

6.3.1 Tutte le modifiche, patch comprese, vengono collaudate prima di entrare a regime in produzione.



ULTIMA DATA UTILE /

COMMENTI 6.3.2 Gli ambienti dedicati allo sviluppo, al collaudo e alla produzione devono essere nettamente separati.

6.3.2 Gli ambienti di sviluppo/collaudo sono separati dall'ambiente della produzione e, per garantire tale separazione, l'accesso è sottoposto a controlli.

6.3.3 I compiti svolti negli ambienti dedicati allo sviluppo, al collaudo e alla produzione devono essere nettamente separati.

6.3.3 C'è una separazione tra le mansioni affidate al personale degli ambienti di sviluppo/collaudo e quelle affidate al personale dall'ambiente della produzione.

6.3.4 I dati della produzione (PAN attivi) non devono essere impiegati nelle fasi di collaudo e sviluppo.

6.3.4 I dati della produzione (PAN attivi) non devono essere impiegati a scopo di collaudo e sviluppo. In caso contrario, devono essere "depurati" prima dell'uso.

6.3.5 I dati e gli account impiegati per i test devono essere rimossi prima dell'attivazione dei sistemi di produzione.

6.3.5 I dati e gli account di collaudo vengono rimossi prima che un sistema di produzione diventi attivo.

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.6 Gli account, i nomi utente e/o le password delle applicazioni personalizzate vengono rimosse prima che un sistema entri a regime in produzione o venga distribuito ai clienti.

6.3.7 Il codice personalizzato deve essere analizzato prima di essere distribuito alla produzione e ai clienti, in modo da poter identificare le possibili vulnerabilità.

6.3.7.a Richiedere ed esaminare tutte le regole disponibili per iscritto o in altra forma per confermare che l'analisi del codice è obbligatoria e deve essere eseguita da soggetti diversi dall'autore del codice stesso.

6.3.7.b Verificare che tale analisi abbia luogo in presenza di nuovo codice e di modifiche apportate al codice esistente. Nota: questo requisito riguarda la fase di analisi del codice per lo sviluppo di software personalizzato che fa parte del ciclo di sviluppo software (System Development Life Cycle, SDLC). L'analisi in questione può essere affidata a personale interno. Il codice personalizzato per le applicazioni visibili sul Web sarà sottoposto a ulteriori controlli a partire dal 30/06/2008 (per maggiori dettagli, si rimanda al Requisito PCI DSS 6.6).



ULTIMA DATA UTILE /

COMMENTI 6.4 Seguire le procedure di controllo previste per la modifica della configurazione del software e del sistema. Tali procedure devono comprendere:

6.4.a Richiedere ed esaminare le procedure aziendali di controllo delle modifiche per quanto concerne l'implementazione delle patch di protezione e degli aggiornamenti software, verificando che le procedure prevedano l'applicazione dei requisiti descritti di seguito (da 6.4.1 a 6.4.4).

6.4.b Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare le ultime tre modifiche/patch di protezione per ciascun componente, cercando di trovare traccia di tali modifiche nella corrispondente documentazione di controllo. Per ogni modifica esaminata, verificare che la documentazione riporti le seguenti informazioni in base alle procedure di controllo in essere:

6.4.1 La documentazione dell'impatto.

6.4.1 Verificare che, per ciascuna modifica esaminata, nella documentazione di controllo sia documentato anche l'impatto sui clienti.

6.4.2 L'approvazione formale del management delle parti interessate.

6.4.2 Verificare che, per ciascuna modifica esaminata, sia presente l'approvazione del management delle parti interessate.

6.4.3 Il collaudo delle funzionalità operative.

6.4.3 Verificare che, per ciascuna modifica esaminata, sia stato eseguito un collaudo della funzionalità operativa.

6.4.4 Le procedure di back-out (che consentono di tornare indietro).

6.4.4 Verificare che, per ciascuna modifica esaminata, siano previste le procedure di back-out.

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.a Richiedere ed esaminare i processi di sviluppo software per tutte le applicazioni Web. Verificare che gli sviluppatori abbiano ricevuto un training sulle tecniche di programmazione sicura e che i processi si basino sulle linee guida OWASP (http://www.owasp.org).

6.5.b Per ogni applicazione Web, verificare che siano stati adottati processi per confermare che le applicazioni Web non siano vulnerabili ai seguenti problemi:

6.5.1 Input non validato 6.5.1 Input non validato



ULTIMA DATA UTILE /

COMMENTI 6.5.2 Violazione del controllo dell'accesso (ad esempio, uso improprio degli ID degli utenti)

6.5.2 Abuso 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.3 Abuso delle credenziali degli account e dei cookie delle sessioni

6.5.4 Attacchi XSS (cross-site scripting)

6.5.4 Attacchi XSS (Cross-Site Scripting).

6.5.5 Buffer overflow 6.5.5 Buffer overflow dovuti a input non validati e ad altre cause

6.5.6 Injection flaw, ad esempio iniezione SQL (structured query language)

6.5.6 Iniezione SQL e altri injection flaw di comando

6.5.7 Cattiva gestione degli errori 6.5.7 Cattiva gestione degli errori

6.5.8 Memorizzazione non protetta 6.5.8 Memorizzazione non protetta

6.5.9 DoS (Denial of Service) 6.5.9 DoS (Denial of Service)

6.5.10 Gestione non protetta della configurazione

6.5.10 Gestione non protetta 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 per il Web.

Nota: questo metodo è da considerarsi migliore pratica fino al 30 giugno 2008,

6.6 Per le applicazioni Web, assicurarsi che sia stato adottato uno dei seguenti metodi:

• Verificare che il codice dell'applicazione personalizzata sia riesaminato periodicamente da un'organizzazione specializzata in sicurezza delle applicazioni; che tutte le vulnerabilità de codice siano state corrette; e che l'applicazione sia stata sottoposta a una nuova valutazione dopo le correzioni.

• Verificare che sia presente un firewall al livello dell'applicazione, davanti alle applicazioni per il Web, a scopo di protezione dagli attacchi provenienti dal Web.



ULTIMA DATA UTILE /

COMMENTI dopodiché da tale data diventerà un requisito.


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

Questo requisito garantisce che l'accesso ai dati critici sia riservato al personale autorizzato.


ULTIMA DATA UTILE /

COMMENTI 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.1 Richiedere ed esaminare le regole disponibili per iscritto per il controllo dei dati, verificando che contengano i seguenti punti:

• Conferimento dei diritti di accesso agli ID utente privilegiati limitando i privilegi al numero minimo indispensabile per lo svolgimento delle mansioni previste.

• Assegnazione dei privilegi in base alla funzione e alla mansione svolta dal singolo dipendente.

• Obbligo di presentazione di un modulo di autorizzazione firmato dal management in cui sono specificati i privilegi richiesti.

• Implementazione di un sistema automatico per il controllo degli accessi.

7.2 Per i sistemi con utenti multipli, 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.

7.2 Esaminare le impostazioni del sistema e la documentazione del fornitore per verificare che sia stato adottato un sistema di controllo degli accessi con le seguenti caratteristiche:

• Copertura di tutti i componenti del sistema • Assegnazione dei privilegi ai dipendenti sulla base della

funzione e mansione svolta • Impostazione predefinita “deny-all” (alcuni sistemi di

controllo degli accessi sono configurati su “allow-all” per impostazione predefinita, pertanto consentono l'accesso generalizzato a meno che o finché non viene scritta una regola per negare l'accesso in modo esplicito).


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.


ULTIMA DATA UTILE /

COMMENTI 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.1 Per un campione degli ID utente, esaminare gli elenchi degli ID e verificare che tutti gli utenti abbiano un nome utente univoco per 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.2 Verificare che gli utenti, per accedere all'ambiente dati dei titolari delle carte, siano autenticati mediante un ID univoco e altre forme di autenticazione (ad esempio una password) procedendo come segue:

• Richiedere ed esaminare la documentazione in cui sono descritti i metodi di autenticazione adottati.

• Per ognuno dei metodi di autenticazione adottati e dei componenti del sistema, osservare un'autenticazione in corso verificando che funzioni esattamente come descritto nella documentazione corrispondente.

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.3 Per verificare che sia implementata l'autenticazione a due fattori per l'accesso remoto alla rete, osservare un dipendente (ad esempio, un amministratore) mentre si connette alla rete in remoto, constatando che sia effettivamente richiesta l'immissione sia della password, sia del secondo fattore di autenticazione (Smart card, PIN token).

8.4 Cifrare tutte le password durante la trasmissione e la memorizzazione nei componenti

8.4.a Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare i file delle password per verificare se queste sono illeggibili.



ULTIMA DATA UTILE /

COMMENTI del sistema. 8.4.b Solo per i provider di servizi, osservare i file delle

password per verificare che le password dei clienti siano cifrate.



ULTIMA DATA UTILE /

COMMENTI 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 Esaminare le procedure e fare domande al personale per verificare che vengano effettivamente implementate le procedure per l'autenticazione degli utenti e la gestione delle password. Procedere nel seguente modo:

8.5.1 Controllare l'aggiunta, l'eliminazione e la modifica di ID utenti, credenziali e altri oggetti identificativi.

8.5.1.a Selezionare un campione di ID utente che includa sia amministratori che utenti generici. Verificare che ciascun utente sia autorizzato ad utilizzare il sistema secondo le politiche aziendali. Procedere come segue:

• Richiedere ed esaminare un modulo di autorizzazione per ciascun ID.

• Verificare che gli ID utente inclusi nel campione siano implementati in conformità al modulo di autorizzazione (con gli stessi privilegi specificati e con tutte le firme richieste) confrontando le informazioni contenute nel modulo di autorizzazione con il sistema.

8.5.1.b Verificare che soltanto gli amministratori abbiano accesso alle console gestionali per le reti wireless.

8.5.2 Verificare l'identità dell'utente prima di reimpostare le password.

8.5.2 Esaminare le procedure relative alle password e verificare che il personale addetto alla sicurezza richieda sempre una prova dell'identità di un utente prima di accogliere la sua richiesta di reimpostazione della password (ad esempio, quando l'utente fa questa richiesta al telefono, tramite posta elettronica, Internet o con altri metodi che non prevedono la sua presenza fisica).

8.5.3 Impostare le password per il primo accesso su un valore diverso per ciascun utente e richiedere la sostituzione di tali password subito dopo il primo accesso.

8.5.3 Esaminare le procedure relative alle password e verificare che il personale addetto alla sicurezza imposti sempre un valore univoco per la password utilizzata per il primo accesso di un nuovo utente e che tale password venga sostituita subito dopo il primo accesso.

8.5.4 Revocare 8.5.4 Selezionare un campione di dipendenti che hanno



ULTIMA DATA UTILE /

COMMENTI immediatamente l'accesso a tutti gli utenti non più attivi.

lasciato l'azienda negli ultimi sei mesi ed esaminare gli elenchi relativi agli accessi degli utenti per verificare che gli ID di tali dipendenti siano stati disattivati o rimossi.

8.5.5 Rimuovere gli account degli utenti inattivi almeno ogni 90 giorni.

8.5.5 Per un campione degli ID utente, verificare che non vi siano account inattivi da più di 90 giorni.

8.5.6 Abilitare la gestione remota degli account dei fornitori soltanto per il periodo di tempo strettamente necessario.

8.5.6 Verificare che tutti gli account utilizzati dai fornitori a scopo di assistenza e manutenzione dei componenti del sistema siano disabilitati, che vengano abilitati soltanto su richiesta del fornitore e che vengano monitorati durante l'uso.

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.7 Fare domande a un campione di titolari degli ID utente per verificare che conoscano le procedure e le regole per l'uso delle password.

8.5.8 Non utilizzare account e password di gruppo, condivisi o generici.

8.5.8.a Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, esaminare gli elenchi degli ID utente per verificare quanto segue: • Gli ID utente e gli account generici sono disabilitati o sono

stati rimossi. • Non esistono ID utente condivisi per le attività di

amministrazione del sistema e altre funzioni critiche. • Non vengono utilizzati ID utente generici o condivisi per la

gestione dei dispositivi e delle reti LAN di tipo wireless.

8.5.8.b Esaminare le regole e le procedure riguardanti le password per verificare che le password di gruppo e condivise siano esplicitamente vietate.

8.5.8.c Fare domande agli amministratori del sistema per verificare che non vengano distribuite password di gruppo e condivise, neppure se richieste.

8.5.9 Cambiare le password degli utenti almeno ogni 90 giorni.

8.5.9 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password degli utenti sia previsto che le password vengano cambiate almeno ogni 90 giorni.



ULTIMA DATA UTILE /

COMMENTI Solo per i provider di servizi, esaminare i processi interni e la documentazione destinata a clienti/utenti e verificare che venga richiesto ai clienti di cambiare le password con periodicità, con istruzioni chiare sui tempi e sulle circostanze in cui è necessario cambiare le password.

8.5.10 Impostare una lunghezza minima di sette caratteri per la password.

8.5.10 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password sia prevista una lunghezza minima di sette caratteri per le password. Solo per i provider di servizi, esaminare i processi interni e la documentazione destinata a clienti/utenti e verificare che venga richiesto ai clienti di rispettare la lunghezza minima delle password.

8.5.11 Utilizzare password contenenti sia caratteri numerici, sia caratteri alfabetici.

8.5.11 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password sia previsto l'uso di una combinazione di caratteri numerici e alfabetici nelle password. Solo per i provider di servizi, esaminare i processi interni e la documentazione destinata a clienti/utenti e verificare che venga richiesto ai clienti di utilizzare password contenenti sia caratteri numerici che 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.12 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password sia vietato l'uso di una nuova password identica a una delle ultime quattro utilizzate dallo stesso utente. Solo per i provider di servizi, esaminare i processi interni e la documentazione destinata a clienti/utenti e verificare che venga richiesto ai clienti di scegliere una nuova password diversa dalle ultime quattro utilizzate.

8.5.13 Limitare tentativi di accesso ripetuti bloccando l'ID utente dopo non più di sei tentativi.

8.5.13 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password sia previsto il blocco dell'account dell'utente dopo non più di sei tentativi di accesso



ULTIMA DATA UTILE /

COMMENTI non validi.Solo per i provider di servizi, esaminare i processi interni e la documentazione destinata a clienti/utenti e verificare che gli account degli utenti vengano temporaneamente bloccati dopo non più di sei tentativi di accesso non validi.

8.5.14 Impostare un blocco della durata di trenta minuti o finché l'amministratore non riattiva l'ID utente.

8.5.14 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che nei parametri relativi alle password sia previsto che, dopo un blocco dell'account dell'utente, questo non venga riattivato prima di trenta minuti o su intervento dell'amministratore del sistema.

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.15 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare le impostazioni di configurazione del sistema per verificare che il tempo di inattività consentito per il sistema o la sessione non superi 15 minuti.

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.

8.5.16.a Per un campione di database, esaminare le impostazioni di configurazione del sistema e verificare che l'accesso venga autenticato (per i singoli utenti, le singole applicazioni e i singoli amministratori).

8.5.16.b Esaminare le impostazioni di configurazione del database e gli account del database per verificare che le interrogazioni (query SQL) ai database non siano consentite (gli account con accesso al database dovrebbero essere pochissimi e le query SQL dirette dovrebbero essere riservate agli amministratori del database).

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.



ULTIMA DATA UTILE / COMMENTI

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 Verificare che esistano fisicamente i controlli della sicurezza per l'accesso ad ogni stanza dei computer, centro dati o altro luogo in cui sono custoditi i sistemi contenenti i dati dei titolari delle carte.

• Verificare che l'accesso sia sottoposto a controlli mediante lettori di tessere magnetiche e altri dispositivi (anche chiavi e lucchetti).

• Osservare un amministratore del sistema mentre esegue la connessione a tre sistemi selezionati in modo casuale e appartenenti all'ambiente dati dei titolari delle carte, verificando che questi siano “bloccati” per impedire usi non autorizzati.

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.1 Verificare la presenza di videocamere di sorveglianza all'ingresso e all'uscita dei centri dati in cui sono custoditi i dati dei titolari delle carte. Le videocamere dovrebbero essere interne al centro dati oppure protette in modo da prevenire eventuali manomissioni. Verificare che qualcuno sorvegli le videocamere e che i dati raccolti siano conservati per almeno tre mesi.

9.1.2 Limitare l'accesso fisico ai connettori di rete accessibili pubblicamente.

9.1.2 Attraverso domande agli amministratori della rete e osservandoli sul lavoro, verificare che i connettori di rete siano abilitati soltanto se necessari ai dipendenti autorizzati. Ad esempio, in una sala utilizzata per ospitare i visitatori non dovrebbero essere disponibili porte di rete abilitate con DHCP. In alternativa, è necessario sorvegliare i visitatori affinché non restino mai da soli in luoghi dove sono presenti connettori di rete attivi.

9.1.3 Limitare l'accesso fisico ad access point di tipo wireless, gateway e dispositivi portatili.

9.1.3 Verificare che l'accesso fisico ad access point di tipo wireless, gateway e dispositivi portatili sia limitato.

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.

9.2.a Esaminare i processi e le procedure di assegnazione delle tessere magnetiche a dipendenti, lavoratori a contratto e visitatori, verificando che includano le seguenti misure:

• Procedure specifiche per l'assegnazione di nuove tessere magnetiche, la modifica dei requisiti di accesso e il ritiro delle tessere magnetiche scadute o appartenute a dipendenti che hanno lasciato l'azienda.




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.

• Accesso limitato alle tessere magnetiche. 9.2.b Osservare il comportamento delle persone all'interno dell'edificio per verificare che siano facilmente riconoscibili i dipendenti dai visitatori.

9.3 Assicurarsi che tutti i visitatori siano gestiti nel seguente modo:

9.3 Verificare l'esistenza di controlli per dipendenti e visitatori 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.1 Osservare il comportamento dei visitatori per verificare l'uso delle tessere magnetiche di riconoscimento. Provare ad entrare nel centro dati per verificare che una tessera magnetica per visitatori non consenta il libero accesso alle zone in cui sono fisicamente custoditi i dati dei titolari delle carte.

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.2 Esaminare le tessere magnetiche per i dipendenti e i visitatori verificando che siano effettivamente differenziate e che le tessere dei visitatori abbiano una scadenza.

9.3.3 Restituiscano il token prima di lasciare l'edificio o alla scadenza.

9.3.3 Osservare il comportamento dei visitatori che escono dall'edificio per verificare che venga loro richiesto di lasciare la tessera magnetica all'uscita 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.4.a Verificare che venga utilizzato un registro dei visitatori per prendere nota degli ingressi nell'edificio, nelle stanze dei computer e nei centri dati dove sono custoditi o dai quali vengono trasmessi i dati dei titolari delle carte.

9.4.b Verificare che il registro contenga il nome del visitatore, l'azienda di provenienza e l'identificativo del dipendente che ha




autorizzato l'accesso. Il registro deve essere conservato per almeno tre mesi.

9.5 Conservare le copie di backup dei supporti in un luogo sicuro, preferibilmente in un edificio distaccato, come un magazzino.

9.5 Verificare che le copie di backup siano custodite in un luogo sicuro. Verificare inoltre che nei depositi o nei magazzini esterni in cui sono custoditi i supporti con i backup vengano effettuati sopralluoghi frequenti e siano presenti sistemi di sicurezza e antincendio.

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.6 Verificare che le procedure per la protezione dei dati dei titolari delle carte prevedano il controllo dei supporti elettronici e cartacei nelle stanze dei computer e nei centri dati, nonché il controllo dei dischi rigidi dei PC e di ricevute, dossier, fax, CD e dischi sulle scrivanie dei dipendenti e negli spazi comuni.

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 Verificare l'esistenza di regole per controllare la distribuzione dei supporti contenenti i dati dei titolari delle carte e verificare che tali regole riguardino tutti i supporti, compresi quelli affidati a singoli individui.

9.7.1 Classificando i supporti affinché siano facilmente identificabili come "riservati".

9.7.1 Verificare che tutti i supporti siano classificati e facilmente identificabili come “riservati”.

9.7.2 Spedendo i supporti con un corriere assicurato o con un altro mezzo di consegna rintracciabile.

9.7.2 Verificare che il trasferimento di tutti i supporti all'esterno dell'edificio sia registrato, approvato preliminarmente dal management ed eseguito tramite un corriere assicurato o con un altro mezzo di consegna facilmente 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.8 Selezionare un campione recente di registri che, in giorni diversi, sono stati utilizzati per i trasferimenti dei supporti all'esterno dell'edificio. Verificare che i registri contengano informazioni dettagliate per rintracciare i supporti e tutte le autorizzazioni del management necessarie.

9.9 Esercitare controlli severi sulla conservazione e l'accessibilità dei supporti

9.9 Richiedere ed esaminare le regole per il controllo della conservazione e della manutenzione delle copie cartacee e dei supporti elettronici, verificando che siano previsti inventari




contenenti i dati dei titolari delle carte.

periodici dei supporti.

9.9.1 Inventariare con precisione tutti i supporti e assicurarsi che siano conservati in un luogo protetto.

9.9.1.a Richiedere ed esaminare i registri con gli inventari dei supporti per verificare che gli inventari vengano eseguiti con periodicità. 9.9.1.b Esaminare i processi per verificare che i supporti siano conservati in modo sicuro.

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:

9.10 Richiedere ed esaminare le regole di distruzione periodica dei supporti, verificando che tali regole riguardino tutti i supporti contenenti i dati dei titolari delle carte e constatando quanto segue:

9.10.1 Tagliare a strisce, bruciare o strappare il materiale cartaceo.

9.10.1.a Verificare che i materiali cartacei vengano tagliati a strisce, bruciati o strappati secondo le specifiche ISO 9564-1 o ISO 11568-3e.

9.10.1.b Esaminare i contenitori utilizzati per le informazioni da distruggere e verificare che siano sicuri. Controllare, ad esempio, che il contenitore dei documenti da distruggere sia dotato di un lucchetto che impedisca di accedere al contenuto.

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.

9.10.2 Verificare che i supporti elettronici siano distrutti irreparabilmente per mezzo di un programma (con livello di sicurezza militare) che cancelli i file oppure smagnetizzando o distruggendo in altri modi i supporti.

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 registri in tutti gli ambienti consente di tenere traccia delle cose che accadono e di analizzarne le cause in dettaglio. Senza i registri delle attività del sistema è particolarmente difficile risalire alla causa di una compromissione.


ULTIMA DATA UTILE /

COMMENTI 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.1 Osservando il comportamento dell'amministratore del sistema e rivolgendogli le domande opportune, verificare che siano abilitati gli Audit Trail, anche per le reti wireless eventualmente connesse.

10.2 Implementare Audit Trail automatizzati per tutti i componenti del sistema, in modo da ricostruire i seguenti eventi:

10.2 Attraverso colloqui, lo studio dei registri di audit e l'esame delle impostazioni dei registri di audit, verificare che i registri delle attività del sistema riportino le seguenti informazioni:

10.2.1 Tutti i singoli accessi ai dati dei titolari delle carte

10.2.1 Tutti i singoli accessi 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.2 Le azioni svolte da un soggetto con privilegi di utente root o amministratore

10.2.3 Accessi a tutti gli Audit Trail 10.2.3 Accessi a tutti gli Audit Trail

10.2.4 Tentativi non validi di accesso logico

10.2.4 Tentativi non validi di accesso logico

10.2 5 Uso dei meccanismi di identificazione e autenticazione

10.2.5 Uso dei meccanismi di identificazione e autenticazione

10.2.6 Inizializzazione dei registri di audit 10.2.6 Inizializzazione dei registri di audit

10.2.7 Creazione ed eliminazione degli oggetti a livello di sistema

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 Attraverso colloqui e osservazioni, per ogni evento passibile di audit (dal punto 10.2) verificare che l'audit trail raccolga le seguenti informazioni:

10.3.1 Identificazione dell'utente 10.3.1 Identificazione dell'utente

10.3.2 Tipo di evento 10.3.2 Tipo di evento

10.3.3 Data e ora 10.3.3 Timbro della data e dell'ora

10.3.4 Indicazione di successo o fallimento 10.3.4 Indicazione di successo o fallimento, anche per le connessioni wireless

10.3.5 Origine dell'evento 10.3.5 Origine dell'evento



ULTIMA DATA UTILE /

COMMENTI 10.3.6 Identità o nome dell'elemento interessato (dati, componente del sistema o risorsa)

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.4 Per un campione di componenti del sistema, di server critici e di access point di tipo wireless, richiedere ed esaminare il processo di acquisizione ed estensione dell'ora esatta in tutta l'organizzazione, nonché le impostazioni relative ai parametri di sistema. Verificare che nel processo siano previsti e implementati i seguenti criteri:

10.4.a Verificare che per la sincronizzazione dell'ora sia utilizzato il protocollo NTP o una tecnologia analoga.

10.4.b Verificare che non tutti i server interni ricevano i segnali orari da fonti esterne. [All'interno dell'organizzazione sono sufficienti due o tre server centrali dell'ora di pari livello, che ricevono i segnali orari esterni direttamente da una speciale stazione radio, dai satelliti GPS o da altre fonti esterne basate sugli standard International Atomic Time e UTC (in passato GMT) e che condividono l'ora con gli altri server interni.]

10.4.c Verificare che sia installata la versione più aggiornata del protocollo NTP (Network Time Protocol).

10.4.d Verificare che siano specificati degli host esterni specifici dai quali i server dell'ora possono accettare gli aggiornamenti dell'ora NTP (per impedire a un hacker di cambiare l'ora). Facoltativamente, è possibile cifrare questi aggiornamento con una chiave simmetrica e creare elenchi di controllo degli accessi in cui siano specificati gli indirizzi IP dei client che riceveranno il servizio NTP (per impedire l'uso non autorizzato dei server dell'ora interni). Per maggiori informazioni, visitare il sito Web www.ntp.org.

10.5 Proteggere gli audit trail da eventuali alterazioni.

10.5 Rivolgere domande all'amministratore del sistema ed esaminare i permessi per verificare che gli audit trail siano protetti da eventuali alterazioni. Procedere come



ULTIMA DATA UTILE /

COMMENTI segue:

10.5.1 Limitare la visualizzazione degli audit trail al personale con competenze specifiche.

10.5.1 Verificare che i file di audit trail possano essere visualizzati soltanto dai soggetti che ne hanno bisogno per svolgere le loro mansioni.

10.5.2 Proteggere i file di audit trail da modifiche non autorizzate.

10.5.2 Verificare che i file di audit trail in uso siano protetti da modifiche non autorizzate mediante meccanismi di controllo degli accessi, separazione fisica e/o segregazione della rete.

10.5.3 Creare copie di backup dei file di audit trail su un server dei registri centralizzato o su un supporto che è difficile alterare.

10.5.3 Verificare che le copie di backup dei file di audit trail in uso vengano eseguite subito su un server dei registri centralizzato o su un supporto difficile da alterare.

10.5.4 Copiare i registri delle reti wireless su un server dei registri o nella rete LAN interna.

10.5.4 Verificare che i registri delle reti wireless vengano scaricati o copiati su un server dei registri interno centralizzato o su un supporto difficile da alterare.

10.5.5 Utilizzare un meccanismo di monitoraggio dell'integrità dei file e un software di rilevamento delle modifiche per i registri, in modo da assicurare che vengano generati allarmi ad ogni tentativo di modifica dei dati dei registri esistenti (ma non per l'aggiunta di nuovi dati).

10.5.5 Verificare che vengano eseguito il monitoraggio dell'integrità dei file o che venga utilizzato un software di rilevamento delle modifiche per i registri. A questo scopo, esaminare le impostazioni del sistema, i file monitorati e i risultati delle attività di monitoraggio.

10.6 Esaminare almeno una volta al giorno i registri per tutti i componenti del sistema. Nell'esaminare i registri, è 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 registri, il parsing e gli strumenti per la generazione di allarmi devono essere utilizzati ai fini della conformità al Requisito 10.6.

10.6.a Richiedere ed esaminare le politiche di sicurezza per verificare che includano procedure per l'esame almeno quotidiano dei registri della sicurezza e che prevedano il follow-up delle eccezioni.

10.6.b Attraverso colloqui e osservazioni, verificare che per tutti i componenti del sistema vengano programmate revisioni regolari dei registri.



ULTIMA DATA UTILE /

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

10.7.a Richiedere ed esaminare le politiche di sicurezza per verificare che includano le procedure per la conservazione dei registri di audit e che obblighino a conservare tali registri per almeno un anno.

10.7.b Verificare che i registri di audit siano disponibili online o su nastro per almeno un anno.

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 personalizzati, in modo da garantire un livello di protezione al passo con i tempi e con i cambiamenti del software.


ULTIMA DATA UTILE /

COMMENTI 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.1.a Attraverso colloqui con il personale addetto alla sicurezza e l'esame dei codice, della documentazione e dei processi pertinenti, constatare che venga attuato il collaudo di sicurezza dei dispositivi per garantire che i controlli siano in grado di identificare e bloccare i tentativi di accesso non autorizzato nell'ambiente dati dei titolari delle carte.

11.1.b Verificare che, almeno una volta ogni tre mesi, venga utilizzato un analizzatore di reti wireless per identificare tutti i dispositivi wireless.

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.

11.2.a Esaminare i risultati delle scansioni delle vulnerabilità della rete, degli host e delle applicazioni che sono state eseguite negli ultimi quattro trimestri, verificando che si svolgano effettivamente i collaudi di sicurezza periodici sui dispositivi nell'ambiente dati dei titolari delle carte. Verificare che il processo di scansione preveda la ripetizione della scansione fino al conseguimento di risultati “puliti”.



ULTIMA DATA UTILE /

COMMENTI 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.2.b Per constatare che venga eseguita la scansione esterna su base trimestrale, secondo quanto previsto nelle procedure per la scansione di sicurezza PCI, esaminare i risultati delle scansioni delle vulnerabilità eseguite negli ultimi quattro trimestri per verificare che:

• Negli ultimi 12 mesi sono state svolte quattro scansioni trimestrali.

• I risultati di ciascuna scansione sono in linea con le procedure per la scansione di sicurezza PCI (ad esempio, nessuna vulnerabilità urgente, critica o elevata).

• Le scansioni sono state eseguite da un fornitore approvato in base alle procedure per la scansione di sicurezza PCI.

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 Richiedere ed esaminare i risultati dell'ultimo test di penetrazione per verificare che tale test venga eseguito almeno una volta all'anno e dopo ogni modifica rilevante dell'ambiente. Verificare che le vulnerabilità evidenziate siano state tutte corrette. Verificare che i test di penetrazione includano:

11.3.1 Test di penetrazione al livello di rete 11.3.1 Test di penetrazione al livello di rete

11.3.2 Test di penetrazione al livello di applicazioni.

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.4.a Osservare l'uso dei sistemi antintrusione IDS/IPS nella rete. Verificare che venga monitorato tutto il traffico della rete che abbia rilevanza per l'ambiente dati dei titolari delle carte.

11.4.b Confermare che è stato adottato un sistema IDS e/o IPS di monitoraggio che avvisa il personale in caso di sospetta compromissione.

11.4.c Esaminare le configurazioni IDS/IPS e confermare che la configurazione, la manutenzione e l'aggiornamento dei dispositivi IDS/IPS avvengono nel rispetto delle istruzioni del fornitore per garantire una protezione



ULTIMA DATA UTILE /

COMMENTI ottimale.



ULTIMA DATA UTILE /

COMMENTI 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).

11.5 Attraverso l'osservazione delle impostazioni di sistema e dei file monitorati e l'esame dei risultati delle attività di monitoraggio, verificare che vengano utilizzati prodotti di monitoraggio dell'integrità dei file nell'ambiente dati dei titolari delle carte.

Adottare una politica per la protezione delle informazioni 12° requisito: Adottare una politica per la protezione delle informazioni rivolta a dipendenti e lavoratori a contratto

Una politica per la protezione è forte se è diffusa nell'intera azienda e se indica ai dipendenti quali comportamenti tenere. Occorre sensibilizzare tutti i dipendenti sull'importanza dei dati e sulla loro responsabilità di proteggerli.


ULTIMA DATA UTILE /

COMMENTI



ULTIMA DATA UTILE /

COMMENTI 12.1 Mettere a punto, diffondere, rispettare e divulgare una politica per la sicurezza che consegua i seguenti obiettivi:

12.1 Esaminare la politica per la protezione delle informazioni e verificare che le regole siano divulgate a tutti gli utenti del sistema (compresi fornitori, lavoratori a contratto e partner commerciali).

12.1.1 Risponda a tutti i requisiti descritti.

12.1.1 Verificare che la politica risponda a tutti i requisiti elencati in questo documento.

12.1.2 Includa un processo annuale per identificare le minacce e le vulnerabilità e giungere a una valutazione dei rischi formale.

12.1.2 Verificare che la politica per la protezione delle informazioni includa un processo annuale di valutazione dei rischi capace di identificare formalmente minacce, vulnerabilità e risultati.

12.1.3 Includa una revisione almeno annuale e venga aggiornata quando l'ambiente cambia.

12.1.3 Verificare che la politica per la protezione delle informazioni sia aggiornata ogni anno e, all'occorrenza, adattata ai cambiamenti negli obiettivi commerciali o nell'ambiente di rischio.

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 la revisione dei registri).

12.2.a Esaminare le procedure operative giornaliere per la sicurezza. Verificare che siano coerenti con il presente documento e che includano procedure amministrative e tecniche per ogni singolo requisito.

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 Richiedere ed esaminare le regole riguardanti l'uso delle tecnologie a disposizione dei dipendenti, verificando i seguenti punti:

12.3.1 Approvazione esplicita del management

12.3.1 Verificare che le regole per l'uso di questi dispositivi prevedano l'approvazione esplicita del management.

12.3.2 Autenticazione per l'uso della tecnologia

12.3.2 Verificare che le regole per l'uso di questi dispositivi prevedano l'autenticazione tramite nome utente e password o con un altro mezzo di autenticazione (ad esempio, un token).

12.3.3 Un elenco di tutti i dispositivi 12.3.3 Verificare che le regole prevedano la creazione di un



ULTIMA DATA UTILE /

COMMENTI di questo tipo e dei dipendenti con accesso ad essi

elenco dei dispositivi e dei dipendenti autorizzati a utilizzarli.

12.3.4 Etichettatura dei dispositivi con proprietario, informazioni per contattarlo e scopo

12.3.4 Verificare che le regole prevedano l'etichettatura dei dispositivi che riporti proprietario, informazioni per contattarlo e scopo.

12.3.5 Usi accettabili della tecnologia

12.3.5 Verificare che le regole impongano solo usi accettabili della tecnologia.

12.3.6 Ubicazioni in rete accettabili per le tecnologie

12.3.6 Verificare che le regole impongano solo ubicazioni accettabili in rete per la tecnologia.

12.3.7 Elenco dei prodotti approvati dall'azienda

12.3.7 Verificare che le regole prevedano la creazione di un elenco dei prodotti approvati dall'azienda.

12.3.8 Disconnessione automatica delle sessioni modem dopo il periodo di inattività indicato

12.3.8 Verificare che le regole prevedano la disconnessione automatica delle sessioni modem dopo un determinato periodo di inattività.

12.3.9 Attivazione dei modem per i fornitori solo su richiesta dei fornitori e con immediata disattivazione dopo l'uso

12.3.9 Verificare che le regole prevedano l'attivazione dei modem utilizzati dai fornitori solo su richiesta dei fornitori e la loro 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 di funzioni di copia-incolla e stampa durante l'accesso remoto.

12.3.10 Verificare che le regole vietino la memorizzazione dei dati dei titolari delle carte su dischi rigidi locali, dischi floppy o altri supporti esterni durante l'accesso remoto ai dati tramite modem. Verificare che siano vietate le 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.4 Verificare che siano definite chiaramente le responsabilità dei dipendenti e dei lavoratori a contratto per quanto riguarda la 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 Verificare che la protezione delle informazioni sia affidata formalmente al capo del settore sicurezza o a un funzionario del management che abbia nozioni di sicurezza. Richiedere ed esaminare le procedure e la politica per la protezione delle



ULTIMA DATA UTILE /

COMMENTI informazioni, in modo da verificare che le seguenti responsabilità siano definite in modo chiaro e formale:

12.5.1 Mettere a punto, documentare e distribuire le regole e le procedure per la sicurezza.

12.5.1 Verificare che sia assegnata formalmente la responsabilità di creazione e distribuzione delle procedure e delle regole per la sicurezza.

12.5.2 Monitorare e analizzare gli avvisi e le informazioni sulla sicurezza e distribuirli al personale interessato.

12.5.2 Verificare che sia assegnata formalmente la responsabilità di monitoraggio e analisi degli avvisi sulla sicurezza per la condivisione di queste informazioni con il personale competente nel settore della sicurezza e nel management.

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.3 Verificare che sia assegnata formalmente la responsabilità di creazione e distribuzione delle procedure di risposta e di escalation in caso di incidenti.

12.5.4 Amministrare gli account degli utenti, comprese aggiunte, eliminazioni e modifiche.

12.5.4 Verificare che sia assegnata formalmente la responsabilità di amministrazione degli account utente e di gestione delle autenticazioni.

12.5.5 Sorvegliare e controllare tutti gli accessi ai dati.

12.5.5 Verificare che sia assegnata formalmente la responsabilità di sorveglianza e controllo degli 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.a Verificare che esista un programma di sensibilizzazione per i dipendenti sul problema della sicurezza.

12.6.b Richiedere ed esaminare le procedure e la documentazione del programma di sensibilizzazione, procedendo nel seguente modo:

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.1.a Verificare che il programma di sensibilizzazione offra vari metodi per comunicare con i dipendenti ed educarli (ad esempio poster, lettere, riunioni).

12.6.1.b Verificare che i dipendenti partecipino a corsi di formazione sulla sicurezza non appena vengono assunti e, in seguito, almeno una volta all'anno.

12.6.2 Richiedere ai dipendenti di firmare un documento che attesti che hanno letto e compreso le

12.6.2 Verificare che il programma di sensibilizzazione preveda che i dipendenti sottoscrivano un documento per presa visione e comprensione delle procedure aziendali per la protezione delle



ULTIMA DATA UTILE /

COMMENTI regole e le procedure aziendali per la sicurezza.

informazioni.

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.7 Parlare con il management delle Risorse Umane per verificare se vengono condotte verifiche preliminari (nei limiti consentiti dalla legge) sui potenziali dipendenti che avranno accesso ai dati dei titolari delle carte o al relativo ambiente. È possibile, ad esempio, svolgere verifiche preliminari presso l'ex datore di lavoro, controllare la fedina penale e la situazione finanziaria e richiedere referenze.

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 Se l'entità sottoposta al controllo di audit condivide i dati dei titolari delle carte con un'altra azienda, richiedere ed esaminare i contratti tra l'organizzazione e i soggetti terzi che gestiscono i dati (ad esempio, un deposito in cui vengono conservati i nastri di backup, un provider MSP (Managed Service Provider) come le aziende di hosting Web o i provider di servizi per la sicurezza, oppure i soggetti che ricevono i dati a scopo di "fraud modeling", cioè per analizzare modelli di possibili truffe). Eseguire le seguenti operazioni:

12.8.1 Adesione dei provider di servizi ai requisiti PCI DSS.

12.8.1 Verificare che il contratto contenga disposizioni circa l'adesione 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.8.2 Verificare che il contratto contenga disposizioni circa il riconoscimento da parte del soggetto terzo delle proprie responsabilità in materia di protezione 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 Richiedere ed esaminare il piano di risposta agli incidenti e le procedure correlate eseguendo le seguenti operazioni:

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

12.9.1 Verificare che il piano di risposta agli incidenti e le procedure correlate prevedano i seguenti punti:

• ruoli, responsabilità e strategie di comunicazione in caso di compromissione;

• copertura e risposte per tutti i componenti critici del sistema;



ULTIMA DATA UTILE /

COMMENTI 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).

• notifica, come minimo, alle associazioni delle carte di credito e agli acquirenti;

• strategia per la continuità dell'attività commerciale dopo una compromissione;

• riferimenti e rimandi alle procedure di risposta agli incidenti adottate dalle associazioni delle carte di credito;

• analisi dei requisiti legali per comunicare eventuali compromissioni (ad esempio, il disegno di legge 1386 della California detta l'obbligo di notificare i consumatori interessati in caso di avvenuta o sospetta compromissione; l'obbligo è esteso a tutte le imprese i cui database contengano i dati di cittadini residenti in California).

12.9.2 Collaudare il piano almeno una volta all'anno.

12.9.2 Verificare che il piano venga collaudato 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.3 Attraverso l'osservazione e lo studio delle procedure, verificare che il monitoraggio e la capacità di risposta siano esercitati 24 ore su 24, 7 giorni su 7, in caso di sospetta attività non autorizzata, di avvisi IDS critici e/o di segnalazioni di modifiche non autorizzate a un sistema critico o a un file con contenuti sensibili.

12.9.4 Addestrare il personale per reagire adeguatamente alle situazioni di violazione della sicurezza.

12.9.4 Attraverso l'osservazione e lo studio delle procedure, verificare che il personale che ha la responsabilità di vigilare sulle violazioni della sicurezza partecipi regolarmente a corsi di formazione.

12.9.5 Includere allarmi dai sistemi antintrusione e dai sistemi di monitoraggio dell'integrità dei file.

12.9.5 Attraverso l'osservazione e lo studio delle procedure, verificare che il piano di risposta agli incidenti preveda processi di monitoraggio e risposta agli avvisi.

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.9.6 Attraverso l'osservazione e lo studio delle procedure, verificare che esista un processo per la modifica e la correzione del piano di risposta agli incidenti sulla base 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

12.10 Attraverso l'osservazione, lo studio delle procedure e l'esame della documentazione pertinente, verificare che esista un processo per la gestione delle entità connesse eseguendo le



ULTIMA DATA UTILE /

COMMENTI entità connesse, comprese le seguenti attività:

seguenti operazioni:

12.10.1 Conservare e aggiornare un elenco delle entità connesse.

12.10.1 Verificare che venga mantenuto e aggiornato un elenco delle entità connesse.

12.10.2 Assicurare che tutte le procedure siano rispettate prima di connettere un'entità.

12.10.2 Verificare che esistano procedure mirate ad assicurare il rispetto delle regole prima di connettere un'entità.

12.10.3 Assicurarsi che l'entità rispetti lo standard PCI DSS.

12.10.3 Verificare che esistano procedure mirate ad assicurare la conformità dell'entità allo standard PCI DSS.

12.10.4 Connettere e disconnettere le entità seguendo un processo consolidato.

12.10.4 Verificare che esista un processo consolidato per la connessione e la disconnessione delle entità.


Appendice A: Applicabilità dello standard PCI DSS per i provider di hosting (con procedure e test) 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 riservare un trattamento speciale ai seguenti punti:

Requisiti Test eseguiti Rispettati Non rispettati Ultima data

utile / Commenti

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: 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à dell'entità 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.

A.1 Per quanto riguarda in modo specifico il controllo di audit PCI di un provider di hosting condiviso, occorre verificare che i provider di hosting condiviso proteggano l'ambiente e i dati delle entità (esercenti e provider di servizi) ospitate. A questo scopo, selezionare un campione di server (Microsoft Windows e Unix/Linux) su un campione rappresentativo di esercenti e provider di servizi in hosting, verificando i 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.1 Se un provider di hosting condiviso consente alle entità (esercenti e provider di servizi) di eseguire le loro applicazioni, verificare che i processi di tali applicazioni vengano svolti utilizzando l'ID univoco assegnato all'entità. Ad esempio:

• Nessuna entità nel sistema può utilizzare un ID utente di un server Web condiviso.

• Tutti gli script CGI utilizzati da un'entità devono



utile / Commenti

essere creati ed eseguiti con l'ID utente univoco dell'entità in questione.

A.1.2 Limitare l'accesso e i privilegi di ciascuna entità all'ambiente dati d i tit l i d ll t di t

A.1.2.a Verificare che l'ID di tutti i processi dell'applicazione non sia di un utente privilegiato (root/amministratore).



utile / Commenti

A.1.2.b Verificare che ogni entità (esercente, provider di servizi) disponga dei permessi di lettura, scrittura ed esecuzione soltanto per i file e le directory che possiede o per i file system necessari (limitazioni imposte tramite permessi sui file system, elenchi di controllo degli accessi, funzioni chroot o jailshell ecc.). IMPORTANTE: i file di un'entità non devono essere condivisi per gruppi.

A.1.2.c Verificare che gli utenti di un'entità non abbiano accesso ai file binari riservati all'amministrazione del sistema.

A.1.2.d Verificare che la visualizzazione delle voci del registro sia consentita solo all'entità proprietaria.

A.1.2.e Per impedire che ciascuna entità monopolizzi le risorse del server per sfruttarne le vulnerabilità (condizioni di errore, "race" e riavvio che generano, ad esempio, il buffer overflow), verificare che siano applicate delle limitazioni all'uso delle risorse del sistema: • Spazio sul disco • Larghezza di banda • Memoria • CPU

A.1.3 Assicurarsi che le funzioni di audit trail e di generazione dei registri 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.3.a Per ogni ambiente di esercenti e provider di servizi, verificare che il provider di hosting condiviso abbia attivato la creazione di registri nelle seguenti modalità: • I registri sono abilitati per le applicazioni di terze parti

più comuni. • I registri sono attivati per impostazione predefinita. • I registri sono a disposizione dell'entità proprietaria che

desideri consultarli. • Le ubicazioni dei registri sono comunicate in modo

chiaro all'entità proprietaria.

A.1.4 Abilitare processi idonei a consentire un'indagine legale puntuale in caso di compromissione di un esercente o un provider di

A.1.4 Verificare che il provider di hosting condiviso abbia messo per iscritto regole che consentano un'indagine legale rapida e puntuale in caso di compromissione.



utile / Commenti

servizi ospitato.

Security Audit Procedures v 1.1 62

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.

Security Audit Procedures v 1.1 63

• 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).

Appendice C: Foglio di lavoro sui controlli compensativi / esempio precompilato

Esempio

1. Limitazioni: Elencare le limitazioni che precludono la conformità al requisito di origine

2. Obiettivo: Definire l'obiettivo del controllo di origine; identificare l'obiettivo conseguito con il controllo compensativo

3. Rischio identificato: Identificare gli ulteriori rischi introdotti dall'assenza del controllo di origine

4. Definizione dei controlli compensativi: Definire i controlli compensativi e spiegare in che modo consentono di raggiungere gli obiettivi del controllo di origine e l'eventuale rischio.

Company XYZ is going to require all users to log into the servers from their desktop using the SU command. SU allows a user to access the ‘root’ account and perform actions under the ‘root’ account but is able to be logged in the su-log directory. In this way, each user’s actions can be tracked through the SU account.

The objective of requiring unique logins is twofold. First, it is not considered acceptable from a security perspective to share login credentials. Secondly, shared logins makes it impossible to state definitively that a person is responsible for a particular action.

Additional risk is introduced to the access control system by not ensuring all users have a unique ID and are able to be tracked.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a ‘root’ login. It is not possible for Company XYZ to manage the ‘root’ login nor is it feasible to log all ‘root’ activity by each user.

new payment card industry (pci) data security standard · 2018. 12. 19. · payment card industry...

Documents