Security Policy Exceptions
Security Policy Exceptions
Contents
Security Policy Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
XFF Forwarded Addresses As Source IP Address Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
You can define exception for some policies when a specific part of the application does not comply with the security
policy in your organization. Using exceptions you can adjust the default SecureSphere policies to meet your
requirements and to prevent false positives by specifying exceptions that include conditions under which an alert is
not created.
For example, in some cases there are acceptable protocol violations for which you do not want the system to generate
an event such as specific URLs to/from which long strings are commonly transmitted, or certain methods that are
employed but do not fully comply with the standards.
Exceptions can be defined only for the policies that contain violations that might cause false positives and not for all
policies.
• In the Violations window, if you see a violation that is actually a false positive, you can define it as exception in
one click, see Taking Action on Alerts and Violations.
• In the Security window you can define exceptions manually for specific security policies.
1. In the Main workspace, select Policies > Security.The Security window appears.
2. In the Security window, select the policy for which you want to define an exception and then select Advanced.
The Advanced tab appears.
3. In the Exceptions pane, click . A new line appears in the Exceptions table.
4. From the drop-down list, select the rule/signature for which you want to define the exception.
5. Add a comment that explains the logic behind the exception, why the exception was added. Comments can also
be added when adding an exception from an alert.
6. Click Save. The Empty link appears in the Exception Summary column.
7. Click Empty. The Edit Exception window appears.
8. In the Edit Exception window, set the exception using match criteria mechanisms and click Save. The Edit
Exception window closes and the summary information appears in the Exception Summary column.
Note: The match criteria used to define exceptions is also used in custom policies. For match criteria
descriptions, refer to Custom Policies Match Criteria.
If, in the policy Exceptions pane, you define a web client’s IP address as the Source IP Address match criteria as
described above, the policy will not ignore connections from that client’s IP address if there is a proxy between the
client and the SecureSphere Gateway. This is true even if Identify real client IP according to HTTP forwarding
header in the HTTP service’s Operation tab is checked.
If the policy you want to modify is an ADC policy which cannot be modified, then clone it, that is, create another
policy based on (Use Existing) the ADC policy.
2. In the new policy, add Source IP Addresses to the Match Criteria (Match Criteria tab).
3. Set Operations to Exclude All.
4. Select the IP Group to exclude (ignore) under IP Groups, or specify a single IP address under User Defined.
5. Click the right pointing arrow to move your selection to the Selected box.
6. Save the policy.
7. Apply the policy to the service.
The Abnormally Long Header Line rule, see the following figure, is included in the Web Protocol Policy rules. If the
length of either the HTTP request Header name or value exceeds the maximum threshold, then the policy is violated,
as it indicates a buffer overflow attempt.
If the violation only occurs in the following specific location in the application: /products/productsline.asp., it is
clearly a false positive as the value is correct. This value is just a little bit longer than the others in the application. In
this case the options are as follows:
• Enable this rule, meaning that each time it happens, alerts and violations appear in the Monitoring workspace.
• Tune the HTTP Request Header Value Length parameter and the HTTP Request Header Name Length
parameter to accept values that are greater than the default values, which applies across the whole service,
meaning that SecureSphere will allow longer or shorter header values and names in all the HTTP requests.
• Disable the policy rule Abnormally Long Header Line so that it does not apply any more to the service,
meaning that this rule will not be applied to any of the HTTP request headers and the real attack will not be
prevented.
• Create an exception directly from the violation or manually in the Security window, meaning that only in the
request headers from that specific URL SecureSphere will not send alerts and will not block the traffic each time
the abnormally long names or values are detected.
Enabling this rule and using it as is will cause a lot of false positives. Tuning the rule to accept greater values or
disabling the rule will seriously compromise the security level. The most accurate results, which will prevent the false
positives and cause low level security compromise, can be achieved by creating an exception.
To define an exception to the Abnormally Long Header Line rule using the URL prefix:
In the Main workspace, select Policies > Security.The Security window appears.
1. In the Filter pane, select Web > Service Level > HTTP Protocol Validation. Web Protocol Policy appears in the
Policies pane.
2. In the Policy Rules tab, select Abnormally Long Header Line and click Advanced. The Advanced tab appears.
3. In the Exceptions pane, click . A new line appears in the Exceptions table.
4. From the drop-down list, select Abnormally Long Header Line and click Save. The Empty link appears in the
Exception Summary column.
9. To apply the URL Prefix exceptions to this rule, click on the green arrow. The URL Prefix is now in the Selected
pane.
10. Click Save. The Edit Exception window closes and the summary information appears in the Exception
Summary column.
You can fine tune this exception to be based not only on URL, but also on specific header or even source IP.