Vulnerability management guideline

Final | July 2018 | v1.0.0 | OFFICIAL - Public |QGCIO

Introduction

Purpose

The Vulnerability management guideline has been developed to assist departments and agencies to meet their operational security requirements under the Queensland Government Information Security Policy (IS18:2018).

The information security policy IS18:2018 requires agencies to run an information security management system (ISMS) compatible with ISO27001:2013. To meet the requirements contained in the Control Objective A12.6.1 of ISO27001, an entity must obtain information on, evaluate and act upon technical vulnerabilities within their environments. A Queensland Government Enterprise Architecture (QGEA) guideline is non-mandatory and provides information for Queensland Government agencies on the recommended practices for a given topic area.

Audience

This document is primarily intended for:

• operational ICT staff
• information security governance
• risk management.

Scope

This guideline relates to the mandatory aspects of the Queensland Government Information Security Policy (IS18:2018), as well as the operational security domain and controls in ISO/IEC 27001.

The following issues are not explicitly addressed and are outside the scope of this guideline:

• baseline standards (i.e. tested and supported minimum levels of software versions)
• software currency (i.e. version control).
• For further information on maintaining an up-to-date software portfolio, see the Software currency policy.

Vulnerability monitoring

Asset tracking

The first step in accurately monitoring vulnerabilities in any environment is to know what information systems and assets exist within it. ISO27001 requires information owners to create and maintain an inventory of the assets associated with information and information systems. We encourage agencies to use existing registers where possible such as the information asset register developed as part of the Information asset custodianship policy (IS44) and application and technology registers developed as part of ICT resources strategic planning (IS2).

By maintaining visibility of all information associated assets and systems within a department, information and asset owners will be able to better understand which vulnerabilities may be creating unnecessary risk within their environments.

To promote better practice agencies should

• share access to the information asset/systems register with the technical teams responsible for vulnerability scanning
• identify attributes of the information systems/assets related to security, for example:
  • internally or externally facing
  • production, test, development
  • information owner
  • system owner
  • business application(s)
  • Business Impact Level (BIL)
  • operating systems
  • services
  • patch level
  • location
  • etc.

Vulnerability scanning

Vulnerability scanning is typically an automated service which scans systems to identify potential vulnerabilities and misconfigurations that adversely affect the security posture of an environment.

All agencies should utilise a form of automated vulnerability scanning. This gives security teams the broadest visibility of vulnerabilities in their systems and the greatest opportunity to mitigate associated risks.

Agencies should:

• Define the following tags
  • internal or external
  • physical location
  • BIL rating of the system
  • asset owner
  • operating system
    • tags are purely informational and are designed to make the scan results of assets more readable and attributable
• implement credentialed scanning
  • credentialed scanning can introduce additional security risks but will provide a more accurate insight than uncredentialed scanning
    • credentialed scanning is the use of an account with administrative or root access to the system it is scanning, allowing the scanner to identify vulnerabilities from a privileged viewpoint within the system.
    • an additional account with admin or root access will always introduce additional risk to a system, scanning accounts typically have escalated access making it a valuable target for adversaries.
  • some ways to mitigate the risk of credentialed scanning include:
    • use a dedicated scanning account that can be disabled between scans
    • where possible, use public key authentication
• scan all information systems/assets belonging to the agency
  • implement a common scan template for all assets across their environments to ensure consistent results

All agencies are encouraged to contact the Cyber Security Unit via the cybersecurityunit@qld.gov.au email address to take advantage of the resources and assistance offered in the implementation of vulnerability scanning or credentialed scanning.

Penetration testing

Penetration testing of a system is another assessment method that can be used to identify vulnerabilities in a system, and is an essential component of an ISO 27001 compliant ISMS. The major difference between penetration testing and other assessment methods is that penetration testing is being actively performed by an actor to simulate an attack on a system.

Penetration testing can be used to identify new vulnerabilities in a system, test existing mitigations, security posture and simulate attacks with various levels of system knowledge. It can also illustrate the exploitability of existing vulnerabilities and loss associated with an attack.

Where possible agencies should ensure that systems involved in processing or storing confidential information (i.e. PII, bank details, etc.) or systems that carry a high Business Impact Level (BIL) for integrity or availability are tested regularly to identify and mitigate vulnerabilities. New systems or those that have received a significant upgrade or modification of their infrastructure should undergo a vulnerability scan and receive a penetration test prior to wider use.

For agencies required to comply with PCI DSS, agencies must:

• Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
• Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
• Where segmentation is used to isolate the CDE from other networks, penetration tests are performed at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and to isolate all out-of-scope systems from in-scope systems
• Ensure exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.

Agencies should follow the above requirements to be aligned with better practice and ensure vulnerabilities are being effectively detected. Penetration testing can be used by agencies to give assurance for controls on higher BIL systems.

When an agency or department is conducting or planning a penetration test, they should consider informing the Cyber Security Unit via the cybersecurityunit@qld.gov.au email address.

Vulnerability assessment

Risk assessment

Unresolved vulnerabilities result in increased risk within an agencies environment, its important the vulnerabilities and associated risk are assessed in the context of the environment they are found. This is important to remember when reviewing the results of automatic vulnerability scanners, these results may include false positives and vulnerabilities that, while carrying some risk, are being mitigated via a separate mechanism. It is because of these reasons vulnerability risk assessments should be the responsibility of the asset owner and/or the asset custodian, this ensures that the responsible actor understands the environment and the existing mitigating controls.

Asset owners and/or custodians should:

• assess the vulnerabilities within their environments
• decide based on their assessment if the agency will:
  • accept the risk
  • transfer the risk
  • avoid the risk
  • mitigate the risk

Agencies should prioritise vulnerabilities based on their own context, many automated scans and risk management tools have their own ways of grading vulnerabilities and risk, agencies are encouraged to use whatever prioritisation system they are most comfortable with. Agencies seeking additional tools to assist in their vulnerability prioritisation should contact the Cyber Security Unit via the cybersecurityunit@qld.gov.au email address.

Agencies can also use the following questions to help prioritise existing vulnerabilities:

• How many systems does the vulnerability exist on?
• Are those systems considered critical or sensitive?
• Is the system likely to be exposed to threats that may exploit the vulnerability such as public facing systems or internet accessible systems?
• What mitigations exist that would limit the damage caused by successful exploitation of the vulnerability? For example, application whitelisting controls may limit the impact of code execution vulnerabilities.
• Does the capability exist to detect or prevent the vulnerability from being exploited using a network or host-based IDS/IDP?
• Is there appropriate logging and alerting in place to respond quickly to systems that have been exploited?
• What is the CVSS rating of the vulnerability? All else being equal, a vulnerability with a higher CVSS rating should be prioritised higher than a vulnerability with a lower CVSS rating.

Agencies are also encouraged to use the Queensland Treasury risk management framework as a guide for their risk assessment processes.

Vulnerability mitigation

Patch management

All information systems should remain supportable and be maintained in a manner that minimises the Queensland Governments exposure to risks associated with vulnerabilities in these systems.

The main type of patch being discussed within this guideline are security patches, Security patches may include, but not limited to; operating system patches, software patches, firmware updates, hardware hotfixes. Security patches are most often released from developers to remove a vulnerability from their program or platform to prevent exploitation of the vulnerability by an attacker. Other patches released by developers with the intent to provide additional functionality or fix unexploitable flaws, can be installed at the discretion of the operational IT team and business owners in accordance with the agencies change management processes.

An effective patch management program will assist in the mitigation of business risk by:

• increasing uniformity across Queensland Government ICT assets by standardising how ICT patches and updates are obtained and applied
• increasing the ability to maintain and support ICT assets in accordance with this guideline
• encouraging that each agency provides their own testing capability and avoids testing, where possible, on production systems
• fixing known vulnerabilities in ICT assets that attackers could exploit for various purposes

Agencies should refer to the Software currency policy and Hardware currency policy to ensure they are maintaining an up-to-date software and hardware portfolio, and reduce the cost of risk associated with managing unsupported products.

Patch assessment

Patch assessment is the process of reviewing the applicability, risk, and suitability of implementing a patch within a specific environment.

Assessment of patches should:

• confirm that the patch has been obtained from a trusted source, and verified for authenticity and integrity.
• utilise the risk scores and results gathered from the risk monitoring systems
  • agencies can use the CISA SSVC Calculator (developed by Cybersecurity & Infrastructure Security Agency in the United States) to prioritise relevant patches.
• consider the BILs of the information systems or information assets affected by the patch.
• include the testing of a patch outside of a production environment.
• occur as soon as practical after notification by the vendor.
• be recorded, including all decisions to apply a patch, or not, for each ICT asset.

Reasoning not to apply a patch may include:

• agency criticality rating assessed as Minor or None/Negligible
• the patch may be integrated into the next baseline release
• lack of vendor support
• interoperability issues with other software or hardware
• stability issues affecting availability
• untenable workaround scenarios
• other incompatibilities.

Patches not applied should be recorded and subject to monitoring / review where appropriate.

Agencies are encouraged to use table 1 patch assessment guide as a tool for assessment timelines. In using the table External vulnerabilities should be considered 1 BIL higher than assessed (e.g. BIL 1 external systems should be considered a BIL 2, BIL 2 external systems should be considered BIL 3, and BIL 3 systems will stay as BIL 3).

Table 1 Patch Assessment Guide

Patch implementation

Patch implementation timelines are at the discretion of the agency; however, timelines should be reasonable, repeatable and risk based.

Agencies should have a standard patch implementation process to match the context of their environment

For more guidance regarding patch implementation agencies should refer to the Australian Signal Directorate Essential 8 (Opens in new window) and the NIST Guide to Enterprise Patch Management Technologies.

Controls

In some cases, the risk generated via vulnerabilities cannot be mitigated with a patch, patches may not exist or may introduce even more risk, in these cases agencies and departments should consider implementing further controls to reduce the generated risk.

Controls can be highly specific to an environment and can encompass business processes to software and hardware implementation. The selection of controls is dependent upon organisational decisions based on the criteria for risk acceptance, risk appetite, risk treatment options and the general risk management approach applied to the organisation, and should also be subject to all relevant state, national and international legislation and regulations. Departments and agencies should consider the Information Privacy Act 2009, the Public Records Act 2002, Telecommunications Interception Act 2009, and may need to seek further legal advice before implementing some control mechanisms.

Control sets that should be considered by a Queensland Government agency or department include:

• agencies are mandated by the Information security policy (IS18:2018) to implement the Australian Signals Directorate (ASD) Essential Eight Strategies to Mitigate Cyber Security Incidents.
• QGCIO also advises agencies and departments review ISO/IEC 27002 Information technology Security techniques Code of practice for information security controls for examples and implementation guidance on common controls in 35 security categories.
• Departments and agencies are encouraged to seek additional control sets to bolster their security posture and mitigate vulnerabilities most effectively.

Controls examples

Below are examples of some business and technical controls with basic considerations, this is in no way an exhaustive list of scenarios or controls.

Mobile device controls

Agency X has noticed growing security concerns with the use of personal mobile devices for official Queensland government business; Agency X is unable to patch the vulnerabilities in individual user phones.

Administrative Control

Agency X could implement a mobile device policy banning the use of employee personal devices for government work, this is contextually acceptable as Agency X provides all of its employees with mobile work devices and employees are able to request exceptions depending upon circumstances

Technological Control

Agency X could provide all employees on official government business, that may need to be completed outside of regular operating hours with an official mobile device. The device could be given access to systems while locking down any access to systems to any other external devices

Cross Site Scripting Controls

Agency X has become aware that one of their web pages is vulnerable to cross site scripting (XSS) injection attacks as a result of a penetration test

Technological Control

Agency X could implement a web application firewall (WAF) as a way to allow, block, and monitor web requests that contain XSS code or create one or more XSS match conditions.

Administrative Control

Agency X could enact a policy enforcing input validation, input escaping, sanitising user input or any combination of the three on all external web applications

Weak configuration or misconfiguration

Agency X received notifications from its automated scanner that a range of their hardware assets are vulnerable due to weak security configurations (e.g. unchanged default passwords, no passwords, software is out of date, unnecessary features are enabled and installed, etc.)

Administrative Control

Agency X could implement an internal policy or standard enforcing minimum security configuration standards to minimise the risk of further misconfigurations or develop a repeatable hardening process that ensures it is fast and easy to deploy future environments that are secure

Technological control

Agency X could set up an automated process to scan the network and test the effectiveness of device configurations to ensure any future devices in the environment are correctly configured