on 06-Dec-2013 07:00
This is the eighth article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first seven articles in this series are:
Don't get me wrong...I love iRules as much as the next guy. But even the most ardent iRule supporters will tell you that it's better to use built-in functionality vice an iRule whenever possible. Which, by the way, we always love to hear about iRule solutions that could potentially be built into future versions of the BIG-IP products...so, keep the feedback coming!
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.
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:
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...
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!!
Well, that does it for the Data Guard article. I hope this has helped, and I would encourage you all to go turn on Data Guard...it's simple, yet it's powerful and effective!
Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list.
Another short and sweet article. I too enabled Dataguard with block mode first and realized its blocking all credit card transactions. We were testing application with dummy purchase and found Dataguard blocking the purchase request, so i disabled blocking for Dataguard and started wondering why this feature is provided if it blocks even legitimate credit card transaction?
One more question, i found a false positive where in URL there is bin directory /bin/ it is part of application, ASM blocks this url as it detects by a signature bin execution URI. I completly does not want to disable this signature so i created a allowed URL giving it a name and mentioning URL however still it blocked. for now i have disabled the signature.
As for the /bin directory issue, I'll take a look at that and see if I can find a good solution. Disabling the signature should work, although that might not be your preference for a final solution.
Thanks again for the comments and questions!
I am working on fine tuning security policy, if i accept learning suggestion for signature does this allows all traffic against the signature or only the url or payload which i accepted through learning suggestion?.
For example, if I see an "attack signature detected" violation against parameter "username" then I can "learn" that violation for that specific parameter. So, if the ASM detected signature 200002147 (a SQL injection) against parameter "username" and then I learn that attack signature against that parameter, the attack signature will be disabled for that parameter only. All other parameters and URLs will still trigger that specific attack signature.
That said, there are some attack signatures that are not parameter or URL based. They are global attack signatures that are not associated with a specific URL or parameter. If you "learn" one of these signatures, then it will be disabled for your entire security policy. The best way to determine if a signature is parameter-based or global is to click the "learn" button next to the attack signature violation and it will take you to a screen that lists all the signatures associated with that violation. You can click the down arrow (show/hide parameters) next to each signature and it will list the details for that signature. If the detailed list includes a specific parameter, then the signature is parameter based and not global. If it does not, it's a global parameter.
I hope this helps. Let me know if you need anything else!
Thank you for clear explanation. As far i know this information is not available in F5 devcentral. Please make this available for larger audience many are confused with this learning process.
I can add more content to the wiki if needed, but this should provide an easy way to find this ASM information.
We are getting overmatching on credit card data - sometimes it is matching a string in some base64 encoded images or guid-like system identifiers that are passed as parameters. I can see that URLs can be excluded from Data Guard, but I wish it could be enabled/disabled on entities like how attack signatures are applied.
Is Dataguard supported in SharePoint Hybrid deployments? We had a recent incident - windows sid in response from SharePoint crawl was ****ed by dataguard and had to turn it off for crawls to work.