Forum Discussion

zandar_304392's avatar
zandar_304392
Icon for Nimbostratus rankNimbostratus
Apr 20, 2017

Best 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

 

ASM Advanced WAF
asm deployment
automatization
devops
security
  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Jul 11, 2017

    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.

     

    1. Accept increased risk of service disruption but minimize risk of security breaches
    2. 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_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Jul 11, 2017

    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.

     

    1. Accept increased risk of service disruption but minimize risk of security breaches
    2. 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's avatar
      zandar_304392
      Icon for Nimbostratus rankNimbostratus
      Jul 11, 2017

      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

       

  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Icon for Nacreous rankNacreous
    Jul 11, 2017

    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.

     

    1. Accept increased risk of service disruption but minimize risk of security breaches
    2. 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's avatar
      zandar_304392
      Icon for Nimbostratus rankNimbostratus
      Jul 11, 2017

      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's avatar
    CharlesCS
    Icon for Cirrus rankCirrus
    Apr 20, 2017

    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.