Windows Server 2003: End of the Road

It’s the end of Windows Server 2003 as we know it. Do you feel fine? asks Johna Till Johnson

Unless you’ve been living under a server rack for the past three years, you’ll be aware that on 14 July Windows Server 2003 reaches its end-of-life. Microsoft will no longer provide general support, bug fixes, or security patches for the OS. The company will no longer even report on security flaws in WS 2003, and will cease to update or support the endpoint security tools offered for it.

If you’re among the estimated near two-thirds of organizations (according to App Zero) that still have WS 2003 in your enterprise, it’s not too late to take action. You have more options than you may realize, but it’s imperative to tackle the problem now.

There are three main issues that will hit on 15 July. First is security; unsupported WS 2003 machines will create a huge vulnerability in your enterprise. As of early June, there have been 25 documented WS 2003 vulnerabilities in 2015, compared with 26 in total in 2014. These range from denial of service (DoS) vulnerabilities to buffer overflow to code-execution issues. So far, they’ve been patched, but that’s not going to happen going forward.

And hackers know it: they’re already going into high gear locating vulnerable servers.

“We’ve seen an uptick in scans, of hackers trying to take inventory to find out who’s running these systems,” says Chris Strand, senior director of compliance and governance at endpoint and server security firm Bit9 + Carbon Black. So the chances are extremely high that your systems will be hit in the 30 days immediately post end-of-life.

But it gets worse. The second major issue is compliance. Virtually every organization is subject to regulation – such as PCI, HIPAA, or Dodd-Frank – and most regulations require vulnerabilities to be patched within 30 days of discovery, something that’s not possible if patch updates aren’t happening.  

Moreover, if an organization is running outdated or unsupported software, it can be subject to additional fines and penalties. So regardless of whether your systems are actually compromised, you’ll fail your next compliance audit.

Finally, there’s the issue of cost. The cost of supporting an obsolete OS is high and will keep on rising, based on everything from the extra work required to keep the system running to the outmoded hardware it’s likely running on. And for enterprises large enough to negotiate a custom support agreement (CSA) with Microsoft, fees can be exorbitant, starting at $1500 per server per year, and compounding annually. (And note that CSAs are only available to organizations that already have a remediation plan in place).

Supporting the WS 2003 operating environment will continue to be a slow drain on your resources, consuming time and effort you could have devoted to something else. The bottom line is that inaction is both dangerous and expensive. This is one deadline you can’t afford to ignore.

What’s The Plan, Stan?

There are several remediation strategies for the WS 2003 end-of-life issues. The most obvious fix is to migrate applications off it. But to where? One option, of course, is to migrate to later OSs, most likely WS 2012.

Another is to take the opportunity to move to the cloud, specifically Microsoft’s Azure. The challenge is that there may not be enough time. Re-architecting applications to run on a different OS (or porting them to the cloud) takes planning and effort. Apps still running on the old system are often hard to uproot, rewrite, or replace for a variety of reasons: close customization to the OS; a lack of application vendor support; or a lack of in-house staff to do a rewrite. So unless you have relatively few applications, migration is probably not a near-term solution.

Another approach is to replace your old applications entirely, relying on software-as-a-service (SaaS) or other solutions. For instance, rather than porting your elderly custom CRM application to WS 2012, you might opt to transition to, say, Salesforce. 

Moving to SaaS is an option that IT professionals should seriously consider, ideally as part of an overarching cloud strategy. But once again, timing doesn’t permit this approach as a quick fix.

What’s left? You could attempt to isolate and protect systems by segmenting behind firewalls, load balancers or other systems that can filter connectivity. This will improve security from low-level and external attacks, but will be less able to protect from application-level attacks that exploit previously undiscovered OS-level flaws, or threats propagating within the protected space. This approach also has the weakness of making systems and the applications they support less reachable by the lines of business.

At the extreme, systems can be placed off-net entirely. This could apply in some healthcare, manufacturing, and other scenarios, for example when a system controls a machine tool or a piece of lab equipment via a dedicated or embedded 2003 server. However, the number of systems that can actually operate off-net is shrinking fast as systems increasingly depend on connectivity.

What’s left? Fortunately, many security vendors have developed security products that use ‘defense-in-depth’ techniques such as virtual patching, application control, endpoint control, and ongoing monitoring to keep the servers protected beyond the end-of-life deadline.

Beefing up security by implementing such systems has two advantages. First, it buys you time to develop a more overarching strategy that covers not only WS 2003 but all your computing platforms. Most likely this will involve some combination of infrastructure-as-a-service (e.g. Azure), software-as-a-service, and private cloud. Since it’s a big shift, you’ll want to take your time planning and executing this strategy.

Second, moving towards a defense-in-depth strategy will increase your overall security stance. If you’re still relying on protecting your systems by strengthening your perimeter, your security architecture is seriously out of date. Moving to a defense-in-depth approach will more effectively protect your entire enterprise, not just your obsolete WS 2003 machines.

Putting It All Together

So if you’ve still got apps running on WS 2003, what should you do? The answer depends on your environment. If there aren’t many, and they aren’t a critical part of your environment, you can migrate them to WS 2012 or Azure. Or, you can replace them with a SaaS solution, assuming your WS 2003 environment is sufficiently contained for this to be feasible in the few days remaining.

If your environment is more extensive than you can handle via migration or replacement, you can segment the servers (or take them offline entirely), assuming this doesn’t affect usability. Note, however, that this is strictly an interim fix: you’re still liable from a compliance standpoint, and you’re still vulnerable to some forms of attack.

You could also invest in defense-in-depth solutions that provide both protection and compliance validation. This approach buys you time, and also moves you in the right direction from a security standpoint.

Assuming you opt for a solution other than migration or replacement, how much longer should you plan to keep your WS 2003 machines operational?  The answer once again depends on how heavy your dependence on WS 2003 is. If your environment is extensive, you should accelerate your migration or replacement strategy, because securing and managing an obsolete OS (and its associated applications and hardware) is likely costing you quite a bit. If your environment is more limited and/or self-contained, you may be able to support the servers for longer.

A good rule of thumb is 30 months on the outside. That is, regardless of your situation, you should be off WS 2003 by 2018. Many of the security vendors won’t commit to supporting the platform beyond 2018, and even if they did, it’s almost certain that your hardware and overall architecture will be obsolete.

And remember, that’s the outside: if you can wrap up a migration or replacement strategy by the end of 2015, so much the better. You’ll have more time, energy, and resources to focus on doing something truly innovative for your organization.

Taking action doesn’t necessarily mean an emergency forklift upgrade. There are plenty of options for buying yourself time and staying protected and compliant.

Options for WS 2003 EOL Remediation

• Server migration – Migrate your applications to up-to-date servers, most likely WS 2012. Consider this if you have a limited number of servers and do not yet have a cloud strategy in place.
• Cloud migration – Migrate your applications to IaaS cloud services, most likely Azure. Consider this if you have a cloud strategy in place, and application migration makes sense in that context.
• Application replacement – Replace your applications with more modern ones, including SaaS. Consider this if you have a cloud strategy in place, and application replacement makes sense in that context.
• Segmentation – Move your WS 2003 machines behind firewalls and gateways, or in an extreme scenario, take them offline entirely. Consider this if there is a limited set of users accessing applications, but remember you won’t be protected against app-layer threats or compliance concerns.
• Augment with defense in depth – Add defense-in-depth technology to your security arsenal. Look for products that can provide real-time monitoring, centralized logging and enforcement, compliance, and the ability to integrate into your strategy going forward. Plan a gradual migration away from WS 2003 over the next six to 30 months. 

This feature was originally published in the Q3 2015 issue of Infosecurity – available free in print and digital formats to registered users