A policy includes a set of rules that tell us when to create tickets, who to assign them to, and how quickly they should be resolved. You can have one global policy for the subscription and one policy for each business unit.
Policy rules are applied to scan results in the order in which they are listed. The rule at the top of the list has the highest priority and is applied first. To change the order, go to Remediation > Policies > New > Reorder. Move a rule up in the list to increase its priority or move it down to decrease its priority.
Who can reorder policy rules?
Managers can reorder policy rules for the global remediation policy (business unit "Unassigned") and for any business unit's policy. Unit Managers can reorder policy rules for their business unit only.
If a detected vulnerability matches more than one rule, the action specified for the first rule it matches takes precedence. For this reason, if you have a rule that specifies tickets should not be created when rule conditions are met, then that rule should be at the top of the list.
Scan results are first compared to the user's business unit policy and then to the global policy. If the user who launched the scan is not assigned to a business unit or if the user's business unit does not have a policy, then the scan results are only compared to the global policy.
Scan results from users in the Unassigned business unit
If the user who launched the scan is not assigned to a business unit, such as a Manager user or another user in the Unassigned business unit, then the scan results are only compared to the global remediation policy. The scan results are not compared to business unit policies. If a global policy does not exist, then no tickets are created.
Scan results from users in a business unit with a business unit policy
If the user who launched the scan is assigned to a business unit and the business unit has a remediation policy, then the scan results are first compared to the user's business unit policy. If the results don't match conditions in the business unit policy, then the results are compared to the global remediation policy.
Scan results from users in a business unit without a business unit policy
If the user who launched the scan is in a business unit that does not have a remediation policy, then the scan results are only compared to the global remediation policy. If a global policy does not exist, then no tickets are created.
No global remediation policy
Managers may choose not to create a global remediation policy and instead delegate this responsibility completely to the individual business units. In this case, only scans launched by users in the business units with policies will result in tickets. Scans launched by Managers and other users outside of the business unit will not result in tickets.
For example, let's say that the only policy in the subscription is a business unit policy created by a Unit Manager to create tickets for all severity 5 vulnerabilities. In this case, if a user in the business unit launches a scan and 10 severity 5 vulnerabilities are detected, then 10 tickets are created and assigned to the user designated in the policy. (Note that the ticket assignee may be somebody outside of the business unit when "Asset Owner" is used.) If a Manager in the same subscription launches a scan on the same hosts and 10 severity 5 vulnerabilities are detected, then no tickets are created. This is because the Manager is not in the business unit and there is no global remediation policy established for the subscription.
The service automatically creates new tickets when detected vulnerabilities match a remediation policy in the account. New tickets are created on a continuous basis as new scan results become available.
Yes. Tickets are created when vulnerabilities detected from agent scans match a remediation policy in the account. When the policy is set to assignee "User Running Scan" tickets will be assigned to the Manager Primary Contact for the subscription.
Yes. You can manually create a ticket for any vulnerability instance. You can create a ticket from a scan report with the vulnerability listed or create a ticket from host information.
How to create a ticket from a scan report
Go to VM > Reports > Templates. Run a scan report template that is configured with host based findings. Choose the HTML report format. When your report appears online scroll down to the Detailed Results section and click next to the vulnerability instance you want to create a ticket for. Then choose Create ticket from the menu that appears.
How to create a ticket from host information
Go to VM > Assets > Host Assets or Assets > Asset Search, find a vulnerable host and then open the Host Information page for that host. Select Vulnerabilities on the left side and view the list of vulnerabilities (or potential vulnerabilities). Click next to the vulnerability instance you want to create a ticket for. Then choose Create ticket from the menu that appears.
The service automatically adjusts ticket state/status as new scan results become available. For example, if a user has marked a ticket Resolved and a subsequent scan verifies that the issue has been successfully fixed, then the service will close the ticket.
There are a few ways that a ticket can be closed. The most common is that you've fixed the vulnerability, and a new scan has verified the fix. In this case, the ticket will be automatically closed for you. You can also close/ignore a ticket if you don't plan to fix the vulnerability. Learn more
Tickets that have been resolved or closed will be reopened automatically if the related vulnerability is detected by a new scan. Users can also manually reopen a ticket. Learn more
The Reopen ticket option allows you to automatically reopen the ticket in a set number of days. You can select this option from the UI (host information) and from within template based scan reports with host based findings. Learn more
The ticket state will change from Closed/Ignored to Open on the due date, assuming the issue still exists, and the ticket will be marked as overdue. If the issue was resolved at some point while the ticket was in the Closed/Ignored state, then the ticket state will change from Closed/Ignored to Closed/Fixed.
After applying a fix launch a new scan on the host to verify the fix and close the ticket. Remediation options set for the subscription determine if a user must mark a ticket resolved before it can be closed or if the service can immediately close an open ticket when a fix is verified by a new scan. Go to Remediation > Setup to see options related to ticket transitions.
The scan options set at the time of the scan determine which tickets are updated. Scan results are applied to tickets in the following ways:
- Scan results from a selective vulnerability scan are only applied to tickets related to the target vulnerabilities.
- Scan results from a partial port scan are only applied to tickets related to those specific ports.
- Scan results from an authenticated scan are only applied to tickets created as the result of an authenticated scan. If a ticket is opened as the result of an authenticated scan and you fix the vulnerability, you must run another authenticated scan on the host to verify the fix and close the ticket.
Managers and Unit Managers have permission to ignore and delete tickets. Scanners and Readers can ignore and delete tickets on hosts only when these remediation options are set for the subscription. Go to Remediation > Setup > Remediation to change permissions for Scanners and Readers.
Go to Remediation > Tickets. Select the tickets you want to reassign and choose Edit from the Actions menu. Then select a user to assign the tickets to.
This depends on whether you have the Daily Trouble Tickets email notification option enabled in your account. Select User Profile below your user name (in the top right corner) and then go to the Options section to see and edit notification options.
This option is available to Managers, Unit Managers, Scanners and Readers. Users with Remediation User role will default to 30 days.