Now that there has been a Zero Day vulnerability identified in IE that will NOT be patched in Windows XP, we have to ask, “what will it take to get you off XP?” Perhaps the fact that you will not be able to meet your compliance requirements will provide the push you need to upgrade.
Many companies, large and small, have relied on Windows XP for years, and it hasn’t been an issue for compliance. However, all of that changed on April 8, 2014, when Microsoft support for the operating system expired.
To my knowledge, none of the major compliance frameworks have come out with any specific statements or guidance labeling Windows XP as non-compliant. However, even without such overt declarations, an unsupported operating system — by definition — violates some of the core tenets of most compliance efforts.
In general, regulatory and industry compliance frameworks like PCI-DSS, Sarbanes-Oxley (SOX), Health Insurance Portability and Accessibility Act (HIPAA), and Gramm-Leach-Bliley Act (GLBA) don’t call out specific platforms or tools. Compliance requirements are typically written as broad guidelines to provide a baseline for security and data protection without endorsing any specific solution or painting the compliance framework into a corner using technology that might be obsolete next year.
Some requirements might simply specify that the operating system must have the most current patches applied. One could make an argument that as long as any updates for Windows XP up through April 8 have been installed, that this requirement is met, because those would be the “most current” patches available. Such an argument clearly violates the spirit of compliance, even if it doesn’t explicitly violate the letter of the rules.
In some cases, risk can be mitigated through compensating controls. In English, that means that performing more frequent audits of security configurations, implementing additional layers of defense (such as firewalls, file integrity monitoring, intrusion detection / prevention, or other security tools), or including supplemental processes or technologies might be used to reduce the overall risk and stay in compliance.
Tyler Reguly, security research manager for Tripwire, points out that there is no such gray area, however, for PCI-DSS. The PCI-DSS Approved Scanning Vendors (ASV) Program Guide specifies on page 18: “The ASV scan solution must be able to verify that the operating system is patched for known exploits. The ASV scan solution must also be able to determine the version of the operating system and whether it is a version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV.”
Read the full story on techrepublic.com