Forum Discussion

Ppp2016_241036's avatar
Ppp2016_241036
Icon for Nimbostratus rankNimbostratus
Mar 12, 2016

Automatic versus Manual policy building

I try to figure out the pros and cons of automatic,rapid,and manual deployment? Also the staging mode is confusing. I am planning to deploy ASM module in production with transparent mode and ask for more advices. My understanding is automically and rapid build policies itself. I know many people suggest to use automatic but administrator does not need to manually add the rules. I want to see your opinions on accuracy and pros and cons for each option.

 

4 Replies

  • Hi, the below link will differentiate between multiple deployment scenarios

     

    https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-getting-started-11-4-0/2.html

     

    We normally plan for an automatic policy and once ASM learned sufficient traffic ( around 2 weeks) you will have to adjust and tune the parameters. Its like a mid approach of positive and negative security model. Just with Automatic only policy deployment will not get the intended results. Also I go for phased deployment with UAT policy -->staging -->production. I do the changes only in the UAT policy, once comfortable and agreed by application owner you can clone the policy to staging and once the testing done move over to production. I will never touch the production policy.

     

    Transparent mode: blocking is disabled for the security policy, and you cannot set the violations to block on the Blocking screen. Traffic is not blocked even if a violation is triggered.

     

    Blocking mode: blocking is enabled for the security policy, and can enable or disable the block flag for individual violations. Traffic is blocked when a violation occurs, and the system is configured to block that type of violation

     

    Enforcement is always manual and it is up to you to decide and implement the enforcement as per agreement with stakeholders

     

    Staging is the period in which the properties for each entity in the policy are not enforced. This means that when any entity is in staging, ASM does not block requests for it, even if the request contains violations, regardless of the global security policy settings. The elements subject to staging are - URLs, File Types, Parameters, Cookies, Attack Signatures, Redirection domains.

     

    hope this helps,

     

    cheers

     

    • Ppp2016_241036's avatar
      Ppp2016_241036
      Icon for Nimbostratus rankNimbostratus
      thanks Vijith for your suggestions. I have some questions. What did you mean "Just with Automatic only policy deployment will not get the intended results?" Do you meant when you are using automatic policy building, you will also look at the findings in traffic learning screen? Also, when you say UAT, Staging, you meant User Acceptance Testing environment, and Staging environment? But the traffic will be different from production
    • Vijith_182946's avatar
      Vijith_182946
      Icon for Cirrostratus rankCirrostratus
      What i meant is that I follow the mid approach of positive security model (automatic policy deployment) and negative security model (which is manual fine tuning). The below link will help you to clear on this approach https://f5.com/resources/white-papers/applied-application-security-positive-and-negative To answer you other query, what you said is correct, and yes production traffic will be different but I test any change in policy in UAT first.
    • Ppp2016_241036's avatar
      Ppp2016_241036
      Icon for Nimbostratus rankNimbostratus
      It make sense do the testing for the policy on UAT environment, the assumption is UAT environment has similar traffic as production since this is user acceptance testing. The question is in production, do you just export the UAT policy and import to production? Or create the new policy manually and import the template from UAT? Or create the new policy automatically and import the UAT policy? There are several options and I am confused. I think your approach is a lifecycle loop of UAT policy testing -> PROD -> UAT policy testing -> PROD.