Issue Parent/Child Relationship

Introduction

This article explores the mechanisms within the Platform that track and link together persistent/reoccurring issues.

The Parent/Child Relationship feature applies to Vulnerability Scanning projects only. Projects that are defined as Penetration Testing projects do not use this feature.

Overview

To effectively track persistent issues that reoccur over time (for example, across multiple weekly scans) the Platform implements a Parent/Child feature to link reoccurring issues together.

As can often be the case with vulnerability management, some issues/vulnerabilities may persist across multiple regular scans. This situation can arise when issues are not remediated in time before the next scan or in cases where remediation wasn’t effective and the issue continues to be reported after the next set of scan results are imported to the Platform.

Parent/Child Relationship

The Platform implements a Parent/Child relationship to identify reoccurring issues and link them together; creating a historic trail of an issue’s persistence.  In doing so, at any given time, users can easily understand the persistence of an issue whilst only seeing the latest occurrence of that issue in the Platform’s main Issues View

Every issue imported into the Platform, whether reoccurring or not, is given a Unique Issue Identification (UIID).  Whilst the UIID can pinpoint an exact issue within the Project and Scan in which it was discovered, where appropriate, the Platform uses the Parent/Child relationship to link all occurrences of these UIIDs together.

To explain this further, let’s assume that a single Project exists into which monthly scan results are imported into the Platform. Each month’s scan results are imported into their own Scan/Phase within the Project. This table below summaries how a persistent EOL/Obsolete Apache Server issue is tracked from the first January Scan to the last June Scan in Project X:

image-20240109-102725.png

Whilst many other fields are tracked in the Platform’s Issue Database, for the purpose of this article the key fields are the issues UIID, the Issue Name, the Affected Asset, and the Issue Relationship

The Issue Relationship(s) table illustrates how the Platform tracks persistent issues and updates these relationships every time a persistent issue is detected after scan results are imported.

  1. After the import of scan results from January Scan, the issue and affected host is first ‘seen’ by the Platform.  The Platform updates the Issue Database as follows:

    1. A UIID of 11 is assigned to the issue in the Issue Database

    2. The Issue Relationship entries are updated for this issue as follows:

      1. The value for First Issue Occurrence is set to a UIID of 11

      2. The value for Latest Issue Occurrence is set to a UIID of 11

      3. The value for Parent Issue is null since this is the first occurrence of the issu

  2. Following the import of scan results from the February Scan, the same issue persists on the same affected host (192.168.1.1). The Platform updates the Issue Database as follows:

    1. A UIID of 43 is assigned to this issue in the Issue Database

    2. The Platform detects this is a persistent/reoccurring issue and updates the Issue Relationship values as follows:

      1. The value for First Issue Occurrence will always be when the issue first occurred.  In this case the UIID of 11 is used (from January’s Scan)

      2. The Latest Issue Occurrence will update for each new occurrence of the issue.  In this case UIID 43 from the latest scan results in February

      3. The Parent Issue will update to reflect the UIID of the prior occurrence of the issue.  In this case UIID 11.

For the platform to consider an issue persistent/reoccurring, a match must occur on both the Issue Name and the Affected Asset from an earlier occurrence of the issue.

As the table above illustrates, for subsequent monthly scan imports for March, April, May and June, the Latest Issue Occurrence and Parent Issue values update each time a new occurrence of the persistent issue is imported into the Platform.  Over time, this creates a historic ‘trail’ for every persistent issue.

Viewing Parent/Child Issues in the Platform’s Issue View

Navigating to ResultsIssues in the Platform will display all current/active issues being tracked by the Platform. In the Issue view, only the latest occurrence of a persistent issue is displayed.

The following screenshots are taken from the main Issues view for a Scan Project in which 3 weekly scans have occurred. None of the 5 reported issues have been remediated.  As shown, only a single occurrence (the latest) is displayed for each of the 5 issues.

image-20240109-103508.png

When viewing 1 of the 5 issues individually, the Platform also reports occurrence information where applicable. This includes on number of occurrences for the issue, when the issue was first seen and when it was last seen as well as the Scan/Phase in which the first or last occurred.

Viewing Parent/Child Issues for a Specific Scan

When viewing the results of a specific scan, the Platform displays a banner when a user is not viewing the latest occurrence of a persistent issue

Using the Apache Struts Showcase…. issue above, since this issue occurred and persisted over three weekly scans, looking at the second-week scan would show a banner:

To view the First occurrence, Last occurrence or Parent Issue, use the Actions button in the top-right of the issue view, as shown below:

Importance of Order When Manually Importing Scan Results

In situations where users upload, import and publish scan results manually, it is necessary to import results in chronological order to maintain the accuracy and integrity of the Parent/Child relationships.

For example, if you are tasked with manually importing a week’s worth of daily scan results from a Tenable Nessus Professional scanner, ensure a chronological order is followed when importing, starting with the oldest scan first:

  • Create a Scan with a Date field that matches when the scan was performed and not the date you are performing the import (unless of course the two are the same!)

  • Within the Import Issues screen for a newly created Scan (above), ensure the Confirmed At date also matches when the scan was performed

In this example below, both the Scan details and the Confirmed At details are set to 04/01/2024

Setting the Date for a new Scan

Setting the Confirmed-At Date for Imported Issues

 

Summary

The Parent/Child feature is an important feature when managing persistent issues over time. The navigational options within an specific Issue allow a user to explore and understand the persistence of an issue. Furthermore, when a user’s workflow primarily starts within the main Issues view, it is unnecessary to display every single occurrence of a persistent issue as this can clutter an otherwise important view of active issues being tracked by the Platform.

Whilst the Parent/Child feature is always enabled, every occurrence of a persistent issue is retained by the Platform along with a facility to view any single occurrence of a persistent issue by viewing the specific scan in which the issue occurrence was originally observed/imported.