IBM Security Services PCI Blog
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  security website ibm compliance solutions pci iss 759 Visits
Most working with PCI DSS and PA-DSS compliance are very familiar with the requirement to securely delete cardholder information and cryptographic materials once the data is no longer needed. Examples of such a requirement include:
3.2 If sensitive authentication data is received and deleted, obtain and review the processes for deleting the data to verify that the data is unrecoverable.
…and from the PA-DSS v1.2
1.1 If sensitive authentication data (see 1.1.1–1.1.4 below) is stored prior to authorization and then deleted, obtain and review methodology for deleting the data to determine that the data is unrecoverable.
This requirement is based upon the fact that simply deleting files from a Windows or Unix file systems does not completely purge the information from the hard drive or partition. During a delete operation, typically the metadata of the file is altered such as the file pointer, etc. has been altered, however, the actual data itself may still be resident in part or even whole. Currently, computer forensics professionals have various tools and techniques available to recover parts or all of the data contained with files that were simply deleted by the operating system. So the real question becomes how can sensitive data that is no longer needed be securely deleted, or in the very least, rendered such that is no longer ‘recoverable’ as described the above requirement from PCI DSS? To obtain some guidance regarding this issue we can review another section of the PCI PA-DSS v1.2:
1.1.4 Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations.
Now this sounds fairly straightforward; one simply obtains a commercial product or open-source software tool that has the capability to over-write consecutive binary data elements (usually all “1”’s or all “0”’s) over all the locations where the file contents were stored on the hard drive or partition. One directs the product or tool at the target files and enables a secure delete, “shred” or other function that consecutively over-writes the previously sensitive data numerous times. Problem solved, work is done, and case closed, right? Well, not necessarily.
While performing a PA-DSS assessment of the MainStreet Softworks payment processing application Monetra (which was ultimately found to be compliant by the way) IBM ISS PA-QSA’s were introduced to an interesting twist to the problem of secure file deletion. MainStreet Softworks CTO, and Senior Engineer Brad House revealed to the on-site QSA’s that it is extremely difficult if not even impossible to securely delete files from many modern file systems, especially what’s known as a Journaling File System (JFS). Brad has even written a technical paper addressing this issue in detail that even includes proof of concept code to prove this assertion.
What is a JFS? I am glad you asked. According to Wikipedia the definition of a Journaling File System is as follows:
“A journaling file system is a file system that logs changes to a journal (usually a circular log in a dedicated area) before committing them to the main file system. Such file systems are less likely to become corrupted in the event of power failure or system crash.”
Most, if not all Unix systems provide several options for file systems and many utilize Journaling. In addition most recent incarnations of the Windows Operating system also provide some JFS capability. As such, if systems that store, process, or transmit PCI cardholder information are built upon JFS systems, then attempting to securely delete sensitive authentication data and cardholder information becomes almost impossible. Even if one tries to implement some a tool or software technique to overwrite sensitive data within a JFS, there still is a probability that some, if not all of the data can be recovered using forensic tools and techniques.
So what can be done to be done to ensure the PCI compliance of credit card payment processing systems that are built on systems using JFS?
Next Post – Meeting the Spirit of PCI With Secure Delete
Andi Baritchi 27000216AA email@example.com Tags:  card compliance security dss credit cardholder iss pci 2 Comments 554 Visits
In today’s challenging economic landscape, clients in every vertical are looking harder than ever to lower costs and maximize ROI. It’s a delicate balancing act between tactical and strategic – one we often see left unbalanced.
In order to be successful, a security program must be:
All cost centers, including security and compliance, have been made prime targets for CFOs’ slash hunts. The most common mistake we’ve observed in such times is to shift security and compliance to a tactical-only paradigm. This shift may save costs in the short term, but chops ROI at the knees in the long run.
For example, building a security program for your organization wholly around PCI DSS compliance is a sexy, but fallacious idea. A security program built on top of the DSS is totally dependent on the Standard – you’ll have to re-think your security strategy every time the PCI Security Council issues an update (and/or clarification). Same goes for any other reg.
Before you ask us the question, I don’t have the budget to get an A in security – I just need a C in compliance, consider the consequences of building a security program that hyperfocuses on compliance.
To contrast, say you implement a sound security framework that, as one of its core dimensions, addresses cardholder data security and PCI DSS compliance. Other dimensions may address your company’s other regulatory, security, and privacy vectors – such as SOX404 compliance, web 2.0 threats, and so on. All the elements of this comprehensive security framework, if designed properly, will work together to keep your and your customers’ data secure. Compliance will just be a natural byproduct.
As a final thought, remember that any standard, whether it’s religious, regulatory, or simply an internal rule, can only be effective once all stakeholders understand and adopt it both in spirit and in function.