i have a migration scenario and need you inputs for best approach to migrate. currently i have following scenario: Firewall > Netscaler WAF > F5 LTM and need to replace the Netscaler WAF and F5 LTM with a new F5 LTM + WAF on same appliance. obviously, i can't migrate the learned traffic from old Netscaler WAF to New F5 LTM+WAF. actually i'm thinking to migrate the existing F5 LTM to the new F5 LTM+WAF and after completely finish of the migration, i will create the ASM policies on the new devices and keep it in learning mode. the scenario become as Firewall > Netscaler WAF > New F5 LTM+WAF and F5 WAF in learning mode, once the new F5 WAF learned the traffic, i will change the NAT from the Netscaler WAF to the NEW F5 LTM+WAF. what do you think about that? also if any one have another applicable idea here, please share.
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.
thank you Romani for you answer. actually I have another idea and need your opinion about it (although I will continue with the way I mentioned before). what about removing the Netscaler WAF and put F5 LTM+ASM instead with automatic policy builder and enforce the attack signatures (remove the staging) so that the apps will be protect from the well known attacks and in same time it will learn the traffic.
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.
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.
Share the opinion that machine learning is viable for URLs, Cookies and Parameters. The feature does not yet perform as good when it to complex settings and attributes. Telling if a particular attack detection signature is relevant for the application can be a challenge. A qualified security specialist with good understanding of the application protected is likely to miss some shots. Machines will miss many more. Depending on learning time and a few other variables, policies built automatically either end up too bulky or too thin. They're never just quite right. Just adding a day of manual work can significantly improve the overall quality of an ASM policy.
It will take till year 2075 before a policy builder I'm happy with comes out. By that time, 75% of air planes are self-flying :)
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.
thank you Hannes and Romani for your replies.
what do you think about the first approach i mentioned before?
@Romani and Hannes,
if you were me, what will be your approach to migrate from Netscaler to F5 as per my scenario?
The feature by feature approach is a good one.
First see what is learnt on ASM even before you start to disable features on your Netscaler, that way you can see ASM's perspective of the traffic, then start to disable the features on the Netscaler, one at a time, until you totally move the security to ASM.
This should be good.
let me put what you are saying in following format and kindly correct me if i'm mistaken:
first thing will replace the existing F5 LTM with the new F5 LTM, then will create the ASM policies and assign to the LTM in learning mode. we keep the setup as is (still the Netscaler WAF in same position) for some time till the ASM learns the traffic(the traffic reaches F5 should be clean because it filtered on Netscaler). these learned traffic(urls, file types, parameters, etc..) will be validated with applications teams and then will disable feature by feature from Netscaler and enable on F5 WAF till we finish migration. is that what you want to say?
Yes, your understanding is correct.
Let's strip this off its layers of complexities.
At the end of the day if you did not have the Netscaler already in place, you would still need to build your policy, either Manually or Automatically, and only put it in blocking once it is matured.
The reason for not asking you to take out the Netscaler completely is to afford you the layer of protection you already enjoy while you build your ASM policy.
The feature by feature approach allows you a seamless and smooth transitioning.
I will still encourage you to pay attention to the learning process and see what ASM learns and how it views your traffic and attend to the learnt traffic appropriately, this way you have a good understanding of exactly how ASM is going to protect your application.
exactly, you read my mind
"have some sort of protection from Netscaler till finish my ASM building".
regarding the feature by feature approach, do you have any document explaining it in more details.
One of these articles should help you get started depending on your version:
K79575295: Creating a security policy automatically (13.x)
K71159058: Creating a security policy automatically (12.x)
I will strongly recommend v13.1.x.x though, and those articles can be adapted to your scenario.
If you want to dig a little more, feel free to search on AskF5.com.