Anton Chuvakin

Here is an interesting piece of research just published by another member of SRMS team, Mario Boer: “Comparing Endpoint Encryption Technologies.”

The document “provides an overview of the various technologies available for endpoint encryption and their strengths and weaknesses, thus enabling security architects to revalidate their architecture.” I am highlighting it here due to its relevance to PCI DSS projects as well as overall value for people deploying endpoint encryption for regulatory and other purposes.

While cardholder data is supposed to be safely stashed away on secure servers, it often finds its way to desktops, laptops, tablets and other mobile devices (even excluding the recently-fashionable mobile payment “terminals” made out of iPhones ). Thus the question of endpoint encryption comes to the forefront of both PCI DSS assessment and control implementation projects. In fact, many organizations have endpoints in scope for PCI, for various reasons, and thus likely need to encrypt cardholder data there.

Some of my favorite highlights follow below.

PCI DSS should rarely (if ever) be the sole factor for choosing encryption. In fact, Mario’s document lists two  requirements most useful when selecting encryption:

• “Identify compliance requirements. These may originate from privacy and data breach laws or other sources.
• Conduct a risk assessment that determines the sensitivity of information that is, or could be, stored on endpoints and the impact unauthorized access to such information may have on the organization”

PCI DSS  also drives some of the reporting requirements for encryption solutions. Specifically, “being able to report on the encryption status of a specific device that has been stolen or lost may be essential” for many mandates and regulations.

One of the common challenges when encrypting data for PCI is choosing between full-disk encryption (FDE) and file/folder encryption. The document has extensive discussion of this choice, such as by listing the fact that in one case the encryption is more transparent (FDE), while in the other case it better supports interoperability (file/folder).

And, obviously, there is discussion about dealing with “evil maids” there: “The evil maid has physical access to the device over an extended period of time. This actor may attempt to install malicious software or hardware devices such as keyboard sniffers and can physically analyze or copy the device. The evil maid can use specific results (login credentials) from earlier encounters to access the device”…

Finally, as we say in the PCI book, despite all the encryption considerations “the best way to protect the data for PCI DSS compliance is to delete it.”

2 Comments »

Category: encryption PCI DSS security SRMS     Tags: encryption, SRMS

Share

Tweet