¿En realidad PCI requiere que las informaciones de la tarjeta estén encriptadas en la memoria?

TL;DR

Técnicamente, PCI requiere que los datos del titular de la tarjeta (CHD) se cifren tanto en tránsito como en reposo. Esto puede parecer simple al principio, pero la realidad es que no se vuelve muy específico acerca de la delimitación entre el en disco vs. memoria volátil . Si desea ser pedante, la memoria volátil sigue siendo datos en reposo, pero de acuerdo con la Preguntas frecuentes , no se requiere explícitamente que se cifre mientras está en la memoria. Aunque es bueno señalar que estas son solo las preguntas más frecuentes, no realmente en el estándar PCI DSS. Aquí hay un buen artículo para leer para obtener más información.

Respuesta larga

La razón para el cifrado en memoria tiene que ver con el vector de ataque que raspa la memoria.

  

PCI DSS hace un buen trabajo asegurándose de que los datos de la tarjeta de crédito sean persistentes   el almacenamiento es seguro, sin embargo, dichos datos en el almacenamiento no persistente -   como los archivos almacenados temporalmente en la memoria - todavía pueden ser vulnerables   comprometer, particularmente a través de malware de raspado de memoria. Aprende más   sobre esta amenaza. SOURCE

Puede encontrar más información sobre lo que requiere PCI aquí . El TL; DR de la respuesta larga es que si no cifra los datos en reposo (en el disco o en la memoria), asegúrese de tener controles de compensación para mitigar el Riesgo de pérdida de datos.

  

Si los datos almacenados del titular de la tarjeta no se pueden cifrar, consulte PCI DSS   Apéndice B: Controles de compensación y Apéndice C: Compensación   Hoja de trabajo de controles.

Los datos del titular de la tarjeta no necesitan estar cifrados en la memoria volátil ( enlace ) Se debe tener en cuenta que la capacidad de los datos escritos en la memoria volátil para persistir en el disco puede y va a suceder. El cifrado del archivo de paginación o de intercambio puede ayudar a evitar esto.

Los datos del titular de la tarjeta deben estar protegidos cuando se encuentren en tránsito a través de redes públicas abiertas [Requerimientos de PCI DSS. 4.1] y cuando se escribe en el disco [PCI DSS Req. 3.4]. Los requisitos no son los mismos para cada uno y se dan ejemplos dentro de las PCI DSS. La columna de orientación a la derecha de la norma también suele ser útil.

La versión más reciente de las PCI DSS se puede encontrar aquí. enlace

Para responder primero a la segunda pregunta, ("No veo ninguna razón detrás de esto, si el atacado puede llegar a los valores, también puede acceder a la clave de cifrado, ¿no?") el raspado de RAM disponible en el mercado el malware simplemente sabe cómo identificar los datos de seguimiento en la memoria. No entiende el mapa de memoria de su proceso de registro. No conoce tus estructuras o campos. No intenta encontrar un búfer char * con la etiqueta "Track_Data". Simplemente lee toda la memoria en su proceso y si coincide con un patrón de 15 o 16 dígitos, lo raspa y lo envía al malvado. El software malicioso no sabe qué bytes forman una clave de cifrado, por lo que una vez que sus datos están encriptados, el software malicioso no los verá. (El malware típico no es muy sofisticado, y ciertamente no reconocería datos XOR o ROT-13, y mucho menos un bloque de datos cifrados AES-128).

Tenga en cuenta que los atacantes deben ser sigilosos: si enviaran volcados de RAM de 2GB desde cada caja registradora después de cada transacción, la gente de la red probablemente se daría cuenta. Solo envían la menor cantidad de datos que necesitan, y no intentan descifrar nada.

(Tenga en cuenta que esto es cierto solo para el malware de uso general de raspado de RAM como Dexter y BlackPOS; si hay malware dirigido a una aplicación específica, puede personalizarse para comprender las estructuras de memoria y tratar de robar claves y / o datos encriptados de direcciones específicas. Todo depende de los atacantes.)

-

Tal como se le preguntó, la primera parte de su pregunta casi describe una condición de carrera: ¿en qué punto los datos de la pista se consideran "en reposo"? ¿Es solo cuando aterriza en un disco duro, o puede considerarse en reposo mientras está en la memoria esperando ser cifrado?

Pero ahora tienes que seguir adelante y obtener más detalles. ¿Está en reposo cuando aterriza en los buffers del controlador del dispositivo USB? ¿Está en reposo cuando se publica un mensaje de Windows para notificar a su proceso que se han ingresado nuevos datos de seguimiento? ¿Está en reposo cuando el búfer se envía al algoritmo de cifrado? ¿Está en reposo cuando la aplicación analiza la pista para recuperar el nombre del titular de la tarjeta, el código de servicio, PAN, CVV y la fecha de vencimiento? ¿Está en reposo cuando elimina los últimos 4 dígitos del recibo? ¿Está en reposo si la aplicación está procesando el número de cuenta de alguna manera antes del cifrado? ¿Quizás validar un dígito de control o determinar si se trata de una tarjeta de crédito Visa o de otro tipo? ¿Está en reposo cuando se está construyendo el mensaje de autorización? Ninguna de esas actividades parece que los datos descansan mucho, y muchas de esas actividades son funciones comunes en los sistemas de POS. En total, todo ese procesamiento puede tardar unos milisegundos o más en ejecutarse.

Ahora consideremos a los atacantes del mundo real. El malware utilizado en algunas de las infracciones de mayor nombre fue el malware de raspado de RAM, y es extremadamente agresivo. Puede barrer a través de la memoria del registro cientos de veces por segundo, y disparar en un breve vistazo de PAN o datos de seguimiento. Puede capturar los datos de seguimiento que llegan a los búferes USB, en los buffers de mensajes de Windows antes de que se notifique a la aplicación, mientras se los descompone en las rutinas de análisis, o incluso mientras se invocan las rutinas de cifrado. Incluso si cumple a la perfección con la letra de las leyes de PCI-DSS y la cifra tan pronto como la ve su aplicación, aún es vulnerable a una violación si algún miembro de esta familia de programas maliciosos ingresa en sus cajas registradoras.

En lugar de centrarse en la interpretación exacta del PCI-DSS, es mejor evitar la situación por completo eliminando tantos sistemas como sea posible del alcance de PCI. Si puede, saque los datos de seguimiento de la caja registradora y colóquelos en un terminal de pago separado que pueda cifrar los datos antes de enviarlos a su caja registradora.

Si mueve el cifrado a un dispositivo separado ubicado fuera del entorno de la caja registradora, el registro nunca necesita recibir datos de PAN o de seguimiento de texto simple. Cualquier malware que encuentre su camino en sus registros no encontrará datos de seguimiento para raspar. Y un terminal de pago tendrá una superficie de ataque mucho más pequeña que una aplicación de caja registradora basada en Windows.

No estoy tan familiarizado con los métodos de cifrado utilizados en PCI, pero hay una buena razón por la que uno querría esto. Las operaciones de hardware a menudo pasan por alto la CPU y tienen acceso directo a la memoria (DMA) para aumentar el rendimiento e ignorar los ciclos de CPU innecesarios. El gran poder viene con gran responsabilidad, y la memoria directa IO puede conducir a proezas creativas .

Para darle un ejemplo, las máquinas virtuales, las cárceles y los contenedores separan los entornos entre el host y los invitados. Aparte de lo permitido explícitamente, nunca un invitado debe poder comunicarse con el anfitrión u otros invitados en segmentos de circulación. Si esto sucede, hablamos de un jailbreak. Cualquier dispositivo de hardware que permita DMA puede ser explotado para llevar malware. Se han publicado numerosos artículos sobre vulnerabilidades en el PCI, lo que expone al anfitrión a los invitados.

Análisis de vulnerabilidad de la computación de la GPU, 2013:

  

[31] menciona la posibilidad de atacar un sistema aprovechando la memoria directa   Acceso (DMA) para acceder a la memoria que de lo contrario estaría protegida. Aunque no específicamente   mencionada en este documento, la extensión de esta idea a las GPU representa una gran vulnerabilidad.   DMA permite que la GPU acceda a la memoria del sistema independientemente de la CPU. Desde la CPU   hace toda la protección de la memoria, este DMA pasaría por alto cualquier tipo de seguridad de memoria y   Permite acceso ilimitado a la memoria del sistema. [12] describe cómo este tipo de ataque ha sido   implementado exitosamente en el pasado usando una tarjeta de red. Sin embargo, nuestra investigación en esta área.   sugiere que actualmente es imposible usar una GPU para realizar tal ataque. Esto es debido a   La forma en que se implementa DMA en CUDA. Para utilizar DMA, cierta copia asíncrona.   Se utilizan funciones. La CPU sigue siendo responsable de asignar la memoria del host, y esta anclado   la memoria se pasa a la GPU para su uso en DMA. Esto evita la vulnerabilidad, ya que la CPU.   Todavía controla el acceso a la memoria y las protecciones siguen en su lugar. La GPU solo puede usar   DMA para acceder a la memoria que ya le había sido otorgada por la CPU, no a ninguno del sistema   memoria protegida Es posible que en el futuro la GPU tenga más control sobre su   DMA, pero en este momento este tipo de ataque no es posible.