Microsoft has a page called How Microsoft Dynamics RMS can help with PCI compliance. They advertise it as current guidance.

IMPORTANT! This document applies to Microsoft Dynamics RMS 2.0 Service Pack 2 and has been reviewed and updated for Feature Pack 1 in August, 2010.

Unfortunately, it might not be a source you can rely on for PCI. Take the wireless section for example, which has a soft recommendation about encryption:

If you choose to use wireless connections despite the fact that these connections are not supported for Microsoft Dynamics RMS database communications, make sure you are doing so in accordance with PCI requirements. For example, you should change the defaults on your wireless modem or router. These defaults might include (but are not limited to) the wired equivalent privacy (WEP) keys…when capable, enable WiFi protected access (WPA and WPA2) technology for encryption and authentication.

WEP is not allowed at all. It should not say “when capable” but rather that the stronger encryption is required. At least as far back as the summary of changes to PCI DSS in the summer of 2008 everyone was warned that WEP would be disallowed. New deployments have been banned from using WEP since March 2009 and all WEP use had to end after last June 2010 for PCI compliance. This document says it was last updated in August 2010…

I could go on but I hope it’s clear that this document should not be seen as a primary source for PCI compliance configuration using Windows XP. So let’s get straight to the title of the blog post.

Microsoft has written on this one page that System Restore on Windows XP violates PCI compliance.

If you are using Microsoft Windows XP, turn off System Restore. The restore points saved by this feature are not PCI compliant. For more information, see Knowledge Base article 310405.

Why?

What restore points are not PCI compliant? I would like to see more information on how the restore points saved are not PCI compliant.

One might assume that their link to the Knowledge Base article will explain. It does not. The title of the Knowledge Base article is “How to turn off and turn on System Restore in Windows XP”. It gives five steps to turn off and four steps to turn on System Restore. It does not use the acronym PCI once and says nothing about compliance requirements or risk for sensitive data.

Dead-end. So I thought maybe I could find the information in the PCI PA-DSS itself.

Requirement 2.1.a is where you will find that an Implementation Guide must list locations that a payment application stores cardholder data. The version 2.0 of PA-DSS has added clarification recently that the Implementation Guide must have “Instructions for configuring the underlying software or systems (such as OS, databases etc.) to prevent inadvertent capture or retention of cardholder data. For example system backup or restore points”.

System backup or restore points may include cardholder data. A PA-QSA should verify that cardholder data is not included in any backup. This still is not a requirement to turn off System Restore. Again, it is not a requirement for compliance, but an example used for clarification, which begs further research.

With this in mind, I searched and found an Implementation Guide posted online with a paragraph about restore points.

Windows provides the ability to create system restore points. Unfortunately, this can cause remnants of memory to be permanently written to the hard drive. Credit card transactions will sometimes write items to the volatile memory of the system, and the system will in turn write these items to the disk in the file(s) containing the restore point information. Therefore, in order for any Windows XP system where the RezOvation application will be running to be compliant with PCI DSS 1.2 and PA DSS 1.2, it is mandatory that restore points are disabled.

That seems to be the best clue so far. It reads to me as though they meant to say turn off the System Failure CrashDumpEnabled option. This is a different function than System Restore. Could it have been an error or typo?

System Restore does not control or save volatile memory. It actually makes me wonder who would design a restore point with volatile memory information for hours or even days? Hibernation mode makes the most sense. System Restore has a different purpose — it preserves system files and related settings so they can be called back when a new version of the file causes system instability.

Microsoft’s description is that the function in Windows XP is based only on a file filter that watches changes in a certain set of file extensions, and then copies them before they are overwritten. Microsoft TechNet says the following are the only items stored using System Restore:

• Registry
• Files in the Windows File Protection (Dllcache) folder
• Local user profile
• COM+ and WMI Databases
• IIS Metabase
• Specific file types monitored

It looks like a static list. Unless I have misread, I see no volatile memory content listed. Microsoft’s MSDN gives a complete list of file types monitored, also without any mention of memory or compliance.

Perhaps the industry discussion around System Restore related to virus reinfection somehow has been conflated with turning off System Failure memory dumps. A goal to prevent large snapshots of memory being left in a file on the drive has become a suggestion (not a requirement) to turn off a file filter and save utility.

I am not opposed to the idea of turning off System Restore (never really liked it myself for a number of reasons) but I find it odd to see it popping up into a compliance standard when there is no clear and official technical industry or vendor explanation.

The requirement, as I read it, is to not store cardholder data where it may be backed up (the Registry, local user profile, etc.). Otherwise the standard could be interpreted to say any system backup service is not compliant because it may back up cardholder data. Instead, a PA-QSA should verify that cardholder data is not included in any backup. I do not see the a requirement to turn off System Restore.