Le procedure di sicurezza dei file previste dallo standard PCI DSS comprendono la scansione, la pulizia e la valutazione di ogni file che entra nel CDE (Cardholder Data Environment, ambiente dei dati dei titolari di carte), attraverso tutti i canali di acquisizione, non solo gli endpoint. La versione 4.0.1 dello standard PCI DSS estende la protezione anti-malware al web, alla posta elettronica, all’archiviazione cloud, al trasferimento gestito dei file, ai supporti rimovibili e alle dipendenze software.
La maggior parte dei team di sicurezza responsabili della conformità allo standard PCI DSS (Payment Card Industry Data Security Standard) ha già svolto il proprio lavoro. L’EDR (Endpoint and Response) è stato implementato. L’antimalware è attivo. Il requisito n. 5 è contrassegnato da un segno di spunta. Si tratta di misure di sicurezza fondamentali, ma quando si considera l’ambito più ampio dei requisiti normativi, i controlli di sicurezza tradizionali potrebbero rivelarsi insufficienti.
La versione 4.0.1 dello standard PCI DSS chiarisce un aspetto che nelle versioni precedenti era lasciato all’interpretazione: la protezione anti-malware si estende a tutti i canali attraverso i quali i file entrano, circolano all’interno ed escono dal CDE. Vulnerabilità zero-day. Traffico web. Posta elettronica. Cloud . Trasferimento gestito dei file. Supporti rimovibili. Software .
Gli endpoint sono solo una delle tante aree di copertura. Se le altre non sono state valutate, sussiste un rischio e i revisori sanno dove cercare.
Questo articolo illustra l'intero ambito di applicazione dello standard, consentendovi di valutare in modo obiettivo il vostro livello di conformità. Per un approfondimento più dettagliato, requisito per requisito, la “Guida alla mappatura PCI DSS” e la “Lista di controllo per principianti” analizzano ogni singolo controllo fornendo raccomandazioni concrete.
Punti di forza
Lo standard PCI DSS 4.0.1 considera la sicurezza dei file come una disciplina multicanale. La protezione anti-malware deve estendersi al web, alla posta elettronica, al cloud, al trasferimento gestito dei file, ai supporti rimovibili e alle dipendenze software, non limitandosi ai soli endpoint.
La protezionedei singoli endpointavviene a valle di tutti gli altri canali. Quando un file raggiunge un agente endpoint, ha già superato o non superato altri sei punti di ispezione.
Il rilevamento basato sulle firme da solo non soddisfa lo standard. Il requisito 5 prevede la copertura di tutti i tipi di malware e il rilevamento comportamentale delle minacce zero-day.
I supporti rimovibili sono soggetti a un obbligo esplicito. Il requisito 5.3.3 impone la scansione automatica dei supporti rimovibili al momento dell'inserimento; le procedure manuali non sono considerate valide.
Software rientrano nell'ambito di applicazione. Il requisito 6.3.2 prevede che il software su misura e personalizzato venga sviluppato in modo sicuro e che venga tenuto un inventario dei componenti di terze parti.
Quali sono i requisiti previsti dalla norma PCI DSS 4.0.1 in materia di sicurezza dei file?
Prima di addentrarci nei dettagli, vale la pena basare la discussione sulle specifiche stesse.
Il requisito 5 descrive chiaramente la superficie di attacco: «Il malware può penetrare nella rete nel corso di numerose attività autorizzate dall’azienda, tra cui la posta elettronica dei dipendenti (ad esempio tramite phishing) e l’uso di Internet, mobile e dispositivi di archiviazione, con conseguente sfruttamento delle vulnerabilità del sistema». Questo è il modello di minaccia principale per gli attacchi basati sui file negli ambienti di pagamento.
Lo standard stabilisce inoltre che il solo rilevamento delle firme non è sufficiente: «L’utilizzo di soluzioni anti-malware in grado di contrastare tutti i tipi di malware contribuisce a proteggere i sistemi dalle minacce attuali e in continua evoluzione». Le espressioni chiave sono «tutti i tipi» e «attuali e in continua evoluzione». Un sistema di rilevamento che riconosca solo le minacce note lascia un’lacuna che lo standard identifica esplicitamente.
Il requisito 5.2.1 va oltre: le sue linee guida sulle buone pratiche sottolineano che è "utile che le entità siano consapevoli degli attacchi 'zero-day' (quelli che sfruttano una vulnerabilità precedentemente sconosciuta) e prendano in considerazione soluzioni incentrate sulle caratteristiche comportamentali, in grado di segnalare e reagire a comportamenti inattesi". Questo è il riconoscimento, da parte dello stesso standard, dell'importanza del rilevamento comportamentale ed euristico per una copertura completa.
I requisiti 6 e 11 ampliano ulteriormente l’ambito di applicazione. Il requisito 6.3.2 richiede che vengano identificate le vulnerabilità di sicurezza nel software su misura e personalizzato, affrontando direttamente il rischio legato alla catena di fornitura del software. Il requisito 11.3.1.2 richiede l’esecuzione di scansioni interne autenticate. Insieme, stabiliscono che la sicurezza dei file in un ambiente conforme allo standard PCI DSS non sia un singolo controllo, ma una disciplina applicata all’intera architettura.
Quali sono i sette canali di acquisizione dei file che lo standard PCI DSS richiede di Secure?
È proprio qui che molti programmi di conformità presentano una lacuna che non è stata ancora quantificata.
Canale di ingestione | Requisiti PCI DSS | Perché Endpoint non riescono a individuarlo | Cosa colma il divario |
Traffico web | Richieste 5, 6 | I file in transito attraverso un proxy web non passano mai attraverso un agente endpoint | Scansione multimotore al punto di accesso |
E-mail e allegati | Req. 1, 5 | La scansione delle firme su un singolo motore non rileva macro, archivi ed exploit incorporati | Multiscanning, pulizia dei file, prevenzione della perdita di dati |
Archiviazione Cloud | Richieste 5, 6 | I caricamenti diretti su SharePoint, OneDrive o S3 aggirano l'ispezione degli endpoint | Scansione dei file inattivi + prevenzione della perdita di dati |
Trasferimento di file gestito | Richieste 5, 6 | I file dei partner di fiducia arrivano già all'interno del flusso di lavoro | Scansione dei file in movimento + pulizia dei file |
Supporti rimovibili | Req. 1, 5, 9 | Le politiche di scansione manuale non soddisfano l'obbligo di scansione automatica | Scansione automatica all'inserimento (chiosco) per impedire l'introduzione di malware da dispositivi esterni |
Software | Richiesta n. 6 | I CVE noti presenti nei componenti di terze parti non sono firme di malware | vulnerability detection dei file (artifatti software) vulnerability detection le fasi del ciclo di vita dello sviluppo del software (SDLC) |
Punti finali | Richiesta n. 5 | A valle di tutti gli altri canali; intercetta le minacce per ultime | EDR / antivirus per endpoint |
- Traffico web: i file scaricati o caricati su un portale web tramite HTTPS transitano attraverso la rete prima di raggiungere qualsiasi endpoint.
- E-mail e allegati: l’e-mail rimane il canale più comune attraverso cui vengono diffuse le minacce basate su file. L’analisi degli allegati deve andare oltre il semplice confronto delle firme. Gli archivi compressi, i documenti con macro abilitate e i file con exploit incorporati sono tutti progettati per eludere tale analisi.
- Cloud locale e Cloud : i file vengono sincronizzati costantemente da e verso SharePoint, OneDrive, S3 e piattaforme simili.
- Trasferimento gestito dei file: gli scambi con i fornitori, le integrazioni con i partner e l'invio di file da parte dei clienti generano flussi di file in entrata che presentano un proprio profilo di rischio.
- Supporti rimovibili: il requisito 5.3.3 è uno degli obblighi più specifici previsti dalla norma: il software anti-malware deve eseguire automaticamente la scansione dei supporti rimovibili al momento del loro inserimento. USB rappresentano un vettore di attacco attivo negli ambienti di pagamento, compresi i sistemi “air-gapped”, dove spesso costituiscono l’unica via di accesso esterna ai dati.
- Software e dipendenze. Il requisito 6.3.2 è stato introdotto poiché le librerie di terze parti e i componenti integrati rappresentano una fonte significativa di esposizione alle vulnerabilità (CDE). Un file binario fornito con una vulnerabilità CVE (Common Vulnerability and Exposure) nota in una delle sue dipendenze comporta il rischio che il rilevamento del malware basato sulle firme non riesca a individuarlo. Si tratta di una vulnerabilità in attesa di essere sfruttata, non di malware nel senso tradizionale del termine.
- Endpoint. Questo è l’unico canale che la maggior parte dei team ha già coperto. Endpoint analizzano ciò che arriva, viene eseguito o persiste su un dispositivo. Tale copertura è necessaria, ma si colloca a valle rispetto a tutti gli altri canali presenti in questo elenco. Quando un file raggiunge un endpoint, ha già superato o fallito altri sei punti di ispezione.
Perché Endpoint antivirus Endpoint singolo Endpoint non è sufficiente
L'EDR e l'antivirus per singoli endpoint sono strumenti eccellenti, ma il loro ambito di applicazione è limitato per definizione.
Endpoint proteggono i dispositivi monitorando ciò che accade sul dispositivo stesso: i file scritti su disco, i processi eseguiti, le connessioni di rete avviate. Non controllano i file che transitano attraverso un proxy web, un gateway di posta elettronica, API di sincronizzazione cloud o un USB . Si tratta di una questione di ambito di applicazione, non di una carenza del prodotto.
La norma PCI DSS 4.0.1 risponde in modo definitivo a questa domanda sull’ambito di applicazione. Lo standard descrive la superficie di attacco come l’insieme di tutti i canali attraverso i quali i file entrano nella rete. Endpoint tutela ciò che si trova già all’interno del CDE. La sicurezza dei file tutela il passaggio dei file.
La vulnerabilità non è solo teorica. Un malintenzionato che diffonda un payload tramite un allegato di phishing analizzato solo da un gateway a motore singolo, oppure tramite una dipendenza dannosa in un pacchetto software fornito dal produttore, o ancora tramite un USB collegato durante una finestra di manutenzione: nessuno di questi percorsi entra in contatto con un agente endpoint finché non è troppo tardi. Sono proprio questi i canali che lo standard vi chiede di chiudere.
In che cosa consiste la sicurezza completa dei file ai sensi della norma PCI DSS 4.0.1?
Le organizzazioni che hanno superato con esito positivo gli audit 4.0.1 sulla sicurezza dei file condividono un'architettura comune: ispezione in ogni punto di acquisizione, con più livelli di difesa.
Ciò significa scansione multi-motore a livello di gateway. L’esecuzione simultanea dei file su più motori antivirus aumenta notevolmente i tassi di rilevamento e garantisce la profondità di copertura richiesta dall’espressione “tutti i tipi” dello standard. Significa inoltre la sanificazione dei file che neutralizza ciò che l’antivirus non è in grado di rilevare: la tecnologia Deep CDR™ ricostruisce i file in formati sicuri e utilizzabili, eliminando i contenuti potenzialmente dannosi, inclusi gli exploit zero-day non ancora catalogati. Significa una valutazione delle vulnerabilità a livello di file rispetto ai CVE noti per i pacchetti software e i file binari prima che raggiungano i sistemi di produzione. E significa una registrazione centralizzata su tutti i canali, non solo sulla telemetria degli endpoint, in modo che i requisiti di audit del Requisito 11 possano essere effettivamente soddisfatti.
MetaDefender™ è la piattaforma di sicurezza dei file OPSWAT, progettata per eseguire la scansione, la sanificazione e la valutazione dei file su tutti i canali di acquisizione prima che raggiungano il CDE.
Come sottolinea la guida alla conformità OPSWAT: "OPSWAT MetaDefender alcune delle funzionalità più avanzate del settore per il Requisito 5. Multiscanning Metascan™ Multiscanning oltre 30 motori antivirus commerciali per rilevare il malware noto con eccezionale precisione, mentre la tecnologia Deep CDR™ neutralizza in modo proattivo le minacce zero-day e quelle incorporate, ricostruendo i file in formati sicuri e utilizzabili."
Questa lacuna non è dovuta a una mancanza di attenzione da parte dei team di sicurezza, ma al fatto che lo standard PCI DSS 4.0.1 richiede un approccio più ampio. I team che la colmano prima di un audit non stanno facendo più di quanto richiesto dallo standard. Stanno semplicemente rispettando tutti i requisiti.
I prossimi passi
Sei pronto a verificare se la tua attuale copertura soddisfa tutti i requisiti previsti dalla versione 4.0.1?
Scarica la Guida alla mappatura PCI DSS + la Lista di controllo per principianti PCI DSS per mappare i controlli esistenti in relazione a ciascuno dei sette canali di acquisizione dei file e individuare eventuali lacune.
Domande frequenti
È sufficiente una protezione su un unico endpoint per garantire la conformità allo standard PCI DSS 4.0.1?
No. Lo standard PCI DSS 4.0.1 estende la protezione anti-malware a tutti i canali attraverso i quali i file entrano nel CDE. La protezione tradizionale degli endpoint garantisce la sicurezza dei dispositivi, ma non ispeziona i file che transitano attraverso proxy web, gateway di posta elettronica, sincronizzazione cloud o supporti rimovibili. OPSWAT MetaDefender si integra con tecnologie multistrato per colmare questa lacuna.
Lo standard PCI DSS richiede l'esecuzione di una scansione antivirus sui supporti rimovibili?
Sì. Quando un supporto rimovibile viene inserito, collegato o montato logicamente, il requisito 5.3.3 impone l’esecuzione di scansioni automatiche o di un’analisi comportamentale continua dei sistemi o dei processi. Le politiche di scansione manuale non soddisfano tale requisito.
Quali sono i canali di acquisizione dei filerelativi alla norma PCI DSS 4.0.1?
Traffico web, e-mail e allegati, archiviazione su cloud, trasferimento gestito di file, supporti rimovibili, dipendenze software ed endpoint.
La norma PCI DSS 4.0.1 affronta il rischio legato alla catena di approvvigionamento del software?
Sì. Il requisito 6.3.2 prevede che il software su misura e personalizzato venga sviluppato in modo sicuro, che le vulnerabilità di sicurezza vengano individuate e risolte e che venga tenuto un inventario dei componenti software di terze parti per facilitare la gestione delle vulnerabilità e delle patch.
Che cos’è l’ambiente dei dati dei titolari di carta (CDE)?
Il CDE è costituito dal personale, dai processi e dalla tecnologia che archiviano, elaborano o trasmettono i dati dei titolari di carte, oltre a qualsiasi sistema collegato. I controlli di sicurezza dei file previsti dallo standard PCI DSS si applicano ai file in entrata, in uscita e in transito all’interno del CDE.
