Vulnerability management guideline
Introduction
Purpose
Implementing robust vulnerability management practices is pivotal in safeguarding entity digital environments. Mature vulnerability management practices can significantly diminish the timeframe in which threat actors can exploit vulnerabilities, decreasing both the likelihood and potential impact of cyber intrusions. Engaging in early detection and timely remediation of vulnerabilities not only mitigates risk but also tends to be substantially more economical than managing the aftermath of a cyber incident.
This guideline supports the management of vulnerabilities in Internet connected Information Technology environments and Internet services and devices for Operational Technology environments. Other Operational Technology environments should adapt this guidance based on their risks and specialist better practices (such as AESCF and ISO62443). IS18 requires that applicable entities implement:
- the ACSC Essential Eight Strategies, which includes the strategies “Patch Applications” and “Patch Operating Systems”
- an ISO27001 based ISMS, which includes the management of technical vulnerabilities (A8.8).
This guidance has been written to support entities in meeting these requirements including across the three Essential Eight maturity levels.
Audience
This document is primarily intended for:
- technology operators
- information/cyber security specialists
- supplies and contract managers providing ICT services
- areas responsible for cyber governance and risk management.
Scope
This guideline relates to the mandatory aspects of the Queensland Government Information and cyber security Policy (IS18).
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)
- security hardening guidance, such as the CIS Hardening Benchmarks
- software currency (i.e. version control)
- for further information on maintaining an up-to-date software portfolio, see the Software currency policy.
Definitions
- higher risk applications: Office productivity suites, web browsers and their extensions, email clients, PDF software, and security products which commonly handle potentially malicious files and are frequently targeted with exploits. This may include other systems deemed to have higher risk as determined by the entity (for example, for handling highly sensitive information, or a history of being attacked).
- high priority vulnerability: A vulnerability is considered high priority when any of the following apply;
- the vendor or service provider has rated it as critical
- in the absence of a vendor or service provider rating, it is rated critical by an industry benchmark (e.g. CVSS >= 9)
- a working exploit exists
- a vulnerability discovered by a Payment Card Industry Data Security Standard (PCI DSS) Approved Scanning Vendor (ASV) service which results in a failed PCI DSS ASV quarterly scan
- if operational technology, would exploitation of the vulnerability would result in a safety impact of “catastrophic” or “critical” as defined in IEC 61508 – functional safety of electrical/electronic/programmable electronic safety-related systems.
- cyber resilience: An organisation’s ability to prevent, withstand, and recover from cybersecurity incidents.
- non-internet facing devices and systems: Workstations, non-internet-facing servers and non-internet-facing network devices including their operating systems and application services.
- online services and internet facing devices: An internet facing system is one that can be accessed from the public internet. Such access is not limited to web browser access via http or https. A system is internet facing if it broadcasts or responds to requests on any internet protocol (IP) open port and can be trivially communicated with from the internet.
- this includes those services sitting behind a perimeter firewall or a reverse proxy. For example, a web portal, a cloud service or a network device (such as a firewall or VPN concentrator).
- this includes the online service itself, the operating systems and application stacks of the servers (physical or virtual) that run the service, and internet facing network devices (including routers, firewalls, etc).
- other applications: Applications outside of “higher risk applications”
Conventions
To assist entities in meeting the requirements for Essential Eight alignment, best practice approaches are shown in the following information boxes.
This activity should be undertaken to meet ACSC Essential Eight alignment.
Entities should always consider these activities in line with their existing risk appetite and tolerance.
Vulnerability management approach
To strengthen cyber resilience, it is crucial for organisations to adopt a structured vulnerability management approach. Vulnerability management is considered a fundamental security practice and addresses two of the Essential Eight requirements (Patch Operating Systems and Patch Applications).
An entity's approach to managing vulnerabilities should clearly establish the purpose and range of this process. The techniques adopted should align with the organization's risk appetite and its risk management framework, with clearly defined roles and responsibilities, governance processes, asset management approach, and vulnerability tracking and resolution processes.
Figure 1: Vulnerability management Lifecycle
Asset Tracking
Asset tracking, including discovery, is essential for entities to identify their existing information systems and assets. The asset management and tracking requirements, which are already mandatory, under policies such as those listed below provide significant benefit in vulnerability management:
- ISO27001:2022 A5.9 inventory of information and other associated assets
- QGEA Information asset custodianship policy
- QGEA ICT resources strategic planning policy
- QGEA ICT profiling standard.
Assets should be tagged with metadata (either in a Software Asset Management tool, a Vulnerability Management System or similar) at the very least to identify between externally and internally facing assets, and business impact information, to assist with vulnerability prioritisation efforts.
The asset register should include asset identifier/name, system owner, information owner, responsible service provider (if applicable), services delivered, information security classification level, system configuration, patch levels, and location. It is recommended that entities implement asset tagging to aid remediation activities and enable risks to be monitored.
When vulnerabilities are detected, it is vital that they can be tied back to assets within the organisation that are impacted.
Discovery scans (asset discovery)
Both authenticated and unauthenticated scan engines can be utilised for discovery scans to discover assets. Asset discovery can determine if target assets are live; collect information on discovered assets, and, after configuration; report any unauthorised devices present on a network. This activity may also be used to inform entities general asset register and reporting requirements under the ICT Profiling Standard. Processes for decommissioning devices should be in place and devices should be removed accordingly from the asset register.
Automated asset discovery, for the purposes of vulnerability detection and management, should occur at least every two weeks.
Vulnerability monitoring
The primary method for monitoring and identifying vulnerable software within an environment is for system owners or their delegates to actively keep up-to-date with the latest security advisories and updates from software vendors. This is typically be achieved through subscribing to update notifications directly from vendors, or by utilising third-party notification services.
While important, vulnerability scanning should be considered as a supplementary approach that complements the information obtained from these advisories and updates as scanning engines may not always have all relevant vulnerability information.
CHIPS and NIBBLIES
Most Queensland Government entities receive several reports from ACSC on a recuring or as required basis:
- CHIPS (Cyber Hygiene Improvement Program)
- HOT (High-priority Operational Tasking)
- NIBBLIES (Notifications of Indicators, Beaconing, Breach Lists and other Information to Effect Security).
It should be noted that these reports frequently contain information related to externally facing vulnerabilities, which should be considered as a priority. In the case of NIBBLIES, identified vulnerabilities are potentially under active exploitation requiring prompt action.
Software Bill of Materials
For custom software developed in-house, or by partner organisations, it may be beneficial to create and maintain a comprehensive inventory of all dependencies, which is called a Software Bill of Materials (SBOM). Storing these details together in a central repository can greatly aid in spotting any security vulnerabilities within the software's components. When a vulnerability is identified in a software library, this repository can be used to identify business applications which are potentially vulnerable as a result.
Integrating this SBOM database with regular update processes, such as in Continuous Integration/Continuous Deployment (CI/CD) pipelines, helps ensure that dependencies are regularly updated.
Vulnerability scanning
Vulnerability scanning, an automated service, identifies potential flaws and security vulnerabilities that threaten the security posture of an environment. As part of a comprehensive risk management strategy, entities should ensure such scanning is embedded in the lifecycle for cloud-based and outsourced systems, affirming the security of production, testing, and staging environments. The practice of systematic scanning is critical not only for the early detection and documentation of new vulnerabilities but also for their swift mitigation or remediation.
Note: The focus of this is on identifying newly emerging vulnerabilities in a timely manner, other techniques such as External Attack Surface Monitoring may also meet the intent of this without requiring explicit scanning.
Vulnerability scanners should be updated with the latest vulnerability definitions (within 24hrs) prior to running a scan.
Vulnerability Scanning should be performed at least at the below frequencies (see table 1) depending on the environments target Essential Eight Maturity Level.
| E8 ML1 | E8 ML2 | E8 ML3 | |
|---|---|---|---|
| Online services and internet facing devices | Daily | ||
| Higher risk applications | Weekly | ||
| Non-Internet facing devices | Fortnightly | ||
| Other applications | N/A* | Fortnightly | |
| Drivers and firmware | N/A* | Fortnightly | |
Table 1: Vulnerability scanning timeframes
* While not an E8 requirement, QGCSU recommend including this with other scanning activities
Authenticated scans
Using a privileged account for scanning enables a thorough examination of systems and yields a more accurate assessment of the vulnerabilities present. However, while entities should consider authenticated scanning for its enhanced visibility into potential security issues, they must also weigh the increased risks of exploitation associated with using such accounts. To mitigate these risks, it's often possible to configure the scanning account with ‘Just Enough Administration’ privileges, ensuring that it does not possess more rights than necessary for effective scanning.
Agent-based scanning
Vulnerability scanning agents can be used where:
- assets are located outside of a corporate network or are mobile
- assets are in an isolated or micro-segmented network
- remote access is not enabled
- remote access credentials are unavailable
- the asset is sensitive to network-based scanning
- the asset requires continuous monitoring
- the asset is in a dynamic, cloud, or other complex environment that requires flexible deployment.
Agents are often preferred in end-user device environments as they provide near real time monitoring regardless of location and do not significantly increase network load. However, Agent based scanning solutions may not detect vulnerabilities on unmanaged assets within the environment.
Penetration testing
Penetration testing, also known as ethical hacking, is an assessment method used to identify vulnerabilities within systems. It stands apart from other methods because it involves an authorised individual actively probing the system to detect weaknesses.
Penetration tests can uncover new vulnerabilities, evaluate the effectiveness of existing safeguards, assess the overall security stance, and simulate attacks based on varying degrees of system knowledge. They can also demonstrate the potential for exploitation of known vulnerabilities and quantify possible losses resulting from an attack.
Where feasible, entities should regularly test systems that process or store confidential information with a medium or high Business Impact Level (BIL), such as personally identifiable information and bank details, to identify and address vulnerabilities. It is especially important for new systems or those that have had substantial infrastructure upgrades or modifications to undergo vulnerability scans and penetration tests, especially those that are accessible via the internet, prior to their broad deployment. A consistent testing regimen can help detect new weaknesses that may emerge as a system evolves and as attack techniques advance.
Entities required to adhere to the Payment Card Industry Data Security Standard (PCI DSS) must note additional, specific penetration testing requirements and ensure compliance with them.
Application Security Testing
Traditional vulnerability scans, particularly those enhanced by authenticated scans or agents, excel at detecting known vulnerabilities in system configurations and widely-used software. However, they are not typically adept at pinpointing weaknesses in custom-developed applications, which necessitates a different approach.
Application Security Testing (AST) tools, both Static (SAST) and Dynamic (DAST), can address this shortfall.
- static AST reviews the application's source code, searching for established patterns suggestive of security vulnerabilities
- dynamic AST examines a live application by executing methods like 'Fuzzing,' aimed at uncovering potential vulnerabilities through simulated attacks.
Integrating these AST tools into Continuous Integration/Continuous Deployment (CI/CD) pipelines automates the vulnerability detection process. Each time an application update is ready for deployment, these tools rigorously test for new vulnerabilities. Discovering such issues early allows for their prompt resolution—or official risk acceptance—prior to the application's release into the production environment. This proactive stance on security solidifies the application's defences and reduces its exposure to potential breaches.
Vulnerability risk assessment
Once vulnerabilities are discovered, they should be evaluated to ensure that the associated risks are managed accordingly. Several factors should be considered:
- does the vulnerability qualify as a 'High Priority Vulnerability'?
- see Definitions
- is the affected software widely used in applications that carry a higher risk, such as office productivity suites, web browsers, and email clients that regularly process content from external sources?
- does the vulnerability jeopardise critical security services or applications?
- could the identified vulnerability be a false positive? For instance, a piece of software may be flagged for a security weakness in a feature that is not enabled in the environment, or an issue may be inaccurately reported due to back-porting, where patches are applied to older software versions without upgrading the version number.
When there is evidence of a vulnerability being exploited in the wild– these should take priority in remediation over other exploits where no evidence of exploitation in the wild exists.
Legacy software
Legacy software and devices are those for which vendors no longer release security updates. As most vendors stop publishing vulnerability information once software reaches its end-of-life, it is dangerous to assume that legacy systems are unaffected by new vulnerabilities, and they may also be subject to undisclosed vulnerabilities.
Such reliance on outdated technology poses significant risks. If updating or replacing legacy software is not immediately feasible, a risk management plan should be developed. This plan should detail the necessary measures to mitigate the continued use of the software (see Risk mitigation plan for unpatched vulnerabilities). These plans should have a lifespan no longer than 12 months and require renewal and approval every 12 months if extended.
Software that is no longer supported by vendors should be replaced.
Vulnerability mitigation
The preferred mitigation for managing vulnerabilities should always be to apply patches when viable. Security patches are crucial for maintaining the safety and integrity of operating and software systems. In addition to firmware updates, hardware fixes, and hotfixes, security patches can remove vulnerabilities that threaten the security of a system and ensure that the vulnerability is not going to inadvertently be re-exposed in the future if an alternate control is disabled in the future. See alternate mitigation techniques for other strategies if patching is not practical.
The preferred method for managing vulnerabilities is to apply patches when viable. Security patches play an essential role in safeguarding operating systems and mitigating risks. This not only removes known vulnerabilities but also helps to ensure that these weak spots remain secure, even if other forms of protection are removed or fail in the future. For situations where patching is not feasible, please refer to alternate mitigation techniques for additional strategies.
The risk of a patch causing significant issues can be partly mitigated by deploying patches in waves or rings, monitoring for issues in between. For example, a ring deployment approach may look like;
| Ring name | Description | Percent of environment |
|---|---|---|
| Smoke test | A small subset of devices, to flag any immediate issues | 1% |
| Pilot | Small representative of users/systems, ideally those that are willing early adopters | 10% |
| Early | Larger representative sample of the user/system base | 20% |
| Mainstream | The bulk of remaining systems | 50% |
| Late | Systems/users that are highly sensitive to disruption | 19% (remainder) |
Table 2: Example ring deployment approach
Vulnerabilities should be mitigated (via patching or approved risk mitigation plan) within the below timeframes depending on the target Essential Eight Maturity Level.
| Target | Priority | E8 ML1 | E8 ML2 | E8 ML3 |
|---|---|---|---|---|
| Online services and internet facing devices | High priority | 48 hours | ||
| Low priority | 2 weeks | |||
| Higher risk applications | High priority | 2 weeks | 48 hours | |
| Low priority | 2 weeks | 2 weeks | ||
| Non-Internet facing devices | High priority | 1 month | 48 hours | |
| Low priority | 1 month | 1 month | ||
| Other applications | All | N/A* | 1 month | 1 month |
| Drivers and firmware | High priority | N/A* | 48 hours | |
| Low priority | N/A* | 2 weeks | ||
Table 3: Vulnerability mitigation targets
* While not an E8 requirement, QGCSU recommend this be done not less than quarterly
Assessment of patches
Before applying patches, entities must conduct a thorough assessment, considering the severity of the vulnerability, the systems impacted, and any existing controls that may mitigate the risk. It's crucial to source patches from reputable providers and to verify their authenticity and integrity to ensure security.
Additionally, it’s important to verify that post-patch, the system will remain supported by application vendors. Testing patches in a non-production environment and adopting a phased rollout, as previously discussed, are potential ways for mitigating the risk of major issues developing. Entities must document the assessment process, including decisions regarding whether to apply a patch, the approval of these decisions by the respective system owner, and the application details for each ICT asset.
Alternate mitigation techniques
There are scenarios where vulnerable assets cannot be patched in a timely manner. Entities may consider implementing other mitigation controls to reduce risk from an unpatched vulnerability. Additional monitoring, tighter segmentation, reconfiguration to deactivate vulnerable components, authentication controls, controlling or narrowing privileges can be appropriate controls to be considered as part of a risk mitigation plan. See Risk mitigation plan for unpatched vulnerabilities.
However, these mitigations are subject to weakening overtime as other changes to the environment are made, these should be considered temporary until the vulnerability can be patched or vulnerable component retired.
Risk mitigation plan for unpatched vulnerabilities
A risk mitigation plan serves as an important internal document within organisations, enabling them to capture and authorise alternative approaches to vulnerability management. This tool enhances transparency, helps track unaddressed vulnerabilities, and facilitates explicit acceptance of associated risks. Outstanding vulnerabilities are those that remain unresolved within designated timeframes, as dictated by internal policies.
Reasons for vulnerabilities persisting beyond these timeframes may include the absence of an available patch or a vendor's lack of support for updates to critical components. Businesses should institute a formal procedure to identify and engage business risk owners for endorsement when, due to specific circumstances, immediate mitigation is unfeasible, or if a less optimal approach becomes necessary.
Organisations must base their control measures on their risk tolerance, acceptance levels, strategy for risk treatment, and overall risk management framework. All such measures must comply with state, national, and international legal requirements. Relevant laws to consider are the Information Privacy Act 2009, the Public Records Act 2023, and the Telecommunications Interception Act 2009. Legal advice may be required when adopting certain control measures.
The elements below constitute what a comprehensive vulnerability mitigation plan may include. These elements can often be extracted from pre-existing registers for information assets, applications, and technology to ensure data accuracy and avoid redundancy:
- vulnerability description
- CVSS score
- dates: when the vulnerability started, was detected, patch availability, and patch application
- affected system(s) and owner(s), indicating whether they are internal or external
- information asset(s) impacted and their owner(s)
- current risk assessment results, including business impact level and likelihood
- availability of a patch
- alternative mitigation techniques used and their implementation dates
- residual risk assessment details
- name of the assessment officer
- approvals of asset owners and Entity Security Executive
- schedule for the next review.
It's important to carry out risk evaluations both before and after the implementation of patches to ensure that new or different risks have not been introduced. A comprehensive risk assessment must balance the potential risks of applying a patch against those associated with not patching, the latter of which may have more significant consequences.