Assessing Security Vulnerabilities and Patches

Download Assessing Security Vulnerabilities and Patches (750K PDF)

Introduction

  1. Applying patches to operating systems, applications and devices is a critical activity in ensuring the security of systems. DSD currently rates this activity as the most effective security practice agencies can perform.
  2. This product provides guidance on assessing announced vulnerabilities and patches in order to determine the risk they pose to the agency, and guidelines for patch deployment.
  3. Note: In this document, vulnerability refers to a flaw in a vendor produced software or device, rather than a misconfiguration or flaw in an agency’s deployment.

Assessing security vulnerabilities and patches

  1. There are multiple information sources that agency staff can use to assess the risk of a vulnerability and associated patch in the context of their IT environment, in particular the vendor’s notification of a patch.
  2. The vulnerability and patch information published by the vendor will typically include:
    • a list of products and versions affected
    • technical details on the vulnerability including an overview of how exploitation occurs
    • typical consequences of exploitation: code execution, information disclosure, denial of service etc
    • current exploitation status: whether the vulnerability is being exploited?
    • the existence and details of any temporary workarounds
    • an overall measure of severity based on the above factors.
  3. Each vendor uses different means of communicating vulnerability severity. The severity may be derived from a standard such as the Common Vulnerability Scoring System (CVSS) or based on vendor defined categorisation such as ‘Critical’ or ‘Important’.
  4. Regardless of the system that the vendor uses, these severity ratings can allow IT staff to quickly conduct an initial assessment of importance in their environment.
  5. In additional to individual vulnerability/patch details some vendors publish a consolidated bulletin which also contains the vendor’s recommended deployment order.

Agency vulnerability-patch risk assessment

  1. Once agency staff have analysed the relevant vulnerability/patch information a risk assessment can be made. A risk assessment allows an agency to properly assess the severity of a vulnerability/patch in the context of their environment.
  2. It is important to consider the following factors when conducting the risk assessment:
    • high value or high exposure assets impacted – increased risk
    • assets historically attacked are impacted – increased risk
    • mitigating controls already in place, or soon to be in place for all affected assets – decreased risk
    • low risk of exposure for impacted assets – decreased risk.
  3. Examples of vulnerability/patch risk assessments are:
    • extreme risk
      • the vulnerability allows remote code execution
      • critical business system/information affected
      • exploits exist and are in use
      • system is Internet-connected with no mitigating controls in place
    • high risk
      • vulnerability allows remote code execution
      • critical business system information affected
      • exploits exist and are in use
      • system is in a protected enclave with strong access controls
    • medium risk
      • vulnerability allows an attacker to impersonate a legitimate user on a remote access solution
      • system is exposed to untrusted users
      • system requires two-factor authentication and administrator-level remote login is disallowed
    • low risk
      • a vulnerability requires authenticated users to perform SQL injection
      • affected system contains non-sensitive, publicly-available information
      • mitigating controls exist that make exploitation unlikely or very difficult

Patch deployment timeframes

  1. Once a patch is released by a vendor and has been assessed by agency staff for applicability and severity, it should be deployed in a timeframe which is commensurate with the severity.
  2. This also ensures that IT resources are spent in an effective and efficient manner by focusing effort on the most significant issues first.
  3. The following are DSD’s recommended deployment timeframes for the assessed vulnerability/patch risk ratings:
    1. extreme – within 48 hours
    2. high – within 2 weeks
    3. medium – upon the next major update or within three months
    4. low – upon the next major update or within one year.
  4. Patching quickly is essential as the likelihood of publicly available exploits increases significantly upon patch release. This is due to attackers reverse engineering patches, in some cases this has been done in as little as a few hours.

Patch testing

  1. Agencies must decide what the greater risk is: an unpatched vulnerability putting the agency at risk of compromise, or the risk of deploying a patch which has not undergone agency testing.
  2. Many vendors, including Microsoft, perform thorough testing of all patches prior to their release to the public. This testing is performed against a wide range of environments, applications and conditions.

Temporary workarounds

  1. Temporary workarounds can be the only effective protection if there is no patch yet available from the vendor. These workarounds may be published in conjunction with, or soon after, the vulnerability announcement.
  2. Temporary fixes may include disabling the vulnerable functionality within the software or device, or restricting or blocking access to the vulnerable service using firewalls or other access controls.
  3. The decision on whether a temporary workaround is implemented should be risk-based, as with patching.

Example patch assessment scenarios

The following are some simplified examples of patch risk assessments:

Agency Vulnerability Mitigating controls Patch risk assessment
Agency A Critical Microsoft Office
remote code execution vulnerability
None Extreme
Agency B Effective email content filtering
AND
Low privileged users
High
Agency C Effective email content filtering
AND
Application whitelisting
AND
Low privileged users
Medium

Further information

Contact

Australian government agencies seeking clarification can contact DSD.