Analisi di terze parti / tracciamento tag javascript e PCI DSS

Non esiste un requisito PCI specifico per avere Javascript di terze parti sul tuo sito o meno.

Personalmente, non ritengo che un fornitore di servizi di analisi sia un fornitore di servizi PCI sotto PCI DSS.

Esistono tuttavia dei requisiti per lo sviluppo sicuro del sito Web personalizzato (6.5) e per la revisione tramite valutazioni di sicurezza o per l'esecuzione sotto la protezione di un WAF (6.6).

Inoltre ci sono requisiti per le scansioni di vulnerabilità (11.2) e il test di penetrazione esterna (11.3.1).

Una libreria di terze parti che ospita il tuo sito web deve essere contrassegnata come vulnerabilità in base a uno di questi requisiti. Durante una normale, test di sicurezza non PCI, questo sarebbe normalmente essere formulato che v'è una libreria di terze parti presenti e questo rischio dovrebbe essere rivisto al fine di garantire che la biblioteca è attendibile, e il dominio è ospitato su è anche di fiducia, dovrebbe questo è un dominio esterno Se il dominio di terze parti non è affidabile, o se è compromesso, ciò rappresenterebbe un rischio per l'ambiente e per la conformità PCI. Cioè, qualcosa ospitato su google.com sarebbe probabilmente OK, ma qualcosa ospitato altrove potrebbe non.

Durante un test di sicurezza, questo è inizialmente classificato da un pentester come vulnerabilità a basso rischio. Tuttavia, dovrebbe essere esaminato dall'azienda. Se la tua azienda accetta questo rischio, documentalo semplicemente come tale. Se lo consideri un rischio che non può essere accettato, allora dovresti documentare le misure adottate per mitigare tale rischio. Ad esempio inserendo lo script di terze parti attraverso una revisione del codice e quindi ospitando lo script localmente anziché recuperarlo da un dominio di terze parti.

PCI DSS si occupa principalmente di documentare come hai affrontato lo spirito di ogni esigenza, piuttosto che una lista nera o bianca di lattine e cannots. Quindi, se dovessi essere controllato, puoi portare il QSA attraverso il tuo processo decisionale aziendale per dimostrare come stai rispondendo ai requisiti sopra riportati.

_{Dichiarazione di non responsabilità: non sono un QSA, né, cosa più importante, il tuo QSA. Solo il tuo QSA qualificato può valutare accuratamente le tue responsabilità secondo PCI DSS, in quanto avranno piena conoscenza della tua attività e del modo in cui si relazionano alle attività di elaborazione delle tue carte.}

Non sono un QSA. Dovresti consultare il tuo QSA su questo argomento.

Concordo pienamente sul fatto che la pubblicazione di javascript da un'origine non protetta come parte di pagine contenenti dati in ambito per PCI-DSS non dovrebbe superare l'invito con un avviso QSA. Vorrei fare un ulteriore passo avanti e dire che le altre pagine nella stessa sessione non dovrebbero contenere javascript non protetti.

Potrei essere eccessivamente prudente, ma farei un paio di passi più in là. L'esecuzione sul lato server o client di qualsiasi contenuto non supererebbe la raccolta se fossi il valutatore. Considera che questa fonte al di fuori del tuo controllo può modificare il contenuto senza che tu sappia di averlo fatto. Quale meccanismo proponi di applicare per testare la sicurezza di quel contenuto esterno? Mi viene in mente una vasta e brutta gamma di potenziali attacchi. In modo affidabile, puoi assicurarti che sia sicuro ogni volta che viene incluso?

In alternativa, valuta la possibilità di copiare il contenuto sul tuo server, verificarne la sicurezza e servirlo direttamente, senza caricarlo dinamicamente da terze parti. In effetti, questo lo rende parte del tuo sito e soggetto ai tuoi processi di controllo delle modifiche.

Requisiti PCI DSS 3.1 n. 12.8

"Le politiche e le procedure sono mantenute e implementate per gestire i fornitori di servizi con i quali i dati dei titolari di carta sono condivisi o che potrebbero influire sulla sicurezza dei dati dei titolari di carta ..."

Quando si esamina se l'analitica rientra nell'ambito, considerare i seguenti punti:

• I fornitori di analisi forniscono sicuramente un servizio e dovrebbero pertanto essere considerati fornitori di servizi. La Guida alla conformità PCI rafforza ulteriormente questo , prendendo come riferimento la definizione del fornitore di servizi PCI:

"Entità aziendale che non è un marchio di pagamento, direttamente coinvolto nell'elaborazione, archiviazione o trasmissione dei dati di titolari di carta. Ciò include anche società che forniscono servizi che controllano o potrebbero influire sulla sicurezza dei dati dei titolari di carta . (Fonte: www.pcisecuritystandards.org) "

• Il javascript esterno ha sicuramente il potenziale per influire sulla sicurezza dei dati PCI. (Vedi la risposta di JaimeCastells)

Se è necessario che QSA riesamini il requisito, utilizza la sua opinione. Se il tuo livello PCI non richiede un QSA, devi prendere la decisione basandoti sulla tua migliore comprensione dopo aver esaminato a fondo la domanda (e facoltativamente assumendo un consulente QSA).

La preoccupazione principale è che devi fidarti di Google o di qualsiasi altra terza parte che ti aiuti a tenere traccia degli utenti. Quando si distribuisce PCI DSS in modo rigoroso, si ha la responsabilità di assicurarsi che solo le entità conformi allo standard PCI DSS possano accedere ai dati del titolare della carta o di eventuali dati sensibili. Quindi il caricamento di uno script da una terza parte che non è conforme non è consentito. La conformità deve essere dimostrata da un COA.

Tuttavia, in genere ciò che puoi fare è ospitare lo script di monitoraggio sul tuo server. Il che significa che puoi valutare una volta che lo script corrispondente non sta rubando i dati delle carte. Quando si ospita lo script, si ha il controllo e non è necessario disporre di un AOC. In genere, i dati di monitoraggio effettivi vengono trasferiti a terzi da un'immagine. Quindi, quando controlli lo script, controlli quali dati lasciano il tuo ambiente e come tale ti senti conforme.