Data Guard with F5 ASM

Protect sensitive information in HTTP responses

 

You might have an application that handles sensitive information like Creditcard numbers, Personal Identification numbers or even Bank account information.
HTTP responses from your application might contain such sensitive information in de clear. In that case you could set the application developers on a new task to make sure that the sensitive data does not leave the network.

But what if you have many of these web applications handling sensitive information, or what if you are dependent on a third party for updates on your application?

For those situations it’s good to know that you can protect your application with a F5 ASM web application firewall.
The feature is called “Data Guard”. And it makes sure your sensitive information does not leave the network via HTTP responses.

The feature also helps to stay PCI compliant.

The way it works

ASM Data Guard can prevent sensitive data exposure in different ways.

  • Masking the data in the HTTP response.

  • Blocking the HTTP response witch contains the sensitive information.

Note:

If your web application policy is in transparent mode, it is highly recommended to use the "Masking" option of Data Guard.

Response headers that Data Guard inspects

Data Guard works with the following content-type headers, and examines responses for these:

"text/..."
"application/x-shockwave-flash"
"application/sgml"
"application/x-javascript"
"application/xml"
"application/x-asp"
"application/x-aspx"
"application/xhtml+xml"

In Use

When Data Guard finds any sensitive information (you’ll have to define what information is sensitive), it will block the HTTP response or mask the information in the response before it get’s send off to the user. With no definition of what sensitive information might swing by, the Data Guard module already recognizes creditcard numbers and social card numbers.

Protecting sensitive data

If a HTTP response contains a creditcard number, a Social Security number, or a custom pattern, then Data Guard will respond based on what the policy enforcement setting is set to.

  • On the F5 Main tab, click Security » Application Security » Data Guard:

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.

  • Select the Data Guard check box to enable Data Guard.

If you want the system to consider credit card numbers as sensitive data:

  • select the Credit Card Numbers check box.

If you want the system to consider U.S. social security numbers (in the form nnn-nn-nnnn, where n is an integer) as sensitive data:

  • select the U.S. Social Security Numbers check box.

To specify additional sensitive data patterns that occur in the application:

  • Select the Custom Patterns check box.
  • In the New Pattern field, type a PCRE regular expression to specify the sensitive data pattern, then click Add. For example, 999-[/d][/d]-[/d][/d][/d][/d].

Tip: You can validate the regular expression using the tool at Security > Options > Application Security > RegExp Validator.
You can add as many custom patterns as needed for the application.

For specific data patterns that is not to be considered sensitive:

  • Select the Exception Patterns check box.

  • In the New Pattern field, type a PCRE regular expression to specify the sensitive data pattern, then click Add.
    Add as many custom patterns as needed for the application.

When ASM detects sensitive information in a HTTP response, it generates the following Data Guard violation: Information leakage detected. When violation is set to alarm or block If the security policy enforcement mode is set to blocking-mode and the violation is set to block, the system does not send the response to the client.

 

←