I had the pleasure of reworking the patch management strategy for a Fortune 500 during my stint as a management consultant. One surprising response I’d get from application owners when questioning them about their patch strategy was around appliances. The company had developed this magical exception for patching appliances. The universal response when asked about appliances patch management, was that the system was a hardened Linux kernel. The logic? Since it was a hardened Linux kernel and maintained by the vendor there was no need to worry about patching.

If the appliance was built on a self-updating distribution such as CoreOS then the argument might be able the fly. An external auditor could at the minimum query the box for the Linux kernel and cross reference that to a CoreOS release history.

However, these systems were not built on something like CoreOS and I’m sure not all of the appliances ran a hardened version of Linux. I just don’t have faith in the wide ecosystem on independent software vendors. Some of these appliances are built on just a stripped down version of Linux that’s only running the bare minimum packages to support the appliance. Others may not have done this minimum level of hardening. Even running minimum services doesn’t equate to hardened kernel.

Enterprise customers need to understand what’s running in their data center. I know this causes pain. It’s difficult to track down every version of Linux running on every virtual or physical appliance within a data center. However, if you are going to put a device on within your trusted data center network then you better understand it’s complete profile. I’ve picked on Linux, but the scope should include all appliances. I once had to struggle to remove Code Red from a copier that ran some type of embedded Windows NT.

A good place to start is understanding what version of Linux is running, what services are enabled and how the device receives OS updates (not just application updates). I like to peel back the onion a little with vendors I engage. I start by asking about the history of updates and how vendors handled mass vulnerabilities. Look for details such as release notes on related to the Linux kernel. If there aren’t release notes regarding the kernel running on the appliance, then it’s a red flag to a good auditor.

Auditors are trained to trust but verify. It would do enterprise admins well to follow the same advice. If a vendor says that their platform is secure and updates are frequent, do the due diligence and find out when and how. If a device phones home for updates and your organization had disabled FTP or Internet access, discuss how out of bound notifications and updates work.

At the end of the day only you can prevent vulnerabilities from entering your data center!

Don’t let Linux appliances compromise security
Tagged on:

One thought on “Don’t let Linux appliances compromise security

Leave a Reply

%d bloggers like this: