Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
Comments on this Answer
Comment made 2 months ago by Philip Jonsson 1018

Hey Chris!

Thanks for the reply. Then it feels like we're on the right track just to get a starting point at least.

But my questions is really regarding structuring the ASM policies in the most effective way. We have the concept of layered policies, but is it wise to create one generic policy and add layered policies as children to the generic?

Rather than simply creating a generic policy which will be used as a template for all new policies and create one policy per app.

I discussed this with a colleague and he prefers the template model rather than layered policies due to the fact that one change in the generic policy could affect multiple applications. Also, when excluding a attack signature for only one app, you'd still have to create a completely new policy for that application.

What is F5's approach around layered polices vs. templates? Like you say, this comes down to preferred workflow but it should've come up during the creation of layered policies. :)

0
Comment made 2 months ago by Chris Grant

A lot of it depends on your environment. If you have a bunch of web apps that are all very similar, the layered approach works well. The child policies are really just the overrides and small tweaks that make each policy optimal for each app in that situation.

If the apps are significantly different than the idea of a generic template used as a base for a series of highly customized stand alone policies makes much more sense. You eliminate a lot of the grunt work of setting up the policy, but don't have to worry about a seemingly minor tweak to the parent policy having unintended consequences on a single child policy.

0
Comment made 2 months ago by Philip Jonsson 1018

Hey Chris!

Thanks for the reply. I think that sums up the reasoning we had as well. :)

0