In this blog post, we discuss the use of end-of-life dependencies/components/software within a FedRAMP compliant environment. This applies to all impact levels with Medium and High impact levels being more stringent.
tldr
Though FedRAMP does not explicitly call out end-of-life software, their use in FedRAMP environments can be heavily scrutinized and discouraged by the AO. Any company trying to achieve a Medium or High impact level will need to continuously monitor and remediate end-of-life software to be compliant.
How does using EOL software affect FedRAMP compliance?
Control SI-2 (Flaw Remediation)
The organization:
- Identifies, reports, and corrects information system flaws;
- Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
- Installs security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates; and
- Incorporates flaw remediation into the organizational configuration management process.
This control addresses how companies should remediate security issues. The use of EOL software will put your organization in potential violation of this control. EOL software receive little research from security experts with most vulnerabilities remaining unidentified. EOL software also receive no attention from its publishers resulting in no security patches that can be applied even in the event of a vulnerability is identified.
Control CM-8 (Information System Component Inventory)
The organization:
- Develops and documents an inventory of information system components that:
- Accurately reflects the current information system;
- Includes all components within the authorization boundary of the information system;
- Is at the level of granularity deemed necessary for tracking and reporting; and
- *Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and*
- *Reviews and updates the information system component inventory [Assignment: organization-defined frequency].*
This control addresses how companies should maintain an inventory of all software and components used along with the regular reviews and updates to them to proactively prevent against exploits. Once again EOL software will potentially put you in violation of this control as they have no security updates to be reviewed nor applied by definition. Vendors very rarely issue out-of-band security patches for their EOL software.
Control CA-7 (Continuous Monitoring)
The organization:
- Identifies, reports, and corrects information system flaws;
- Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
- Installs security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates; and
- Incorporates flaw remediation into the organizational configuration management process.
This control addresses how companies should continuously monitor systems for flaws and install security updates within a certain time period. EOL software will directly put you in violation of this control as the vulnerabilities within them are rarely identified but also because it is impossible to install security patches or updates to EOL software.
Control RA-5 (Vulnerability Scanning)
The organization:
- Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
- Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
- Enumerating platforms, software flaws, and improper configurations;
- Formatting checklists and test procedures; and
- Measuring vulnerability impact;
- Analyzes vulnerability scan reports and results from security control assessments;
- Remediates legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk; and
- Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).
This control addresses how companies should run regular vulnerability scans to identify known risks then remediate them within a timely fashion. Once again EOL software complicates adherence to this control. Besides the fact that EOL’s vulnerabilities are rarely identified, EOL software usually cannot be remediated in a timely fashion. Between major version upgrade, total replacement of functionality, or compensating controls, all these options can only be pulled off with careful planning ahead of time.
NIST 800-53
Additionally FedRAMP uses the NIST 800-53 security controls which recommends controls in place to monitor or avoid all together end-of-life software in your software supply chain. We have already discussed in details these NIST requirements in our previous blog post.
How do I comply?
Monitor
Add tools to give your security team full visibility into your software supply chain and cloud environments. It is important to keep in mind that end-of-life software are not limited to just commercial software like operating systems or datastores. They include the dependencies that your engineering teams are using to power your product offering as well such as .NET, Javascript, or Python dependencies. Full visibility also means you can proactively identify EOL issues and plan accordingly rather than react to them ad hoc.
Control
Add controls in place to gate EOL software or dependencies from accidentally being deployed to your FedRAMP environments. With the zero-tolerance for EOL in FedRAMP, it is extra crucial to ensure that your engineering teams are not accidentally introducing EOL software into your FedRAMP environments. Remember that programming frameworks and dependencies can be EOL as well.
Remediate
Addressing EOL issues immediately with your team should be a priority as the paths ahead can be quite limited. As we have addressed above, upgrade, replacements, or compensating controls all take time to execute well. Good visibility into your EOL software landscape will help your team create proactive plans to remediate these issues rather than be caught on the back foot. Creating good remediation plans ahead of time will also paint a more compelling story for auditors on de-risking EOL software usage.