Vulnerability Scanning Guide
Parent topic: Vulnerability Scanning and Patch Management Guide
This guide explains the scanning requirements for Ministry of Justice (MoJ) systems.
This guide is a sub-page to the Vulnerability Scanning and Patch Management Guide.
The MoJ should conduct the following scanning activities outlined in this guidance and in line with the requirements identified in this guide.
- If you are developing a system or application, you must ensure that they are scanned for vulnerabilities prior to live deployment and as part of approval for live deployment.
- If you are managing a live service, you must ensure that the system or application is scanned at specified intervals after deployment until it is withdrawn from service.
The scanning frequency section in this guide gives the minimum scanning requirement, however the system or application itself may need to be scanned more frequently. Any specific scanning frequencies or requirements will be outlined in the system or application Information Risk Assessment Report (IRAR).
An IRAR is normally completed by Security Architects and Risk Assessors, in conversation with the system architects, designers and developers. The IRAR document must also be agreed with the Business Continuity Team. For more information regarding IRARs, and how to create and maintain them, contact the Security team.
- Scanning must be conducted through automated vulnerability scanning tools that scan web applications, from inside or outside the system, to look for security vulnerabilities.
- The scanning process should consider the licensing and support status for an infrastructure device, its operating system, or any applications hosted on the device.
- Scans which take place one year before the expiry of a license or vendor support should flag the forthcoming expiry as requiring attention and remediation such as license renewal or equipment replacement.
- Examples of known vulnerabilities which must be scanned for include cross-site scripting (XSS), SQL injection, command injection, path traversal, and insecure server configuration.
- If scans identify vulnerabilities, patches must be applied according to the schedule described in the Patch Management guide.
For assistance with identifying, evaluating, and selecting appropriate tooling for scanning, contact the Security Team.
Note: Expired or missing license or support materials for a system or service are also considered to be vulnerabilities. The reason is simple - using a system or service without the necessary license might result in financial or reputational loss. Similarly, using a system or service without the necessary support in place might result in loss of availability, performance, integrity, confidentiality, or other problems.
Point in time scanning
By default, all applications and services should be scanned automatically, on a regular basis. However, there will be occasions where extra, ‘Point in time’ vulnerability scans are required. These provide an assessment of the vulnerabilities at that point in time.
An example might be following a significant configuration change or application update, and it is considered advisable to check for vulnerabilities at that point in time, rather than waiting until the next, scheduled check.
In addition to specific scanning processes, the NCSC’s Web Check services must be employed for all open internet facing websites operated by the MoJ. Web Check continuously scans these websites and provides regular reports to the Security team. If you are responsible for developing or running a website for the MoJ, you must:
- Ensure that it is added to the MoJ HQ Web Check Account. Contact the MoJ Security team to be added to the MoJ Web Check Account.
- Ensure that any vulnerabilities identified are patched according to the Patching Schedule in the Patch Management guide.
Further information on the NCSC’s Web Check service can be found here.
Scanning should be undertaken in line with the following indicative schedule for each system and equipment type.
|System and equipment type||Minimum scanning frequency|
|Internet Facing Websites and Digital Services||Every week.|
|Infrastructure Devices||Every week.|
|Server Applications||Every week.|
|End User Clients||Every two weeks.|
The actual minimum scanning frequency for a given service or system might be determined by a separate Service Level Agreement, contract, IRAR or other formal agreement. If there is a conflict with the Scanning Frequency defined in this guide, the contract, IRAR or other formal agreement takes precedence over this guide.
You need to ensure that scanning logs and results are made available to the MoJ Security Team (email@example.com) for subsequent analysis and potentially forensic investigation purposes.
Any problems picked up during scanning must be recorded and reported as a vulnerability alert. As a minimum, the alert should be reported to:
- The system owner.
- The person responsible for risks regarding the system.
- The person responsible for risks regarding the information accessed or processed using the system.
- The Security Team.
These vulnerability alerts must contain as a minimum:
- An alert identifier.
- A cross-reference to known vulnerabilities.
- A risk rating (refer to the following Vulnerability risk ratings section).
- A description of the fix, mitigation, or workaround, where known.
- A link to patch materials, if available.
- A status which is updated as necessary.
- Where to get further information.
Vulnerability risk ratings
Vulnerabilities are designated a severity rating (1-4) based on the level of risk they pose to the MoJ. The schedules defined in the Patch Management Guide for remediation are aligned with the risk exposure the vulnerabilities create to systems. The vulnerability ratings are based on the Common Vulnerability Scoring System (CVSS) which is aligned with the Cyber Essentials Scheme. If vendors use different terminology to define Critical or High Risk vulnerabilities, the following table should be used to define the CVSS score of the vulnerability:
|Rating (Severity)||Values on CVSS||Definition|
|Critical (4)||9.0 - 10.0||High, with compounding issues or additional circumstances. An issue that will cause extreme financial or reputational damage.|
|High Risk (3)||7.0 - 8.9||A serious issue that is likely to cause severe financial or reputational damage.|
|Medium (2)||4.0-6.9||A significant issue that may cause financial or reputational damage.|
|Low (1)||0.0 - 3.9||An issue that is unlikely to cause financial or reputational damage.|
|Info||N/A||An issue with no immediate security implications.|
Roles and responsibilities
If you are responsible for a system or a service which is managed by a vendor, or a Managed Service Provider, the vendor may be responsible for scanning and alerting you of any vulnerabilities and providing patches. Please refer to the Patch Management Guide for more information. The specific responsibilities will depend upon the services provided by the vendor and any contractual agreements between the MoJ and the vendor.
The schedules for vendors to conduct vulnerability scanning and issue vulnerability alerts to the MoJ are outlined in this guidance.
- Scanning after Scheduled Patch Releases: Scan to take place within two business days from the implementation of the patch as required by the Patching Schedule Service Level Agreement in the Patch Management Guide. The MoJ must be alerted of any vulnerabilities within 1 business day of the scan being conducted.
- Scanning after Ad Hoc / Off Cycle Patch Release: Scan to take place within three business days from the implementation of the patch as required by the Patching Service Level Agreement in the Patch Management Guide. The MoJ must be alerted of any vulnerabilities within 1 business day of the scan being conducted.
The actual scanning schedule for a given managed service or system may be determined by a separate Service Level Agreement, contract, IRAR, or other formal agreement. If there is a conflict with the requirements in this guide, the contract, IRAR or other formal agreement takes precedence over this guide.
If you are developing or running a system or application in-house, you must make sure that it is scanned. Where centralised scanning is not possible, the system owner is responsible for ensuring that scans are undertaken with at least the frequency defined in this document and in sufficient depth to identify vulnerabilities in libraries, code or infrastructure configuration.
Contact the Security Team for advice on risk, scanning and patching, to report a vulnerability alert, or to add a URL to the MoJ Web Check system: firstname.lastname@example.org.
If you have any questions or comments about this guidance, such as suggestions for improvements, please contact: email@example.com.