Legacy Operating Systems and Compliance Mandates
We’re going to take a moment to talk about legacy operating systems and compliance frameworks. Before we get into the technical details, let’s define what we mean by a legacy operating system.
A legacy operating system is defined as a platform that is no longer used due to the availability of newer or updated versions. Legacy operating systems often are no longer supported by their creator – which also means they do not receive product patches or security patches.
An additional byproduct of end-of-life systems is that other companies that make software eventually stop supporting their products on those platforms – such as Antivirus / Antimalware manufacturers, remote management tools, and other critical applications.
Aside from legacy systems being listed on the CISA bad practices list, legacy systems introduce risks to an organization’s compliance obligations. Here are a couple examples:
"Flaw Remediation - Identify, report, and correct information and information system flaws in a timely manner. FAR Clause 52.204-21 b.1.xii. NIST SP 800-171 Rev 2 3.14.1"
"Perform Maintenance - Perform maintenance on organizational systems. NIST SP 800-171 Rev 2 3.7.1"
“Install valid security patches provided by the vendor to ensure that all system components and software are protected from known vulnerabilities. PCI DSS Requirement 6.2.”
“Ensure authorized software is currently supported. CIS 2.2”
“Perform automated operating system patch management. CIS 7.3”
“Perform automated application patch management. CIS 7.4”
The above controls are a sampling from multiple frameworks we encounter on a routine basis. One key thing we can observe is the common trend across each framework – namely that patching operating systems and applications is critical for compliance. Furthermore, each compliance framework also includes requirements for additional security tools (e.g., antivirus) that may no longer be supported on these platforms.
Unfortunately, this means that operating systems that do not have patches available may not be adequately secured and thus constitute a risk to an organization’s compliance obligations.
“But we still use this” or “well this is only used to access historical information.”
We’ve heard these two statements time and time again and completely understand the business cases for them. Fortunately, the folks that write the compliance frameworks have as well. This is where we can introduce something called a ‘compensating control.’
What is a compensating control? Well, simply put it’s a control (usually pulled from elsewhere in the compliance frameworks) that compensates for the inability to comply with one of the objectives. Unfortunately, compensating controls may require changes to company workflows and the implementation of various technologies to achieve success.
If you have questions regarding your end-of-life systems and want to discuss your options, please reach out to us for assistance!