CVE-2018-13379 was the top vulnerability of 2022. It’s a Fortinet SSL VPN vulnerability that the company fixed four years ago, in May 2019.
So, when someone tells me that they have OS updates or vulnerability patching under control, I’m understandably skeptical.
Can you imagine not updating a device more frequently than every 3 or 4 years? That’s what’s happening to those who are still exposed to this Fortinet bug. And, it’s not by any means limited to Fortinet. Late last year, Cisco issued a press release about patches that had been available for a year, trying to get customers to update.
People just don’t update their software. Why?
Why is updating network or security devices so hard?
- It’s unclear how CVEs map to a company’s actual inventory, and it’s easy for devices to fall through the cracks. This falls into the category of motivation. If companies realized they were vulnerable, they’d patch. However, they often don’t realize. They can track CVEs, they can track inventory, but they need a way to correlate CVEs to inventory, and do so in a way that takes manual inventory tracking out of the equation to avoid errors. It’s too easy for any individual device to be forgotten, especially when it “just works”. For the Fortinet vulnerability above, companies have hardware that they haven’t updated in 3 years or longer. It makes me wonder if they know the devices exist well enough to have a solid backup or contingency plan in case of a failure.
- It’s an administrative task, so doesn’t get prioritized. In the past, software updates were mostly driven by new features. However, more recently as the number of CVEs have increased, updates are driven more by vulnerability patching than new features or enhancements. However, the process of updating or patching devices is still considered an administrative task and not a security task. Organizations need to adapt to the new threat landscape and ensure that updating device OS’s is given the priority it needs… and of course, we recommend investing in the right automation tools to make updates as non-intrusive as possible. Many of our customers have automated updates and eliminated the need for teams to be on-site on nights and weekends. This is a big win for them.
- Updating devices is not a risk-free activity; new device OS versions need to be regression tested. It’s easy to say “update the device”, without considering the implications. Some companies have policies not to be on the latest version of anything (but if it’s the latest version that has the vulnerability fix…). Regardless, it’s important to test anything before it’s put into production. That takes time.
BackBox addresses these three reasons with a important capabilities:
- We can map vulnerabilities to actual inventory.
- We score vulnerabilities and overall risk to give hard data that can be used to prioritize updates.
- We integrate pre- and post-checks to updates to validate that updates are working as expected; these automations can be used in a pre-production environment as part of testing new releases as well as during the actual upgrade process.