Outdated software that can't be patched poses a serious risk to your organization's security and compliance. Hackers can exploit known vulnerabilities in such software to compromise your systems, data, and reputation. How can you deal with this challenge in a proactive and effective way? Here are some steps you can take as part of your incident response strategy.
The first step is to identify and inventory all the software applications and components that you use in your environment. You can use tools like vulnerability scanners, asset management systems, or configuration management databases to collect this information. You should also document the software versions, dependencies, licenses, and support status for each item.
Some practical ways I have seen work are:- 1. utilizing a patch management system to track the status of software updates and patches to help identify which software versions are outdated plus how-long it takes for a vendor to push an update. 2. This therefore means you need to also perform periodic audits to verify versions 3. Utilize SAM (Software Asset Management) tools
From an OT perspective, this is often neglected due to the "sensitivity" of the systems being inventoried. Though these systems are more or less static, one can be strict when it comes to inventory of these systems, and follow a strict Change Management Regime, to make sure your Asset Management Database is up to date. And, one should include not only the type of device (HMI, PLC, RTU), but also include the function of the device. Is that PLC running an elevator or reactor? Classify your assets based on criticality and function.
The next step is to assess and prioritize the risks and impacts of outdated software that can't be patched. You can use frameworks like CVSS or NIST to score and rank the severity of the vulnerabilities and the potential damage to your assets, operations, and customers. You should also consider the regulatory and contractual obligations that you have to maintain a certain level of security and compliance.
Risk Assesment help you identify potential risks associated with outdated software looking at factors like exposure to the internet and criticality of the software. Then, prioritize addressing the most critical vulnerabilities based on the risk assessment.
The third step is to isolate and protect the outdated software that can't be patched from external and internal threats. You can use techniques like network segmentation, firewall rules, access control policies, encryption, logging, and monitoring to limit the exposure and reduce the attack surface of the vulnerable software. You should also implement backup and recovery plans to restore the software in case of a breach or failure.
Some legacy systems that cant be protected by modern security controls, should have compensating controls available. This could be administrative control such as room access control to protect against insider threats.
One can also implement additional security controls like firewalls, IDS/IPS to fortify the outdated software’s security. As well, use virtual patching solutions provided by third-party security vendors to add an extra layer of protection against known vulnerabilities.
The fourth step is to replace and upgrade the outdated software that can't be patched with newer and more secure alternatives. You can use tools like patch management systems, software update services, or cloud-based solutions to automate and streamline this process. You should also test and verify the functionality and compatibility of the new software before deploying it to your production environment.
The fifth step is to educate and communicate with your stakeholders about the risks and benefits of outdated software that can't be patched. You can use channels like newsletters, webinars, or training sessions to raise awareness and provide guidance on how to use the software safely and responsibly. You should also inform your customers, partners, and regulators about the actions you have taken to mitigate the risks and comply with the standards.
The sixth step is to review and improve your incident response process and policies for outdated software that can't be patched. You can use metrics like mean time to detect, mean time to respond, and mean time to recover to measure and evaluate your performance and effectiveness. You should also solicit feedback from your team, users, and auditors to identify and implement best practices and lessons learned.
Consistently improving incident response procedures for unpatchable software is crucial. Measuring metrics like detection, response, and recovery times helps gauge and enhance effectiveness. Valuable input from team, users, and auditors guides the adoption of agile best practices. This iterative approach fosters agility, resilience, and adaptability, reinforcing the organization's ability to manage challenges tied to outdated software.
Application whitelisting - use it to allow only trusted applications to run on the system, reducing the risk of unpatched software being exploited.