Assessing, Prioritizing, and Fixing Software Vulnerabilities

Rounding up our discussions at MMS

In this year’s Midwest Management Summit I had the chance to present with Kent Agerlund on the importance of deploying and maintaining software that is free of security vulnerabilities. I can see that the topic is becoming more and more relevant for SCCM Admins, but I can also see that many questions and challenges remain. So here is a roundup of what we discussed during these days in Minneapolis.

Drowning in vulnerabilities and patches

In 2017 there were nearly 20,000 vulnerabilities disclosed. 86% of those had a security update available to mitigate it right away. But it’s up to you to find out about such security updates and patch them quickly. But how quickly? Why is gaining control of patching such a challenge?

To have a shot at succeeding you’ve got to:

  • Know just what you have in your environment. Not just what titles but what specific versions.
  • Know a vulnerability exists for an application that concerns you.
  • Know how critical they are and which risk they represent
  • Obtain, package and test the update to ensure its deployment does not have a negative impact on your environment.
  • Successfully deploy it to all relevant devices.

Considering many enterprise environments have several hundred applications in their portfolio, this becomes a task that is not only daunting but constant due to the frequency of security updates being released. So if this may be a task that you are going to be constantly working to address, some help prioritizing the workload to make sure you get the most out of your efforts is yet another consideration to be had in achieving a successful patching process.

Assessing. Prioritizing. Fixing.

Those are the key phases in addressing software vulnerabilities, but to complete those phases you must have a good track of the time it takes for you to find vulnerabilities and determine whether they need patching or other mitigation action. We look at this time lapse as two distinct chunks: “Disclosure to awareness” and “awareness to remediation”

1 – Disclosure to Awareness

We define “disclosure to awareness” as the period between a vulnerability being publicly disclosed and you learning about it. This period may vary greatly, considering the amount of applications organizations need to manage.
For Microsoft applications, for example, there is Patch Tuesday so you normally learn about security patches at the same time the vulnerability is disclosed. Third party applications aren’t as easy to stay on top of.
“Disclosure to awareness” time lapse is influenced by factors such as the process for vendors to inform users about new vulnerabilities, and the processes users have to track their applictions and the vulnerabilities affecting them.

2 – Awareness to Remediation

“Awareness to remediation” is the time it takes you to complete the steps to determine how to handle the vulnerability and implement the remediation action required.

Applying patches for all vulnerabilities on all applications just isn’t a realistic goal for most, so it becomes critical to prioritize patches as effectively as possible. The ideal way to prioritize patches will vary from organization to organization. Factors you might consider key include the criticality of the vulnerability, the number of systems affected by the vulnerability and the exposure of the devices in question.

Some vulnerabilities may require physical access to a device, so if such a device is in a locked room it may be considered less critical. Some vulnerabilities may require use of hardware or functionality not present in your environment. A device that lives outside your controlled network or who’s primary user is a member of your finance department, may be considered higher risk and should affect your prioritization.

Once you’ve decided on your top priorities, crafting a package to update the application can be its own challenge. Some applications simply provide better support for automated deployments than others making the amount of time necessary to create and test a patch vary significantly. Some applications are of more risk to update that others. Middleware or frameworks that are dependencies for critical applications require extra testing to mitigate operational risk.

Software Vulnerability Manager (SVM)

Our Flexera Secunia Research team is constantly investigating new vulnerabilities, and has been for over 15 years. They identify vulnerabilities and the patches released to address them daily. This research, tied to a detection and assessment system can quickly detect vulnerable software throughout your environment and automate alerts, service desk tickets, and even the publishing of patches automatically.

How We Solve Disclosure to Awareness

As opposed to attempting to accurately match inventory data to vulnerable software builds, SVM specifically scans systems for what are known to be vulnerable software. To perform this operation on endpoints you may install an agent or run such as a task, but the process is quick and requires little memory or bandwidth. The result is a complete picture of your vulnerability risk that you can slice and dice anyway you like.

How We Reduce the Time from Awareness to Mitigation

Workflows are provided within SVM to alert you (in the product, via email, even via text message), open a ticket (internally, or in other leading ticketing systems like ServiceNow and Remedy), or automatically publish an update.
Flexera provides thoroughly tested patches for many popular products and even offers the ability to create reusable templates that can set application specific settings related to its deployment. SVM can not only identify a vulnerability and provide a mitigation, but leverages your existing patching process to publish those updates. Patches are published to WSUS or SCCM so that you can leverage your existing infrastructure to manage the roll out of third party security updates.

To learn more about SVM, visit https://www.flexera.com/products/software-vulnerability-management/software-vulnerability-manager.html

Category: General

Leave a Reply

Your email address will not be published. Required fields are marked *