When it comes to securing the Department of Defense's massive networks, software-defined networking (SDN) can help protect vulnerable legacy and custom-developed network infrastructure.

The U.S. Department of Defense (DoD) operates one of the largest and most complex networks on the planet, which poses unique security challenges.

During the Air Force Association’s 2017 Air, Space, and Cyber Conference in September, Navy Admiral Michael S. Rogers, commander of the U.S. Cyber Command and director of the National Security Agency, pointed out four key areas that the DoD is focusing on defending: networks, platforms, weapons systems, and data.

Much of what goes on to protect the DoD’s network is classified, but embedded systems are surely among its greatest security challenges. “DoD networks are global in scope and support absolutely critical operations,” says Dr. Dennis Moreau, senior engineering architect, networking and security, for VMware in Palo Alto, California. “When they aren’t working, people are at risk. And these networks contain many devices developed under contract, such as specialized signals processing and specialized communications … across the board to embedded sensors, field-programmable gate arrays (FPGAs), and all sorts of new electronics ‘at the edge.’”

One of the problems these enormous networks bring is that “when endpoints are idiosyncratic, custom-developed, or developed under contract, it’s difficult to go find a patch for something that was built maybe 10 years ago, but has since become an absolutely essential part of the network infrastructure,” Moreau adds.

The DoD’s massive network has evolved over a long period of time, so this requires bringing together many unique endpoints. “If we consider the military network with embedded systems writ large, I’m not sure there is anything more complex – from a configuration-management, security-management perspective, sort of ‘defense across asset evolution,’” Moreau says.

If you think it would be a complete nightmare to try to secure all of these networks and devices, you’re right. “Its complexity is also due to the unique challenges that the military has with regard to staffing,” Moreau points out. “Folks go in and get very good at something and then move on, because it’s ‘up or out’ in terms of promotion.”

Third parties or contractors provide a level of continuity, but their roles and contracts also change over time, so it can be difficult to get a clear, long-term definition of what their roles are, what their organizational entitlements are, and what normal behaviors are when you have all of these dynamics and very evolved systems with global reach in place. “You can see how situations in which contractors gain too much access and are able to do things that would otherwise seem extraordinary – like exfiltrating gigabytes worth of data – can happen within this kind of environment,” Moreau notes.

What role can SDN play in network security?

Again, much of what the DoD is doing in terms of network security is secret or classified, but 2017 budgets for the Army, Navy, and the Defense Information Systems Agency (DISA) all include mentions of software-defined networking (SDN).

“We’re seeing significant initiatives within the Defense Department to cultivate ‘software-definedness,’” Moreau says. “One of the biggest is DISA’s decision to move the inter-military branch networks to a software-defined basis.”

SDN is essentially a stack architecture designed with security as its foundation, which separates the network-control plane from the data-forwarding plane and centralizes it within a controller that defines forwarding behavior through higher-level policy. Northbound application programming interfaces (APIs) sit atop the controller and present a network abstraction interface to the applications and management, while southbound APIs allow the controller to define switches’ behavior at the bottom of the SDN stack. The key to SDN is the separation of data and control planes.

“DISA and individual military branches have been looking hard at the recognition that there really isn’t a ‘finish line’ here because SDN is evolving,” Moreau says. What this means is that they need an infrastructure that gives them a level of agility to respond to what they see as it’s happening.

“The ‘software-definedness’ of the networking and ‘plumbing’ – even software-defined radio and systems that provide battlefield frontline connectivity – is all in recognition of the fact that what you need to do often isn’t well defined before you need to do it, so you need the ability to be agile and to shape your infrastructure to accommodate whatever it is that you need to do,” he continues.

All embedded technologies that were built under contract and may be old, or were custom-developed and don’t have a consistent place to go for security patches, can be protected via SDN. “You can wrap a logical network right around those custom-developed capabilities – whether it’s a device, a sensor, or a system – to give it state-of-the-art protection in terms of its network and intrusion prevention system (IPS) capabilities,” Moreau explains.

SDN provides the flexibility of “potentially giving every custom system its own network, which can then be protected appropriately, without having to change the underlying system behind the scenes,” he says. “You can give it its own protection policy, allowing you to decide what should and shouldn’t go into and out of an application, placing the controls right on its boundary. So you can extend the secure operational lifetime of some of these older or custom technologies.”

For example, you can give an embedded radar system on a naval ship its own network, protection, and policy, so that those policies will be a concise set of policies, aligned to whatever changes occur on that system and vulnerabilities discovered over time. “No need to change the system that may have been built five to ten years ago,” Moreau says. “Many aspects of ‘software-definedness’ that make security better in defense, military, and embedded scenarios are also being leveraged in the enterprise.”

Another bonus is that compelling sustainable costs come from SDN because it allows the user to essentially host legacy capabilities on modern technologies. “Also, by reducing the complexity, the same system that can host Linux can also host Windows and very old Windows – and provide state-of-the-art protections to it by having modern firewalls, IPS, web application firewall (WAF), sandboxing … sitting right in front of old versions of old applications on old operating systems,” Moreau adds.

SDN visibility

One of SDN’s biggest benefits is that it provides granular visibility when firewalls are placed on east-west traffic.

“Try doing this with hardware and you’ll end up hairpinning the traffic out of the data center to some device on the outside and then back in. The latency, complexity, and selectiveness with which we have do that really limits your visibility,” Moreau explains. “But if I can put the firewall right on the logical boundary of the application, the virtual machine, or the embedded system, then my visibility is intrinsic and it scales with the number of workloads. More workloads, more protection, more visibility. Consequently, the ability to grope around for a victim and to move laterally within an environment once an initial infection occurs is no longer something that occurs in the dark.”

There’s still work to be done, because SDN needs effective analytics to pay attention to all of the new sensors’ instances and boundaries within these environments and “to then make what we see to usable, again using the flexibility of the network to help to defend it,” he says.

Going forward, SDN even enables advanced protections like moving target defense (MTD). “MTD is becoming more easily realizable because of things like ‘software-definedness’ and especially SDN, where we can proactively provision systems so that when we see something anomalous we can reprovision it,” says Moreau says. “We can throw down a brand-new network, a brand-new machine, and provision an application on top of it from trustworthy sources, so that an infected one can be rolled off [for investigation] and a new one rolled in. All this can happen by using the dynamics you get from ‘software-definedness’ you get as a protection mechanism.”

Putting SDN to work

If you simply take an existing network topology and implement it on “software-defined” technology and don’t change the logical topology at all, you won’t get the ability to wrap a network around those legacy or custom solutions or get the more granular protection, visibility, and additional flexibility it provides, Moreau says.

Taking advantage of SDN requires investing in the definition of granular security posture, the policy you want to place on the boundary of those applications and systems to get tighter “least-privileged protection, preventing ad hoc abuse of loose permissions and access controls,” he adds.

It involves characterizing all of the systems, both legacy and current – to decide how they should and shouldn’t behave (for example, decide what the firewall rules on its boundary should be); what the SNORT [a network-intrusion prevention system] rules on the IPS on its boundary should be; what the MSRI rules on the WAF should be to stop cross-site scripting.

“This requires knowing what the system is supposed to do,” Moreau cautions. “So you need to do that work and documentation so that it’s current and maintained to be able to take advantage of the cost and capability advantages of SDN.”

None of this happens by accident. “It takes effort and involves cost – but the cost is repaid in spades in terms of efficiencies, life cycle costs, and more effective protection,” Moreau asserts.

Attacks on SDN controllers/hypervisors

Two of the security concerns people have expressed about SDN are that its controllers and hypervisors can be attacked. Know what stops that conversation almost immediately? “For decades, we’ve had hardware-based network protections and control and it doesn’t seem to have stopped massive breaches,” says Moreau says.

With software-defined controllers, if you find a flaw, when something isn’t behaving the way you want, you can rapidly address it. “This isn’t the case with a bunch of hardware devices scattered across the globe and synchronized in different ways, using an operating system designed exclusively to run, for instance, routers and firewalls. Those have a long history of having challenges with respect to security themselves,” he explains. “No software artifact ever built was perfect. The question is: Does it have the resilience to have a vulnerability or exploit occur and the ability to continue operating with integrity? This is where ‘software-definedness’ comes into its own.”

The same goes for hypervisors because no underlying processors are perfect. “We’ve seen issues, for example, in IOMMU [input-output memory management unit] addressing in TMP firmware, in control flow, in controllers using DMA, and on,” Moreau notes. “The very same issues can cause problems with hardware ISPs and firewalls, or anything else used for isolation or protection. The big advantage is that, with SDN, we can do something about it.”

Agility and resilience

SDN’s ability to cultivate situational awareness comes in the form of “actionable context and flexible response – workloads that we can move, networks on which we can ratchet down security posture or adaptively change the isolation boundaries,” says Moreau.

This agility “results in resilience that lets us do something about flaws when and if they come up,” he continues. “So it’s not a matter of getting to a point where there are no flaws in hypervisors, network controllers, or underlying hardware in firewalls – physical or virtual. It’s all about being able to see when something is wrong and being able to effectively respond.” Having the flexibility to correct problems and adapt to them while continuing to leverage the system to do what you need it to do is “what resilience is really about,” Moreau concludes.