Gestione dei dati HTTP non crittografati per un sistema conforme allo standard PCI - nell'ambito di PCI DSS v3 ma non v2?

3

Al momento disponiamo di un'applicazione personalizzata basata su cloud in grado di analizzare quindi instradare il traffico HTTP e HTTPS in un dominio. Quindi, se un cliente desidera utilizzare il nostro servizio, reindezza il suo DNS all'indirizzo IP della nostra applicazione e la nostra applicazione analizzerà il traffico e quindi instraderà come appropriato.

Per soddisfare la conformità PCI DSS dei nostri clienti, non decifriamo o analizziamo il traffico HTTPS, solo HTTP. Il traffico HTTPS viene semplicemente instradato al sistema di destinazione. Ciò significa che non dobbiamo rispettare noi stessi PCI per mantenere la conformità dei nostri clienti.

Tuttavia, al fine di mantenere la conformità dei nostri clienti per PCI v3 che entrerà in gioco alla fine del 2014, siamo stati informati che ciò non sarebbe stato accettabile. Il fatto che i dati HTTP passino attraverso il nostro sistema renderà i sistemi dei client non conformi come un difetto nel nostro sistema potrebbe consentire a un MITM di cambiare il reindirizzamento per i dettagli di pagamento in un sito diverso invece del canale HTTPS crittografato per il dettagli del titolare della carta (un po 'come sslstrip ). La nostra altra soluzione, che richiedeva ai nostri clienti di ospitare contenuti HTTPS su un dominio separato indirizzato direttamente al sistema del cliente, non era probabilmente accettabile per PCI v3 perché i dati HTTP non crittografati sarebbero soggetti allo stesso attacco (cioè potrebbe essere diretto altrove).

Quali specifiche modifiche allo standard PCI v3 potrebbero influire sulla conformità PCI DSS dei nostri clienti per questo problema?

    
posta SilverlightFox 09.09.2014 - 13:11
fonte

1 risposta

3

Parte di entrambe le risposte:

Dichiarazione di non responsabilità: non sono un QSA. E qui mi sto allontanando dall'opinione di quanto preferisco, quindi applica il sale in grana.

Nuova risposta dopo la modifica della domanda:

Ci sono due modifiche con DSS 3 che si basano su ciò con cui sembri flirtare

  1. l'aggiunta della nuova categoria SAQ A-EP.
  2. il litigio sul retro che è stato iframe contro javascript che continua a minacciare di scoppiare in una qualche forma di guida ufficiale.

Entrambe queste voci riguardano la provenienza del flusso delle transazioni con carta di credito. Se vado sul sito X, e clicco su "Check out" dal loro carrello, vado da qualche parte per inserire i dettagli della mia carta di credito. Dov'è da qualche parte? Come faccio a sapere che è dove sono destinato a essere? Come faccio a sapere che non instrado il mio traffico attraverso la Bulgaria per primo?

La tua attività sembra essere un intermediario del traffico. Voilà, sei esattamente ciò che il PCI si sta muovendo per evitare, o almeno per assicurare. Desiderate che i vostri clienti inviino senza problemi il traffico e fornirete il valore X. Ma PCI non vuole che il traffico venga reindirizzato senza problemi a meno che non ci sia una sicurezza sufficiente: per esempio, nessuno può modificare il processo per utilizzare un altro ( malevola) pagina di checkout.

Si indirizza il traffico in base all'analisi. Grande! Ciò significa che un utente malintenzionato può utilizzarti per reindirizzare il traffico. In termini PCI, significa che sei nell'ambito o non autorizzato. E come fornitore di servizi che è rimasto fuori dal campo di applicazione in passato, significa che è probabile che qualcosa cambi.

Ora, i problemi di provenienza non sono chiaramente definiti. Non posso puntare a DSS 3 sezione 13.7 che dice che quello che stai facendo è indirizzato. Ma posso dirti che i QSA inizieranno a fare domande del tipo "E questa azienda fa cosa? Intermedia tutto il tuo traffico HTTP, incluso il traffico che manda le persone al carrello della spesa e alla cassa?" Quindi vorranno vedere la certificazione del fornitore di servizi, in base alla definizione del fornitore di servizi :

This also includes companies that provide services that control or could impact the security of cardholder data.

Quindi, sì, potresti avere problemi con il passaggio al DSS 3. Non mi sento ancora sicuro di aver capito la tua attività, quindi non posso dire nulla di sicuro, ma il tuo traffico è mediocre, sei nella lista e potresti perdere clienti se non sei un fornitore di servizi certificato. (Prolexic is not. Akamai is. Chi può dire?)

Risposta originale di seguito:

Recentemente ho eseguito un confronto riga-per-riga di PCI DSS v2 rispetto a v3 e non ricordo nulla all'interno del DSS stesso che possa influire sulla traversata del traffico HTTPS attraverso un provider. La sezione 4 riguarda la crittografia dei "dati dei titolari di carta su reti pubbliche aperte" e sarebbe il posto più ovvio da guardare, e questo è appena cambiato.

Detto questo, due avvertimenti:

1) Il DSS non è l'unica cosa a cui prestare attenzione. Anche la formulazione dei questionari SAQ, se si applicano alle attività in questione, e vari altri documenti di orientamento che elaborano il significato dei QSA sono importanti.

2) Non è del tutto chiaro per me che il tuo servizio sia semplicemente un canale di traffico crittografato. Dichiari che i tuoi clienti "reindirizzano il loro DNS all'indirizzo IP della nostra applicazione e la nostra applicazione analizzerà il traffico e quindi instraderà come appropriato". La frase "analizza il traffico" attirerà qualsiasi QSA per un aspetto più approfondito. Non dovresti avere molto da lavorare per l'analisi, nel caso di HTTPS; dovresti consentire la negoziazione SSL attraverso il vero back-end per inchiodare HTTPS prima che il canale fosse al sicuro da te, e se questo è tutto ciò che stai facendo, il tuo servizio non sta facendo molto. In breve, non credo che abbiamo abbastanza dettagli sul tuo servizio per darti consigli solidi.

    
risposta data 09.09.2014 - 15:32
fonte

Leggi altre domande sui tag