In GOS 4, the Greenbone Security Manager (GSM) for SME, MIDRANGE and ENTERPRISE (models 100 and above) offer several Alert methods to create an automatic workflow from vulnerability detections into a remediation process. The latter is a external ticket management system with a generic interface. Some special products are supported directly.
This makes sense for environments where already a powerful ticket management system is in place and vulnerability issues are meant to be handled with same procedures like other IT-related issues.
Introducing a new ticket management only to handle findings of GSM in workflow is something Greenbone was asked to help avoid by adding a integrated basic ticket management.
With GOS 5 a integrated remediation workflow is introduced for MIDRANGE and ENTERPISE (GSM 400 and above):
The integrated remediation workflow is a ticket management focussed on resolving the finding of vulnerabilities. Compared to a generic ticket management system it is much simpler and has less options. On the other hand, it is capable to automatically consider re-scans in order to verify that an assignee has indeed fixed a security problem. Additionally, all valuable information to understand and resolve a problem is directly cross-linked and thus directly available for an assignee.
The base concepts of the integrated remediation workflow are:
- Owner and Assignee must be user accounts on the same GSM.
- There are 4 states a ticket can have, “Open”, “Fixed”, “Fix Verified” and “Closed”.
- The workflow assumes Owner and Assignee work as a team. Therefore, both can edit/overwrite the content of a ticket equally, can close or re-open it. Only the owner can delete a ticket, though.
- If an Assignee has permission to see other users, it is possible that the Assignee can assign to another user.
- A ticket has no history other than the last status modification times and the text edited jointly by Owner and Assignee(s) in the status fields.
- If Owner or Assignee resets the ticket to an earlier status, the status texts will be kept unless changed or deleted explicitly. All times will be kept.
- Individual workflows can be modeled by applying Tags.
- One Result per Ticket: A ticket is linked only to a single results. However, for the same result, multiple tickets could be created.
- Severity: The severity shown in the ticket view is always the latest one of the respective result, and if an override exists, then the override is considered.
Automatic verification of fixes:
If the scan to which the ticket refers to is executed again and the vulnerability does not occur in the new scan report, then the status of the ticket is automatically set to “Fix verified” and a link to the respective new report is added.
Because many reported vulnerabilities are found by using authenticated tests, it mandatory that the scan report does not report about a failed login via SSH or via SMB for the respective host. Otherwise it could happen for example that a changed password leads to the assumption the vulnerability is closed. In essence, if a login failed, the ticket will not be set to “Fix verified”.
If the report or even the entire task where the ticket refers to is removed, the ticket is marked “Orphaned”. Naturally, no automatic verification will happen anymore.
If Owner or Assignee reset the status to “Open” or “Fixed”, the “Fix verified” is automatically reset as well, which means the reference to the report is removed.
Once the fix was automatically verified, subsequent further scans are not regarded anymore for this ticket. So, if the vulnerability would re-occur, the ticket status would not be changed. Either it needs to be re-opened manually or a new ticket needs to be created.
Email-Notifications:
In order get email notification about Tickets, a user creates Alerts with method “Email”. For the email alert three events can be distinguished: “Ticket Received”, “Assigned Ticket Changed” and “Owned Ticket Changed”.
Each of the event types can be configured separately, even with a different email address.
Note, that for the Email notification to work, an email service needs to be configured in the GOS setup.
Permission implications:
As soon as a ticket is assigned, the assignee gets read access to the respective task. Thus providing access to all reports and single results of this task. This also enables the Assignee to follow the reference into the scan report that verified the fix.
If the assignment of a ticket is withdrawn from a user, the permission to read the task remains. Whether there are permissions to a task can be seen on a task details page. Here it is also possible to remove unwanted permissions.
If multiple tickets for results of the same report are created for the same Assignee, then you will see the same permission multiple times.
If the Assignee of a Ticket is changed, the new Assignee does not automatically get permission to the Task. The ticket Owner could edit the permission via the Task details page and give it to another user.
Internal feature code: FS-180103-0646.