The BIG-IP Application Security Manager Part 2: Policy Building
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. What Is A Security Policy? 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). How Do I Create A Policy? 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: Create a policy automatically Create a policy manually Create a policy for XML and web services Create a policy using a vulnerability scanner 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. Create A Policy Automatically 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: Create A Policy Manually 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? Create A Policy For XML And Web Services 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... Create A Policy Using A Vulnerability Scanner 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. The Rest Of The Story 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. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
