Risk // Compliance
6/3/2014
12:00 PM
50%
50%

Compliance: The Surprising Gift Of Windows XP

The end of Windows XP will force organizations to properly reinvest in a modern and compliant desktop infrastructure that will be easier to maintain and secure.

I’ve seen countless articles explaining how the end of Microsoft’s support of Windows XP will make companies non-compliant with numerous regulations and laws, especially HIPAA and various regulations in financial industries.

Apparently, not everyone got the memo that technology alone never makes an organization compliant or non-compliant. Compliance standards almost never state what software or computer hardware is required. Upgrading to a new version of Windows may make the boss feel compliant, but technology alone is never the full problem or solution.

Of course, technology used as the basis for any system needs to meet minimum levels of security capabilities. An operating system that will not be updated as new threats develop is certainly a cause for deep concern. At the same time, running the latest greatest computer software, if not set up and maintained correctly, still won’t provide proper security. More importantly, such software will not solve a  problem created when organizations ignore process and procedural issues.

The end of support for Windows XP did not suddenly make XP unsecure. Windows XP has simply reached the point where it is more difficult to keep it secure in a world of ever changing threats. And Microsoft simply made a business decision to no longer work to address future threats in an old program.

There are even instances where Windows XP will remain an acceptable solution in compliant and secure systems. Although increasingly rare, stand-alone computers and isolated networks likely won’t have compliance issues by continuing to run XP, provided processes and procedures are compliant.

The end of XP support does mean that the cost of using XP to remain compliant and secure increased immediately. Other technical and procedural efforts will be required to offset what is expected to be an ever-increasing risk. As a result, it is easier to claim XP is no longer secure and compliant and should be replaced than it is to deal with all the extra effort (and confusing explanations) of the alternatives.

Now for the gift of XP
In 1998, my company worked with a client to replace an ancient customer software program that no longer even met the department’s business needs. The budget for this replacement project was rejected by the large organization’s capital budget committee as too expensive. The business need of the software was apparently not a major factor in the decision.

In 1999, the client modified the budget proposal with only one minor change: The new software would also resolve the Y2K problems present in the old software. This time the project was instantly approved by the budget committee.

Y2K was the key to solving a much bigger business issue for my client. The new software enabled the organization to move ahead in their market, improve their efficiency, better utilize staff, and more easily quote and bill work. The project has paid for itself, but it needed Y2K to get past the short-sighted bean counters.

Flash forward to 2014 and I see a similar situation. Clients with scores of slow, outdated computers have been rushing to not only replace XP, but to replace the computers running XP. The business need for upgrading these computers has been visible for some time, in some cases, years.

Like Y2K, the end of Windows XP support will prove to be a huge benefit for businesses that are finally moved to replace outdated computers. The new computers from these projects will work faster, be easier to maintain, be easier to secure, and provide a bottom-line benefit.

As much as management, including technical management, like to complain about the headaches of problems like Y2K and XP support, without these problems many organizations would fail to properly reinvest in the necessary infrastructure required for compliance, security, and even business success.

Glenn works with business leaders who want to leverage technology and understand the often hidden risks awaiting them. The Founder and Sr. Consultant of Forte' Incorporated, Glenn and his team work with business leaders to support growth, increase profits, and address ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
6/5/2014 | 9:42:04 AM
Re: Interesting Y2K analogy
Great points all! Plus, there's one other difference, that just occurred to me. In the runup to Y2k (1999-2000), compliance regs like HiPAA and Sarbanes-Oxley weren't even on the drawing board. Those laws came into existence later in the decade. 
gphillips35101
50%
50%
gphillips35101,
User Rank: Author
6/5/2014 | 9:33:37 AM
Re: Interesting Y2K analogy
Hi Marilyn, I agree with you that Y2K had much more of a doomsday sentiment and for a number of reasons. Still, XP end-of-support is one of the rate "events" similar to Y2K since Y2K. I have small business clients finally updating computers and our large clients have been even more focused on the task.

There is even more focus in organizations with compliance requriements, where waiting until a refesh cycle completes is not an option. And if they have a proper refresch cycle, they should not have hit this deadline with any XP computers. There is not the general public fear of course but it is still one of the rare events that was not ignored. Thanks!! G
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
6/3/2014 | 3:17:51 PM
Interesting Y2K analogy
Hi Glenn. I take your point that Y2k presented a unique opportunity for organizations to spend money and update antiquated computer systems -- and perhaps the same will hold true for the end of life support for XP. Still, if my memory servers me correctly, there was much more of a doomsday sentiment surrounding Y2k. With XP organizations can ignore and keep using, pull off line, or continue with their traditional desktop refresh cycles until they are fully replaced. 
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.