Suggerimento su come essere compatibile con PCI

3

Sto lavorando su un sistema che prende le informazioni della carta di credito dei clienti prima di inviarle al processore. Mi richiede di chiedere al cliente cc #, CVV, data, uno alla volta e di inviarlo al mio server tra ogni richiesta (https, nessun cookie, cache o sessioni utilizzate). Come devo tenere traccia dei dati tra le richieste? Ho pensato a Memcache (d) o archiviato (crittografato) in un database e cancellato non appena la transazione è stata completata. Non sembrano davvero le migliori opzioni. Gradirei alcuni suggerimenti se ne avete qualcuno.

    
posta Brad 13.09.2013 - 08:55
fonte

3 risposte

1

È conforme per tenerli in memoria durante la transazione. È più sicuro (da un Pov di conformità) e più semplice è memorizzarli temporaneamente in un database.

PCI DSS 3.0 fornisce ora una guida per proteggere i dati sensibili in memoria durante l'elaborazione per evitare perdite di dati in crash dump.

La cosa migliore è usare una libreria che codifica la memoria volatile.

    
risposta data 16.01.2014 - 16:00
fonte
8

Innanzitutto, I consiglia vivamente di scaricare completamente gli obblighi di conformità PCI-DSS trasferendo la responsabilità di acquisire ed elaborare le credenziali di pagamento al fornitore del gateway di pagamento. La maggior parte dei fornitori di pagamenti ospita le pagine di acquisizione dei pagamenti per i loro clienti per questo motivo. Ciò consente di passare semplicemente le informazioni sui prezzi e i dettagli della fattura al gateway di pagamento e quindi restituire se il cliente ha effettivamente pagato. Rolling your own payment gateway è pericoloso tanto quanto far rotolare la tua cripto-peggio in realtà; come gestirai denaro e varie passività bancarie.

Tuttavia, se per qualche motivo tu o la tua organizzazione non volete utilizzare nessuno dei venditori di pagamenti preesistenti; è necessario tenere presente quanto segue:

  • Sarà necessario crittografare o cancellare qualsiasi "informazione confidenziale" della carta di credito registrata. Questi includono il numero della carta, la scadenza della carta e il nome del titolare del conto. L'hashing è una misura di conformità più semplice da soddisfare rispetto alla crittografia. Non memorizzare affatto è ancora meglio.
  • Il valore CSC / CVV (numero sul retro della carta) non deve mai essere memorizzato sui tuoi server, è solo una proprietà di autenticazione "presente carta" temporanea.
  • Credo che al giorno d'oggi i nuovi siti Web conformi allo standard PCI-DSS siano strongmente sollecitati ad implementare 3D-Secure o equivalente, dove l'utente può anche autenticare il pagamento con una password inserita su una rete di credito o un sito web bancario di terzi.
  • SSL / TLS dovrà spesso essere del tipo più costoso di certificato Extended Validation. Tali certificati (e alcuni rinnovi) richiedono anche una documentazione lenta sulle intestazioni ufficiali e sull'autorità di "funzionari" delegati in un determinato organigramma. Bob dall'IT nel seminterrato non lo taglia (almeno fino a quando le pratiche non dicono a Verisign o cose simili che Bob è ora l'ufficiale delegato). Questo processo per i nuovi certificati non è veloce.
  • PCI-DSS richiede il controllo di qualsiasi accesso ai server che memorizzano i dettagli della carta di credito o partecipano a qualsiasi parte della catena di elaborazione, dal proxy inverso DMZ ai server di database e di backup. Ciò include l'elaborazione o l'archiviazione nel cloud.
  • PCI-DSS richiede il controllo e il controllo degli accessi per tutto lo sviluppo e l'implementazione del software; che è alquanto in disaccordo con persone in buona salute / persone che credono nei progetti Agile.
  • PCI-DSS ha alcune idee abbastanza specifiche su quale dovrebbe essere la topologia della rete; un accordo che può aumentare i costi se non si dispone già di router, switch e firewall disposti nella struttura subnet desiderata.
  • PCI-DSS si aspetta database tradizionali e demoni web; e che sono completamente aggiornati e aggiornati. A tal fine, i revisori richiederanno spesso contratti di supporto interamente versati per il tuo software. Molti auditor (almeno quando ho dovuto lavorare con PCI-DSS) non apprezzeranno il software open source dove esiste un'applicazione commerciale "robusta" più familiare. Quindi aspettati la possibilità di passare da PostgreSQL a un database Oracle.
  • Dovrai tenere registri dettagliati di personale di riparazione di emergenza o appaltatori di software ad hoc che hanno accesso al codice sorgente o ai server.
  • Dovrai pagare per un auditor PCI-DSS esterno su base routine.
  • Il controllo esterno PCI-DSS richiede anche la documentazione del controllo interno PCI-DSS da parte dell'organizzazione. Ciò consente di risparmiare un po 'di tempo all'auditor esterno e dimostra che l'organizzazione deve effettivamente pensare periodicamente alla propria sicurezza. Anche gli audit interni costano denaro.
  • Questo è non un elenco completo o *. Il revisore esterno può essenzialmente richiedere qualsiasi adeguamento a qualsiasi sistema o processo aziendale per soddisfare la conformità. L'azienda può talvolta firmare un elenco di rischi di revisione e ottenere comunque un certificato PCI-DSS, ma gli avvocati della compagnia urleranno delle passività assorbite dal dover firmare una deroga di revisione "conforme".

Quindi pensa molto attentamente ai beni o servizi principali della tua attività. Quindi considera se stabilire e gestire l'elaborazione diretta delle carte di credito è un prodotto chiave della tua attività.

* ciclo password, restrizioni sudo shell, documentazione di supporto completa, ruoli di divisione indipendentemente dalle dimensioni dell'azienda; la lista continua. Il processo di conformità PCI-DSS può richiedere 6 mesi o più.

    
risposta data 13.09.2013 - 09:57
fonte
0

Puoi controllare e provare OSSEC (Open Source Security) che è un sistema di rilevamento delle intrusioni basato su host. Essere open source è un vantaggio per la sicurezza e aiuta con PCI.

Si dice:

OSSEC helps customers meet specific compliance requirements such as PCI, HIPAA etc. It lets customers detect and alert on unauthorized file system modifications and malicious behavior embedded in the log files of COTS products as well as custom applications. For PCI, it covers the sections of file integrity monitoring (PCI 11.5, 10.5), log inspection and monitoring (section 10) and policy enforcement/checking.

    
risposta data 13.09.2013 - 10:38
fonte

Leggi altre domande sui tag