Best Practice - Policy management when there are several instances of the same application behind several ASM's

So I am not sure I understand.... When you say tailored to the violations on that device what do mean? Are you about allowing traffic through manual policy building and adjusting the policy based on traffic seen? Is the application the same behind each of the 3 ASMs you have or is each instance different? Also what version are you running?

The application behind each ASM is identical. We're running 10.2.0 HF 2.

 

 

 

 

We anticipated performing automatic policy building for a week or two and then fine tuning the policy through the manual violation review process.

 

since application is identical, i prefer the second one.

 

 

just my 2 cents.

Also, in 11.0 ASM added support for synching policies across separate ASM units. Though you can only have the policy builder running on one unit at a time. But you run it on the main ASM unit and then still tune the policy on other units using Learning or manual changes and have the changes synchronized.

 

 

 

http://support.f5.com/kb/en-us/products/big-ip_asm/releasenotes/product/relnotes_asm_11_0_0.htmlnew_feat

 

 

Device Management

 

 

Device management is a mechanism used to maintain a synchronized configuration, between a group of Application Security Manager (ASM) enabled BIG-IP devices in a given network, called a device group. For ASM purposes, a device group comprises one or more BIG-IP devices, using the same ASM configuration. All devices must run the same version of ASM. Using device management, all new security policies, and any configuration changes made to a security policy on one device, can be manually pushed to all other devices within the device group, even if you do not apply the security policy. However, we recommend you apply the security policy in order to ensure consistent enforcement among all devices.

 

 

If device management is used within different data centers, the logging profiles will also be synchronized, meaning that the Syslog server destination will be synchronized as well, even though it probably resides on a different address.

 

 

The Real Traffic Policy Builder® may be run on only one device for any given policy. Activating Policy Builder on any device will automatically disable Policy Builder for that policy on all other devices within the device group. All security policy configuration changes made by Policy Builder will be relayed and performed by all devices within the group.

 

 

If Attack Signature Update is configured for scheduled automatic updates, each device in the device group will update itself independently according to each device’s configured schedule. This update is not relayed to other devices.

 

 

You can select whether a preconfigured ASM device group’s devices are to be synchronized, and if so, which device group. Navigate to Application Security > Synchronization > Application Security Device Group.

 

 

 

Aaron

So I am in the same situation as you are with 4 ASMs 2 in each Data Center and we have multiple applicaations that run through them. Same sort of thing where one application is identical across all 4 ASMs and we have to keep policy in Sync. I am currently running the same version as you are as well. The process I have here is we use a testing environment that is a copy of production to do learning for major changes to the application, I also have a form and spreadsheet that I send to the Developers to have them fill out all the file types, URL's, parameters and information on the values. Then we normally take that information and build policy in the test environment put the policy in blocking and have the users test. Then we copy the policy from the test environment to all 4 production boxes, from there any violations should be minimal so we just manually adjust all 4 boxes when needed, which is not all that often.

 

 

You are probably thinking this is very tedious and time consuming, and it is a bit, but once you get people rolling in the process it is not that bad. You spend a bit of time building policy during the development phase of the application and dealing with a few blocks during testing, but once you go production you should very few violations to manage across all the devices. This process and the forms we use have been refined over the last 4 years of working with ASM, and it took a bit of teeth pulling from the developers to get them on board but it works quite nicely now.

 

 

Having said all that I will say I am planning to upgrade to 11.x code sometime this year and look forward to the features Aaron described as it will save some time in production. So ultimately if you have the ability to upgrade to 11.x and use the new sync features I would go that route.

So I am in the same situation as you are with 4 ASMs 2 in each Data Center and we have multiple applicaations that run through them. Same sort of thing where one application is identical across all 4 ASMs and we have to keep policy in Sync. I am currently running the same version as you are as well. The process I have here is we use a testing environment that is a copy of production to do learning for major changes to the application, I also have a form and spreadsheet that I send to the Developers to have them fill out all the file types, URL's, parameters and information on the values. Then we normally take that information and build policy in the test environment put the policy in blocking and have the users test. Then we copy the policy from the test environment to all 4 production boxes, from there any violations should be minimal so we just manually adjust all 4 boxes when needed, which is not all that often.

 

 

You are probably thinking this is very tedious and time consuming, and it is a bit, but once you get people rolling in the process it is not that bad. You spend a bit of time building policy during the development phase of the application and dealing with a few blocks during testing, but once you go production you should very few violations to manage across all the devices. This process and the forms we use have been refined over the last 4 years of working with ASM, and it took a bit of teeth pulling from the developers to get them on board but it works quite nicely now.

 

 

Having said all that I will say I am planning to upgrade to 11.x code sometime this year and look forward to the features Aaron described as it will save some time in production. So ultimately if you have the ability to upgrade to 11.x and use the new sync features I would go that route.

One other side note, when doing the policy building we only run through 1 ASM so all the information can be built on one box and once we are at 99-100% then we move to prod across the 4 boxes. Of course this is two separate environments as I am not comfortable from a Security standpoint doing policy building in production. If you only have 1 environment and you have to do the policy building there, I would try and put one ASM out front for the two week automated policy building, but if you are relying on production traffic for that I would advise caution, as we see a lot of blocks when we get to prod that is either just junk traffic most of the time but I also see some poking at the application to see what they can get to. In my large customer facing applications we have a decent size ignore list of URLs that we don't even see in blocking any more because there was so many of the requests coming in.

 

 

Thanks guys! Great discussion!