2.2.1 Definition
A Vulnerability Assessment is an asset-centric security test used to identify the maximum number of known vulnerabilities and insecure configurations in the target environment, with minimal proof-of-concept or supporting evidence without in-depth exploitation.
2.2.2 Qualifications
The Supplier’s security testers should minimally possess either of the following industry- recognised certifications:
- Offensive Security Certified Profession (OSCP)
- CREST Registered Tester (CRT)
In addition, security testers should possess the most recent “Mastering CVSS” certificate to demonstrate proficiency in assessing the severity of findings using the Common Vulnerability Scoring System (CVSS).
2.2.3 Lifecycle
2.2.3.1 Pre-engagement matters
2.2.3.1.1 Scoping
The Customer and the Supplier should agree on the defined scope of the VA, which includes the following:
- Objective of the VA: Go-Live testing, testing of new features, testing of newly identified threats, routine VA, etc.
- In-scope components (e.g. list of IP addresses, URLs, endpoints): to comprehensively cover the system or application under test.
- Testing environment: (Production is preferred) on-premise, GCC 1.0/2.0 (including CSP), GDC, or GPC.
- Methodology: An authenticated scan is mandatory
- Time and resources to be expended
- Rules of engagement including timeline, location, personal data handling, testing hours, cooperation with Customer’s security team, and permission to test
The Customer and Supplier should allocate sufficient time and manpower for the VA based on the following suggested guide. If a system exceeds the size of the “Large” scope, the Customer should consider breaking it up into multiple smaller scopes. The following tables serve as a guideline, and the Supplier should work with the Customer to decide on a reasonable testing duration and manpower, based on the scope below.
| Network VA | ||
|---|---|---|
| Scope | Number of IP Addresses | Estimated man-days |
| Small | 1-20 | 2-5 |
| Medium | 21-100 | 6-10 |
| Large | 101-200 | 11-15 |
| Web app VA | |||
|---|---|---|---|
| Scope | Number of User Roles | Number of dynamic pages/API endpoints | Estimated man-days |
| Small | 1 | <=30 | 2-5 |
| Medium | 2-3 | 31-80 | 6-10 |
| Large | 4-10 | 81-250 | 11-20 |
| Cloud VA | |||
|---|---|---|---|
| Scope | Number of IAM policies (variations of policies, e.g. identical except for resource targets or subsets of policies, are counted as 0.5) | Number of Cloud Services | Estimated man-days |
| Small | 1-15 | 1-10 | 2-5 |
| Medium | 16-30 | 11-20 | 6-10 |
| Large | 31-45 | 21-30 | 11-20 |
2.2.3.1.2 Information
The Customer should provide the Supplier with all relevant information required for the VA, including:
- System/product name and description.
- Security Classification and Data Sensitivity.
- List of in-scope application IP addresses/URLs.
- Where applicable, past VA reports (at least 1), including the name of the supplier which conducted such past VA.
- Risk register, including risk acceptance with supporting evidence.
- Documentation of the various roles, privileges, and access control matrix.
- Network architecture diagram elaborating on the following details:
-Identified network segments in scope for the test
- Servers
- Security controls/appliances
- Network/data flow
- List of all expected services and ports exposed at the perimeter.
- Development and infrastructure teams (whether in-house or from external contractors).
- Logging mechanism: Agency Security Operations team, and/or GCSOC.
2.2.3.1.3 Pre-engagement logistics
The Customer agrees to support the Suppliers with reasonable and appropriate logistical requirements for the VA. This may include the following:
Assigning a Point-of-Contact (POC) from the Customer to liaise with the Supplier on all logistical issues.
Provisioning of the test environment. The Customer is responsible for ensuring that the test environment is stable, and the testing machines can access the target nodes successfully. The Customer should also provide system output to ascertain that the test environment and testing machines have been successfully configured prior to the scan.
Providing information on any scheduled downtime or changes to the testing environment which should be taken into account during scoping.
Providing credentials to assume various roles and tenants (if applicable). The Customer is responsible for ensuring that credentials are working before the start of VA fieldwork and should provide evidence of the same.
Providing support for authenticated scans, including cases where Multi-Factor Authentication (MFA) is deployed (e.g. disabling MFA, setting OTP to a known value, whitelisting scanners to bypass MFA, etc.), restoring the application to its original condition after.
For remote VA, provisioning of access for suppliers to target nodes (e.g. via IP whitelisting).
Whitelisting the testing machine IP in the IDS/IPS/Firewall/AV or similar mechanism that could otherwise block scan traffic.
If the scanner is directly installed onto a Customer provisioned VM or laptop, whitelisting the scanner in AV or similar mechanism.
Notifying the GCSOC and SOC to suppress alerts during the test duration, inclusive of the post-review period.
For on-site VA (where applicable):
Clearance of the Suppliers’ testing machines
Provisioning of testing machines of mutually agreed upon technical specifications
Provisioning of a reasonable working area with desk and chair, functional power outlets and access to bathroom facilities
The Customer should perform a system backup prior to the scan.
For Network VA
Whenever possible, the Supplier should place network scanners within the same network partition as the targets it will be scanning, with no firewall between the scanner and the target. The Customer should support the Supplier in achieving this.
The Customer should support the Supplier with the required credentials (e.g. account credentials) to perform authenticated VA.
The Customer should ensure that network traffic throughout the full TCP/UDP port range (1-65535) is allowed between the scanner and the targeted machines.
For Web App VA
- Provisioning of minimum 1 user account per role (including admin role) and access control matrix for web app VA.
- The Customer should provide an application walkthrough to the Supplier with an Application User Guide or UAT Report to support scoping.
- The Customer should provide a list of application URLs/endpoints (i.e. application sitemap) to the Supplier for use in conjunction with the DAST tool prior to the scan.
- The Customer should ensure that each application page has transactional data to allow the tool to run successfully.
- Support for disabling/disarming rate limiting features (e.g. CAPTCHA) to allow the tool to run successfully and to restore the application to its original condition afterwards.
- Prior to Web App VA, the Customer may disable services that may incur additional costs to the Customer (e.g. SMS/email notification). Alternatively, the Customer may provide a list of URLs to be excluded from scanning.
- The Customer should ensure that network traffic on the applicable TCP port numbers (e.g. 443/80) is allowed between the scanner and the target machines.
- The Customer should perform a backup of the application database as well as the integrated components before the start of the scan (e.g. if the application directly manipulates the AD, then the AD should also be backed up)
2.2.3.2 Fieldwork
2.2.3.2.1 Methodology
An effective VA involves an automated scan, followed by validation of the scan results. The Supplier should perform authenticated scans, whenever possible. There are several considerations in the deployment of a VA scanner:
| Scanner type | Network Scanner Viewing the target from the outside (without credentials) |
Agent-Based Scanner Viewing the target from the outside (with credentials) |
|---|---|---|
| Description | A network scanner is a tool that identifies vulnerabilities in a network by scanning all the systems and devices connected to the network. Network scanners can detect open ports, services running on those ports, and vulnerabilities associated with those services. Network scanners are typically used by security professionals to identify weaknesses in a network and to prioritise remediation efforts. | An agent-based scanner is a tool that is installed on a host or device to identify vulnerabilities in that specific system. The agent continuously scans the host and sends the results back to a central server for analysis. Agent-based scanners are typically used in environments where traditional network scanners are not effective, such as in cloud environments, virtualised environments, or on mobile devices. |
| Coverage | Network scanners can scan entire networks, including all devices and systems connected to the network. | Agent-based Scanner scans the specific system on which they are installed. |
| Resource Utilisation | Network scanners use network resources to scan devices and systems, which can cause network congestion and slow down the network. | Agent-based Scanner uses system resources, which can affect the performance of the system being scanned |
| Deployment | Network scanners are easy to deploy as they do not require any installation on individual devices or systems. | Agent-based scanners require installation on each system to be scanned (test targets), which can be time-consuming and complex. |
| Accuracy | Network scanners can sometimes provide inaccurate results due to the complexity of the network environment. Scanning might be hampered when the scan traffic is dropped by WAF / IDS / IPS /AV or a similar mechanism that is monitoring the network traffic on the infrastructure. | Agent-based scanners, on the other hand, provide more accurate results as they scan the specific system and take into account the system's unique configuration. |
| Plugins | Runs check using the Remote plugin. | Runs check using the Local plugin. |
| Used for | Probing the services and ports. Brute-forcing using commonly used credentials and passwords. | Identifying missing patches and misconfiguration of the OS and middleware. |
| Firewall | If the scanner cannot be situated within the network segment and has to cross a network segment, the Customer needs to raise a Firewall Change Request to allow TCP/UDP for port 1-65535, to allow scan traffic between the scanner and the scan target. | During the setup of the agent, the Customer needs to raise a Firewall Change Request to allow the agent to synchronise the scan results back to the application portal. |
| Web Application Scan | The Supplier is to configure the entry points to the web application in the scan policy, before the scanner can run the Web Vulnerability Assessment Tool. | |
Network scanners and agent-based scanners are both effective tools for identifying vulnerabilities in networks and systems. Network scanners are ideal for scanning large networks and identifying vulnerabilities across multiple devices and systems. Agent-based scanners are ideal for identifying vulnerabilities in specific systems, such as cloud environments or mobile devices.
For authenticated scans, if the Customer already has agents installed on the endpoints, they may perform the scan and furnish the scan results to the Supplier for validation. Otherwise, Customers should provide the necessary administrator credentials for the Supplier to perform authenticated network scans.
In addition, scans should be performed from within the internal network, and not from the Internet.
2.2.3.2.2 Conduct
The Supplier should review and validate scan results to identify and remove false positives.
The Supplier should export and furnish raw results to the Customer.
For Web App VA
- The Supplier should ensure that their scanners can detect session invalidation and perform automated session renewal for scans to remain authenticated.
- The Supplier should configure its scanners to be able to scan endpoints which require pre or post- requests such as forms with anti-CSRF tokens or multi-step forms.
- The Supplier should be aware of endpoints and functionalities that have an adverse effect from large volumes of scanning requests or automated crawling such as the following:
= Functions that incur charges on third-party services such as SMS
Administrative interfaces with application-wide configuration settings such as updates to a database connection string or a button to reset to factory settings
Non-production hosts or applications with integration to Production services such as Active Directory
The Supplier should inform the Customer when testing such endpoints and functionalities and (a) seek the Customer’s approval for such tests and (b) implement mitigating controls before the conduct of such tests.
2.2.3.2.3 Industry tools and configurations
The Supplier should perform VA scans using reputable, industry- recognised (e.g. Leaders in Gartner Magic Quadrant or equivalent) scanning tools. A non-exhaustive list is provided below as a reference:
Network VA
- Tenable Nessus Professional (with/without Tenable. sc)
- Rapid7 Nexpose
- Amazon Inspector
Web VA
- Synopsys WhiteHat Dynamic
- Portswigger Burp Suite Pro (Active Scan with Session Handling, Macros and relevant Extensions)
- OpenText WebInspect,
- HCL AppScan (Previously known as IBM AppScan),
- Rapid 7 App Spider
- Qualys Web Application Scanning (WAS)
- Tenable.io WAS
Cloud VA
- Tenable Cloud Security
- Prowler
- NCC Group Scoutsuite
- Aquasecurity Cloudsploit
The VA scanner should be configured by the Supplier to be updated to the latest security vulnerabilities signatures prior to the VA scan.
2.2.3.2.4 Fieldwork logistics
The Supplier should provide regular (e.g. weekly) status updates via email or meetings for the duration of the fieldwork.
For discovery of High/Critical severity findings, the Supplier should inform the Customer within 24 hours of such finding.
The Customer should not make changes to the testing environment once agreed with the Supplier that may impact the fieldwork in terms of behaviour or functionality, unless necessary. Events that may impact fieldwork include:
- Remediation of identified vulnerabilities
- Feature updates
- Changes in application logic
- Software version updates and patches
If incremental features, additions or changes are made as part of agile development practices, the Customer should identify and log such changes for future testing.
2.2.3.3 Reporting
The Supplier should provide a report including a list of validated vulnerabilities identified from the VA scan. The report should minimally contain the following components:
- Sequential finding ID per scope
- Brief description of the vulnerability
- Risk Severity of the vulnerability
- Evidence of vulnerability (e.g. screenshots, server banner)
- Recommendations for remediation and/or mitigation
The Supplier should assign base metrics for reported vulnerabilities using the Common Vulnerability Scoring System (CVSS) version 3 or newer. The Supplier may also collaborate with the Customer to assign temporal and environmental metrics to derive a more contextualised CVSS severity.
Where the Customer does not agree with the CVSS severities proposed by the Supplier, the Customer should discuss and clarify with the Supplier and provide relevant input that may moderate the CVSS severities. This input should be technical and not people and process- oriented. The Supplier should consider this input when revising and validating the findings, including their severities.
The Customer should perform a risk assessment of the identified vulnerabilities (e.g. using ICT RMM) and seek risk acceptance for findings that cannot be remediated within the established timeframe.
If required, the Supplier should validate the remediation/mitigation and provide evidence of remediation/mitigation via a rescan.
For Web App VA, the report should include the list of URLs/endpoints that have been scanned to assess coverage.
For Network VA, the report should include the list of IP addresses that were scanned and indicate whether the scan was conducted using an external Network scanner or endpoint scanner, whether the scan was performed from the production LAN or management LAN and whether a direct connection or remote VPN connection was used.
The Supplier should declare any extenuating circumstances that were encountered during the fieldwork that might negatively affect the scan results (e.g. Application was only partially functional during the scan).
If there is insufficient time to complete the scan, the Supplier should at its discretion, request for an extension of testing duration to complete the scan.
The report should include the name and version of the scanner used, along with the last definition updates applied to the scanner in this report.
2.2.3.3.1 Prioritisaion for remediation (CVSS)
The Customer should prioritise remediation based on the CVSS severities of the identified vulnerabilities in the scan report, according to the established timeframe. If the Customer is unable to complete remediation within the timeline, the Customer should perform a risk assessment (e.g. via ICT RMM) and seek risk acceptance of residual risks at the appropriate forum.
2.2.3.4 Post-engagement matters
If requested by the Customer, the Supplier should secure erase and destroy any data (including Confidential Information) obtained in connection with the testing.
The Customer should document and track individual findings internally (e.g. as a GitHub issue or GitLab vulnerability report.
The Customer should document and track remediation efforts internally (e.g. screenshots, code changes, configuration changes, etc).
