In the course of performing hundreds of risk and PCI assessments, we occasionally come
across a client who is running an obsolete version of a system, application, or device. Normally, when a system has reached “end-of-life,” it is no longer supported. On the surface, this would appear to be a security risk and also a violation of PCI DSS requirement 6.1: “Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release.” Organizations must determine the ideal strategy to address risk associated with using obsolete systems/applications. Short of replacing/upgrading the offending system, there may be more creative means to offset this risk.
There is no one-size-fits-all solution, but here are some potential arrows for your risk-based-approach quiver:
- Are there any compensating controls that would effectively eliminate risk associated by not patching (since systems can no longer be patched)? This may include host-based intrusion prevention, white-listing, real time monitoring of processes and critical files, etc.
- Are there any Third Parties who provide extended support for the end-of-life product?
- What risks are associated with the end-of-life product? Are there any publicly known vulnerabilities? If there are no known vulnerabilities associated with an end-of-life product, it may still be “reasonably secure” …. today. But, unlike supported systems/applications which will provide you with a ‘fix’ once a vulnerability is known, the unsupported systems force you to walk the tightrope without a net. What is secure today may have a vulnerability tomorrow. Consider:
- What can be done to monitor/search for recently disclosed vulnerabilities pertaining to the end-of-life platform. You will need to be extremely diligent in keeping an ear to the track to watch for vulnerabilities associated with that product/system/application and have established processes in place to stay on top of this.
- If possible, risk can be mitigated by segregating unpatchable systems from other critical systems through firewalls and access control lists (ACLs) to strictly control traffic.
- Consider implementing host-based intrusion prevention (HIPS), in-line IPS, in-line proxies, or security gateways.
- Understand what entities can access the system or application in question and lock down those that require access. Also consider beefing up the access controls (such as multi-factor authentication) in general.
- Lock down what the system can do to allow only critical processes needed for running the system and security controls.
- Monitor, monitor, monitor – in addition to file integrity monitoring (FIM), consider implementing controls to monitor all running processes to prevent or alert your team on any unauthorized ones. Also make sure that the system/application is effectively monitored by your centralized monitoring systems.
- Consider performing additional testing to demonstrate that the overall risk associated with a particular vulnerability/obsolete platform has been mitigated (a penetration test for example).
If you do find yourself in a situation where part of your critical environment has reached its end-of-life and your organization may be in violation of PCI DSS requirement 6.1, do the legwork to understand the risk associated with the end-of-life system/application as well as evolving threat landscape. It is possible to prolong the ‘afterlife’ of these systems/applications if you take a thorough, pragmatic, risk-based approach which, in turn, may dramatically reduce risk, alleviate headaches, and help save time and money. If you are unsure whether you are running the most current versions of a system, application, or device, feel free to contact me directly.
To learn more about how Online can help ensure your security program is addressing the most critical threats to your organization, visit our Cyber Risk Resource Center.
Submit a Comment