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!  

Adam Evans, CISSP

About Adam Evans, CISSP

Adam is a seasoned cybersecurity professional with more than a decade of experience in the MSP industry. He started his career as a helpdesk engineer and worked his way up through various technical roles to specialize in cybersecurity – specifically GRC, security architecture, and defensive operations. 

Adam is passionate about sharing his expertise and insights with the next generation of security professionals. He believes that by working together and sharing knowledge, we can make the world a safer and more secure place for everyone.

Connect with Adam on LinkedIn: https://www.linkedin.com/in/grcadame/

Previous
Previous

What is an Example of an IT Service?

Next
Next

What Is A Firewall And Why Is It Important?