|
Why flagged QIDs not included in the scan result or scan report? |
|
|
|
Search lists are custom lists of vulnerabilities that you can save and use in order to customize vulnerability scans, reports and ticket creation.
You can use search lists in a number of ways.
Scanning - Limit a vulnerability scan to only a select list of QIDs or only scan vulnerabilities for a particular vendor like Apache or Microsoft. Simply add your search lists to the option profile you want to use for the scan.
Reporting - Use search lists to filter the QIDs in your vulnerability scan reports. In this case you add search lists to your report template.
Remediation - You need search lists for creating policy rules. The search lists determine which vulnerabilities result in ticket creation.
A Static search list includes a specific list of vulnerabilities (QIDs) that you select. A Dynamic search list has a set of vulnerability search criteria that you select. When you use a dynamic search list, we'll automatically find all the QIDs that match your criteria.
Here are some examples:
- Create a dynamic list for an always up-to-date Microsoft patch Tuesday scan report, scan option profile and remediation rule.
- Create a dynamic list of QIDs flagged for PCI compliance.
- Create a dynamic list of QIDs for a particular vendor or product, such as Apache, Cisco, Microsoft, or Sendmail.
- Create a dynamic list of QIDs that are remotely exploitable on the .net framework.
- Create a static list of QIDs for troubleshooting and verifying authentication.
- Create a static list of QIDs to exclude from scans and reports.
- Create a dynamic list of CVE IDs you're interested in. For a large list of CVE IDs, we recommend using the Dynamic Search List API since the UI is limited in the number of characters you can enter. Refer to the API User Guide for more information.
From the Search Lists tab, go to New > Import Search List. There are several pre-defined search lists for you to choose from. Select the search lists you like and click Import. The search lists will be copied to your account.
Select the option "Make this a globally available list" in the search list settings. When a Manager takes this action, the list is available to all users in the subscription. When a Unit Manager takes this action, the list is available to all users in their business unit. You can clear this option at a later time and the search list will no longer be available to other users.
When creating a new search list, the user creating the search list is set as the owner. Managers and Unit Managers have the option to change the search list owner. To change the owner, first save the search list and then edit the search list. On the Edit page, select a different user from the Owner menu. The possible assignees listed in the Owner menu depends on the global status of the search list, the role of the manager making the change, and the current owner's role and business unit.
Who can own global and non-global search lists?Who can own global and non-global search lists?
Global search lists may be owned by Managers and Unit Managers.
|
User Taking Action |
Current Owner |
Possible New Owner |
|
Manager |
Manager in the Unassigned business unit |
Manager in the Unassigned business unit |
|
Manager |
Unit Manager in a custom business unit |
Manager in the Unassigned business
unit |
|
Unit Manager |
Unit Manager in a custom business unit |
Unit Manager in the same business unit as the current owner |
Non-global search lists may be owned by Managers, Unit Managers, Scanners and Readers.
|
User Taking Action |
Current Owner |
Possible New Owner |
|
Manager |
Manager, Scanner or Reader in the Unassigned business unit |
Manager, Scanner or Reader in the Unassigned business unit |
|
Manager |
Unit Manager, Scanner or Reader in a custom business unit |
Manager in the Unassigned business
unit |
|
Unit Manager |
Unit Manager, Scanner or Reader in a custom business unit |
Unit Manager, Scanner or Reader in the same business unit as the current owner |
Tell me about conflicts with business objectsTell me about conflicts with business objects
Changing the search list owner may lead to conflicts with option profiles, scan report templates, and scheduled tasks. Conflicts occur when the search list is no longer available to the owner of a business object using the search list.
After you save the search list with the new owner, a Warning page appears with messages to assist you in resolving conflicts. Click the View Report button to see a list of option profiles, report templates, and scheduled tasks affected by the change. Edit the affected business objects to change the assigned search lists. If a scheduled task is left without a valid option profile before the next scheduled run time, then the scheduled task is automatically deactivated and the task owner is notified by email.
Tip - If you're changing the owner to a Manager or Unit Manager, then you may consider making the search list global before making the change. This way you can avoid conflicts and allow users to continue using the search list.
This may occur for vulnerabilities that have half red / half yellow severity (
) . The half red / half yellow severity level in the KnowledgeBase represents vulnerabilities that may be confirmed in some cases and not confirmed in other cases because of various factors affecting scan results. If the vulnerability is confirmed during a scan, it appears as a red vulnerability in the results. If it cannot be confirmed, it appears as a yellow potential vulnerability in the results.
QIDs with the half red / half yellow severity match both confirmed and potential. That means these QIDs would match search lists for both confirmed and potential.
If you create a search list that includes all confirmed QIDs and excludes all potential QIDs, then the QIDs with half red / half yellow severity will be excluded. This is because these QIDs match confirmed and potential, and your report will always exclude the QIDs in the excluded list.