top space  top space  top space  top space  top space       Visualizza il sito in italiano Visualizza il sito in inglese

PCI DSS: segmentazione della rete e componenti ''non virali''


Lo standard PCI DSS, sia nella versione 2.0 che nella 3.0 di recente pubblicazione, indica chiaramente come esso “si applichi a tutti i system components inclusi o connessi al cardholder data environment”.

 

Per comprenderne le reali implicazioni è necessario innanzitutto esplodere le definizioni presenti nella frase, iniziando con

  • Cardholder data environment (CDE): ambiente che comprende “persone, processi e tecnologie che registrano, elaborano o trasmettono dati di carta o dati sensibili di autenticazione”;
  • System components: insieme che include “dispositivi di rete, server, elaboratori e applicazioni”;
  • Cardholder data (CHD): informazioni che contengono il PAN, il nome del titolare, la data di scadenza e/o il service code;
  • Sensitive authentication data: traccia magnetica o suo equivalente conservato sul chip, codice di verifica, PIN o blocchi PIN.

 

La conseguenza è, nella maggior parte dei casi, l’inclusione potenziale dell’intero perimetro delle aziende coinvolte nel trattamento di dati di carta di pagamento: per questo nello standard PCI DSS (implicitamente nella versione 2.0, esplicitamente nella versione 3.0) si prevede la possibilità di segmentare le reti al fine di restringere il perimetro PCI - e conseguentemente di ridurre gli adempimenti ad esso legati per il raggiungimento della conformità allo standard.

 

La segmentazione della rete

Cosa significa però, in termini pratici, attuare la “segmentazione di rete”?

Significa inserire all’interno di una o più reti tutti i componenti del Cardholder data environment e restringere l’accesso a tali reti tramite tecnologie quali firewall, router layer 3 con access list o similari. Tramite questi accorgimenti è possibile considerare le reti non PCI dell’azienda (e ciò che contengono) come “reti untrusted” e pertanto esterne all’ambito di applicazione della PCI DSS.

Tutti i system components che si trovano all’interno delle reti PCI segmentate e tutti i dispositivi installati ai loro confini devono adempiere a tutti i requisiti della PCI DSS a loro applicabili.

 

Questo approccio, apparentemente semplice da adottare, riserva alcune domande che si presentano al momento della sua messa in opera, quali:

  • Dove devono essere posizionati i system components che non trattano cardholder data, ma che per varie ragioni devono comunicare con il CDE? Devono essere all’interno del perimetro PCI DSS o posso restare nelle reti untrusted?
  • Si applicano requisiti PCI a questi ultimi? E se sì, quali sono e come si discriminano?

 

Sebbene all’interno dello standard e nei vari information supplement forniti dal Council non ci sia una risposta esplicita a queste domande, l’indicazione su come procedere si può dedurre da un’attenta lettura e interpretazione di quanto contenuto nelle sezioni “Scope of PCI DSS requirements” e “Network segmentation" 1

 

In particolare, è importante tenere sempre ben presente il campo d’applicazione che la norma stessa afferma fortemente nelle sue pagine iniziali e come richiamato all’inizio di questo articolo: “lo standard si applica a tutti i componenti inclusi o connessi al CDE”.

Conseguentemente, anche i componenti di sistema che non trattano direttamente cardholder data ma che lavorano a supporto e in diretta comunicazione con essi, devono rispettare e implementare i requisiti a loro applicabili.

 

Per quanto concerne la segmentazione, la PCI DSS indica come criterio principale per l’isolamento dei system components dalle restanti reti il fatto che essi “archivino, elaborino o trasmettono dati di carta di pagamento”, lasciando poi all’assessor che effettua l’analisi (in caso di organizzazione Level 1) oppure alle risorse interne (in caso di Self Assessment Questionnaire) la responsabilità di verificare in ultimo la lista di elementi da includere o da escludere.

 

Come regola generale e considerando che ogni realtà aziendale dovrebbe venir analizzata separatamente per definire la segmentazione delle proprie reti, si può affermare che:

 

  1. All’interno della rete segmentata devono venir inseriti tutti i componenti di sistema che trasmettono, registrano o elaborano dati di carta di pagamento (inclusi i dispositivi di rete e/o di firewalling che si trovano sui confini della rete segmentata);
  2. I sistemi che non trasmettono, elaborano o registrano dati di carta di pagamento ma che interagiscono in modo diretto con essi (ad esempio active directory server o NTP server) possono venir posizionati al di fuori della rete PCI segmentata ma devono rispettare comunque tutti i requisiti della DSS a loro applicabili;
  3. I restanti componenti sono esclusi dall’ambito della DSS.

 

Ma non è forse vero che la DSS afferma di essere applicabile a tutti i componenti di sistema che elaborano, trasmettono e registrano dati di carta di pagamento e a tutti i sistemi a loro connessi? Come è possibile che esistano componenti che, pur trovandosi al di fuori del CDE e vedendo applicati su di sé i requisiti DSS, non implichino l’adozione dello standard a tutti i restanti dispositivi a loro collegati?

 

In realtà il campo di applicazione dello standard è “tutti i componenti che trattano dati di carta e tutti i componenti a loro collegati”: nella rete untrusted sono posizionati unicamente dispositivi che non trattano dati di carta e che sono collegati a componenti del CDE (per questo a loro si applica lo standard). Grazie a questa distinzione e alla corretta segmentazione della rete, si può interrompere la viralità dell’applicazione di PCI DSS.

 

Il concetto di “viralità” dei componenti sottoposti a PCI DSS

Il concetto di “viralità” riguardo all’applicazione della PCI DSS non rientra nella terminologia ufficiale ma viene unicamente usato in questo articolo per facilitare la comprensione del campo di applicazione dello standard.

 

I “sistemi PCI DSS viralisono tutti quei componenti di sistema che direttamente trasmettono, elaborano o registrano dati di carta di pagamento: si tratta quindi di dispositivi che:

  1. Appartengono al CDE;
  2. Devono rispettare tutti i requisiti DSS a loro applicabili;
  3. Devono essere inseriti all’interno della rete PCI DSS segmentata (CDE) qualora si decida di adottare la segmentazione;
  4. Implicano l’adozione dei requisiti DSS per tutti i dispositivi con i quali essi condividono la rete (da cui il concetto di “viralità” dell’applicazione dello standard).

 

I “sistemi PCI DSS non virali sono tutti quei componenti di sistema che non trasmettono, elaborano o registrano dati di carta di pagamento ma che entrano in contatto diretto con questi ultimi, e quindi:

  • Sono esterni al CDE;
  • Devono rispettare tutti i requisiti DSS a loro applicabili;
  • Possono essere lasciati all’esterno della rete PCI DSS segmentata (CDE) qualora si decida di adottare la segmentazione;
  • Non implicano l’adozione dei requisiti DSS per tutti i dispositivi con i quali essi condividono la rete.

 

Figura 1 - Esempio di rete con CDE e componenti "non virali"

 

Riassumendo, dal punto di vista di PCI DSS è possibile raggruppare i componenti di sistema di un’azienda in tre gruppi:

  1. I sistemi interni al CDE, tutti sottoposti ai requisiti dello standard e che ne diffondo l’obbligo di applicazione in modo virale.
  2. I sistemi esterni al CDE ma coinvolti direttamente in attività legate a questi ultimi, anch’essi sottoposti ai requisiti dello standard ma che non ne diffondono l’obbligo in modo virale.
  3. I sistemi esterni al CDE e non coinvolti in alcun modo dagli aspetti legati alle carte di pagamento o ai componenti di sistema ad esse dedicati.

 

È inoltre importante ricordare che, nel caso di assessment “Level 1” (e quindi che richiedono un audit onsite e un Report on Compliance) è sempre responsabilità ultima dell’assessor definire quali sistemi possano essere esterni al CDE (non virali) e quali invece debbano essere localizzati forzatamente al suo interno (virali).

 

 

30/05/2014 - Alberto Perrone, Security Advisory Team @ Mediaservice.net

 


1 PCI DSS v.3.0, Novembre 2013, pag. 10 e pag. 11