Applies To:

Show Versions Show Versions

Manual Chapter: Working with Attack Signatures
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

11 
Attack signatures are rules or patterns that identify attacks or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. Additionally, within the requests signatures pool, some signatures can apply to alpha-numeric user-input parameters.
The global attack signatures pool contains all of the attack signatures that are part of the Application Security Manager configuration. This includes both system-supplied attack signatures, including XML signatures, and user-defined attack signatures.
The Application Security Manager ships with an extensive database of attack signatures. These are known as system-supplied attack signatures. You can disable system-supplied attack signatures, but you cannot delete them.You can also update system-supplied attack signatures to ensure that the system always has the most current protection against known attacks. For information on updating the attack signatures pool, refer to Updating the system-supplied attack signatures.
User-defined attack signatures are those written by customers. User-defined attack signatures must follow the same syntax rules as the system-supplied attack signatures. For details on creating and managing user-defined attack signatures, see Managing user-defined attack signatures.
An attack signature set is a group of attack signatures. Rather than applying individual attack signatures to a security policy, you can apply one or more attack signature sets. The Application Security Manager ships with several system-supplied signature sets. By default, a generic attack signature set is assigned to new security policies. Additionally, you can create your own attack signature sets. For information on creating and managing attack signature sets, refer to Working with attack signature sets.
Attack signatures apply to requests, responses, and alpha-numeric user-input parameters. Request signatures apply to the entire request, or the elements of the request. Response signatures are similar to request signatures, and provide an additional level of security for attacks that may have avoided detection in the request. Parameter signatures, which are a subset of the request signatures, apply to the name and value pairs for the alpha-numeric user-input parameters that are defined in a security policy. These signatures attempt to identify classes of attacks, for example, SQL injection, command injection, cross-site scripting, and directory traversal. Refer to Types of attacks that attack signatures detect, for specific information on the various attack types.
When the Application Security Manager receives a request, the system applies the attack signatures associated with the security policy to the request. If, in the request (or response), a pattern matches one or more of the attack signatures, the system generates the Attack signature detected violation. If the enforcement mode is blocking, the system also blocks the request and issues the Blocking Response Page to the client making the request.
Table 11.1 describes common web application attacks that attack signatures can detect.
Uses a web site's own features and functionality to consume, defraud, or circumvent the applications access control mechanisms.
Targets a web site's method of validating the identity of a user, service or application. Authorization attacks target a web site's method of determining if a user, service, or application has the necessary permissions to perform a requested action.
Occurs during an outside attempt by hackers to access post-logon pages of a web site by guessing user names and passwords; in a brute force attack, a malicious user attempts to log in to a URL numerous times, running many combinations of user names and passwords until they successfully log in.
Alters the flow on an application by overwriting parts of memory. An attacker could trigger a buffer overflow by sending a large amount of unexpected data to a vulnerable component of the web server.
Occurs when an attacker manipulates the data in a user-input field, by submitting commands that could alter the web page content or web application by running a shell command on a remote server to reveal sensitive data-for example, a list of users on a server.
Pertains to the transmission of unauthorized commands through authenticated (trusted) users of the web application. CSRF attacks can include money transfers, stock trades, privilege escalation, application modification, or other unauthorized access.
Attempts to list and access resources that the application does not directly reference, but are still accessible. An attacker can search for unlinked contents, such as temporary directories and files, and old backup and configuration files. These resources may contain sensitive information.
Attempts to cause an HTTP parser to crash, consume excessive resources, run slowly, run an attackers code, or cause the web application to do anything beyond its intended design.
Sends a specially formatted HTTP request that might be parsed differently by the proxy system and by the final system, so the attacker can smuggle a request to one system without the other one being aware of it. This attack makes it possible to exploit other attacks such as session hijacking, cross-site scripting (XSS), and the ability to bypass web application firewall protection.
Occurs when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.
Attempts to include in a request information that is not permitted by the security policy, such as including a null value in a request or including an illegal attachment.
Occurs when an attacker attempts to pass JSON data that the parser cannot parse, and may contain malicious code that can result in various attacks such as Denial of Service or cross-site scripting.
Refers to an attempt to upload a file that could cause damage to the system, for example, through the use of remote code execution or hostile data uploads.
Relates to an attempt by automated client access to obtain sensitive information. HTML comments, error messages, source code, or accessible files may contain sensitive information.
Represents attacks that do not fit into the more explicit attack classifications, including email injection, HTTP header injection, attempts to access local files, potential worm attacks, CDATA injection, and session fixation.
Involves the manipulation of parameters exchanged between client and server to modify application data, such as user credentials and permissions, or the price and quantity of products.
Compromises a session token by stealing or predicting a valid session token to gain unauthorized access to the web server. Web servers often send session tokens to the client browser upon successful client authentication. A session token is usually a string of variable width, and it could be placed in the URL, in the header of an HTTP request, for example, as a cookie, or in the body of the HTTP request.
Tries to circumvent a web servers or web applications built-in security by masking the attack within a legitimate communication. For example, an attacker may include an attack in an email or Microsoft® Word document, and when a user opens the email or document, the attack starts.
Attempts to cause an XML parser to crash, consume excessive resources, run slowly, run an attackers code, or cause the web application to do anything beyond its intended design.
The attack signatures pool contains all of the attack signatures that are part of the configuration. The pool includes the system-supplied attack signatures, which are the attack signatures that are shipped with the Application Security Manager, and any user-defined attack signatures. You can perform the following tasks to manage and maintain the attack signatures pool:
The attack signatures pool is quite large, so there is a filter that you can use to display only those signatures that you are interested in viewing. The filter has several built-in filter options. You can also create a custom filter.
The built-in filter options reduce the viewable attack signatures to a subset that matches a specific characteristic of the attack signatures. Table 11.2 describes the built-in filters.
Show signatures of accuracy greater than/equal to
Displays only signatures whose accuracy is rated greater than or equal to the accuracy that you select. The attack signature accuracy indicates the ability of the attack signature to identify the attack, including susceptibility to false-positive alarms.
Displays only signatures whose risk is rated greater than or equal to the accuracy that you select. The attack signature risk indicates the level of potential damage this attack may cause, if it were successful.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures List screen opens, where you can review the entire attack signature pool.
2.
From the Filter list, select a built-in filter.
The screen refreshes, and displays either a text box or a select list for the selected filter.
3.
Provide the appropriate information, and click the Go button.
The screen refreshes, and displays only those attack signatures that match the criteria you selected.
If the built-in filter options are too broad in scope, you can configure a custom filter option to view signatures in the attack signatures pool. For example, you can create a custom filter that displays attack signatures that apply only to parameters, or you can create a custom filter that displays only attack signatures for a specific attack type. When you create a custom filter, you can use one or more of the filter options, as required. Table 11.3 describes the custom filter options.
Attack signature
custom filter option
Displays only attack signatures that match a specific signature ID number. Signature ID numbers are system-supplied, and cannot be modified.
Displays only attack signatures that match the selected attack type. See Table 11.1, for a description of the attack types having signatures associated with them.
Table 11.4 Signature properties 
Low: Indicates a high likelihood of false positives.
Medium: Indicates some likelihood of false positives.
High: Indicates a low likelihood of false positives.
Low: Indicates the attack does not cause direct damage or reveal highly sensitive data.
Medium: Indicates the attack may reveal sensitive data or cause moderate damage.
High: Indicates the attack may cause a full system compromise.
Indicates whether the system provides documentation explaining this attack signature (View) or not (N/A). Click the View link to display the available documentation.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
In the Signature Name column, click (the Show/Hide Details icon) next to the signature for which you want to view information.
Basic information display on the screen below the signature.
Tip: You can also click the name of the signature to display the signature properties.
3.
For the Documentation setting, click View to see additional information that applies to the selected attack signature.
A new screen opens (Documentation for Attack Signature), and displays the additional documentation.
Note: Some attack signatures have no additional documentation. You see N/A for the Documentation setting if this is the case.
4.
When you finish reviewing the documentation, click the Close button.
The Attack Signatures screen reopens.
You can update the system-supplied attack signatures on a regular basis to ensure that your applications are protected against new attacks and threats.
When you update the system-supplied attack signatures, the update includes any new signatures that are available, and also updates any existing attack signatures that have been revised, including the signature documentation. You can configure automatic updates, or you can update them manually.
Two conditions may cause an attack signature update to fail: insufficient network access and duplicate attack signature names. In addition, it is a good idea to update the attack signatures on all Application Security Manager systems in your network environment, keeping them in sync.
The Application Security Manager must have external network access for the update process to work. To obtain the updated signature files, you must also have both a valid service agreement with F5 Networks, and a service check date within 18 months of the signature-file update request.
If your license has lapsed, you must re-license the Application Security Manager. If you need details about allowing signature file updates through a firewall or an HTTPS proxy, refer to Solution 8217, Updating the BIG-IP ASM attack signatures, on the F5 Networks Technical Support web site. Contact F5 Networks Technical Support, http://support.f5.com, for additional assistance.
Do not use system-supplied attack signature names when you create a user-defined attack signature. Although the system does not prohibit duplicate attack signature names, future attack-signature updates may fail because of name conflicts.
If you inadvertently duplicate a system-supplied attack signature name, rename the user-defined attack signature (see Modifying a user-defined attack signature, for more information). You can then retry the update process.
F5 Networks recommends that you have the same set of attack signatures on all Application Security Manager systems, especially if you plan to copy security policies from one system to another. If you are updating the attack signatures on one system, it is a good idea to update them on all of the systems, to maintain synchronization and consistency with system security.
If you are using device groups for centralized management of BIG-IP® systems, you need to configure each system for automatic attack signature update separately. (An automatic update is one whose update mode is set to Scheduled.) Each device in the group updates its signatures automatically according to its schedule. The attack signatures update configuration is not relayed to other devices in the device group.
If you are using manual attack signature update procedures for systems in device groups, the configuration is relayed to other devices, regardless of the delivery mode. (In this case, the update mode is set to Manual.)
1.
On the Main tab, expand Application Security, point to Options, Attack Signatures, and then click Attack Signatures Update.
The Attack Signatures Update screen opens.
2.
For the Update Mode setting, click Scheduled.
3.
For the Update Interval, select how often you want the system to check for updates (daily, weekly, or monthly).
4.
If you want the system to automatically apply all active security policies after updating the system-supplied signatures, make sure the Auto Apply Policy After Update is checked.
5.
Click the Save Settings button to preserve any changes you may have made to the configuration.
If you want to update the system-supplied attack signatures manually, you can use the manual update option. You can obtain the latest attack signatures update file from http://downloads.f5.com.
1.
On the Main tab, expand Application Security, point to Options, point to Attack Signatures, and then click Attack Signatures Update.
The Attack Signatures Update screen opens.
2.
In the Attack Signatures Update area, for the Update Mode setting, click Manual.
The screen refreshes, and displays the Delivery Mode setting.
3.
For the Delivery Mode setting, select one of the following options:
Select Automatic if you want to go directly to the F5 web server for the latest update file.
Select Manual if you want the system to save the updates in a file that you can apply at a later time. The screen displays the Upload File setting, where you can specify the path to the file that contains the updates.
4.
If you want the system to automatically apply the new attack signatures configuration to all active security policies, leave the Auto Apply Policy After Update box checked.
5.
Click the Save Settings to save your changes.
6.
Click the Update Signatures button to start the update process.
The Application Security Manager records the logistical information about the most recent update activity, and displays this information on the Attack Signatures Update screen. You can review the last update time, as well as the readme file that pertains to the update.
1.
On the Main tab, expand Application Security, point to Options, point to Attack Signatures, and then click Attack Signatures Update.
The Attack Signatures Update screen opens.
2.
In the Latest Update Details area, you can review the creation date and time for the database, as well as the date and time at which the database was most recently updated.
3.
For the Readme option, click View Readme to see the details regarding the update.
If you want to receive notification from F5 Networks about attack signature updates available for download, you can sign up on the AskF5 web site for the Security email distribution list. Once you are on the distribution list, F5 Networks sends an email message whenever attack signature updates are available.
Note: You must have a valid service contract, and an AskF5 account, to receive the attack signature update notifications.
1.
Open a browser, and log in to the AskF5 web site at support.f5.com.
The AskF5 Knowledge Base screen opens.
2.
On the left, click the Mailing Lists button.
The TECHNEWS screen opens.
3.
In the Security area, click the security-subscribe@lists.f5.com link.
4.
Send the blank email message, as is.
The list manager adds your email address to the Security email distribution list.
Rather than assigning individual attack signatures to a security policy, you assign attack signature sets. By default, when you create a new security policy, the system automatically assigns the Generic Detection Signatures set to the security policy. In addition to the generic signatures set, you can assign one of the other system-supplied signatures sets to the security policy, and you can create a signature set and assign that to the security policy. You can also remove all signature set assignments from a security policy, although F5 Networks recommends against doing this.
When you create an attack signature set, you can tailor the attack signatures to your specific systems and applications. For more information on assigning an attack signature set to a security policy, see Assigning attack signature sets to a security policy.
The Application Security Manager ships with several system-supplied signature sets. By default, the Generic Detection Signatures system-supplied set is associated with all new security policies. Table 11.5 describes the system-supplied signature sets.
Targets attacks against the Microsoft® Outlook Web Access (OWA) application.
Targets attacks on a variety of different computing platforms integrated using WebSphere including general database, Microsoft Windows, IIS, Microsoft SQL Server, Apache, Oracle, Unix/Linux, IBM DB2, PostgreSQL, and XML.
You can create signature sets in two ways: by using a filter or by manually selecting the signatures to include. Filter-based signature sets are based solely on criteria you define in the signatures filter. The advantage to filter-based signature sets is that you can focus on the criteria that define the attack signatures you are interested in, rather than trying to manage a specific list of attack signatures. Another advantage to filter-based sets is that when you update the attack signatures database, the system also updates any signature sets included in the update.
1.
On the Main tab, expand Application Security, point to Options, point to Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Above the Attack Signature Sets list, click Create.
The Create Signature Set screen opens.
3.
In the Create Signature Set area, in the Name box, type a unique name for the signature set.
4.
For the Type setting, select Filter-based.
5.
For the Default Blocking Actions setting, decide which blocking actions you want the system to enforce for the signature set when you associate it with a new security policy.
Note: The Learn, Alarm, and Block settings take effect only when you assign this signature set to a new security policy. If this signature set is already assigned to an existing security policy, these settings have no effect.
6.
If you want the system to automatically include this signature set in any new security policies you create, select the Assign To Policy By Default check box.
7.
In the Signatures Filter area, select the filter options you want to use to create the new signature set. For descriptions of the individual filter options, see the online help.
8.
In the Signatures area, for the Signatures setting, you can review the signatures list that the filter settings generate.
The list content changes dynamically with the filter selection.
9.
Click the Create button.
The screen refreshes, and you see the new signature set in the Signatures Set list.
User-defined signature sets are composed of attack signatures that you individually select from the attack signatures pool. You can use the signatures filter to help narrow the scope of the available signatures in the pool, however, once the manual signature set is created, the system does not retain the filter criteria.
1.
On the Main tab, expand Application Security, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Above the Attack Signature Sets list, click Create.
The Create Signature Set screen opens.
3.
In the Create Signature Set area, in the Name box, type a unique name for the signature set.
4.
For the Type setting, select Manual.
5.
For the Default Blocking Actions setting, decide which blocking actions you want the system to enforce for the signature set when you associate it with a new security policy and enable them.
Note: The Learn, Alarm, and Block settings take effect only when you assign this signature set to a new security policy. If this signature set is already assigned to an existing security policy, these settings have no effect.
6.
If you want the system to automatically include this signature set in any new security policies you create, select the Assign To Policy By Default check box.
7.
In the Signatures Filter area, use the filter options to reduce the scope of the Available signatures list (in the Signatures area). For descriptions of the individual filter options, see the online help.
The list content changes dynamically with the filter selection.
8.
For the Signatures setting, move the signatures you want to include in the set into the assigned signatures list.
9.
Click the Create button.
The screen refreshes, and you see the new signature set in the Signatures Set list.
You can edit user-defined attack signature sets to add or remove signatures, or change the properties of the signature set. When you edit attack signature sets, the changes apply to all of the security policies to which the set is assigned. Additionally, filter-based signature sets automatically receive any applicable updates when you use the attack signature update feature. (For more information, see Updating the system-supplied attack signatures.)
1.
On the Main tab, expand Application Security, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
In the Name column, click the name of the signature set that you want to edit.
The Signature Set Properties screen opens.
4.
Click the Save button below the Signatures area.
The system updates the signature set in all security policies that include this set.
You can remove a user-defined signature set from the configuration. When you delete a signature set, you are not deleting the attack signatures that make up the set. You are, however, removing the signature set from the security policy, which may have significant ramifications on the security policys effectiveness.
1.
On the Main tab, expand Application Security, point to Options, Attack Signatures, and then click Attack Signature Sets.
The Attack Signature Sets screen opens.
2.
Select the check box preceding the signature set that you want to remove, and click the Delete button.
A confirmation popup screen displays.
3.
Click OK.
The system removes the selected signature set from the configuration.
Each security policy has its own attack signature sets. By default, the system assigns the Generic Attack Signatures to all security policies. In additions, you can assign any additional attack signature sets to a security policy, including any system-supplied set, or those that you may have created.
1.
On the Main tab, expand Application Security, click Attack Signatures.
The Policy Attack Signature Sets screen opens.
3.
In the Attack Signature Sets Assignment area, in Available Signature Sets list, select the attack signature sets that you want to assign to the security policy.
Tip: To select more than one set, hold the Ctrl key and click the names.
4.
5.
Click the Update button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can review the attack signature sets that are associated with a security policy from the Signature Sets screen. By default, the system assigns the signature set, Generic Detection Signatures, to all new security policies. Additionally, the system includes in the security policy any attack signature sets you selected with the Deployment wizard.
1.
On the Main tab, expand Application Security, click Attack Signatures.
The Policy Attack Signature Sets screen opens.
2.
In the editing context area, ensure that the edited security policy is the one whose attack signature sets you want to view.
3.
In the Assigned Signature Sets list, you can review the signature sets that are associated with the security policy, as well as the blocking policy actions for signatures in the set.
When you assign an attack signature set to a security policy, the system builds a list of all of the attack signatures. You can review the signatures, their current blocking policy, and their state on the Policy Attack Signatures screen. Figure 11.1 shows a sample of the attack signature list for a security policy.
1.
On the Main tab, expand Application Security, point to Attack Signatures, and then click Policy Attack Signatures.
The Policy Attack Signatures screen opens.
2.
In the editing context area, ensure that the edited security policy is the one whose attack signatures you want to view.
3.
For the Filter option, select Show all signatures to display all signatures associated with the security policy.
1.
On the Main tab, expand Application Security, point to Attack Signatures, and then click Policy Attack Signatures.
The Policy Attack Signatures screen opens.
2.
In the editing context area, ensure that the edited security policy is the one with attack signatures you want to disable.
3.
For the Filter option, select Show all signatures to display all signatures associated with the security policy.
4.
Click the signature name of the attack signature you want to disable.
The Policy Attack Signature Properties screen opens.
5.
Clear the Enabled check box.
6.
Click Update.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The blocking policy defines how the Security Enforcer processes requests that trigger violations. For each attack signature set that is assigned to a security policy, you enable one or more of the blocking actions:
When the signatures have passed the staging period and before the system applies the blocking actions, you have a chance to review the attack signatures list and decide which ones to enable or disable. For information on how to do this, refer to Enabling or disabling signatures in staging.
Note: The blocking policy applies to all of the signatures in the signature set. You cannot specify a blocking policy for individual signatures.
1.
On the Main tab, expand Application Security and click Attack Signatures.
The Policy Attack Signature Sets screen opens.
3.
In the Attack Signature Sets Assignment area, for each signature set in the Assigned Signature Sets list, check or clear the boxes in the Learn, Alarm, and Block columns as required.
Note: If the enforcement mode for the security policy is transparent, the Block action is not configurable. You can enable or disable the Block action only when the enforcement mode is set to blocking.
4.
Click the Update button to save any changes you may have made.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
When you first activate a security policy, the system puts the attack signatures into staging (if staging is enabled). Staging means that the system applies the attack signatures to the web application traffic, but does not apply the blocking policy block action to requests that trigger those attack signatures. The default staging period is seven days. Whenever you add or change signatures in assigned sets, those are also put into staging. (For more information on updating signatures, see Updating the system-supplied attack signatures.)
1.
On the Main tab, expand Application Security and click Policy.
The Policy Properties screen opens.
3.
For the Staging-Tightening Period setting, type the number of days for which you want new or updated attack signatures to remain in staging.
4.
Select the Enable Signature Staging check box.
5.
Click Save to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Placing new and updated attack signatures in staging helps to reduce the number of violations triggered by false-positive matches. When signatures match attack patterns during the staging period, the system generates learning suggestions. You can view these attack signatures from the Attack Signature Staging screen. Upon evaluation, if the signature is a false-positive, you can disable the signature, and the system no longer applies that signature to traffic for the corresponding web application.
Alternately, if the detected signature match is legitimate, you can enable the corresponding attack signature. Note that enabling the signature removes it from staging, and puts the blocking policy into effect.
1.
On the Main tab, expand Application Security, point to Policy Building, and click Manual.
The Traffic Learning screen opens.
2.
In the Traffic Learning area of the Negative Security Violations setting, click the Attack signature staging link.
The Attack Signature Staging screen opens, where you can review the signatures that detected attack patterns in a request.
Figure 11.2 shows the Attack signature staging link on the Traffic Learning screen.
Figure 11.3 shows a sample screen with examples of the attack signatures that are in staging for the current edited security policy. On your screen, click the number under Recent Incidents to view details about requests that caused the violation for that signature.
If a new or updated attack signature in staging detects an attack pattern in the web application traffic, you should review the signature details and the requests that triggered the attack signature. If the detected attack pattern is not an actual threat, the signature has generated a false-positive alarm. If a particular attack signature triggers false-positives, you may want to disable that particular attack signature.
In some situations, you may want to take action to enable or disable an attack signature immediately, rather than wait for the staging period to complete. For example, if a signature detects a legitimate attack pattern, you may want to enable that signature right away, instead of waiting for the staging period to end.
Another example is when a trusted-traffic signature match is detected but the request is legitimate. In such a case, you should disable that signature immediately.
1.
On the Main tab, expand Application Security, point to Policy Building, and click Manual.
The Traffic Learning screen opens.
2.
In the Negative Security Violations section of the Traffic Learning area, click the Attack signature staging link.
The Attack Signature Staging screen opens.
a)
In the Action column, select Enable or Disable from the list.
6.
Below the Attack Signature Staging area, click the Apply button.
A confirmation popup screen opens.
7.
Click OK.
The popup screen closes, and displays the Traffic Learning screen.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
On the Main tab, expand Application Security, point to Policy Building, and click Manual.
The Traffic Learning screen opens.
2.
In the Negative Security Violations section of the Traffic Learning area, click the Attack signature staging link.
The Attack Signature Staging screen opens.
3.
Click the Enforce Signatures button.
The system removes from staging all signatures that did not cause violations and enforces them.
User-defined attack signatures are those that the user creates and adds to the attack signature pool. User-defined attack signatures have the following attributes:
They are never updated by F5 Networks. All user-defined signatures are carried forward as-is whenever there is a software version upgrade.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Create.
The Create Attack Signature screen opens.
3.
In the Name box, type a unique name for the new attack signature.
Warning: If you create a user-defined attack signature with the same name as a system-supplied attack signature, subsequent signature updates may fail.
4.
In the Description box, type an optional description of the signature.
5.
To include this signature in all active security policies, make sure that Auto Apply New Signatures Configuration After Create is selected.
6.
For the Apply To setting, select whether the new signature applies to requests or responses.
7.
For the Systems setting, select from the Available Systems list any systems to which the new signature applies, and use the Move buttons (<< and >>) to add them to the Assigned Systems list.
8.
For the Attack Type setting, select the type of threat that the new signature protects against.
9.
For the Rule setting, type a rule according to the syntax guidelines in Appendix C, Syntax for Creating User-Defined Attack Signatures. This setting is required.
10.
For the Accuracy setting, select an accuracy level. The accuracy level indicates the ability of the attack signature to identify the attack, including susceptibility to false-positive alarms.
11.
For the Risk setting, select a risk level. The risk level indicates the level of potential damage this attack may cause, if it were successful.
12.
Click the Create button.
The screen refreshes, and displays the Attack Signatures list.
You may need to update a user-defined attack signature, for example, to change the accuracy level after the signature has been in use for a while, based on observed traffic.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
In the Attack Signatures list, click the name of the user-defined attack signature that you want to modify.
The Update Attack Signature screen opens.
4.
Click Save to retain the changes.
You can permanently remove user-defined attack signatures from the attack signature pool. Note that when you delete a user-defined signature from the attack signature pool, the system removes that signature from any signature sets of which the attack signature is a member.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
In the Attack Signatures list, in the Select column (far left), select the box next to the name of the user-defined attack signature that you want to delete.
3.
Below the Attack Signatures list, click the Delete button.
A confirmation popup screen displays.
4.
Click the OK button.
The system deletes the attack signature from the configuration, and displays the Attack Signatures list screen.
If you have a large number of user-defined attack signatures that you want to add to the configuration, you can import them in an XML-formatted file. You can also use the import functionality to import a previously exported user-defined attack signature file onto a system with the same version of Application Security Manager. Figure 11.4 shows an example of the XML file format for the user-defined attack signatures file.
Warning: The sig_name attribute uniquely identifies a user-defined attack signature. Therefore, when you import an attack signature XML file, if there are any signatures in the XML file whose sig_name attribute matches that of any existing user-defined signatures, the system overwrites the existing definition with the imported definition.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Import.
The Import Attack Signatures screen opens.
3.
In the Choose File box, type the path to the XML file that contains the user-defined attack signatures. Alternately, click the Browse button and navigate to the XML file.
4.
To include this signature in the active security policies, make sure that Auto Apply New Signatures Configuration After Import is selected.
5.
Click the Import button.
The system imports the user-defined signatures, and issues either a success message or a failed message.
6.
If the import is successful, click the OK button.
The screen refreshes, and displays the Attack Signatures list with the additional user-defined signatures.
7.
If the import was not successful, make any required changes to the XML file, and then try to import the file again.
You can export all user-defined attack signatures to transfer them to another system, or save them in a remote location. When you export user-defined attack signatures, the Application Security Manager saves them in an XML file using the format shown in Figure 11.4.
1.
On the Main tab, expand Application Security and click Options.
The Attack Signatures screen opens.
2.
Above the Attack Signatures list, click Export.
The web browser opens a file download or a save file popup screen.
Note: Each web browser manages this functionality differently.
3.
Save the signature file in a location that meets your requirements. Application Security Manager saves the signature in a file name with this format:
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)