Il software senza patch è conforme a PCI DSS 3.1?

Per i bug critici, la Guida di riferimento rapido PCI DSS 3.1 copre questo senza mezzi termini:

6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Questo è speculare nella documentazione ufficiale per PCI DSS 3.2 (I couldn ' trovare un PDF v3.1) che dice esattamente la stessa cosa:

6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

Per risparmiare una lettura lunga, il TL; DR del requisito 6.1 è che la criticità deve essere misurata sulla base dei punteggi CVSS forniti dal settore, amplificati da fattori di business.

In termini più generali, la questione se siano o meno violazioni di PCI DSS quando sono in esecuzione software obsoleti e vulnerabili dipende dalla decisione del loro QSA. Se il bug è di lieve entità, ad esempio un problema di static content injection o una minore divulgazione di informazioni, allora il QSA potrebbe ritenere appropriato che l'organizzazione abbia identificato il problema e lo abbia inserito nel proprio registro dei rischi per una futura soluzione. Se l'errore è più grave ma non considerato critico (ad esempio, l'XSS riflettente che richiede l'interazione dell'utente), la QSA potrebbe ancora considerare questa una violazione di PCI DSS a propria discrezione.

Per quanto riguarda il software EOL, PCI DSS non lo menziona in modo specifico, ma afferma semplicemente che

All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Questo indica che l'utilizzo del software EOL diventa responsabilità dell'organizzazione che gestisce i dati dei titolari di carta. Se si riscontra una vulnerabilità nell'applicazione, è compito dell'organizzazione mitigarla. Ciò potrebbe richiedere loro di ricucire manualmente l'applicazione (difficile, costosa), fornire controlli secondari (ad esempio collocando l'applicazione in un ambiente contenitore isolato come XenApp), o sostituire completamente il software.

Per ulteriori informazioni, ti suggerisco di dare una lettura della documentazione PCI DSS. È un documento piuttosto lungo, ma puoi saltare alle sezioni applicabili alle tue preoccupazioni e la lingua è abbastanza chiara e leggibile. Ricorda inoltre che PCI DSS è uno standard progettato solo per incoraggiare pratiche di sicurezza sensibili sulla gestione dei dati delle carte di pagamento - non è una ricetta per una strong sicurezza da solo, quindi "conforme PCI" non significa necessariamente "sicuro".

Dipende

Mentre PCI DSS richiede ad es. installare patch di sicurezza critiche per sistemi in-scope entro un mese, la domanda generale di software senza patch o EOL dipende molto dalle circostanze. Ovviamente non dovresti farlo, ma è possibile in determinate circostanze se l'organizzazione lo vuole davvero e adotta le misure appropriate per farlo.

In primo luogo, l'organizzazione può utilizzare il software senza patch / EOL su tutti i sistemi che non rientrano nell'ambito di applicazione della conformità PCI DSS, che in qualsiasi configurazione sensata sarà la maggior parte dei loro sistemi.

Per i sistemi che rientrano nell'ambito dei requisiti PCI DSS (che dovrebbero essere pochi e isolati), il requisito PCI DSS effettivo è quello di disporre di criteri che garantiscano che i sistemi siano sicuri in base alle proprie priorità aziendali . Per esempio. afferma "Considerare la priorità delle installazioni di patch in modo che le patch di sicurezza per i sistemi critici o a rischio siano installate entro 30 giorni e altre patch a basso rischio vengano installate entro 2-3 mesi."

Quindi, in generale, è in qualche modo possibile che l'organizzazione abbia (a) conoscenza e valutazione dei rischi particolari di queste vulnerabilità; (b) li ha valutati (in base alle proprie politiche di rischio!) come non critici, e (c) scelto di non applicare ancora queste patch. Questo potrebbe essere conforme, o no - i dettagli contano molto.

PCI DSS richiede il monitoraggio delle vulnerabilità nel software pertinente e agisce per mitigarne l'impatto, ma in genere è possibile scegliere come farlo, e l'applicazione di patch, gli aggiornamenti della versione e l'abbandono del software EOL non sono unico modo per farlo. Esistono in genere altre alternative per mitigare le vulnerabilità anche senza patch o aggiornamento della versione - ad esempio, se una particolare vulnerabilità si basa su determinati servizi abilitati o su determinati accessi remoti possibili, è possibile attenuarli prevenendo tali condizioni anziché l'aggiornamento della versione, se l'aggiornamento della versione non è auspicabile per altri motivi.