Netscaler WAF Migration

I believe 'Server Technologies' included in v13.1 likely addresses the concerns of having the right signatures or signatures sets added to the policy. The system uses the detected server technologies within the client server communication to determine the appropriate signature sets to apply to a policy, ensuring proper protection for the application.

Policies cannot be too bulky when Automatic policy builder has been used to learn traffic, as it will not add anything to the policy it has not seen in traffic, and seen for an appropriate number of time, clients or user sessions.

Also with Automatic or Manual learning process, attributes are presented to the Security specialist for review, that they otherwise might not even have thought about. So paying attention to the learnt traffic is important, but Automatic policy builder can also be very reliable in easing the work of the administrator in this regard.

If there are any specific concerns or area deemed to need improvement, we are more than happy to review this within our Support process, and handle appropriately.

It might be a good idea to follow the feature by feature approach for the reasons suggested, such as ensuring you continue to have the level of protection you have at the moment with the Netscaler WAF, until you have a full migration to the ASM with your policy fully maturing after learning all traffic. Also monitoring the policy building process will allow you to learn more about ASM building your Security policy. However, I would expect that you get more than 75% accuracy on your automatically built policy as compared to the manual built process, particularly since both now use the Unified learning framework, available from v12.x. I believe you should achieve high accuracy with your Automatic Policy builder.

With WAF migration, consider feature by feature approach as a worthy alternative.

If an incident occurs, all troubleshooting efforts can be focused on a smaller area of surface. As an example, in day 1-2, you could only enable basic HTTP compliance checks on BigIP WAF and disable the respective protection on Netscaler WAF. In day 3-4, you take next feature and progress further until Netscaler WAF has no enforced features left. While the migration is ongoing, you're free to handle your usual day-to-day activities with no exposure to major risks.

If you enable learning, your own understanding of the product will not improve as much. Furthermore, automatic learning only gets you to 75% quality of a manually built policy regardless of the learning duration. With that said, in some scenarios 75% could be justified when human labor costs are taken into account.

Hawary, I believe the way you have fashioned out your deployment makes sense. Ofcourse you won't be able to transfer your learnt traffic from the Netscaler WAF to the F5 Big-IP ASM, but we can learn the traffic. Fortunately, you will be able to quite easily migrate the F5 Big-IP LTM config to the new LTM/ASM device and this should be up and running in no time, and able to give you your existing functionality and performance almost immediately. Ensure that ASM sees all the traffic that you intend it to protect, and policy builder should have a good view of the traffic and build the appropriate policy for you, usually faster with the more traffic it sees for the application(s). You can monitor the learning process of Policy Builder to ensure that things are going as you would expect. Hope this helps.