on 04-Sep-2013 06:00
This is the second article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first article in this series discussed the basics of the BIG-IP ASM...what it is, why you need it, some key features, etc. This second article in the series will introduce the feature of policy building.
A security policy is a collection of settings that secures traffic for a web application by determining what traffic can access that application. This policy is the critical and foundational set of rules that will ultimately protect your application.
Let's say you have a web application you want to protect. When a user sends a request to the web app, the ASM will compare the request to the security policy and then decide whether or not to forward the request to the web app. If the request does not comply with the security policy, the ASM generates a violation and the request is either blocked by the ASM or forwarded to the web app depending on the enforcement mode of the policy. In a similar fashion, the ASM checks responses from the web app to make sure they comply with the policy as well. If the responses don't comply, they are handled the same way as non-compliant requests...either forwarded on or blocked depending on the enforcement mode.
I'm sure you can imagine that it would be beyond difficult to configure every one of your web pages to follow a particular security policy. The nice thing about the ASM is that you can define a security policy in one location and then let it do all the hard work for you. If you need to make any changes, you simply change the policy on the ASM and then it automatically protects all the apps behind it with the new configuration(s).
Navigate to Security >> Application Security >> Security Policies and click on the "Create" button on the top right portion of the page. You will have the option of associating this new security policy with an existing virtual server, creating a new virtual server (which you can do directly from the security policy configuration page), or not associating it with a virtual server at all. Remember, if you don't associate the security policy with a virtual server, then it won't do anything because no traffic will flow through it. Check out the following screenshot:
After you finalize the virtual server configurations, you will select a deployment scenario. There are four deployment options available:
In the interest of space, I'll only show screenshots of the automatic policy option. Never fear, though...I'll talk about all the options in this article. The good news is that each of these options is really easy to navigate. If you want to get a good understanding of the layout of each option, you can always click through each one and then cancel it before you finalize the policy.
Creating a policy automatically is a pretty simple and straightforward process. Using this deployment scenario, you simply name your security policy and choose the language used by your application (or select the Auto detect option). See the screenshot below:
Next, you configure the attack signatures that will be used in this security policy. The ASM comes preconfigured with over 2,300 attack signatures, but you can always add user-defined signatures as well. Even though the ASM provides a large variety of attack signatures, you really only need to select the attack signatures that apply to the systems in your application. For example, if your app doesn't use Unix at all, then there's no need to select the attack signatures associated with Unix/Linux. I'll go into more detail on the attack signatures in a future ASM article, so be sure to check back and learn all about attack signature fun!
The final step in the automatic policy option gives you the opportunity to select a policy type (Fundamental, Enhanced, or Comprehensive), learning behaviors, trusted IP addresses, and other blocking response behaviors. The automatic policy will learn the behavior of your application and tune the policy accordingly. There's no magic formula for the amount of time that the policy needs to learn all about your app, but the more traffic it sees, the more tuned it becomes. That said, a good rule is to give it 1-2 weeks to see an adequate amount of traffic. The following screenshot shows the details of this final step in building the automatic policy:
The manual policy is actually quicker to set up than the automatic policy. Using this option, you select the application language and then you can select one of several "Application-Ready Security Policies" which are pre-built policies for many popular applications. For example, if you are protecting a SharePoint 2010 application with this security policy, you could choose the SharePoint 2010 Application-Ready Security Policy and then the ASM takes care of the rest (it already knows what attack signatures to enable, so it doesn't even prompt you for that). Keep in mind that you can configure a separate security policy for each virtual server. So, if one virtual server points to a SharePoint application and another points to an Oracle 10g Portal application, you can configure an Application-Ready Security Policy for each virtual server...one using SharePoint and the other using Oracle 10g Portal.
If you aren't sure which security policy to choose, my recommendation is the "Rapid Deployment Security Policy."
After you choose the deployment policy, you select the amount of time the policy will "learn" about your app. This is listed as the Enforcement Readiness Period. The default is 7 days, but you can change it based on the amount of traffic your app receives...the more traffic it receives each day, the lower this figure can be.
If you choose the Rapid Deployment Security Policy, you will need to choose the attack signatures needed for your application. This step is exactly the same as the one shown above in the automatic policy section. This is the final step in configuring the manual policy...who said this wasn't easy?
Moving down the "easy to set up security policies" list, we find ourselves right in the middle of some XML and Web Services action. Building a security policy almost can't get easier than this. This specific security policy is used to verify XML format and validate XML document integrity against a WSDL or XSD file. If your application uses a WSDL or XSD file to validate XML documents, you will need to copy the file to the ASM. Likewise, if your app uses a URL or parameter to point to the XML documents you want to protect, you will need to provide that info to the ASM as well. Another cool feature is that this policy can handle encryption and decryption for web services.
In this option, you simply choose the application language, and then you have the option of configuring attack signatures (this step is, again, the same as the attack signature configuration found in the other two policy building options). The good news here is that the attack signatures are already configured with the default signatures and the XML signatures. So, if you are happy with that, then you're done! If not, you can add more to the list and then...guess what? You're done! I might set up one of these just for the heck of it since it's so easy...
The option to build a security policy directly from the results of a vulnerability scanner is just plain awesome! And, many companies are choosing this option as they build their security policies. This type of policy does a great job of protecting the application where it counts...at the known vulnerabilities. After all, why should you protect against a bunch of threats that don't cause problems for your app? I should mention that this type of policy will not tune itself based on what it learns from application traffic because it is designed to respond to vulnerabilities found by the scanner.
When you choose this method, you'll be asked for the application language, and you will have the unique option of putting this policy directly into Blocking mode if you choose (more on that in just a minute). As expected, you will choose the Vulnerability Assessment Tool and then you can identify exceptions for the scanner IP address. Then, you click "Finish" but there's actually a little more for you to do. Once you finish the initial configuration, the ASM will need to contact the vulnerability scanner and import the vulnerabilities. So, you will need to provide some authentication info (API key, etc) and then the ASM can talk to the scanner. Then, you can import the vulnerabilities into your policy, and the ASM will configure itself to protect against those vulnerabilities. The following picture outlines the cycle used by the vulnerability scanner and the ASM to protect your application.
There are a few other things to know before you unleash your security policy on your application. Remember all those attack signatures we talked about? Well, when you initially build your policy, those signatures are, by default, placed in "staging" mode. In staging mode, the ASM will not block any traffic, but it will learn the behavior of the application as it relates to the attack signatures. This also gives you a chance to review logs and see what traffic is causing violations or not. So, after you feel like the ASM has seen enough traffic to learn about your application, be sure to take the attack signatures out of staging. To do this, navigate to Security >> Application Security >> Attack Signatures >> Attack Signature Configuration and uncheck the Signature Staging box.
Also, make sure you update your policy's enforcement mode from Transparent to Blocking. When your policy is in Transparent mode, it simply watches all the traffic to/from your application and learns all about it. But, it doesn't actually block anything. So, when you are ready to flip the switch and have it start blocking stuff, make sure you put it in Blocking mode.
The last thing I'll mention is the importance of hitting the "Apply Policy" button after you make any changes to the policy. I've hit my head against the wall more than once on this one...if you make a change (or changes) to your policy, they will not go into effect until you hit the Apply Policy button. This button will appear on the upper right portion of your screen (check out the following screenshot). Be sure to hit it so that all your fantastic changes will get applied!!
Well, that's it for this article. I hope this was helpful information for you. If you have any questions or comments, use the comment box below to let me know. Look for the third article in this series next week! See you then...
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.
Thank you a lot for you articles which are very interresting and helpful. I have juste one question regarding the policies, what do you recommand for ASM administrators, using automatic policy generating or manual ? I heard that automatic mode is not recommanded, could you confirm please ?
Thank you in advance for all.
When discussing policy building, it's hard to say that one policy deployment option is better than another. However, there are some benefits to the manual deployment option:
- more visibility on policy configurations
- more control for administrators
But, when you allow more control and visibility, you run the risk of missing something in your configurations. That's one of the key benefits of the automatic deployment option...if you aren't sure what buttons to push, boxes to check, etc, you can simply build out the policy using the automatic option and let the ASM configure everything for you.
So, it's a bit of a balancing act as to which one is right for you. If you have an ASM admin who really knows the details of the application(s) being protected, I'd say the manual option might be better. But, if the ASM admin is fairly new to the application(s), the automatic option might be the way to go so that you don't miss anything.
Also, keep in mind that you can always change configurations after the policy is built, so if you choose the automatic option (or the manual option for that matter) and then figure out you need to change some things, you can always do that.
Let me know if you need any other info...thanks again for the great question!
Well written article. I have few questions.
1) When deploying ASM first time in production how can i leave it in transport mode? Is it not high risk?
2) I can not check signature staging also, as i observed even if policy is in block mode when i enable signature staging it does not blocks. How can i balance this in production, without signature staging i run a chance of false positive however with signature staging my application could be compromised without blocking.
1) You can place any security policy in transparent mode by selecting the policy and choosing the "transparent" radio button on the enforcement mode (see the last diagram in the article). In transparent mode, the policy will not block anything, but it will learn traffic patterns and collect log entries so that you can modify it according to your needs.
2) In order for a policy to block, it must be in blocking mode and signature staging must be turned off. When signatures are in staging mode, they are essentially learning traffic patterns on your network. The best way to implement a policy is to enable signature staging for a period of time (up to 2 weeks) and let the policy learn all about the traffic patterns of your application. Then, you can take the signatures out of staging mode and they will block the bad traffic. If you run into false positives, you can always look at your logs (Security > Event Logs > Application > Requests) and view the details of the violations. This view also gives you the option to "learn" a violation, so in the case of a false positive, you can simply "learn" the violation and your security policy will stop blocking on that specific request.
I hope this helps...let me know if you have any other questions!
Thanks for answering.
While the policy in learning mode how can i stop any attack, what if in this 2 week learning period any one hack my production website.
In addition, you can enable other security modules like the AFM or even the security features of the LTM (i.e. syn flood protection) to protect your site even more.
I hope this helps...let me know if you have any other questions. Thanks again!
I guess it is an old article, even though it says Updated 21-Feb-2017, the screenshots does not match with what I have, I have bigip with 13.0.0 build 2.0.1671 and it does not look like this, it might make sense if the author indicate what version of F5 he used to make this article.
nice article, post staging, policies or traffic or logs are validated and enforced, it's changed to blocking mode as well. Is there a feasibility to export the logs or traffic pattern which was enforced, which can be imported in a different box which is not sync as there are two sites and we are going with learning and blocking mode at one site, in case of export/import option availability , second site can directly go in blocking mode, both sites are with same traffic, no difference in traffic pattern.
Thanks for wonderful article. I have one doubt. Suppose my policy enforcement mode is changed to blocking and signature staging is turned off. After couple of days if my application started receiving some new attacks which were not learned during transparent mode. How would i protect my application then ? Will it use attack signature database to download latest attacks and map to my policy ?
Thanks for this GREAT and helpful article about the ASM, I LOVE your sense of humor it makes it easier to follow along the readings 🙂 🙂
Thanks for your knowledge sharing...John !!!