Debate: 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?
ASM best practices and web application updates
Hello! Could anyone kindly elaborate how the ASM detects web application changes when the application has been upgraded and has changed - does it detect new variables/parameters (that have been added to the web application) etc and allow them after detection or does it block them by default till the learning counter increases enough to make the parameter valid? We have a production system and users all over the world and the development team updates the apps quite frequently. Are there any best practices how the web application upgrades should be handled ASM-wise? Like for example putting the policy to transparent for a an hour or two till the new stuff has been learned by ASM so we won't get any legitimate users/data blocked? Regards, Erkki