I run a business that profits from this need to migrate from 2003 Server but it is still worth exploring other avenues…
For those that need to remove 2003 – fine, you know your direction.
For some other companies we meet their server teams are confident they do not need to rush to eliminate the legacy OS, based on other safeguards, data and usage.
Issue: Deciding whether or not to tackle those Windows Server 2003 machines is not a black and white scenario.
A bit of a headache, especially if the remediation work will affect service and necessitate expense on redevelopment. In many situations solutions like AppZero are the answer, virutalise and move the problem without having to revisit the code.
We’ve also made the point that from a technical and delivery point of view these same problems present very interesting and highly challenging work. Trying to dismantle and build systems and introduce new solutions simultaneously across tens or hundreds of workloads is no mean feat.
Windows Server 2003 EOL cannot be treated like XP EOL nor can Mainframes be used as a good reference point (any malware developers out there with a IBM mainframe at home?).
A Shade of Grey
Even though support has now been withdrawn, it appears it isn’t as black-and-white decision to upgrade. It makes long-term business sense to upgrade of course, but to migrate on your terms. Organisations are going to have the same problem with Windows Server 2008 in a couple of years.
So there might be a different approach. Before we make some suggestions, here’s a few things to consider:
Windows Patches are reactive
Microsoft issued plenty of patches whilst was still Windows 2003 supported. But patches are reactive when someone uncovers a problem and we are made aware.
There are probably many vulnerabilities that existed even whilst your servers were being supported by Microsoft.
So were your servers always protected by your security measures?
Malware developers do not attack computers directly
Yes, Malware attacks the computers once they penetrate corporate firewalls so the malware can only be presented in a number of ways:
– Social Engineering
– Remote Code Execution
– Trojan Horse
So would defence in depth ensure servers are protected until you are ready to move?
End-users do not have admin access
Or so we assume. And if we take that assumption further not many people can log-in to the servers. So how much “administrative” or direct use of these servers occurs?
Use of Internet Browsers…
…on a windows Server 2003 machine. Are you serious? Hopefully those applications are simple enough to port to a newer version of ASP/ IIS.
If Social Engineering is a main avenue for malware it makes sense to limit usage of web traffic, browsers and servers on Windows Server 2003.
Use of Internet Infomration Services (on Windows Server 2003)
As above. It may be possible to justify stopping use of these old IIS servers in order to eliminate obvious malware risks
It might be possible to achieve this by either stopping or monitoring usage of IE,IIS and ports 80/443.
Interaction with other servers on the network
If your 2003 server(s) interact with critical servers you either have to change, monitor or segment this traffic. When you reach the need to segment the network it is looking very similar to a PCI DSS configuration.
Solution: Segment network and “protect” servers. Categorise servers / Segment network similar to PCI DSS / deal with the “at risk” servers.
An approach could be to enforce a number of controls against the “unprotected” server estate until your business is ready to migrate onto a modern platform, or until Windows Server 2016 has been released.
For this to be effective real-time monitoring of this compliance state would be necessary.
With this in mind the following recommendations might work in conjuntion with each other:
- Remove 2003 servers in the DMZ / at risk
- Maintain malware protection
- Maintain Firewall Protection
- Categorise servers as it non-risk / at risk
- Potentially segment the network as you would with PCI DSS
- Manage remediation of the at-risk solutions
- Monitor the servers that are deemed not at risk and they stay that way
- Track who has access to the servers
- Track or disallow usage of the IE process
- Track or disallow usage of the IIS process
- Track usage of Port 80
This might seem a lot to do but it may be a lot less than an upgrade programme and it might give you the runway to deal with the application problems in more strategic fashion. it also gives you a strategy and time for Windows Server 2008.
The obvious issue with this approach is it does not follow industry recommendation. But it provides a temporary approach that can be compared with the two other options which are to either (a) do nothing at all or (b) run a complete upgrade programme.
The issue with temporary appraoches are they become permanent.
Appreciate there is some level of assumption with this approach, but better tan doing absolutely nothing maybe?
The approach touches concepts similar to desired configuration state which is not built-in to Windows Server 2003.
It is likely you can reach out to people with PCI DSS experience who can advise how to segment your environment.