SDNOverview

February2012

SecurityImplicationsofSoftwareDefinedNetworks
Withonlyahandfulofverysmallsoftwaredefinednetworksactuallyin production around the world, most SDN conversations are purely can tro academic. But that hasnt impeded the interest and announcements that seem to be on an accelerated pace in recent weeks and months ban khoan (seesidebar).Whytheflurryofannouncements?Thereasonisbecause hap dan oftheenticingpotentialofSDNs. By separating the control plane from the data plane, which essentially removes and then centralizes the brains from the muscle of the network, you can quickly make changes to improve the speed, reliability, efficiencyandevensecurity ofthatnetwork.Youcontrolthe networks layout and flow, so you can define and distribute loads, optimizeandprioritizetraffic,andscaleservicesorcapacityupordown with just a few clicks, that is in theory. Thats the key. Commercially available solutions that enable you to realize the potential of SDNs are gia dinh simply not there yet. Assuming they are on their way, from vendors, such as IBM, NEC, HP, Big Switch, Nicira, and still unknown/unannounced players, its important to think through some ofthesecurityimplicationsofthisnewarchitecture.
1

SDNAnnouncementRecap
Nicira unveiled its Network Virtualization Platform (NVP), which AT&T says its using within its internal OpenStack deployment to open the network for innovation and unlock numerous, differentiated offers, such as the AT&T API Delivery Platform, the AT&T Developer Center ForHealth, and otherservices(Feb.6,2012). HPannouncedaportfolioofOpenFlow enabled switches. HP plans to expand support for OpenFlow across all switches in the HP FlexNetwork architecturethisyear(Feb.2,2012).
cong bo

IBM and NEC released news that organizationsareusingtheirstandards based OpenFlow solution to power networks, manage massive amounts of information and deliver new services (Jan.30,2012).

WHATTOCONSIDER

The following are the top security issues and implications for SDNs that need to be thought through before any largescale deployments can be reasonablyundertaken.
SECURETHECONTROLLER

through controller clusters, distributed controllers or some other mechanism. While this may require dang ke significant synchronization and added giam nhe complexity, it is needed to mitigate the impact any one controller could toan bo haveontheentirenetwork. Another thing you should pay chu y attention to when evaluating technology is the failover mechanism. You need to understand and be comfortable with what happens if communication fails; understand the reliability and latency implications to ensure they are within youracceptablerange.
ESTABLISH TRUST BETWEEN THE CONTROLLERANDSWITCH

ENSURE THE INTEGRITY OF THE APPLICATIONS

Because controllers (the brains of the network) can theoretically be used to do anything, their su thoa hiep compromise could have potentially endless threat implications. First and foremost, controllers, need to be secure, both physically and logically. This will require the controller thong thao technology, itself, to mature from a security standpoint, as well as IT phong ngua personnel taking precautionary measuresduringdeployments.

You need to make sure rogue applications cannot bind themselves to the controller and take over the network.Authenticatingtheapplication is a start, as well as being able to then identify and validate any changes to those applications that are authorized. Building in privilege separation between processes can help ensure changes are controlled and authorized; more standardized, powerful APIs into the controllers will also enable a more consistent, predictable application ecosystem.
DEVELOP A FRAMEWORK ROBUST POLICY

gia mao

Currently, the communication channel For example, direct access needs to between the controller and the han che be restricted; who and how users can switches/routers/servers is open; it interact with controllers needs to be needs to be secured and encrypted menh lenh clearly defined (best practice dictates (SSL) to prevent maninthemiddle, accessshouldbelimitedtoonlythose packet injection, snooping, and other hoan toan adminswhoabsolutelyneeditandbe attacks. authenticatedandlogged). (Note, some SDN protocols already

In theory the management of SDNs should be simpler. Controllers are the centralized decision points for the hundreds, thousands, even tens of thousands of switches/routers/servers in your network, which means you should be able to make changes with just a few clicks to keep up with the demands of your everchanging environmentinrealtime. However, whats needed is a system of checks and balances to make sure the controllers are doing what you actually wantthemtodo.Ifachangeismadeto the forwarding table, you need to be tin chac confident it is the right change. This requiresarobustpolicyframeworkthat can guarantee overall corporate policiesarefollowed.Anyviolationscan pose a risk to your organization or knock you out of compliance. For instance, if you have a corporate policy thatnooneshouldbeabletogettothe finance server and the controller reroutes traffic to that server, there

Understanding and limiting what controllers are connected to (nothing other than the switches/routers/ chat che servers) and tightly controlling the applications that can be deployed (should come from only trusted, verifiable sources) must also be normalpractice.
PROTECTTHECONTROLLER

have SSL/TLS built into the specifications but are either poorly implemented or not implemented at all byexistingsolutions.) There also needs to be strong, mutual authentication between the switch/router/server and controller to validate the identity and integrity of eachcontroller. Some pilot SDNs are built as outof band networks to keep them isolated and the threats contained. This is obviously only a temporary work around and not scalable or reasonableforthelongterm.

If the controller goes down (for example, because of a DDoS attack), so goes the network, making the availability of the controller a top priority. The technology must cai tien advance to easily enable redundancy,

needs to be a system in place that flags andpreventsitfromhappening.

FORENSICSANDREMEDIATION

If an incident happens, you must be able to determine what it was, recover and then protect against it in the future. Log analysis and event correlation have always been a challenge, but in SDNs it will fast become a big data issue. Tools need to be developed that can address all the forensics and compliance requirements frommanagement,eventcorrelation toreportingofanynetwork.
kham pha

competing ideas and approaches, for tranh luan example, theres a debate about where the management and control will actually take place. Will it be within the network or within the servers (hypervisors)? The good and bad news for security in all this is the same: the possibilities appearendless.

phuong phap tiep can

SarahSorensen,Consultant sarah@sarahsorensen.com Sorensen Consulting focuses on providing strategic communications and sustainabilty strategies to innovative organizations large and small. During her 8 year tenure at Juniper Networks, NetScreen and OneSecure, she worked on developing new product categories, such as IPS and DI, and educating customers on the evolving threat landscape. Sarah has a strong background in brand, positioning, messaging, sales enablement, channel, product, social and Web marketing for both B2B and B2C companies large and small. She also brings expertise in sustainability she unified the implementation of sustainable business practices within Junipers operations and developed the companys strategy; she has worked with organizations, as a consultant, benchmarking, facilitating focus groups, conducting gap analysis and making recommendations on sustainabilityprogramsandobjectives. She has spoken at events on the topics of network security, SDNs and sustainability. She is also the author of "The Sustainable Network," and blog, bothpublishedbyO'Reilly.

EXPLORINGTHEOPPORTUNITIES

The opportunities for SDN applications vo han are infinite and this also applies to security. The potential to use SDNs to architect easier, cheaper, better securitysolutionneedstobeexplored. For example, one network in pilot wrote an application to distribute its traffic load across a cluster of intrusion detection systems (Snort loaded onto kiem tra virtual servers) to ensure inspection without any performance degradation. The SDN offered a less expensive way to implement this solution and significantlyreducedthecapitalneeded toinvestinapplianceshadthisprovider gonewithamoretraditionalapproach. CONCLUSION

While SDNs are still in their infancy, hap dan their potential is intriguing. As vendors jump into the market and providers deploymorenetworks,itwillforcehard questions around how these networks areactuallyarchitectedandsecured. Over the next three to five years, developers will wrestle with how to solve the issues of availability, policy enforcement, mitigation, management, and overall security. There are several