Part 8: Data Guard

Data Guard

As we all know, we need to protect the personal and sensitive information of our users. So back in the day, some super-smart people developed an iRule that scrubs out credit card numbers from HTTP traffic that passes through the BIG-IP (the link to the iRule is here). This is a great iRule, but the good news is that the BIG-IP ASM gives you all the power of this iRule (and more) by simply checking a box in the Data Guard settings. In fact, the ASM gives you the option to scrub more than just credit card numbers. It also allows you to protect social security numbers and other sensitive information based on custom patterns that you can define!

In the BIG-IP ASM, you can navigate to Security >> Application Security >> Data Guard and you will see the following screen:

Notice that you can simply check the box for Credit Card Numbers and US Social Security Numbers. For credit card numbers, the ASM uses the Luhn Algorithm to verify that a specific sequence of numbers is, in fact, a valid credit card number (just because you have a sequence of 16 numbers doesn't mean you have a credit card number).

If you need to protect another specialized number, you can simply build the pattern in the "Custom Patterns" (using regular expression syntax) and enable that as well...you can add as many custom patterns as you want. In addition, you can set Exception Patterns...these are patterns that the ASM will recognize as not being sensitive.

The "Mask Data" checkbox is simple but important. When you check this box, the ASM replaces all sensitive data (as defined by any/all of the options you choose) with a string of asterisks (*). Keep in mind that if you don't check this box, the ASM will not insert the asterisks in place of your data...so make sure you check this one!

File Content Detection is a really cool feature as well. This gives you the option of selecting one or more of the available file types as sensitive data. For example, if your organization uses a specific file type for sensitive data, then you can move that document type from "Available" to "Members" and the ASM will protect the server from delivering that file type to users.

Finally, the Enforcement Mode allows you to either "Ignore URLs in the list" or "Enforce URLs in the list". The default setting is to Ignore URLs. This option allows you specify URLs that will be ignored or protected (respectively) by the Data Guard feature. If you want to protect all URLs in your application, just leave the "Ignore URLs in the list" selected and make sure there are no URLs listed...that way, the ASM doesn't ignore anything.

Blocking Settings

I feel like I talk about Blocking Settings all the time in these articles, but these settings are important! Navigate to Security >> Application Security >> Blocking >> Settings to list the options for all the blocking settings in your policy. Scroll way down to the bottom of the page to find the "Data Guard: Information leakage detected" and this will give you the option to Learn, Alarm, and/or Block when the ASM triggers on a Data Guard violation.

You will probably want to just Learn and Alarm on this setting. If you Block on this setting, then every time a Data Guard violation occurs (as defined by all the stuff you selected in the section above), the ASM will generate a Blocking Page. Instead, if you Learn and Alarm on this setting, the ASM will allow the user to see the page, but it will mask the sensitive data (as long as you select the "Mask Data" option on the Data Guard page). The screenshot below shows all the details:

The Test...

Now that all the Data Guard settings are in place, I want to see how the ASM performs on a web application. In this example, I went back to my trusty Hack-it-yourself auction site (configuration settings are here if you need them). As you can see from the screenshot below, I went to the "Sell an Item" page and entered a credit card number (looks fake, but it actually passes the Luhn test for valid credit card numbers) and a US Social Security Number.

After I entered all the data, I hit "submit" to sell my test item...this is where the ASM should catch the request and notice it contains sensitive data...
 

The Results...

As you can see from the screenshot below, the ASM recognized the sensitive data and masked it correctly. I also tested this by changing the blocking settings to "Block" and sure enough, I got the ASM block page when I tried to sell the exact same item.

Last thing...I wanted to show a screenshot of the ASM logs. Notice that the ASM simply Alarmed on this violation (no blocking page), but it caught the Credit Card Number as well as the Social Security Number. Pretty cool stuff!!