Identifying and Patching Vulnerabilities in a Post-Microsoft Security Bulletin World

Thursday, July 27, 2017

Ken Hilker

Eb7e8df20aa93ae571f506153de0fe84

Microsoft’s security bulletins have provided IT administrators with a monthly list of vulnerabilities and accompanying patches for decades…until recently. Last November Microsoft warned that the Security Bulletins on Patch Tuesday would be discontinued, and they followed through on their promise with the April 2017 edition.  

Companies relying on Microsoft Security Bulletins can now only find information about software vulnerabilities on the Security Update Guides portal (SUG). This change is troublesome for patch management professionals who already have enough on their plate without periodically checking SUG for new vulnerabilities and patches. Moreover, the additional time to research and understand the security patches required for their unique environments will only lengthen the time to patch. While the portal is searchable by Common Vulnerabilities and Exposures (CVE), Knowledge Base (KB) article, product or release date, the change in process will impact the daily routines of IT administrators and security professionals around the world.  

Microsoft says that SUG has functionality that users have been asking for, and that the portal allows users to customize it for their unique needs.  While the portal has advanced capabilities, the change has generated concern about the impact on patch management activities.  

Part of the Microsoft outcry relates to changes that companies will have to make to their IT processes.  Security Bulletins have been around for decades, and administrators have built their processes around the predictable and consistent delivery of these bulletins. Microsoft’s format changes are inconvenient for patch management professionals and may require more time spent researching and identifying the security patches required for their specific environments.  

Consequently, companies relying on Microsoft Security Bulletins must now change their processes, or need to find alternative solutions to streamline and improve efficiency.   

Then and Now

An example of this format change is a vulnerability in Adobe Flash Player (which Microsoft distributes to their users). The older format looked like this:

It was one security bulletin that could be read and used to quickly determine what Windows platforms and products are affected.  

Now, using the SUG, the same vulnerability information is broken out into separate listings in the Website per platform. This same Adobe Flash Player vulnerability now looks like this:

Pulling Vulnerability Information

Even without Microsoft’s long-issued Security Bulletins, businesses and IT administrators can still access vulnerability information from thousands of sources – including Microsoft and Adobe. Businesses can reference the National Vulnerability Database, the U.S. government repository of standards-based vulnerability management data, use a threat feed provider, or implement a software vulnerability management platform to help them identify and patchvulnerabilities before they impact their business.  

Vulnerability Ratings

Once a business has identified the vulnerabilities present in their software, IT administrators now need to prioritize and address those vulnerabilities based on their criticality. The criticality of a vulnerability is based on the assessment of the vulnerability’s potential impact on a system, the attack vector, mitigating factors and if an exploit exists for the vulnerability and is being actively exploited prior to the release of a patch.  

The vulnerability ratings follow:

  • Extremely Critical (5 of 5): Typically used for remotely exploitable vulnerabilities that can lead to system compromise.  Successful exploitation does not usually require any interaction and exploits are in the wild.  These vulnerabilities can exist in services like FTP, HTTP and SMTP or in certain client systems like email applications or browsers.
  • Highly Critical (4 of 5): Normally used for remotely exploitable vulnerabilities that can lead to system compromise.  Successful exploitation does not typically require any interaction, but there are no known exploits available at the time of disclosure.  Such vulnerabilities can exist in services like FTP, HTTP and SMTP or in client systems like email applications or browsers.
  • Moderately Critical (3 of 5): This rating is also used for vulnerabilities allowing system compromise on LANs in services like SMB, RPC, NFS, LPD and similar services that are not intended for use over the Internet.  Usually used for remotely exploitable Denial of Service (DoS) vulnerabilities against services like FTP, HTTP and SMTP, and for vulnerabilities that permit system compromises but require user interaction.
  • Less Critical (2 of 5): Usually used for cross-site scripting and privilege escalation vulnerabilities.  This rating is also used for vulnerabilities allowing exposure of sensitive data to local users.
  • Not Critical (1 of 5): Typically used for very limited privilege escalation vulnerabilities and locally exploitable DoS vulnerabilities.  This rating is also used for non-sensitive system information disclosure vulnerabilities (e.g. remote disclosure of installation path of applications).

Additional Considerations

Beyond criticality, IT administrators also need to consider:

  • Impact – what this vulnerability can affect (System Access, DoS, Release of Sensitive Information, etc.)
  • Where – from where this vulnerability can be exploited: Local System, Local Network or Remote (outside of network)
  • Solution Status – is there a patch or other method that migrates the vulnerability?
  • CVE references – uses industry standard CVE to aid in communication across groups
  • Products affected – can show if the advisory is for one product or multiple ones (in this case, the vulnerabilities affect multiple operating system versions)
  • Advisory details – Summary of the issue
  • Solution details – how this vulnerability can be mitigated

We’ll All Be OK!

Many businesses are concerned about Microsoft changing the way they release vulnerability information around their products to the world.  Yes, Microsoftused to publish the Security Bulletins, which helped IT pros understand patches that closed multiple vulnerabilities, patches closing vulnerabilities affecting multiple products, and so on. Thankfully, however, there are solutions available today that achieve a similar view – more than making up for the lack of Security Bulletins.

About the author: Ken Hilker is a Senior Product Manager of Installation Solutions at Flexera. Flexera is reimagining the way software is bought, sold, managed and secured.

Possibly Related Articles:
96359
Operating Systems Enterprise Security
Microsoft Windows CVE Microsoft Security Bulletin Security Update Guides
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.