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).
v 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.
v 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:
v 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.
v Classification:Filter the findings based on classifications described in this topic.
Classification rules are restrict-only.
v 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 assessmentin 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).
v API: Filter all vulnerabilities of a specific API.
v File: Filter all vulnerabilities from a specific file.
v Directory: Filter all vulnerabilities from a specific directory.
v Project: Filter all vulnerabilities from a specific project.
v Trace: Allows you to filter findings based on trace properties (see “Sources and sinks” on page 163 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 disabledhover text.
You can also refine the filter by mechanism or technology by using the Add a VMAT propertybutton 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 Filterfield.
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.HTTPfilter in the Source Properties section and Vulnerability.Injection.SQLand 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.