La nuova versione degli standard porta con sé diverse novità e requisiti più stringenti in vari ambiti, come il penetration testing, la segmentazione e lo sviluppo sicuro, con una maggiore attenzione alle carenze di formazione e consapevolezza del personale, alle capacità di rilevare manomissioni e malware, alle misure di autenticazione, alle garanzie di sicurezza delle terze parti, nonché alla consistenza degli assessment e all’evoluzione di rischi e minacce.

La nuova versione 3.0 degli standard globali di sicurezza PCI DSS (Payment Card Industry Data Security Standard) e PA DSS (Payment Application Data Security Standard) è stata ufficialmente rilasciata in bozza dal PCI Security Standards Council (PCI SSC) a tutte le società QSA (Qualified Security Assessor) e alle altre organizzazioni partner la scorsa settimana. Stando a quanto dichiarato dal PCI Council nel documento di “Change Highlights”, la nuova versione è maggiormente focalizzata su alcuni dei più importanti fattori di rischio nel panorama delle minacce, offre maggiore chiarezza sui requisiti e una migliore comprensione sul loro intento e sulle modalità di attuazione, migliora la flessibilità di implementazione e verifica degli standard, consente una migliore gestione dei rischi e delle minacce in costante e rapida evoluzione, è maggiormente allineata con i cambiamenti nelle best practice di settore ed elimina i requisiti ridondanti, consolidando la documentazione.

In attesa del rilascio definitivo dei nuovi standard, ecco le principali novità riscontrate nelle ultime versioni draft che, a quanto si dice, hanno buone probabilità di diventare documenti finali.

Perimetro del PCI DSS

Finalmente viene chiarito che tutti i sistemi che forniscono servizi di sicurezza, facilitano la segmentazione della rete e possono impattare la sicurezza dei dati dei possessori di carte di pagamento, appartengono senza dubbi al perimetro PCI DSS. Di conseguenza, asset come i server di autenticazione Active Directory o i sistemi di protezione antivirus e antimalware diventano elementi da prendere in considerazione nelle valutazioni di conformità. In aggiunta, nella sezione 2, viene introdotto il requisito di mantenere un inventario dettagliato e costantemente aggiornato di tutti i componenti di sistema ricompresi nel perimetro di riferimento.

Diagrammi di rete

La sezione 1, dedicata alla protezione firewall, conferisce maggiore enfasi al requisito di creare e mantenere aggiornati diagrammi di rete che illustrino, con la dovuta chiarezza, il flusso dei dati dei possessori di carte di pagamento all’interno dell’infrastruttura tecnologica e di telecomunicazione.

Crittografia e Key Management

Molti chiarimenti sono stati introdotti nella sezione 3 dello standard per assicurare un’adeguata protezione a tutti gli elementi crittografici, abbracciando le più diffuse best practice di settore. Ad esempio, una maggiore enfasi è stata posta sulle procedure di collaudo con l’obiettivo di imporre specifiche misure come l’archiviazione sicura delle chiavi crittografiche (es. HSM), la separazione delle KEK (Key Encrypting Keys) e delle DEK (Data Encryption Keys), nonché l’imposizione di criteri di split knowledge e dual control per la protezione delle chiavi crittografiche. Una precisazione riguarda l’inutilità di proteggere le chiavi pubbliche, per ovvi motivi. Le password degli account applicativi o di servizio, infine, verranno considerate analogamente alle password degli account utente, pertanto saranno soggette ai medesimi criteri di gestione e di sicurezza di queste ultime.

Antimalware e antivirus

La nuova versione dello standard prevede che la sezione 5 si arricchisca di una migliore e più aggiornata definizione di “sistema”, includendo maggiore enfasi sulle strategie antimalware per sistemi non-Microsoft come Linux e Unix, storicamente (ed erroneamente) considerati a prova di virus e malware.

Sviluppo sicuro

Anche la sezione 6 dello standard riceve molti chiarimenti, ad esempio sul fatto che gli sviluppatori debbano essere adeguatamente formati ed addestrati sulle più recenti tecniche di secure coding e che criteri e metodologie di sviluppo sicuro si applichino anche alle applicazioni sviluppate da terze parti, oltre a requisiti più stringenti sull’uso dei Web Application Firewall (WAF). Un nuovo requisito riguarda la protezione specifica dagli attacchi a PAN e SAD quando gestiti in maniera non sicura in memoria, un requisito considerato al momento solo come best practice ma che diverrà obbligatorio dal 30 giugno 2015. Più in generale, la sezione 6 sarà oggetto di una revisione complessiva per renderla più attuale rispetto ai contenuti della top ten OWASP 2008 sulla quale si basa l’attuale versione 2.0 dello standard e per integrarla con un ventaglio maggiore di requisiti e best practice, non più adottando il solo OWASP come riferimento, ma anche altre fonti (es. NIST, SANS Institute, ecc.).

Controllo accessi in base ai ruoli e user management

In merito all’accesso ai sistemi viene chiarito che ciascun ruolo deve essere esplicitamente definito con tutti i livelli di privilegio da esso richiesti per l’operatività. Maggiore enfasi è stata posta sugli user ID gestiti da fornitori e terze parti che accedono ad ambienti del cliente: questi particolari account devono essere obbligatoriamente disabilitati quando non utilizzati. Inoltre, è richiesto che venga fornita agli utenti una migliore guida in merito alle modalità più opportune di selezione delle credenziali di strong authentication, non solo riguardo alle password ma, ad esempio, anche per token, smart card e certificati. Infine, la nuova versione dello standard dovrebbe tenere conto dell’evoluzione tecnologica del mercato, ad esempio dell’affermazione di sistemi biometrici e nuovi meccanismi di autenticazione senza uso di password.

Sicurezza fisica

La sezione 9, riguardante la limitazione dell’accesso fisico ai dati dei possessori di carte, adesso include anche la protezione dei dispositivi POS, nonché i requisiti di mantenere una lista aggiornata di tali dispositivi e di addestrare il personale al riconoscimento di eventuali tentativi di manomissione o sostituzione fraudolenta. Soluzioni in tal senso potranno essere l’adozione di dispositivi POS con approvazione PTS/UKPA oppure misure di vincolo fisico dei dispositivi al piano di lavoro (ove possibile).

Monitoraggio

Nella sezione 10 vengono chiariti intenti e obiettivi della revisione giornaliera dei log di monitoraggio per identificare attività sospette, offrendo anche una certa flessibilità nella revisione degli eventi meno critici in accordo con le strategie di risk management. Viene chiarito, poi, che il requisito di autenticazione a due fattori si applica agli accessi di rete originati dall’esterno della rete del cliente.

Penetration testing

La sezione 11, relativa ai test su sistemi e processi di protezione, adesso richiede la definizione e l’adozione di un’adeguata metodologia di penetration testing, e prevede il requisito obbligatorio di garantire che i test di penetrazione rispettino le più accettate best practice di settore per assicurare che i relativi risultati siano effettivamente funzionali ad una corretta valutazione dei livelli di sicurezza del perimetro esaminato. Il processo di penetration testing è vincolato ai requisiti di asset management richieste nella sezione 2 e alla disponibilità dei diagrammi di rete richiesti nella sezione 1. Questo contribuirà probabilmente ad aumentare il livello di regolamentazione sui servizi forniti dalle aziende di assessment e penetration testing, dando così maggiori garanzie sull’aderenza dei risultati alla reale situazione, comprendendo aspetti di sicurezza fisica, del personale, di rete e applicativa. Nuovi requisiti riguarderanno la verifica obbligatoria dei controlli usati per la segmentazione, quando questa è attuata.

Outsourcing e ricorso a servizi di terze parti

La sezione 12 è stata resa più comprensibile, evidenziando che un service provider deve produrre sufficienti evidenze che attestino la realizzazione di un apposito assessment PCI DSS in merito ai servizi applicabili ad uno specifico cliente, nonché precise garanzie sul mantenimento della conformità ai requisiti di propria competenza. Sono stati introdotti anche altri requisiti per assicurare che le responsabilità sulle varie aree di competenza PCI DSS vengano chiaramente definite fra clienti e fornitori di servizi.

Ulteriori informazioni possono essere consultate in anteprima nel documento ufficiale “Payment Card Industry (PCI) Data Security Standard and Payment Application Data Security Standard – Version 3.0 Change Highlights – August 2013”.

Ettore Guarnaccia