Forum Discussion
zandar_304392
Nimbostratus
NimbostratusBest way to let developers adjust ASM policy
Hello Everyone,
Intro: Behind our F5's we have multiple web servers managed be different dev teams with different security levels and also working with different technologies.
I'd like to ask you, based on your practical experience, what is the best way to adjust ASM policy to current Release of the web application?
I know there is learning mode and also we do have test env., but you might test how long you want and you will never caught all possible causes and so in PROD env. you will have to solve quite lot ASM issues (ilegal parameter type, ilegal URL ... etc).
Is there any way to offer developers some page/script/scantool/iApp that would help them to adjust ASM policy by them self? If yes which one is prefered way?
Or shall I just developed one (shouldn't be hard just couple of forms saving result in .xml)? I don't beleive I'm only one with this needs/question.
Thank you.
Y
You're describing the typical dilemma of risk management. Luckily (or sadly), you only have 2 choices here. The same as with any other security upgrades.
- Accept increased risk of service disruption but minimize risk of security breaches
- Accept increased risk of security breaches but minimize risk of service disruption
My preference is first. I always want to avoid using any learning or staging. But this also means a WAF 'babysitter' must personally attend every application upgrade intervention to make quick calls and policy adjustments accordingly. Legitimate traffic blockings will inevitably occur more often with this path of action. That's the tradeoff. On positive, policies will be exposed to 'unfinished' status for a much shorter period of time as the application upgrades take place.
Hannes_RappYou're describing the typical dilemma of risk management. Luckily (or sadly), you only have 2 choices here. The same as with any other security upgrades.
- Accept increased risk of service disruption but minimize risk of security breaches
- Accept increased risk of security breaches but minimize risk of service disruption
My preference is first. I always want to avoid using any learning or staging. But this also means a WAF 'babysitter' must personally attend every application upgrade intervention to make quick calls and policy adjustments accordingly. Legitimate traffic blockings will inevitably occur more often with this path of action. That's the tradeoff. On positive, policies will be exposed to 'unfinished' status for a much shorter period of time as the application upgrades take place.
zandar_304392Hello Hannes Rapp,
thank you for your answer. We are currently using let say little bit automated option nr. 1. But as our web services are growing, I'm looking for maybe more optimal way to address this issues.
I'm completli aware of what are you writing here and thats why I believe I could develop some kind of "self provisioning" portal for developers to upgrade the security policy.
Y
Hannes_Rapp_162Nacreous
You're describing the typical dilemma of risk management. Luckily (or sadly), you only have 2 choices here. The same as with any other security upgrades.
- Accept increased risk of service disruption but minimize risk of security breaches
- Accept increased risk of security breaches but minimize risk of service disruption
My preference is first. I always want to avoid using any learning or staging. But this also means a WAF 'babysitter' must personally attend every application upgrade intervention to make quick calls and policy adjustments accordingly. Legitimate traffic blockings will inevitably occur more often with this path of action. That's the tradeoff. On positive, policies will be exposed to 'unfinished' status for a much shorter period of time as the application upgrades take place.
- zandar_304392
Hello Hannes Rapp,
thank you for your answer. We are currently using let say little bit automated option nr. 1. But as our web services are growing, I'm looking for maybe more optimal way to address this issues.
I'm completli aware of what are you writing here and thats why I believe I could develop some kind of "self provisioning" portal for developers to upgrade the security policy.
Y
- CharlesCS
Cirrus
If each application and its associated ASM policy (or policies) are in separate partitions, then users can be assigned the "Application Security Editor" role with access only to their relevant partition.
Remotely-authenticated users can instead be associated with a Remote Role Group having the Application Security Editor role for their partition.
