Protecting Sensitive Information in Memory

POS environments are the most commonly breached entities that exist.

January 25, 2016 • Published by

Memory and the Payment Transaction

Whether it is PAN data (credit card numbers), ePHI, PII or intellectual property, the rationale is all the same; disclosing any sensitive data can be a nightmare for your company or product’s future. This post, however, is focused on cardholder data, because businesses with POS environments are the most commonly breached entities that exist and quite frankly, their average security posture is pretty low.

Once upon a time, using memory to manipulate and transmit cardholder data was enough to prevent actual data storage at the point of transaction as well as protect the transaction itself. However, as developers and application architects have gotten more clever, so have cyber criminals.

Every interview that is held during an IT assessment typically involves developers. Almost every developer has the same instinctual response when asked about their cardholder data environment:

“We don’t store credit card data, we just pass it on to X.”

That doesn’t work anymore. A simple memory dump using command line tools provided by Microsoft can pull plain text card numbers from memory in real-time without any complications. However, developers and their directors seem to be under the impression that as long as the data is in memory, it’s protected. This is one of the single largest root causes of cardholder data breaches.

Why Your Business Must Safeguard Data in Memory

In languages with inherent garbage collection (C#, Java), do you actually know if the unallocated memory is being securely overwritten? Typically, pointer management (done under the hood in these languages) does not securely delete anything; the range is overwritten when reallocated to another function. In other words, PAN data could unexpectedly be in memory.

What about in a language such as C, where memory management is the responsibility of the developer? Do those Malloc() commands actually do anything beyond allocating memory to a function? No. The developer must manually address these things.

Due to garbage collection (or sometimes lack thereof), it is entirely possible to inadvertently store cardholder data in volatile memory, which may then be written to a disk using memory paging. Each instance of PAN within memory must be able to be followed through its entire lifecycle, and this is very difficult to do with machine assisted memory management.

Tips for Data Protection and Devaluation

What should every developer and application development firm be doing with the numbers in memory? First, take steps to protect them from extraction and second, devalue them should a cyber criminal successfully bypass your protective efforts.

Casting your data into SecureStrings in C# (or GuardedStrings in Java) can be used to ensure that the internal memory management only allocates one position in memory for the data. This will help ensure that the location of the PAN data is predictable, and can be managed.

Encryption is another common method to protect and devalue cardholder data, however if it is not initiated at the card reader (i.e., before the POS application) then there will be a brief moment after the swipe and before any encryption method is executed when that data is “in the clear” and can be intercepted.

How many businesses have I seen using end-to-end encryption? Not enough so far.

Get a big picture of your organization's IT security posture.

If your business takes credit card payments, don’t let it be low-hanging fruit for hackers. ControlScan can help. Request more information or give us a call at 800-825-3301, ext. 2.