Forum Discussion
Philip_Jonsson_
Altocumulus
AltocumulusDebate: How do you configure an optimal and scalable ASM policy structure?
The reason behind this question is to raise a debate regarding how BIG-IP administrators usually go about configuring ASM policies. I have heard numerous of different methods but no real "best practices" regarding structuring the policies.
In order to get started with a policy, I tend to only go with a Negative Security Policy, focusing on Attack Signatures based on the Generic bundle or adding technology specific bundles. The reason for this is that the application developer does not have a clue how the application works and they do not have dedicated teams that operate the policies when I leave the project (working as a consultant).
I have also seen demos for AWAF and Cloud Edition, where you simply "add a policy" and you're protected, using a more generic policy for all applications. For the applications requiring more specific policies, you create individual for those applications. With Layered Security Policies, this should be quite easy to manage and I'm guessing that is the main reason for it.
What I had in mind was to create the following policy structure:
1. Generic Policy - This will form as a baseline, created using the Rapid Deployment Method and will only contain the Generic Attack signatures along with other mandatory settings. This policy should be mandatory for all applications.
2. Technology Based Policies - This will be a child policy to the Generic Policy also focusing on the Negative Security Model. Here we add attack signatures based on technologies in order to form "security packages". Creating perhaps the following policies:
- Windows
- Linux
- IIS (Windows + IIS)
- Apache (Linux + Apache)
These will be gradually created as the teams send in their orders with technologies that does not already have a policy.
The reason for this is to make it easier for App Teams to select a security package based on what technologies their application is running.
3. Application Specific Policies - This will also be based on the Generic Policy but with more specific settings. Here we can exclude certain attack signatures that are not compatible with the application but also create a policy based upon the positive security model.
The core concept of having a model like this to make it easier for app teams to get a baseline and/or a slightly advanced policy. With the application specific policy, you won't be locked down and having exclusions affect all applications. Also having the ability to create specific and more secure policies for the applications that require it.
This is just an idea I've had when thinking about structuring the ASM policies but I have no idea if this is feasible in real life.
Is there anyone operating their ASM policies in this manner or do you have a different approach?
Chris_GrantEmployee
I don't know that you can definitively answer this question, but I'll answer it anyway. In theory you would put a negative security policy in place and then you would add all the objects you expect to find to a whitelist, effectively giving the ASM a map of your application.
As you correctly note, most people don't understand their web application well enough to tell you what should be there, and what should not. The negative security policies generate a lot of false positives if they aren't very carefully applied, and as a result the web admins decide the WAF either doesn't work or doesn't work well.
Advanced WAF is intended to address these use cases. If you either don't have Advanced WAF, or can't move to it, and you don't have a comprehensive overview of your web application, applying a negative security policy and spending the time to disable attack signatures that generate false positives in your environment is not a bad way to go. If you have white list features you are comfortable with they will certainly help. Without Advanced WAF it really is a balancing act between maintenance and functional security, with reduced maintenance meaning reduced security, and more security requiring more maintenance.