Il PCI richiede effettivamente che le informazioni della carta vengano crittografate in memoria?

TL; DR

Tecnicamente, PCI richiede che i dati del titolare della carta (CHD) vengano crittografati sia in transito che a riposo. All'inizio questo può sembrare semplice, ma la realtà è che non è molto specifico delineare tra il resto su disco vs memoria volatile . Se vuoi essere pedante, la memoria volatile è ancora a riposo, ma secondo Domande frequenti crittografate-while-in-memoria, non è richiesto esplicitamente di essere crittografato mentre è in memoria. Anche se è bene sottolineare che queste sono solo le FAQ, non in realtà nello standard PCI DSS stesso. Ecco un buon articolo da leggere per maggiori informazioni.

Risposta lunga

Il motivo per cui la crittografia in memoria ha a che fare con il vettore di attacco che graffia la memoria.

PCI DSS does a good job of making sure credit card data in persistent storage is secure, however, such data in non-persistent storage -- such as files stored temporarily in memory -- can still be vulnerable to compromise, particularly via memory-scraping malware. Learn more about this threat. SOURCE

Maggiori informazioni su ciò che PCI richiede possono essere trovate qui . Il TL; DR della lunga risposta è che se non cripti i dati a riposo (su disco o in memoria), assicurati di avere i controlli compensativi per mitigare il rischio di perdita di dati.

If stored cardholder data cannot be encrypted, consult PCI DSS Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet.

I dati dei titolari di carta non devono essere crittografati nella memoria volatile ( link ) Va notato che la capacità dei dati scritti sulla memoria volatile di persistere su disco può e avverrà. La crittografia del file di paging o del file di scambio può aiutare a prevenire questo.

I dati dei titolari di carta devono essere protetti durante il transito su reti pubbliche aperte [PCI DSS Req. 4.1] e quando scritto su disco [PCI DSS Req. 3.4]. I requisiti non sono gli stessi per ciascuno e gli esempi sono riportati all'interno di PCI DSS. Di solito è utile anche la colonna Guida sulla destra dello standard.

La versione più recente di PCI DSS può essere trovata qui. link

Per prima cosa rispondi alla tua seconda domanda ("Non vedo la ragione dietro di essa, se attaccato può raggiungere i valori, può anche ottenere la chiave di crittografia, giusto?") la RAM di RAM predefinita il malware semplicemente sa come identificare i dati di traccia in memoria. Non capisce la mappa della memoria del processo di registrazione. Non conosce le tue strutture o campi. Non cerca di trovare un buffer char * con l'etichetta "Track_Data". Legge solo tutta la memoria nel processo e, se corrisponde a un modello di 15 o 16 cifre, la rimuove e la invia al cattivo. Il malware standard non conosce certamente quale byte costituisce una chiave di crittografia, quindi una volta crittografato, il malware non lo vedrà. (Il tipico malware non è molto sofisticato e certamente non riconoscerebbe i dati XOR o ROT-13, tanto meno un blocco di dati crittografati AES-128.)

Considera che gli attaccanti devono essere furtivi: se hanno inviato 2 GB di dump di RAM da ogni registratore di cassa dopo ogni transazione, probabilmente le persone della rete si accorgerebbero. Invia solo la più piccola quantità di dati di cui hanno bisogno e non tenta di decodificare nulla.

(Si noti che questo è vero solo per la RAM generica che cancella malware come Dexter e BlackPOS; se c'è malware indirizzato a un'applicazione specifica, può essere personalizzato per comprendere le strutture di memoria e provare a rubare le chiavi e / o dati crittografati da specifici indirizzi. Tutto dipende dagli aggressori.)

-

Come richiesto, la prima parte della tua domanda descrive quasi una condizione di gara: a che punto i dati della traccia sono considerati "a riposo"? È solo quando atterra su un disco rigido, o può essere considerato a riposo mentre nella memoria in attesa di essere crittografato?

Ma ora devi andare avanti e ottenere maggiori dettagli. È a riposo quando atterra nei buffer del driver del dispositivo USB? Sta riposando quando viene inviato un messaggio di Windows per notificare al processo che sono stati immessi nuovi dati di traccia? Sta riposando quando il buffer viene inviato all'algoritmo di crittografia? È a riposo quando l'applicazione analizza la traccia per recuperare il nome del titolare della carta, il codice di servizio, PAN, CVV e la data di scadenza? È a riposo quando toglie le ultime 4 cifre della ricevuta? È a riposo se l'applicazione sta elaborando il numero di account in qualsiasi modo prima della crittografia; forse convalidare una cifra di controllo o determinare se si tratta di un visto o di un altro tipo di carta di credito? È a riposo quando viene costruito il messaggio di autorizzazione? Nessuna di queste attività sembra che i dati stiano riposando molto e molte di queste attività sono funzioni comuni nei sistemi POS. In totale, tutta l'elaborazione può richiedere alcuni millisecondi o più.

Consideriamo ora gli attaccanti del mondo reale. Il malware utilizzato in alcune delle più grandi violazioni di nome era RAM che raschiava il malware ed è estremamente aggressivo. Può scorrere la memoria del registro centinaia di volte al secondo e attivare il più breve sguardo su PAN o tenere traccia dei dati. Può acquisire i dati di traccia che arrivano nei buffer USB, nei buffer dei messaggi di Windows prima che l'applicazione venga notificata, mentre vengono smontati nelle routine di analisi o anche quando vengono invocate le routine di crittografia. Anche se si rispetta perfettamente la lettera delle leggi PCI-DSS e la si cripta non appena l'applicazione la vede, si è ancora vulnerabili a una violazione se qualche membro di questa famiglia di malware accede ai propri registratori di cassa.

Invece di concentrarsi sull'interpretazione esatta di PCI-DSS, è meglio evitare completamente la situazione rimuovendo quanti più sistemi possibili dall'ambito PCI. Se puoi, scarica i dati della traccia dal registratore di cassa e in un terminale di pagamento separato che può crittografare i dati prima di inviarli al registratore di cassa.

Se si sposta la crittografia su un dispositivo separato situato all'esterno dell'ambiente del registratore di cassa, il registro non deve mai ricevere PAN in chiaro o tenere traccia dei dati. Qualsiasi malware che si trovi nei tuoi registri non troverà traccia di dati da analizzare. E un terminale di pagamento avrà una superficie di attacco molto più piccola di una vera e propria applicazione per registratore di cassa basata su Windows.

Non ho molta familiarità con i metodi di crittografia usati in PCI, ma c'è una buona ragione per cui uno vorrebbe questo. Le operazioni hardware spesso ignorano la CPU e dispongono dell'accesso diretto alla memoria (DMA) per aumentare le prestazioni e ignorare i cicli di CPU non necessari. Il grande potere arriva con grandi responsabilità e la memoria diretta IO può portare a exploit creativi .

Per fare un esempio, macchine virtuali, carceri e contenitori separano gli ambienti tra host e ospiti. Oltre a quanto esplicitamente consentito, mai un ospite dovrebbe essere in grado di raggiungere l'ospite o altri ospiti in segmenti circuitali. Se ciò accade, parliamo di un jailbreak. Qualsiasi dispositivo hardware che consente DMA può essere sfruttato per trasportare malware. Ci sono stati numerosi articoli pubblicati su exploit pass-through PCI, che espongono l'ospite agli ospiti.

Analisi della vulnerabilità di GPU computing, 2013:

[31] mentions the possibility of attacking a system by taking advantage of Direct Memory Access (DMA) to access memory that otherwise would be protected. While not specifically mentioned in this paper, the extension of this idea to GPUs represents a large vulnerability. DMA allows the GPU to access system memory independently of the CPU. Since the CPU does all the memory protection, this DMA would bypass any type of memory security and allow unlimited access to system memory. [12] describes how this type of attack has been successfully implemented in the past using a network card. However, our research in this area suggests that it is currently impossible to use a GPU to perform such an attack. This is due to the way that DMA is implemented in CUDA. In order to use DMA, certain asynchronous copy functions are used. The CPU is still responsible for allocating host memory, and this pinned memory is passed to the GPU for use in DMA. This prevents the vulnerability, since the CPU still controls the memory access and the protections are still in place. The GPU can only use DMA to access the memory that was already given to it by the CPU, not any of the system protected memory. It’s possible that in the future the GPU will have more control over its DMA, but at the moment this type of attack is not possible.