Triage with filters

Filter overview

Filters remove or restrict items that meet the criteria determined by filter rules and help you manage scan results during triage or reporting. A filter helps guide workflow and focuses security analysts on the most critical areas of a subset of findings. For example, during code examination, an analyst may create a filter to avoid viewing low severity findings. Alternatively, the analyst may prefer to exclude vulnerabilities in system library include files. A filter can eliminate these items from view, and may exclude individual files or files that have been previously investigated.

Filters can be applied before or after scanning:

• To apply filters before scanning, you set global filters in project or application properties - or you scan with a scan configuration that includes filters. When you apply filters before scanning, you cannot show unfiltered findings or remove the filter without scanning again.
• Various views (in particular, the Filter Editor view) allow you to apply filters after scanning. When these views are used for filtering, all filtered items remain in the scan results - but only appear in the Findings view if the Show Filtered Findings () toggle is selected.

AppScan Source includes several predefined filters that can be selected for filtering scan results.

Once you have a filter, you can set a property to make the filter an exclusion. An exclusion affects scans and eliminates all findings that match the filter or alternatively, all findings that do not match the filter.

Filter rules

Each filter consists of rules that define which findings to restrict (include) or remove (exclude) from the results in the findings table (for trace rules, you can both restrict and remove based on trace properties).

• A Restrict to rule (inclusive rule) excludes findings that do not have the specified criteria and removes these findings from the visible results in the findings table.
• A Remove rule (exclusive rule) removes findings that contain criteria from the scan results. A remove rule excludes any findings that have the specified criteria and removes these findings from the visible results.

A filter rule may include these traits:

• Severity: Identifies the potential impact or risk of the individual findings. Severity rules are restrict-only.
  • High: Poses a risk to the confidentiality, integrity, or availability of data and/or the integrity or availability of processing resources. High-severity conditions should be prioritized for immediate remediation.
  • Medium: Poses a risk to data security and resource integrity, but the condition is less susceptible to attack. Medium-severity conditions should be reviewed and remedied where possible.
  • Low: Poses minimal risk to data security or resource integrity.
  • Info: The finding, itself, is not susceptible to compromise. Rather, it describes the technologies, architectural characteristics, or security mechanisms used in the code.
• Classification: Filter the findings based on classifications described in this topic. Classification rules are restrict-only.
• Vulnerability Type: Filter by a particular vulnerability category, such as BufferOverflow. When you add a vulnerability type, you can select from all possible vulnerability types - or you can choose from only those types that have been found in the current assessment. To choose from vulnerability types that have been found in the current assessment, select Show only values from open assessment in the Select Values dialog box.

  Selecting from all possible vulnerability types is useful when you are creating a filter for future scans. To display all vulnerability types, deselect Show only values from open assessment (if there are no open assessments, all vulnerability types display by default and the Show only values from open assessment check box is unavailable).

• API: Filter all vulnerabilities of a specific API.
• File: Filter all vulnerabilities from a specific file.
• Directory: Filter all vulnerabilities from a specific directory.
• Project: Filter all vulnerabilities from a specific project.
• Trace: Allows you to filter findings based on trace properties (see Sources and sinks to learn more about trace properties). Filters can include trace rules that both restrict and remove based on trace properties. When you click Add in either section (restrict or remove), the Trace Rule Entry dialog box opens. In it, you can specify:
  • Source: In the Source section API RegEx field, specify the trace source or a regular expression that covers multiple sources (the default entry is .* - the regular expression or wildcard which will return all). If you are using a regular expression, select the type in the RegEx Type field menu (the default regular expression type is PERL). If you are not using a regular expression, select Exact Match in the RegEx Type field menu.

    If the API RegEx entry is a valid expression, a green check mark icon will appear next to the field. If the entry is not a valid expression, a red X icon will appear next to the field and the dialog box OK button will be disabled. Hovering over either icon provides more information about the validation results. If you have made an entry that is not a valid expression, but you want to proceed with its use, select the Ignore validation errors above check box at the bottom of the dialog box. This will enable the dialog box OK button (so long as the expression is not empty) and the icon next to the invalid expression will change to a green check mark with Validation disabled hover text.

    You can also refine the filter by mechanism or technology by using the Add a VMAT property button in the Source Properties section (more information about VMAT properties is available below) - however using this feature to limit by vulnerability will not have the desired effect since vulnerability type is determined by sink and not the source.

  • Sink: In the Sink section, you can add sinks as filters in the same manner in which sources are specified.

    You can refine the filter by limiting it to specific vulnerability types (to limit the effect of the trace rule entry to just specific types of vulnerabilities, mechanisms, or technologies). To do this, click the Add a VMAT property button in the Sink Properties section and then select the property in the Choose Properties dialog box. The list of properties can be filtered using the Filter field.

    VMAT is a categorization of the four major types of properties that AppScan Source applies to application programming interfaces (API). VMAT property categories include:

    • Vulnerability: the type of exploit or attack vector that results in a security violation
    • Mechanism: the security control used to prevent a vulnerability
    • Attribute: these properties are not currently available in the Choose Properties dialog box
    • Technology: the general description for the type of functionality an API provides

    Filter example: To filter for all SQL injections and XSS coming from HTTP (your highest risk source), create a Restrict to trace rule that contains a Technology.Communications.HTTP filter in the Source Properties section and Vulnerability.Injection.SQL and Vulnerability.CrossSiteScripting rules in the Sink Properties section.

  • Required Calls: In the Required Calls section, add specific API calls that must be on the path from the source to the sink. Required calls limit the findings to those that have traces that pass through the specified required calls. When you click Add an intermediate call, the Configure API dialog box opens. In this dialog box, specify the call in the same manner that sources and sinks are specified.
  • Prohibited Calls: In the Prohibited Calls section, add specific API calls that must not be on the path from the source to the sink. Prohibited calls limit the findings to those that have traces that do not pass through the specified prohibited calls. Add a prohibited call in the same manner as required calls are added.
  Tip:

  • When filtering by Vulnerability Type, API, File, Directory, or Project, the list that displays in the Select Values dialog box can be filtered by typing a pattern into the filter field at the top of the dialog box.
  • In any findings table, look at the Source and Sink columns to get a feel for the sources and sinks that you want to filter out.
  • To get a feel for source, sink, and call properties that you want to filter, look at the Vulnerability Type column in any findings table.
  • To see calls that you may want to filter, view the entries in the API column in any findings table.

Filter examples