Queensland Government Enterprise Architecture

Vulnerability management
guideline

Final
July 2018
V1.0.0

PUBLIC
QGEA PUBLIC Vulnerability management

Document details
Security classification PUBLIC
Date of review of July 2018
security classification
Authority Queensland Government Chief Information Officer
Author Queensland Government Chief Information Office

Documentation status Working draft Consultation release  Final version

Contact for enquiries and proposed changes

All enquiries regarding this document should be directed in the first instance to:
Queensland Government Chief Information Office
qgcio@qgcio.qld.gov.au

Acknowledgements
This version of the Vulnerability management guideline was developed and updated by the
Queensland government chief information office.
Feedback was also received from a number of agencies, which was greatly appreciated.

Copyright
Vulnerability management guideline
© The State of Queensland (Queensland Government Chief Information Office) 2018

Licence

This work is licensed under a Creative Commons Attribution 4.0 International licence. To view the
terms of this licence, visit http://creativecommons.org/licenses/by/4.0/. For permissions beyond the
scope of this licence, contact qgcio@qgcio.qld.gov.au.
To attribute this material, cite the Queensland Government Chief Information Office.
The licence does not apply to any branding or images.

Information security
This document has been security classified using the Queensland Government Information
Security Classification Framework (QGISCF) as PUBLIC and will be managed according to the
requirements of the QGISCF.

Final | v1.0.0 | July 2018 Page 2 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

Contents
1 Introduction........................................................................................................................... 4
1.1 Purpose......................................................................................................................... 4
1.2 Audience........................................................................................................................ 4
1.3 Scope............................................................................................................................ 4

2 Vulnerability monitoring.......................................................................................................4
2.1 Asset tracking................................................................................................................ 4
2.2 Vulnerability scanning....................................................................................................5
2.3 Penetration testing......................................................................................................... 6

3 Vulnerability assessment.....................................................................................................7
3.1 Risk assessment............................................................................................................ 7

4 Vulnerability mitigation.........................................................................................................8
4.1 Patch management........................................................................................................8
4.2 Controls......................................................................................................................... 9

Final | v1.0.0 | July 2018 Page 3 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

1 Introduction
1.1 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.

1.2 Audience
This document is primarily intended for:
 operational ICT staff
 information security governance
 risk management

1.3 Scope
This guideline relates to the mandatory aspects of the Queensland Government Information
Security Policy (IS18:2018) and Information security information standard (IS18:2009), 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.

2 Vulnerability monitoring
2.1 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.

Final | v1.0.0 | July 2018 Page 4 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

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.

2.2 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 uncredentialled 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

Final | v1.0.0 | July 2018 Page 5 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

 implement a common scan template for all assets across their environments to ensure
consistent results
All agencies are encouraged to contact the QGCIO Cyber Security Unit via the
cybersecurityunit@qgcio.qld.gov.au email address to take advantage of the resources and
assistance offered in the implementation of vulnerability scanning or credentialed scanning.

2.3 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 QGCIO Cyber Security Unit via the
cybersecurityunit@qgcio.qld.gov.au email address.

Final | v1.0.0 | July 2018 Page 6 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

3 Vulnerability assessment
3.1 Risk assessment
Unresolved vulnerabilities result in increased risk within an agencies environment, it’s
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 QGCIO Cyber Security Unit via the cybersecurityunit@qgcio.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.

Final | v1.0.0 | July 2018 Page 7 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

4 Vulnerability mitigation
4.1 Patch management
All information systems should remain supportable and be maintained in a manner that
minimises the Queensland Government’s 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.

4.1.1 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 QGCIO vulnerability priority calculator (contact the QGCIO CSU
for access) 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

Final | v1.0.0 | July 2018 Page 8 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

 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).

Patch Assessment Guide

CVSS BIL 1 BIL 2 BIL 3
Score/Highest BIL
0 Discretionary Discretionary Discretionary
1-3 Discretionary 4 Weeks 3 Weeks
4-6 3 Weeks 1 Weeks 1 Week
7-10 1 Week Same Day ASAP

Table 1 Patch Assessment Guide

4.1.2 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 and the NIST Guide to Enterprise Patch Management
Technologies.

4.2 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.

Final | v1.0.0 | July 2018 Page 9 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

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.

4.2.1 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 webpages 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, sanitizing 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.)”

Final | v1.0.0 | July 2018 Page 10 of 11

PUBLIC
QGEA PUBLIC Vulnerability management

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”

Final | v1.0.0 | July 2018 Page 11 of 11

PUBLIC