In the onward rush to software-defined things in the cloud, it seems the concept of network function virtualization (NFV) is beginning to catch up with the more mature (and some might say commoditized) server and application virtualization technologies. With NFV reaching stages of maturity, and controller solutions emerging from seemingly every vendor, what’s holding back the full-on adoption of Software-Defined Networking (SDN)? Well, there is a missing link in the chain, namely security.
The promise of SDN is the ability to define data paths via the network that are optimized for scale and efficiency. Tried and true technologies such as routing protocols seem positively rigid by comparison to SDN and NFV. However, even when the entire data path is completely fluid at the network layer, some services reside on the network that aren’t defined by route and switch policies.
With security in mind, these services include everything from IPS services to load-balancing and decryption services, most of which are stateful. So, via SDN, we can dynamically shift a traffic flow through a path with the right bandwidth, connecting two or more endpoints, but if vital services relating to security aren’t also dynamically configured, the data transaction will never be successful. Ultimately, a network is about successful data transmission, and these security service gaps make the full promise of SDN impossible to realize.
Stateful security services are not marketed as “SDN-ready” or as “software-defined security” (SDS). (By the way, security vendors better hurry because the storage people are claiming “SDS,” too.) Most of these services already host an API, in addition to the more commonly-used CLI and GUI management options. In fact, many vendors are hurrying to update and enhance these APIs to make them more readily programmable and robust, usually by converting to REST and ensuring feature-parity with CLI command options. When evaluating our current security services, whether network firewall, IPS, web application firewall (WAF), or other service, these are important aspects of the API that should be inspected. It may be as straightforward as upgrading the firmware operating system of the security appliance to obtain a more robust, modern API capable of supporting our goals for SDN automation and orchestration.
Given that some stateful security services can be dynamically programmed to add an ACL rule or policy via such an API, what are the next steps?
First, if we haven’t already selected an SDN controller or orchestration suite, we must research whether a supported plug-in or integration exists. Many security technologies have focused on vetting integrations for the most popular SDN solutions such as Cisco ACI, VMware NSX, and OpenFlow, to name only a few. The integration may be as simple as a plug-in to install, or as seemingly complex as a script that must be customized. In either case, not all such integrations may cover how we leverage the security services in our infrastructure, so we must be prepared to customize and extend these integrations or build them ourselves to suit.
The second part, which may be more challenging for us as an industry, is finding the skills within our ranks to build these solutions. Do we have the folks with programming and scripting skills on our security or networking teams? If not, are we able to “borrow” resources from our friends in application development? Who are the individuals on staff who can quickly ramp these new skills? These types of conversations between network, security, and development teams could be the necessary catalyst to an entire DevOps movement within the organization.
On the subject of DevOps, one of the keys to success in creating some notion of software-defined security services may well be thinking smaller. Last week, Jeff Sussna (@jeffsussna) wrote a very intriguing article on micro-services segmentation needing DevOps to succeed, and I would agree. We are seeing a convergence of many ideas (cloud, SDN, DevOps, microservices, etc.) which have the potential to be incredibly powerful in the world of security, altering how the infosec team is perceived within most organizations.
In the world of information technology, the security people are often seen as the “Department of No,” a gating factor to progress or deployment of a new system or service. In the software-defined world of things, we have the opportunity to alter that perception by enabling the adoption of SDN and simplifying the configuration and management of security services. While the skills shortage may be killing defense in depth, there’s an opportunity for information security professionals to enhance their own careers while simultaneously improving their organization’s security posture.
Can SDN and SDS be combined to revive the defense-in-depth concept? Clearly, the potential exists to create more focused and adaptable security services via the concepts of DevOps, microservices, and integration with SDN. The tools exist today on various security service platforms to build these types of solutions, so the obstacle is not one of tools or technology. The first challenge for many will be bringing various organizations together for collaboration: security, networking, development, and perhaps others. The next challenge will be identifying the necessary skills to build the integrations from the gathered stakeholders. With the expanding threat landscape, we cannot afford to abandon defense-in-depth strategies. Rather, we must leverage these new architectural and design concepts to make these old strategies more effective.
[su_box title=”About Brian A. McHenry” style=”noise” box_color=”#0e0d0d”]
Bio: As a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
Twitter: @bamchenry[/su_box]
