F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Getting Started
  5. Creating a Security Policy for Web Services
Manual Chapter : Creating a Security Policy for Web Services

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Creating a Security Policy for Web Services

Overview: Creating a security policy for web services

Use the Application Security Manager™ to create a security policy for a web application that uses XML formatting or web services. The security policy can verify XML format, and validate XML document integrity against a WSDL or XSD file. The security policy can also handle encryption and decryption for web services.

The Deployment wizard guides you through the steps required to create a security policy to protect web services or XML transactions.

Considerations for developing XML security

Before you get started, you need to understand a bit about the application you are developing a security policy for. For example, you need to know the answers to the following questions:

  • Does the web application use a WSDL or XML schema (XSD) file to validate the XML documents? Some web services use a WSDL or XML schema document to validate whether or not the incoming traffic complies with XML language rules. If the application uses a WSDL or XSD file, you need a copy of the file.
  • Does the application use a URL or parameter to point to the server that you want to protect? You need to know the URLs or parameters that the application uses.

Task summary

About XML security

Because XML is used as a data exchange mechanism, it is important to inspect, validate, and protect XML transactions. With XML security, you can protect the following applications:

  • Web services that use HTTP as a transport layer for XML data
  • Web services that use encryption and decryption in HTTP requests
  • Web services that require verification and signing using digital signatures
  • Web applications that use XML for client-server data communications, for example, Microsoft Outlook Web Access

You implement XML security by creating an XML profile for a security policy. The XML profile can protect XML applications in the following ways:

  • Validates XML format
  • Enforces compliance against XML schema files or WSDL documents
  • Implements defense rules for XML documents
  • Masks sensitive XML data
  • Encrypts and decrypts parts of SOAP (Simple Object Access Protocol) web services
  • Signs and verifies parts of SOAP messages using digital signatures

Flowchart for configuring XML security policy

How you proceed with configuring XML security depends on the type of application you want to protect. If the application consists simply of XML content, creating the security policy is straightforward. If your application is a SOAP web service, you have additional options for setting up the security policy.

Flowchart for XML security policy

Securing XML applications

Creating a security policy for web services

Before you can create a security policy using ASM™, you need to complete the basic BIG-IP® system configuration tasks including creating a VLAN, a self IP address, and other tasks according to the needs of your networking environment.

Application Security Manager™ can help you create a security policy that is tailored to protect a web service application. The Deployment wizard guides you through the tasks required.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the Create button.
    The Deployment wizard opens to the Select Local Traffic Deployment Scenario screen.
  3. For the Local Traffic Deployment Scenario setting, specify a virtual server to use for the security policy.
    • To secure an existing virtual server that has no security policy associated with it, select Existing Virtual Server and click Next.
    • To create a new virtual server and pool with basic configuration settings, select New Virtual Server and click Next.
    • To create an active but unused security policy, select Do not associate with Virtual Server and click Next. No traffic will go through this security policy until you associate it with a virtual server. The Policy Builder cannot begin automatically creating a policy until traffic is going to ASM through the virtual server.
    The virtual server represents the web application you want to protect.
    The Configure Local Traffic Settings screen opens if you are adding a virtual server. Otherwise, the Select Deployment Scenario screen opens.
  4. If you are adding a virtual server, configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, virtual server name, virtual server destination address and port, pool member IP address and port, and the logging profile.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy. Specify the protocol and virtual server.
    • If you selected Do not associate with Virtual Server, you will have to manually associate the security policy with a virtual server at a later time. On the policy properties screen, you need to specify a name for the security policy.
    The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, click Create a security policy for XML and web services manually and click Next.
    The Configure Security Policy Properties screen opens.
  6. In the Security Policy Name field, type a unique name for the policy.
  7. From the Application Language list, select the language encoding of the application, then click Next.
    Important: You cannot change this setting after you have created the security policy.
  8. If the application is not case-sensitive, clear the Security Policy is case sensitive check box. Otherwise, leave it selected.
    Important: You cannot change this setting after you have created the security policy.
  9. If you do not want the security policy to distinguish between HTTP/WebSocket and HTTPS/WebSocket Secure URLs, clear the Differentiate between HTTP/WS and HTTPS/WSS URLs check box. Otherwise, leave it selected.
  10. Click Next.
    The Configure Attack Signatures screen opens.
  11. To configure attack signatures, move the systems used by your web application from the Available Systems list into the Assigned Systems list.
    The system adds the attack signatures needed to protect the selected systems.
  12. Retain the default value of Enabled for the Signature Staging setting.
    New and updated attack signatures remain in staging for seven days.
  13. Click Next.
    The Security Policy Configuration Summary screen opens.
  14. Review the settings for the security policy. When you are satisfied with the security policy configuration, click Finish.
    The system creates the security policy, and the Create New XML Profile screen opens and displays the message: The initial configuration of the <<policy>> is complete. You can now create a new XML profile.
The Deployment wizard creates the security policy. You can now configure the security policy for XML validation.
If your application has no WSDL or XML schema validation, create a basic XML profile. If the application uses a WSDL file, create an XML profile with WSDL validation. If the application uses an XML schema file, create an XML profile with XML schema validation.

Creating a basic XML profile

Before you can complete this task, you must have created a security policy using the option Create a policy for XML and web services manually.
If your web service includes XML data (without WSDL or schema validation), follow these steps to create a basic XML profile that defines the formatting and attack pattern checks for the security policy. You associate the XML profile with a URL or parameter.
  1. If you are on the Create New XML Profile screen, skip to step 2. If not, at the top of the screen, click the Create new XML profile link.
    You can also navigate to Security > Application Security > Content Profiles > XML Profiles and click Create.
    The Create New XML Profile screen opens.
  2. For Profile Name, type a unique name.
  3. Select the Use XML Blocking Response Page check box to send an XML response page when the security policy blocks a request that contains XML content that does not comply with this XML profile.
  4. To allow SOAP messages to have attachments, select the Allow Attachments in SOAP Messages check box.
  5. In the Defense Configuration area, for Defense Level, select High (the default value), Medium, or Low to specify the level of protection you want the security policy to provide for XML applications and services.
    The system adjusts the defense configuration settings according to your choice. You can review the settings by selecting Advanced next to Defense Configuration.
  6. Click Create.
    The Associate XML Profile screen opens.
  7. For the Associate XML Profile setting, specify whether to associate the XML profile with a URL or a parameter:
    Option Description
    URL Validates XML data found in requests to this URL.
    Parameter Validates XML data in a parameter. You also select the Parameter Level:

    Global specifies that this is a global parameter that has no association with URLs.

    URL specifies that this parameter is associated with a specific URL, a protocol (HTTP or HTTPS), and a target URL path.
  8. Click Next.
    The New Allowed URL or Add Parameter screen opens, depending on which entity you choose to associate with the XML profile.
  9. Create the URL or parameter to associate with the XML profile. Your steps depend on which option you selected.
    Option Description
    URL Type the explicit URL or wildcard URL that represents the web application, and click Next.
    Global Parameter Type the name of the parameter, and click Create.
    URL Parameter Type the explicit URL or wildcard URL that represents the web application, and click Next.

    Type the name of the parameter, and click Create.
    The system creates the URL or parameter and displays the list of entities.
The system automatically associates the XML profile with the URL, global parameter, or URL parameter.
Next, you can review the status of the security policy you created.

Creating an XML profile with WSDL validation

Before you can complete this task, you must have created a security policy using the option Create a policy for XML and web services manually. You need to have the WSDL file you want to use for validation, and it must comply with W3C XML schema specifications and use UTF-8 character encoding.
Follow these steps to include the WSDL document in the XML profile. The resulting security policy can then enforce the allowed (or disallowed) methods and URLs.
  1. If you are on the Create New XML Profile screen, skip to step 2. If not, at the top of the screen, click the Create new XML profile link.
    You can also navigate to Security > Application Security > Content Profiles > XML Profiles and click Create.
    The Create New XML Profile screen opens.
  2. For Profile Name, type a unique name.
  3. Select the Use XML Blocking Response Page check box to send an XML response page when the security policy blocks a request that contains XML content that does not comply with this XML profile.
  4. In the Validation Configuration area, for the File option of the Configuration Files setting, navigate to the WSDL document.
  5. Click Upload.
    The screen lists the uploaded file.
  6. If the imported file references another URL (and the setting is available), for Import URL, type the URL.
  7. To allow SOAP messages to have attachments, select the Allow Attachments in SOAP Messages check box.
  8. In the Defense Configuration area, for Defense Level, select High (the default value), Medium, or Low to specify the level of protection you want the security policy to provide for XML applications and services.
    The system adjusts the defense configuration settings according to your choice. You can review the settings by selecting Advanced next to Defense Configuration.
  9. Click Create.
    In most cases, the system automatically associates a URL or parameter with the application based on the WSDL file.
    If the XML Profiles screen is displayed, you are done creating the profile. Otherwise, the Associate XML Profile screen opens, and you can continue with the next step.
  10. For the Associate XML Profile setting, specify whether to associate the XML profile with a URL or a parameter:
    Option Description
    URL Validates XML data found in requests to this URL.
    Parameter Validates XML data in a parameter. You also select the Parameter Level:

    Global specifies that this is a global parameter that has no association with URLs.

    URL specifies that this parameter is associated with a specific URL, a protocol (HTTP or HTTPS), and a target URL path.
  11. Click Next.
    The New Allowed URL or Add Parameter screen opens, depending on which entity you choose to associate with the XML profile.
  12. Create the URL or parameter to associate with the XML profile. Your steps depend on which option you selected.
    Option Description
    URL Type the explicit URL or wildcard URL that represents the web application, and click Next.
    Global Parameter Type the name of the parameter, and click Create.
    URL Parameter Type the explicit URL or wildcard URL that represents the web application, and click Next.

    Type the name of the parameter, and click Create.
    The system creates the URL or parameter and displays the list of entities.
The security policy now includes the XML profile with WSDL validation.

When you upload a WSDL document, the system automatically populates a list of SOAP methods in the validation configuration of the XML profile. Additionally, the system adds the SOAP methods as URLs in the security policy, and automatically associates the XML profile with the URLs. The system configures into the policy all relevant URLs that it finds in the WSDL and designates them as valid SOAP methods. By default, all methods are enabled, which means that the security policy allows those methods.

Next, you can review the status of the security policy you created.

Creating an XML profile with XML schema validation

Before you can complete this task, you must have created a security policy using the option Create a policy for XML and web services manually. You need to have the XML schema file you want to use for validation, and it must comply with W3C XML schema specifications and use UTF-8 character encoding.
You incorporate the schema file into the XML profile to complete this security policy.
  1. If you are on the Create New XML Profile screen, skip to step 2. If not, at the top of the screen, click the Create new XML profile link.
    You can also navigate to Security > Application Security > Content Profiles > XML Profiles and click Create.
    The Create New XML Profile screen opens.
  2. For Profile Name, type a unique name.
  3. Select the Use XML Blocking Response Page check box to send an XML response page when the security policy blocks a request that contains XML content that does not comply with this XML profile.
  4. In the Validation Configuration area, for the Configuration Files setting File option, navigate to the XML schema file (.xsd), then click Upload.
  5. If the imported file references another URL (and the setting is available), for Import URL, type the URL.
  6. To allow SOAP messages to have attachments, select the Allow Attachments in SOAP Messages check box.
  7. In the Defense Configuration area, for Defense Level, select High (the default value), Medium, or Low to specify the level of protection you want the security policy to provide for XML applications and services.
    The system adjusts the defense configuration settings according to your choice. You can review the settings by selecting Advanced next to Defense Configuration.
  8. Click Create.
    The Associate XML Profile screen opens.
  9. For the Associate XML Profile setting, specify whether to associate the XML profile with a URL or a parameter:
    Option Description
    URL Validates XML data found in requests to this URL.
    Parameter Validates XML data in a parameter. You also select the Parameter Level:

    Global specifies that this is a global parameter that has no association with URLs.

    URL specifies that this parameter is associated with a specific URL, a protocol (HTTP or HTTPS), and a target URL path.
  10. Click Next.
    The New Allowed URL or Add Parameter screen opens, depending on which entity you choose to associate with the XML profile.
  11. Create the URL or parameter to associate with the XML profile. Your steps depend on which option you selected.
    Option Description
    URL Type the explicit URL or wildcard URL that represents the web application, and click Next.
    Global Parameter Type the name of the parameter, and click Create.
    URL Parameter Type the explicit URL or wildcard URL that represents the web application, and click Next.

    Type the name of the parameter, and click Create.
    The system creates the URL or parameter and displays the list of entities.
The security policy includes the XML profile with XML schema validation.
Next, you can review the status of the security policy you created.

Reviewing the status of an XML security policy

Before you can complete this task, you must have created a security policy using the option Create a policy for XML and web services manually, and traffic must be flowing to the application through the BIG-IP® system.
You can monitor the general progress of the XML security policy created using the Deployment wizard. The system processes the traffic to gather information needed to create the security policy, and displays messages about its progress.
  1. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  3. Review the messages in the identification and messages area to learn about the security policy status.
    Status Message Description
    The initial configuration of the security policy is complete. Checking to see if ASM is detecting traffic. The Application Security Manager™ is parsing and analyzing received requests. Allow the system several minutes to analyze requests.
    The ASM did not detect any traffic for the <<policy>> security policy. Verify the networking configuration (check the VLAN, self IP address, pool, and virtual server).
    ASM detected traffic successfully. Waiting for a minimum of 10000 requests and at least one hour from running the wizard for the name security policy. The ASM detected n requests during x hours and y minutes. Application Security Manager detected traffic and will sample requests until it processes at least 10,000 requests, and at least one hour has passed since you started the Deployment wizard.
    Processing XML violations for at least one hour for the name security policy. The ASM found n new XML violations during xx minutes and yy seconds. After successfully detecting traffic and sampling requests, the Application Security Manager processes XML violations. Based on what it finds in the traffic sample and the violations, Application Security Manager automatically adjusts security policy settings to match the traffic and eliminate false positives. The system samples requests for at least one hour.
    The system did not detect any new XML violations over the last hour for the name security policy. You can now go to the Traffic Learning page to fine-tune the security policy. For at least an hour, none of the traffic going to or from the application has caused XML violations. When you see this message, you can fine-tune the security policy.
    Timed out while waiting for sufficient number of requests for the security policy. Checking XML violations status. The system processed insufficient traffic to finish building the security policy. Check to be sure that traffic can access the web application.

Reviewing learning suggestions

After you create a security policy, the system provides learning suggestions concerning additions to the security policy based on the traffic that is accessing the application. For example, you can have users or testers browse the web application. By analyzing the traffic to and from the application, Application Security Manager™ generates learning suggestions or ways to fine-tune the security policy to better suit the traffic and secure the application.

Note: This task is primarily for building a security policy manually. If you are using the automatic learning mode, this task applies to resolving suggestions that require manual intervention, or for speeding up the enforcement of policy elements.
  1. On the Main tab, click Security > Application Security > Policy Building > Traffic Learning .
    The Traffic Learning screen opens, and lists suggestions based on traffic patterns and violations that the system has detected.
  2. If you want to change the order in which the suggestions are listed, or refine what is included in the list, use the filters at the top of the column.
    You can also list the suggestions by average violation rating of all matching requests, first occurrence, last occurrence, matched entity name, or use the search filter to display specific types of suggestions that you are interested in.
    By default, the suggestions that have the highest learning score (those closest to being ready to be enforced) are listed first. Suggestions have higher learning scores if that traffic has met the conditions in the policy, if it originates from many sources, if it is unlikely to be a violation, or if the traffic comes from a trusted IP address. They may also be suggestions to add an entity the system learns, for example, a new file type, URL, or parameter.
  3. On the Traffic Learning screen, review each learning suggestion.
    1. Select a learning suggestion.
      Information is displayed about the action the system will take if you accept the suggestion, and what caused the suggestion.
    2. You can learn more about the suggestion by looking at the action, the number of samples it is based on, the violations caused and their violation ratings, and if needed, by examining samples of the requests that caused the suggestion.
    3. With a request selected on the left, you can view data about the request on the right, including any violations it generated, the contents of the request itself, and the response (if any). Note that some requests may contain violations related to different suggestions.
      By examining the requests that caused a suggestion, you can determine whether it should be accepted.
    4. To add comments about the suggestion and the cause, click the Add Comment icon and type the comments.
  4. Decide how to respond to the suggestion. You can start with the suggestions with the highest learning scores, or those which you know to be valid for the application. These are the options.
    Option What happens
    Accept Suggestion The system modifies the policy by taking the suggested action, such as adding an entity that is legitimate. If the entity that triggered the suggestion can be placed in staging (file types, URLs, parameters, cookies, or redirection domains), clicking Accept Suggestion displays a second option, Accept suggestion and enable staging on Matched <<entity>>. Click this option to accept the suggestion and place the matched entity in staging.
    Delete Suggestion The system removes the learning suggestion, but the suggestion reoccurs if new requests cause it. The learning score of the suggestion starts over from zero in that case.
    Ignore Suggestion The system does not change the policy and stops showing this suggestion on the Traffic Learning screen now and in the future. You can view ignored suggestions by filtering by status ignored.
    Leave the suggestion You can read the suggestions and wait to handle them until more traffic has passed through, or until you get more information. The suggestion remains in the list and no changes are made to the policy.
    Note: If you are working in automatic learning mode, when the learning score reaches 100%, the system accepts most of the suggestions, or you can accept suggestions manually at any time. If you are using manual learning, when the learning score reaches 100% (or before that if you know the suggestions are valid), you need to accept the suggestions manually.

    If you know that a suggestion is valid, you can accept it at any time even before the learning score reaches 100%. The ones that reach 100% have met all the conditions so that they are probably legitimate entities.

  5. To put the security policy changes into effect immediately, click Apply Policy.
By default, a security policy is put into an enforcement readiness period for seven days. During that time, you can examine learning suggestions and adjust the security policy without blocking traffic. The security policy then includes elements unique to your web application.
It is a good idea to periodically review the learning suggestions on the Traffic Learning screen to determine whether the violations are legitimate and caused by an attack, or if they are false positives that indicate a need to update the security policy. Typically, a wide recurrence of violations at some place in the policy (with a low violation rating and a high learning score) indicates that they might be false positives, and hence the policy should be changed so that they will not be triggered anymore. If the violations seem to indicate true attacks (for example, they have a high violation rating), the policy should stay as is, and you can review the violations that it triggered.

Enforcing a security policy

You only need to enforce a security policy if it was created manually (not using automatic learning), and if it is operating in transparent mode. Traffic should be moving through Application Security Manager™, allowing users to access the web application for which you set up the security policy.
When you enforce a security policy, the system blocks requests that cause violations that are set to block.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. For the Enforcement Mode setting, select Blocking.
  4. Review each of the policy building settings so you understand how the security policy handles requests that cause the associated violations, and adjust if necessary. You need to expand most of the settings to see the violations.
    Tip: To the right of Policy Building Settings, click Blocking Settings to see and adjust all of the violations at once.
    Option What happens when selected
    Learn The system generates learning suggestions for requests that trigger the violation (except learning suggestions are not generated for requests that return HTTP responses with 400 or 404 status codes).
    Alarm When selected, the system marks requests that trigger the violation as illegal. The system also records illegal requests in the Charts screen, the system log (/var/log/asm), and possibly in local or remote logs (depending on the settings of the logging profile).
    Block The system blocks requests that trigger the violation when (1) the security policy is in the blocking enforcement mode, (2) a violation occurs, and (3) the entity is enforced. The system sends the blocking response page (containing a Support ID to identify the request) to the client.
  5. Click Save to save your settings.
  6. On the Main tab, click Security > Application Security > Security Policies .
    The Active Policies screen opens.
  7. Click the name of the security policy you want to work on.
    The Policy Properties screen opens.
  8. To change the number of days that the security policy entities and attack signatures remain in staging, change the value in the Enforcement Readiness Period field.
    The security policy does not block traffic during the Enforcement Readiness Period even if violations occur.
  9. If you want to immediately block traffic that causes violations, you need to enforce entities that are ready to be enforced. This is one way to do this quickly:
    1. Set the Enforcement Readiness Period to 0. (Not generally recommended. Use only if you want to speed up the process.)
    2. Click Save.
    3. On the Main tab, click Security > Application Security > Policy Building > Enforcement Readiness .
    4. Click Enforce Ready.
    In most cases, it is better to use a longer Enforcement Readiness Period, such as the default of 7 days. The entities become ready to be enforced after that.
  10. To put the security policy changes into effect immediately, click Apply Policy.
  11. For a quick summary of system activity, look at the Overview screen ( Security > Overview > Application ).
    The Summary screen displays statistical information about Application Security traffic.
After the enforcement readiness period is over and the enforcement mode is set to blocking, the security policy no longer allows requests that cause violations set to block to reach the back-end resources. Instead, the security policy blocks the request, and sends the blocking response page to the client.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information