Why would you? Could you if you had to?
Although Microsoft discontinued support for XP back in April 2014, Windows XP systems are still being used by the millions around the world. It’s a particular concern due to some apparent security laggards in health care, government, and even in the defence vertical. (Perhaps places where low assurance COTS systems shouldn’t ever be used?) Reports of new strains of malware attacking XP systems are still appearing. Of course XP embedded is still being supported, and we heard last week that US Navy just laid out some cash for extended support of XP, so it will be around for a while.
There are some understandable reasons why some enterprises don’t appear to listen to the appeals to migrate. It’s not just about the software expense; there’s new hardware requirements, staff training, business application dependencies, all requiring consideration and budget to pay. In some people’s minds, XP still works – it meets their needs, and there’s also a question of having satisfactory options to upgrade to. Maybe Windows 10 gives an option people are more happy with now? Then there are things that boggle the mind, like the bureaucratic red tape at DoD! So, due to scarce resources and whatever practical difficulties of upgrading operating systems exist, many enterprises will have to live with Windows XP, and be in risk, until there’s budget and the timing is right.
Gartner is now recommending that folks start planning in 2016 for the Windows 7 upgrade, and support for that ends in 2020. So the ideal situation in IT lifecycle management doesn’t always jive with the timetables of those who control the purse strings. Despite not repeating this same scenario in 2020 for Windows 7, there will still be many who drag their feet.
The reality is, that any time a commonly used platform becomes legacy by definition, because the software is no longer supported either by design or by policy, enterprises remain tasked with the already difficult challenge of protecting sensitive data. Vigilant security pros can usually find a few ways to mitigate some of the risk to avoid falling victim to so called “zero day forever” XP attacks. The real problems is in embedded critical infrastructure and medical devices for which there are no patches forthcoming and are attached to networks without any practical stop-gap measures.
In an article on XP risk in health care, “XP Device Support Ends: Now What?“, Dr. Kevin Fu tells us that “XP in hospitals … is a dominant operating system”. He suggests the greatest impacts of using XP in health care might be the following:
“I think the primary risks are going to be the unavailability to deliver patient care. So let’s say you have an admission system for a patient monitor running Windows XP, and then because of a security problem that device no longer can function. It’s making it more difficult to deliver quality patient care, so that can introduce safety risks when you don’t have those devices you normally think are available.
The other issue is one of what we call integrity….When malware gets into a Windows XP machine, which can be a medical device, it’s often a silent infection. You don’t notice; there’s no blinking light on the medical device saying[it’s] infected. Instead what might happen, and what has happened, is the device slows down. It may begin to give false readings. So if it is a sensor device, it may start to give erroneous information to the healthcare professional.”
Kevin Fu may be right in that there isn’t a lot that can be done for medical devices running XP in the short term. The best hope is probably finding real inherently secure operating system options for future devices. He says his workplace tries to select devices they need with the latest model year OSs, but there isn’t a lot that can be done for those in the house now. As far as XP workstations still used in the network he says,
“There may be cases where you can make XP maintainable, but I haven’t yet found one.”
Steve Ranger points out that those running Windows 7 will face similar issues in future, in his article, “When should businesses upgrade to Windows 10?” He tells us that some have no plans to upgrade Windows 7 devices to Windows 10:
“They work, they’re rock solid, and all their drivers are perfectly tuned to the hardware they’re running on…”
Despite such intentions,
“However long it takes enterprises to take the plunge, Windows 10 is likely to become widely adopted, if only because most firms will need to move off of Windows 7 eventually, while the relatively few who did move to Windows 8 will also update sooner rather than later. The pressures that forced companies to migrate off Windows XP and onto Windows 7 will eventually make them move from Windows 7 to Windows 10.
So will we be replaying this record in 2020 for Windows 7? What if software upgrades only had to take place when new versions included innovative features offering improvements in effectiveness, efficiency and value performing business tasks for the business. In other words, what if people didn’t have to upgrade systems because vendor support was ending?
Protecting Legacy (XP) Healthcare Environments
In previous conversations with folks consulting health care institutions regarding IT security, some asked if Trustifier could protect the many XP workstations still prevailing in health care networks, and we can. This is a vertical that’s in trouble. Since some recent posts explain why to use math, KSE algebraic modelling and advanced kernel protections, here, and here, which are the basis for KSE trusted computing, we can use protecting legacy XP as an example of the kinds of things that become possible.
Would you? Could you? What if you had to?
Even though you might not want to, if you had to protect networks of XP computers, could it be done? The first thing that comes to mind with the end of vendor support is no more patches for found vulnerabilities, – the curse of doom in the vuln-by-default and patch-and-pray world. What would happen though, if one could escape the vulnerability-centric model so that systems would have some level of inherent security to remain protected without patching? That’s what Trustifier does of course. We think the following general design would work in a typical hospital environment, but it could also apply to any typical network.
Our suggested solution
The strategy is to ramp up the security of networks using XP by integrating our algebraic model based KSE trusted computing (TC) security into typical service oriented architectures (SOA) used. On the back end, crown jewel data is transferred onto a KSE protected host running on the Trustifier CloudFort trusted computing (TC) security private cloud, and integrating it with Active Directory (AD). Deployed hosts will deliver services under virtual machine control in a full host TC solution in which KSE is running the Open Stack virtual machine manager. XP (or other) endpoints become thin clients via a virtual desktop interface (VDI). Data can be accessed from an XP workstation but KSE is able to keep track of what is being requested and accessed, as well as when, and by whom, with it’s unique user-centric privilege control framework.
Files can also be shared under CloudFort run as a virtual instance; it integrates right into MS office, Sharepoint or a windows environment, and data labelling takes place on it to provide cloud-based MLS.
In terms of a Web services based SOA environment perspective, Trustifier technology is able to ensure full HIPAA compliance because it has the ability to monitor all application conversations going back and forth for safeguarding, protecting data on the fly. Trustifier Fahrenheit WAF technology is built using algebraic modeling and is the first complete langsec based WAF. (There are no signatures used.) When used as reverse proxy Web application firewalls in the network, Fahrenheit is able to intercept all of the conversations that Web apps are having and filter out any sensitive out health care data that is used in unauthorized ways as it flows across the wire. The scope of KSE protection for assurance of HIPAA compliance is very broad.
KSE has always been able to protect most legacy OSs when vendor support ends for some time. For legacy applications, it is possible and reasonable to custom craft (by Trustifier Inc. or by resellers) Parameter Provider Modules (PPMs) to query at a sub-application level, so KSE reference monitors / authorization engine / enforcement engines can monitor behavior status at the application level and act to enforce per user security rules for access and use at the kernel level if required.
Most of this might seem fairly straight forward, but there are some unique pieces of this puzzle that only Trustifier brings to the table, not to mention the algebraically verifiable trusted computing capability and ability to protect systems without patching.
Even easier with the new TUX GUI
Some XP boxes have probably been converted VDI over the last year. To convert hundreds or thousands of boxes might seem a challenge to some. The new TUX GUI will be module-based, and the kit to find XP (or other target) boxes on a network and the VDI module to replicate a VDI copy of workstation systems automatically will be available. With the replicate option, the original system is untouched, but upon launch, users would run off a ghost XP running on VDI, with all of the Trustifier trusted computing assurances supporting the necessary transaction processes and data flows. Patching XP systems will not be required.
Even though you may be able to run XP in VDI format now, you can’t compare the security of all the rest with the level delivered by trusted computing. It’s the whole system design that must be considered. You will need a verifiable root/chain of trust, not just VDI capability.This is what we mean when we refer to the Defender Chain and tailored trustworthy zones ideas. One needs the whole provable chain of trust, and TUX GUI will facilitate this part of the network design work.
Hope for medical devices?
This level of inherent security would apply to medical device security roll-outs facing forward. I’m sorry, but to me the word patch is not congruent with inherent security. Period. Would it not be far easier to institute a rule change than to patch? Assurance of controls preventing device tampering would bring both peace of mind and value to hospitals and consumers alike. And besides, patching is sometimes not even possible! What then? And what’s with running Windows on medical devices? Is this really the best choice? (If anyone ever says your device needs to run AV, run away.)
Surely an OS for any embedded device would benefit from the separation kernel, reference monitor and enhanced trusted computing base providing kernel level enforcement KSE can provide. This would produce devices that are inherently secure and resistant to tampering without the need for patching down the road.
Even though Trustifier security could actually still support XP shops, this doesn’t mean picking up cheap discarded XP systems to fill your networks with. However, this strategy is a pretty good idea even when an OS is being supported, because – 0days, misconfiguration, errors. One could benefit from the Trustifier trusted computing secure back-end or cloud hosts at any time. It would then be easy to accommodate new endpoint operating system rollovers when the budget plan timing was right, with the additional option of extending useful system life well past that the planned lifetime of that XP, or whatever, legacy system. So if an enterprise opted to protect Windows 7 in this way, when support ended in 2020, they wouldn’t be putting themselves at risk if they defer a migration.
Does this mean that system upgrades would become based on software innovations delivering greater business functionality and value, rather than discontinued vendor support?
Hey, maybe escaping the vuln-centric model has benefits!