Lo standard PCI DSS (Payment Card Industry Data Security Standard) definisce misure che proteggono dati e processi nelle transazioni finanziarie con carte di pagamento. Elaborato dalle principali società emittenti di carte di credito, riunite nel forum Payment Card Industry Security Standards Council, lo standard è stato sviluppato per favorire e migliorare la protezione dei dati dei titolari di carta e per semplificare l’implementazione di misure di sicurezza dei dati a livello globale.

La prima versione, rilasciata nel 2006, è stata nel tempo aggiornata per adeguarsi all’evoluzione del mercato e migliorare l’autenticazione, l’attendibilità delle terze parti e la progettazione dei software. La versione più recente è la 3.2, che comprende il Requisito 8.3: considerato “best practice” fino a gennaio 2018, è entrata in vigore a tutti gli effetti da febbraio di quest’anno.

Il Requisito 8.3 tenta di rispondere ai sempre più frequenti episodi di violazione dei dati che compromettono le informazioni personali sensibili di milioni di consumatori. Ecco le principali novità che introduce e come garantire la conformità.

Autenticazione multi-fattore e Cardholder Data Environment

La principale novità del Requisito 8.3 è l’autenticazione multi-fattore, che diventa obbligatoria per tutti i soggetti coinvolti nei processi di pagamento con carte, compresi commercianti, compratori, emittenti, service provider e chiunque archivi, elabori o trasmetta dati di titolari di carte di pagamento o dati di autenticazione sensibili

Dirk-Denayer - VASCO Data Security

Dirk Denayer, Business Solutions Manager di VASCO Data Security

“Il termine ‘autenticazione multi-fattore’ sostituisce quello precedentemente utilizzato di ‘autenticazione a due fattori’”, spiega Dirk Denayer, Business Solutions Manager di VASCO Data Security. “E’ un cambiamento apparentemente sottile, ma molto importante, che codifica e chiarisce i requisiti minimi di autenticazione”.

Tra i cambiamenti più importanti Denayer indica anche l’estensione dei requisiti di autenticazione, che impattano su tutti coloro che hanno “accesso amministrativo non da console”, ovvero accesso remoto, al Cardholder Data Environment (CDE), ossia il contesto di elaborazione, archiviazione o trasmissione dei dati sulle carte di pagamento.

Il requisito dell’autenticazione multi-fattore si applica a chiunque acceda ai dati attraverso una rete piuttosto che tramite una connessione fisica diretta, comprese le reti interne ed esterne. Si applica a utenti generici, amministratori e terze parti (quali fornitori per servizi di supporto e manutenzione) con accesso remoto alla rete, in ogni caso in cui da ciò possa conseguire un accesso al CDE.

Principi dell’autenticazione multi-fattore

L’implementazione dell’autenticazione multi-fattore richiede l’utilizzo di almeno due dei tre fattori di autenticazione già descritti nel Requisito 8.2: qualcosa che si conosce (come password, PIN o risposte a domande segrete), qualcosa che si possiede (come un dispositivo token o una smartcard) e una caratteristica personale (come un parametro biometrico).

Lo standard stabilisce che i meccanismi di autenticazione devono essere indipendenti l’uno dall’altro. L’accesso a un fattore non deve consentire l’accesso ad alcun altro fattore e la compromissione di uno di essi non deve influire sull’integrità o sulla riservatezza degli altri.

In sintesi, “nell’autenticazione multi-fattore tutti i fattori devono essere verificati insieme e di concerto prima di ottenere l’accesso al sistema”, commenta Denayer, “in modo che un aspirante truffatore non possa corrompere la sicurezza da un telefono rubato”.

Per chiarire tutti gli aspetti relativi all’autenticazione multi-fattore il Consiglio ha pubblicato un Supplemento Informativo che presenta i principi di implementazione dell’autenticazione multi-fattore, leggi e regolamenti, scenari comuni di autenticazione, best practice ed errori da evitare.

Tra questi ultimi, in particolare, vengono evidenziati:

  • Riutilizzo delle credenziali. Quando una combinazione nome utente/password viene utilizzata per accedere alla rete aziendale e le stesse credenziali consentono anche l’accesso a un account di posta elettronica al quale viene inviata una one-time password (OTP) valida come secondo fattore, questi fattori non sono indipendenti. Il primo fattore (nome utente/password) fornisce accesso all’account di posta elettronica e quindi al secondo fattore.
  • Accesso comune ai certificati. Un certificato software memorizzato su un PC portatile (qualcosa che si possiede) protetto dallo stesso set di credenziali utilizzato per accedere al portatile (qualcosa che si conosce) potrebbe non garantire l’indipendenza.
  • Vulnerabilità del singolo dispositivo (mobile). Il Consiglio osserva che “trasmettere una one-time password a uno smartphone è considerato un metodo efficace Out of Band (OOB). Tuttavia, se lo stesso telefono viene utilizzato per inviare l’OTP – per esempio tramite un browser Web – l’efficacia dell’OTP come fattore secondario viene effettivamente annullata. Quando si immettono credenziali tramite lo stesso dispositivo che riceve (o memorizza/genera) un secondo fattore, un hacker che ha il controllo del dispositivo potrebbe catturare entrambi i fattori di autenticazione”.