Recently a handful of companies reported being bitten by the Accellion bug. That’s the one where a 3rd party file transfer system was subject to an exploit, which led to customer data being revealed and, in some cases, more serious complications. It highlighted a couple of issues, such as relying on 3rd party applications that may not be entirely secure, and the potential pitfalls of keeping systems in service that may be well past their prime. It’s time we talked about best practices for retiring your legacy kit.
While Accellion identified the issue and patched fairly quickly, which is a Good Thing™, the bad guys moved fast enough to leverage the exploit before it was deployed across the entire user base. The thing is, Accellion themselves acknowledged that the affected product was nearing the planned end of life which implies that it would be out of service reasonably soon in any case.
Not Just 3rd Party
On a similar note, the recent attack on a water treatment plant in Florida was against a system that’s running Windows 7. With an equally old application running the water treatment plant. Whether that was close to end of life I don’t know, but Windows 7 is well past its prime. Though, to be fair, Microsoft is offering Extended Security Updates for Windows 7 Pro and Enterprise for purchase to the people who insist on keeping it in service a little while longer.
The common thread here is that application software and the operating system it runs on has a finite life cycle. While it varies from product to product and OS to OS, they all have a “Best Before” date figuratively stamped on them somewhere. The same goes for hardware, though not for exactly the same reasons.
The SDLC Includes EOL
With software and operating systems, the developer has this continuous improvement life cycle thing going. There may be some features added incrementally, but there are always a lot of bug fixes, security and stability improvements, and a host of other “fixes” that happen between initial release and the eventual end of life.
Eventually, with applications, there have been enough changes that a whole new version comes out to replace the old one. With operating systems, it’s similar, but there are often entirely new features, hardware support, new user interfaces, and sometimes an entirely new kernel under the hood. But in either case, the application needs to be upgraded or the OS replaced.
Hardware Has a Shelf Life Too
Hardware follows a similar path as well. New chipsets. New CPU’s. Faster and cheaper memory. Bigger and better mass storage. More compute burning less power and dumping less heat into the datacenter. Not to mention that there are occasionally security risks associated with the hardware and the only way to remedy the problem is to replace the kit.
Which brings me, finally, to the subject of this blog: retiring your legacy kit.
So . . . When Do I Swap it Out?
I started in IT as a System Administrator before moving into Information Security. Which means I had my hands in a lot of hardware swaps, upgrades, migration plans, and executing to the contingency plan when things went pear shaped. Which they sometimes did. Even when we had everything planned out in advance, and had the equipment staged and had consulted with all the stakeholders and subject matter experts on the kit in question, things sometimes went wrong.
Which is why you plan, of course. You plan so things don’t go wrong, but you know what to do when they do. Creating an effective plan takes practice and a bit of experience – and knowing what the best practices are for retiring old kit and replacing it with the new. Which is what our webinar presentation is about.
Security is a Reason on its Own
Being we are a cybersecurity company, there is also the security aspect in why you should be retiring your old kit. It’s not just about new features and saving on your heating and AC bills. There are some real-world security risks to keeping that old kit in service past its prime, as the Accellion and Florida water treatment breaches highlight.
Yes, there are some cases where there really is no replacement or realistic alternative – like an ancient audio encoder the local radio station relies on – but the reality is that most organizations have kit that they can and should either replace or retire.
Fortunately, one side benefit of how the Gurucul Risk Analytics (GRA) platform does its security analytics, is that you already have the information you need to track down the old kit in your environment. Even if it isn’t vulnerable to some exploit that’s raising its risk score enough to trigger an alert, the information on what OS it’s running, what applications are running on it, and who’s accessing it, are all there to find with a simple search.
Worried there may be an old Novell server walled into a closet somewhere, or maybe an audio encoder running on Windows Vista? GRA can show you it exists and where it lives on the network.
Watch the Webinar
Watch our webinar to take a look at the best practices involved in retiring that old kit.