Secure organizations should have a robust patch management practice and deploy patches as close–to-release as possible. The protective process of patching should be commonplace….as commonplace as wearing a helmet when you ride your bike (PSA for the day). In fact, last year, at one of our financial services clients, we found that patching alone fully remediated about 60% of all vulnerabilities. We see the importance of patching across the industry and how unpatched 3rd party software products can be detrimental to business. In 2019, it was found that close to 60% of breaches were linked to a vulnerability where a patch was available, but not applied – think Equifax. (Security Boulevard, 2019).
So, then, why aren’t organizations patching more? As with anything, there are limitations and gaps that prove challenging. Patching is still a highly complex, manual process and organizations are noticing. In fact, more than half of all companies (55%) say that they spend more time manually navigating the various processes, than actually patching those vulnerabilities (Ponemon, 2018). If an organization does have a robust patching program, two factors resulting in the most manual effort are, first, identifying, tracking, and logging of 3rd party software patches, and second, finding the applicability of these patches across the environment. Beyond Operating Systems and a limited number of 3rd party software products, most organizations are manually tracking 3rd party software patches via monthly website checks or after receiving emails identifying available patches. Thereafter, there is still the need to upload the insights into a common registry, where another team reviews, determines applicability, tests, and deploys the patches. This process is timely, costly, and does not provide the accuracy and consistency needed. Furthermore, this impacts time-to-patch KPIs/KRIs, and often the ability to remediate within SLAs.
What about those organizations not actively tracking 3rd party software patches? By foregoing cyber security from a patch identification lens, pressure is placed on organizations to be reactive to any new vulnerabilities (patches) identified through NIST. Most times, patches are released by the vendor up to several months before any security-related vulnerability is first publicly identified. Because there is not a publicly identified vulnerability (CVE) today, does not mean that the patch is not security–related (read the release notes). Not to mention, this leaves a gap in the process for non-security patches and upgrades.
How then, can we automate some of the above issues? ImagineX has assessed the automated patching landscape and recommends PatchFol.io, for patch identification and determination of applicability. It is a reasonably priced, more accurate way of tracking all 3rd party software patches (24/7) and can leverage data from your inventory scans to give a true landscape view of all endpoints and patching performance metrics.
Feel free to reach out if you want to discuss anything patching: [email protected]
