What’s the problem here?
Introduced in 1996, Microsoft’s Windows NT 4.0 operating system was originally designated for obsolescence on December 31, 2003 but support was extended for an additional year. As of December 31, 2004, Microsoft stopped releasing security patches for Windows NT 4.0. That means that any vulnerability discovered in the platform after that date will NOT be fixed.
At least one vulnerability to a denial of service attack, MS03-010, is recognized by Microsoft as affecting NT 4.0 and received no hotfix patch. Microsoft cited the following in this instance: “The architectural limitations of Windows NT 4.0 do not support the changes that would be required to remove this vulnerability.”
Consider for a moment the myriad of vulnerabilities discovered in the Windows platform in 2005, 2006, and beyond. Suppose that 25%, 50%, or 75% of these vulnerabilities also affect Windows NT 4.0. Isn’t it possible that worms targeted for other Windows platform systems might also affect Windows NT 4.0? What about a specially designed Windows NT 4.0 worm?
Due to the number of organizations still harboring legacy NT 4.0 systems, a well-planned worm designed to attack Windows NT 4.0 systems could cause widespread destruction. Fortunately, there are ways we can mitigate these risks.
The ideal solution to this problem is simply to replace the Windows NT 4.0 systems. In many cases they can be upgraded directly to Windows 2003 Server and omitting the Windows 2000 intermediary step will prevent having to repeat the process again when Windows 2000 support ends on July 13, 2010.
However, you might decide to take a step backward and re-evaluate the legacy system from a business perspective. Perhaps the functions supported by the legacy NT 4.0 system are obsolete and can be jettisoned altogether? That would simply require notifying any remaining users of a sunset timeline and decommissioning the system. Your investigations might also uncover other non-Microsoft based solutions that support the functionality currently powered by the NT 4.0 system. If these new solutions are active open source projects you may find a path away from planned obsolescence.
Suppose your Windows NT 4.0 systems run an application that is only used by a small subset of personnel, would be prohibitively expensive to upgrade or replace, and won’t run on modern operation systems? If that’s the case, then we need to do the best we can to isolate the legacy NT 4.0 systems to isolate any risk of damage or interference to the rest of the network.
The lowest budget way to handle isolation is typically through VLANs and access control lists. Users of the NT 4.0 legacy system should be added to the same VLAN as the Windows NT 4.0 systems. However, this can often be cumbersome to manage, especially with users in multiple locations and interaction with other enterprise infrastructure, such as backup and anti-virus systems.
For another low cost solution, consider reusing old VPN hardware to create an isolated internal network for the legacy Windows NT 4.0 systems. Your decommissioned VPN hardware may no longer have enough horsepower to serve the entire enterprise, but it will probably perform adequately to allow a small to medium number of users to access the NT 4.0 legacy systems.