$400,000,000. That's the latest estimate of Target Corporation's cost of recovery after the data breach that affected 70,000,000 of its customers. I write out these figures to contrast them with the number of people "technically" responsible for the damage -- two or three.
Why two or three? It's safe to assume that there were only a couple of network admins involved in opening the firewall to allow Target's compromised HVAC vendor access. Then there was likely one manager who made the decision to allow that HVAC vendor to provide remote energy management, which may have enabled the breach.
This leads me to consider the pressing need to secure SDN. Imagine what happens when software makes 75% of network and security configurations for us. Will the costs of such errors be hundreds of millions, or billions of dollars?
Security suffers at the bleeding edge
Security is unfortunately always the last feature added to revolutionary new software. Innovation is opportunity-driven, delivering functionality that moves the needle and generates returns on IT investment. More often than not, security is something "we'll get to down the road," or "not included in the first release." That may be fine and dandy for the latest mobile app, but it's unacceptable when it comes to securing SDN.
The level of high-authority automation we'll be implementing in 2014 will be significant. Once managers realize they can use this automation to reduce staff and cut costs, they'll be tempted to go into production with first-generation SDN products. But anyone considering SDN should take a long, hard look at the possible risks of a breach caused by the current state of the nearly opaque SDN security mechanisms. How many decimal places are you willing to take off your balance sheet to shave off a little on automation?
But can't SDN enhance context-based security?
Ah, but you say, "SDN will fully expose the existing context-based security mechanisms of underlying systems via its APIs." Yes, and that's the problem. There won't be an admin with the human brain's ability to spot anomalies on the other end of the API. Instead we will have a controller that is only as good as its producer's willingness to invest in security. So far, that's not much.
Discounting Cisco's ACI strategy and VMware's NXS solutions for a moment, consider OpenDaylight. The consortium is the first to market with actual, downloadable code. The first OpenDaylight release, Hydrogen, offered only rudimentary authentication and authorization mechanisms; forget security basics like auditing, distributed contexts, impersonation and delegation. Things won't improve much in the next release, Helium. Several OpenDaylight members have said security is something they're thinking about, but it's not a focus. That's especially troubling in light of what Helium can do -- controller federation.
Consider a parallel: Active Directory federation. Can you imagine Microsoft releasing the ability to allow cross-domain trust relationships, except that everything is wide open and admins have no control over how trust context flows from one domain to the other? Who would accept that? Yet with controller federation, that's essentially what we're talking about. Going back to the Target example, you'd be taking the last few human admins out of the loop. Did anyone watch WarGames?
Rejecting the Maginot Line fallacy in secure SDN
More on securing SDN
Just how secure is the SDN stack?
Will SDN cause network security vulnerabilities?
Where SDN and DPI meet
SDN and granular policy control
I believe that the lack of security focus in SDN comes from the same thinking that's always exposed us to significant risk. We simply can't let go of the belief that if we build an iron firewall and monitor strategically, everything inside the network is safe. We install countless devices which make dangerous assumptions about external security shielding them from the outside world. Would you put your HVAC systems on the Internet? Of course not. That would be easy picking. The Internet of Things may be a problem on the horizon, be we already have the Intranet of Things. And from a security perspective they are mostly pretty stupid devices.
There's no magical firewall that excuses us from making SDN security a primary focus. Sharp network admins already assume that the enemy is already inside the walls and spend a fair amount of time segmenting and securing networks to mitigate the spread of contagion. They scan, they audit and they report. Admins and network managers working on SDN must be just as vigilant and proactive as the admins working on legacy infrastructure. SDN is not going to be behind the firewall -- it will be the firewall. If you were part of Target's likely all-new IT department, would you recommend automation with "just a bit less" security? I don't think so.
About the author:
Patrick Hubbard is a head geek and senior technical-product marketing manager at SolarWinds. With 20 years of technical expertise and IT customer perspective, his networking management experience includes work with campus, data center, storage networks, VoIP and virtualization, with a focus on application and service delivery in both Fortune 500 companies and startups in the high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.