Don’t let SDN just be Security Defined Networking!

By Charles Crawford ·

I’ve had the opportunity, pleasure and dare I say “fun” of working with Software-Defined Networking (SDN) for some time now. The thing I feel blessed about is the chance I have had to work with this emerging technology and methodology while wearing various professional hats — one as a CTO (get it working), the other as a CISO (secure it … wait, what is it?, OK, keep it away from this stuff).

Now, working for FishNet Security, I have the job of integrating everything from best-of-breed products in security and networking to new emerging trends and models. Following the SDN trend along with OpenFlow has been amazing. The push of excitement with all of the collaboration and corporate participation by larger players is really solidifying the SDN movement and proving the technology will make a long-term impact, but what does this mean to security architectures, governance and policies?

Looking at all of the use cases and benefits of SDN and real-life issues this can resolve — BYOD, mobility, simplifying network design, etc. — the traditional security architecture no longer applies. Is this a good or bad thing? 

Well, I guess it depends on how you look at it. If you take “the glass is half-full” approach, there is now an opportunity to enhance the security profile of a company through additional layers.  Examples abound — Network Access Control-type solutions, addressing BYOD , delivering enhanced services to users while addressing mobility concerns, appropriately matching service and security levels to the user and service being consumed, automating service delivery thereby possibly reducing human error. As with any new approach, there is some “Security through Obscurity” as I called it as a CISO. Done correctly, this environment can be  a win-win. If you are a “glass is half-empty” type of person, well, you could see this as a huge impact and hurdle. What happens to our compliance regarding areas like PCI, SOX or HIPAA? What about our firewalls? Is the security model of defense in-depth gone? Where do we start?

My answer is, “It changes things.” But don’t forget the spirit of security — Risk Management. Is it worth introducing SDN everywhere immediately, especially in these environments? NO WAY! 

With Risk Management in mind, the other thing we should think about is the “User Experience.” I, the user, want to get to something from somewhere and have it work without having to go through additional hurdles, red tape or barriers. What this means is provisioning, auto policy creation, QOS, access, authorization and accountability. This brings me to a couple of key elements that I often see overlooked when it comes to successful SDN deployments, Identity Management and SIEM. The AAA (authentication, authorization and accounting) of security comes into play once again, arguably even more so in the new SDN environments, since this really can be seen as a core foundation for SDN to work in a practical environment. After all, if a user requests a service that triggers the controller to create a route and cause packets to traverse that route, you want to ensure the user is authorized to do so and that your environment can account for that activity.  That part of security has not changed with the onset of SDN.  

Where do we go from here, what’s next and how do we start? It’s most important that we don’t forget all of the lessons learned and hard work everyone has done to put together standards and frameworks. Let’s not recreate the wheel. TOGAF comes to mind as a great place to start. What is the business objective that we are trying to accomplish? Are we aligned properly from a technical perspective to be successful? What benefit does SDN provide to our environment? Let’s not forget the various ISO standards we have become familiar with. ISO 27001, 9001 and 20000 all helped us address security, quality and service management. Again, these standards are completely applicable, we need to look at how they apply in wherever we are applying this new technology and then look at possible new risks, processes and even services we can now deliver and how well we can deliver them. And, finally, there is COBIT, the governance of our environment. With the introduction of possible new services, there are new risks. As such, it is important we have proper oversight — much like we had in our existing security and technology architectures. 

At the core, we have a new opportunity with SDN to deliver services to our users in a more transparent and agile way. With this opportunity, we have a way to implement security like never before. For instance, a firewall would no longer be seen as a barrier to admins and users alike, especially running multiple firewalls with different rule sets. What if we can have firewall rules created dynamically based on user roles? The ACLs can be provisioned and de-provisioned on the fly and logged based on user or service roles and access rights. Thin client, VDI and other virtual ways to deliver to services can also be taken advantage of in this new SDN era, again without having to reintroduce security barriers, but while integrating security through the service delivery aspect. Automation is a huge opportunity with SDN. This allows us to implement security controls in processes that have normally been human-initiated. With proper logging and authorization in place, we can actually have better accountability of what happened and better troubleshooting tools if something goes wrong. 

There are opportunities and hurdles the security community will have to face when it comes to SDN environments. How an organization goes about addressing these challenges will determine how successful they will be. Hopefully, the key to remember is don’t recreate the wheel, remember the lessons learned from the past, and look at how the new technology can help or not help in your environment.