|
I see multiple remediation tickets created for the same QID on the same host |
|
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 VM/VMDR > Remediation > Policies > New > Reorder. Move a rule up in the list to increase its priority or move it down to decrease its priority.
Tip - If you have a rule that specifies tickets should not be created when conditions are met, then make sure that rule is at the top of the list so it is applied first and a ticket will not be created.
Who can reorder policy rules?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.
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.
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.
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 policyNo 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.
To create ticket for cloud agent asset, assign "Cloud Agent" tag in the policy rule. Similarly, you can create ticket by assigning "All" group or asset group having IP tracked entry of cloud agent asset in the policy rule. Policy Rule created with "ALL" asset group must have IP addresses for cloud agent in the VM license container.
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.
Note: In AGMS and network-enabled accounts, the ticket assignee list has only the users with access to that particular host.
How to create a ticket from a scan reportHow to create a ticket from a scan report
Go to VM/VMDR
> 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 informationHow to create a ticket from host information
Go to VM/VMDR > 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.
Note: If Asset Group Management Service (AGMS) is enabled for your subscription, you will see the Address Management tab instead of Host Assets. To understand the changes that happen when AGMS is enabled for your subscription, refer to Introducing AGMS.
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 moreLearn more
The status of the ticket will be based on the following conditions:
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 VM/VMDR > 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 VM/VMDR > Remediation > Setup > Remediation to change permissions for Scanners and Readers.
Go to VM/VMDR > 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.
When Qualys updates the QID severity level, it gets reflected on the remediation ticket listing page (Remediation>Tickets tab) only after executing the subsequent scan. However, the Ticket Information, Host Information, ASR (Asset Search Report) display the updated QID severity level.
Example: There is a policy rule with severity level = 5. A ticket gets created after running the scan with severity level 5. Qualys updates a severity level after a few days from 5 to 3. The updated severity level 3 is displayed on the page (Ticket Information, Host Information, ASR) except remediation ticket listing page.
Multiple remediation tickets may appear for a single QID on the same host. This is because each instance of these QIDs is technically distinct according to the following criteria:
If the asset group is configured with DNS and used in remediation policy, then policy evaluation fails, and the remediation tickets do not get created. This is an expected behavior. During scan processing, the backend service (AGMS) resolves only IPs from the asset groups, not DNS. Due to this, policy evaluation fails for such assets, and remediation tickets do not get created.