Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Tips for migrating applications to Software Defined Networks

Avishai Wool, CTO, AlgoSec | Feb. 22, 2016
The five steps involved in an SDN migration and what you need to consider.

In order to do this, you need to go over every filtering rule in your network security equipment, discovering all the places where the servers’ old addresses appear. Then you need to duplicate those rules, modifying them to include the new server addresses.

As a side note, migrating to SDN is a great opportunity to reduce clutter and improve your policy efficiency. So, you should only convert actively used rules to the new network – in fact, a good migration solution will automatically flag redundant firewall rules for you.

Once your new filtering policies are written, you need to deploy them to the relevant devices. This involves configuring firewalls, routers and load balancers to allow traffic to and from the new servers.

* Testing to production.  At this point you’ll have a functional system which you should test rigorously, to ensure that all the required functionality is in place and everything operates as it is meant to. You can only move on from this stage once you are confident that the application in its test environment is equivalent to the ultimate production environment.

Moving from test to production, at its most fundamental level is about renaming things. It may be that there is a public name for the server, or a website that users need to access your application. You now need to reconfigure the official published access points to direct to the new server instead of the old.

This stage could involve creating another version of the software configuration already outlined, or it could involve changing default actions within your network. Again, it’s important at this stage to check whether you need to make changes to your filtering policy too.

* Decommissioning legacy versions. The final part of the migration process is decommissioning the legacy versions of application connectivity - but don’t do it before you’re absolutely ready. Make sure your new system has had time to mature, to be stable and fully tested for an adequate time period.

Then, getting rid of the old system doesn’t just involve shutting down old servers. To avoid creating security gaps and breach points for hackers, best practice requires decommissioning all the filtering rules from your old firewalls, routers and load balancers. However it’s important to check that these rules aren’t still used by other functioning applications in your data center, before decommissioning them!

* Managing the network.  Once deployed in production, you should now prepare for ongoing security policy management of your SDN environment. This means structured change management processes, auditing, and compliance reporting, risk management etc. The best way to manage this is with a holistic, automated change-request system that supports both the software-defined network firewalls and security controls, as well as the traditional firewall estate – since the likelihood is that your enterprise environment will still comprise both and therefore unified management is critical to ensure your security posture.


Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.