Click Here - Part 1
Click Here - Part 2
In a fast-changing technology landscape, security is a moving target as the sophisticated attacker unearths and takes advantage of new weaknesses. Cybercrime has moved beyond mere vandalism and emerged as a professional industry focused on exploit kit innovations and planned attacks, given its lucrativeness and with some countries around the world involved in extensive cyber-espionage. The global hackers’ economy is pegged conservatively at around $450B, while Gartner estimates the worldwide security market for 2014 to be just about $71B.
In the December 2013 breach of retail giant Target, data from as many as 40M credit cards and 70M user accounts were hijacked, while Home Depot data breach between April and September 2014 affected 56M debit and credit cards, data of which is said to have appeared within days on black-market sites. Per Checkpoint security report 2014, 88 percent of analyzed organizations experienced at least one potential data breach event in 2013, up from 54 percent in 2012. Verizon’s data breach investigation report identified nine major patterns that covered over 90% of security incidents in the past decade, with the dominant pattern varying across industry verticals. [Refer bottom-right of the following chart for a listing of these categories.] In the recent years, dangers of targeted attacks and advanced persistent threats (APTs) have garnered much of the attention in the information security world.
How can SDN improve security?
With the increase in network traffic, virtual machines, cloud computing, and malware threats, IT manpower is a major security bottleneck, as they simply can’t keep up with the increasing demand of sorting through incidents/alerts and fine-tuning security controls based upon latest threats. This situation can be expected to exacerbate as IoT applications gain momentum. The only way to bridge this growing response-capability gap is through intelligent incident detection and automated response.
While automated security is a key driver, the excitement with SDN enabled security is more so around the opportunity for intelligent response on a granular basis – be it on per flow, per application or per user basis – to provide Security-as-a-Service, while eliminating manual configuration errors and keeping down SecOps & NetOps staffing costs. No longer would the default system response to any severe security threat be ‘Fully Block’.
Enterprise SecOps teams are interested in using SDN to enable multiple usecases – to selectively block malicious traffic from endpoints while still allowing normal traffic flows, to centralize security policy and configuration management, and for network security policy auditing and conflict detection/resolution.
With deperimeterization, corporate networks no longer have a single point of entry or exit, resulting in the demand for network telemetry and flow-based security solutions. SDN could be used to act on any anomalies detected on flow capture data, by dynamically establishing rules to divert specific flows to either a centralized or distributed enforcement points. Additionally, SDN could be used for traffic engineering to direct discrete network application flows to specific combination of security services such as FWs, IDS/IPS and WAFs.
SDN’s capability to programmatically and dynamically insert customized security services in the network path, via service chaining of physical and virtual L2-L4 routers/switches/appliances [as illustrated in below figure], could help minimize performance impact of ‘bump in the wire’ security devices, while enhancing security by acting on gleaned threat intelligence.
Figure – SDN enabled network and application security (Source: devcentral.f5.com)
While SDN controller limits its visibility and programmatic focus to underlying physical/virtual network elements and thus directly implements network security, application layer security is provided in this architecture by working in tandem with orchestration components to control other L4-L7 data path elements.
In a nutshell, SDN can help improve security by aligning the right security service with the right flows.
Common Security Usecases of SDN
Having gone over SDN security benefits in the previous section, let’s now deep dive into a couple of well-defined SDN security usecases – DDoS mitigation, Advanced Malware Quarantine and Elephant Flow mitigation.
DDoS Mitigation
Distributed Denial of Service (DDoS) attacks that are typically launched from compromised systems (bots) bombard enterprise applications with fake service requests, with the intent of denying or degrading performance of legitimate service requests. In addition to hogging the application servers, such attacks consume SP network capacity and saturate inline security devices. Addressing DDoS attacks requires detection of fake requests and diverting traffic to a specialized cleaning device to remove fake packets from the traffic stream, and sending back legitimate packets to the enterprise application/service.
While DDoS defense can be implemented through Remotely Triggered Black Hole (RTBH) or Policy based routing (PBR), the former solution implements filters that block all traffic to the target application, thus making it unavailable for legitimate services too. On the other hand, while static PBR based solution provides granular flow control, it requires SPs to add manual filter configuration on their backbone/edge routers and thus prolongs the recovery time from such attacks.
In comparison, BGP FlowSpec which aligns with the SDN paradigm follows a more granular approach and automates distribution of filter lists that can match a particular flow via BGP NLRI to the backbone/edge routers. So, policy updates happen dynamically and only a specific flow traffic (based on L3/L4 information) is stopped instead of dropping all traffic to a server, as illustrated in the below figure. SDN can thus boost security by dynamically reprogramming and restructuring a network that is suffering a distributed denial-of-service attack.
Figure – DDoS Mitigation using BGP FlowSpec (Source: Alcatel-Lucent)
Automated Malware Quarantine (AMQ)
SDN can also offer security capabilities such as automatically quarantining an endpoint or network that has been infected with malware.
In the non-SDN architecture, AMQ is typically deployed as a proprietary standalone solution where each device performs its specified function autonomously, with limited awareness of other devices in the network. This closed approach is suitable only for static traffic flows, and inflexible in data center environments where server workloads are virtualized, traffic flows are highly dynamic and multiple simultaneous flows must be maintained.
In a SDN controller driven network, if detailed forensics by network security devices generate a high enough score to initiate a quarantine directive, the SDN controller translates this into a set of OpenFlow rules that is pushed down to OpenFlow enabled switches to cut off the infected host from the production network and display (via the Web Proxy Notifier in the below figure) a web page with corrective actions to be performed. Once the corrective actions are performed, the rules are changed to allow the end host back into the network. Such automated reconfigurations through SDN reduce the response time to security threats, while allowing user mobility at the network edge. Given that this AMQ implementation does not require any additional software or hardware support beyond OpenFlow enabled devices, this is a vendor agnostic solution and ripe for deployment.
Figure – Advanced Malware Quarantine using SDN (Source: ONF)
Elephant flow detection/mitigation
Short-lived flows referred to as mice tend to be bursty and are often latency sensitive. In contrast, long-lived flows termed as elephants normally perform transfers of large blocks of data and are typically packet latency insensitive. Without intelligent traffic engineering, elephant flows may fill up network pipes causing latency and/or service disruption of mice flows.
SDN applications could help select a marking action and instruct the SDN controller to push the action to OpenFlow routers/switches to assign a selected queue for traffic associated with elephant flows. Other applications include offloading elephant flows from L2/L3 network fabric to the optical circuit switched network i.e. a pure photonic layer 1 network, for better performance and scalability at lower cost. In an enterprise environment, elephant flows observed during network backup of a filesystem could be prevented from taxing the firewall and slowing down its performance without compromising on security, by implementing a firewall service bypass function dynamically via SDN, based on whitelisted flow parameters of “good” permitted elephant flows. The permitted elephant flows are now dynamically re-directed so that they are sent directly in/out of the campus and the firewall is no longer in the forwarding path.
Security-centric SDN offerings
While OpenFlow is a key technology enabler of SDN security usecases as we saw in the previous section, few firms offer enhanced SDN security solutions that go beyond OpenFlow.
Illumio – a promising startup with a veteran executive team from Cisco, McAfee, Nicira, Riverbed and VMware – is based on the idea that each workload must have its own defenses. Illumio’s Adaptive Security Platform (ASP) provides visibility and enforcement services to dynamically keep pace with the motion, change and automation of the underlying IT infrastructure and applications, by attaching fine-grained security at the level of individual workloads while being continuously aware of its context. [Refer below figure to understand workload context.] It allows enterprises to secure applications across private, public or hybrid cloud environments on any physical server or VM. Illumio has 25 customers including Morgan Stanley, Plantronics, Creative Artists Agency, UBS, Yahoo and NTT I3.
Figure – Workload context (Source: Illumio)
Illumio ASP provides two modes of operation: (1) illumination mode which security administrators can use to visualize workloads and traffic flows, perform policy analyses, assess security gaps and potential impacts to application flows, and even discover unused workloads. (2) enforcement mode which lets administrators write security policies using natural language to describe desired communications between workloads. Once the policies are enforced, workloads are locked down to interact only with the specifically allowed paths.
As illustrated in the below figure, Illumio ASP is architected as a distributed and asynchronous system with Virtual Enforcement Nodes (VENs) attached to individual workloads (running on any VM, physical server, or private/public/hybrid cloud) and a centralized policy engine (PCE). The VENs listen continuously for the context of their workload and relay the information to the PCE, which computes enforcement rules by combining the workload’s context with configured security policies. The enforcement policies are then sent to the VEN, which modifies the appropriate iptables or Windows Filtering Platform parameters on the workload.
Figure – Security-centric SDN – Illumio ASP architecture (Source: Illumio)
NetOptics, a provider of application and network visibility and monitoring solutions, offers Security-centric SDN by combining an SDN controller with Network Packet Brokers (NPBs) in an architecture that allows for intelligent orchestration of the customer’s existing security appliances and solutions. NPBs embody dynamic attack monitoring, ability to chain solutions and distribute traffic, while the SDN controller is used to assess the network and adapt the network behavior based on threats detected through security enforcement elements, to either divert suspicious traffic, change security devices’ responses, or block packets altogether, all with minimal-to-no human intervention.
Radware’s Defense4All, the first open SDN security application to be integrated into OpenDaylight, offers carriers and cloud providers DoS and DDoS detection and mitigation as a native network service. The application uses the programmability of SDN to collect statistics, analyze information and control the infrastructure layer to proactively defend against network flood attacks. This allows operators to provide DoS/DDoS protection service per virtual network segment or per customer.
In today’s dynamic cloud data centers, assets and their network configurations are subject to change yet compliance lacks automation and continues to rely on manual processes. Catbird, the leader in security policy automation and enforcement for private clouds and virtual infrastructure, offers CatBird vSecurity to bring automation and agility of the cloud to security automation and enforcement of compliance standards such as PCI, HIPAA and FISMA. By integrating with Cisco ACI, Catbird provides IT teams a highly standardized, automated approach to provisioning security as part of the network policy, through the asset lifecycle from asset inception to teardown.
Most vendors including Juniper (Altor Networks acquisition rebranded as Firefly Perimeter) and Cisco offer SDN controllers that seamlessly integrate with virtual and physical routers/switches/security devices to enable dynamic provisioning and service chaining of security services. Among the vendors that have already announced OpenDaylight Helium-based products is Brocade. Helium release has multiple security capabilities including Secure Network Bootstrapping Infrastructure (SNBI) and AAA. Alongside, we have OpenFlowSec, a community focused on developing OF security applications, kernel extensions and application frameworks, to assist OpenFlow practitioners in enhancing security capabilities of OpenFlow.
Is SDN secure enough, to offer security?
We’ve seen that good potential exists to enhance security through SDN, and there are ongoing industry efforts to help realize it. But, is SDN inherently secure enough, to augment network and application security? Or is SDN security an oxymoron as skeptics put it? Let me explore this aspect to try and calm down the naysayers to SDN from a security perspective, before I wind up this post.
Here are the top security concerns of the SDN architecture –
- Single point of failure, given the central function of the SDN controller
- Wide span of impact, when the network is opened up to applications
- Need for secure communication between controller and end nodes/applications, to stem MITM attacks
Single Point of Failure
Because the control plane and thereby the SDN controller play such a central function in the SDN architecture, security strategies must focus on protecting the control plane to thwart any targeted attacks on the controller – be they to saturate the control plane or attempts to leverage policy configuration errors for infiltration and lateral movement – as access to the controller could potentially give complete control of the network to an attacker.
It is vital to secure the SDN controller by carefully designing access control policies, manage authorization, track and audit usage of the controller. Also, where it resides on the network is a big security concern. This concern of having a king that needs to be protected are being addressed in variants of the SDN architecture through High Availability in the controller, SSL communication between controller and network elements, extension to the OpenFlow data plane called connection migration, which dramatically reduces the amount of data-to-control-plane interactions that arise during such attacks, SIEM to log everything that comes out of the system, analytics to correlate logs from SIEM and alert the manager of any changes.
Wide span of impact
In contrast to pre-SDN one-by-one configuration process, where an error might only affect one part of the network, SDN now makes it easy to have one policy applied uniformly and in an automated way. However, opening up the network to its own applications require their own security policy framework, governance and management to be put in place.
Business applications are vulnerable to potential threats because of the powerful SDN programming model. Multiple SDN network services may interfere with one another, compromising the forwarding behavior of the network and such conflicts must be avoided. Security policies may be compromised at the controller, at one or more network devices, and/or at other places. As a result, security policies must be validated, along with the network configuration and behavior and performance.
While the upside is that SDN will demand clear policies, companies will need to spend time thinking about and designing those policies. These can be expected to be reside as pre-provisioned security policy logic in a policy management system.
Communication between controller and end nodes/applications
To thwart any security barriers to SDN adoption, OpenDaylight community launched a project to analyze current security capabilities of its SDN implementation, and provide recommendations for security enhancements. Below is a quick snapshot of the transport layer security of existing northbound (NB) and southbound (SB) plugins. For example, OpenFlow specifies the use of TLS or UDP/DTLS, which support authentication using certificates and encryption to secure the connection.
Figure – Transport Layer Security capabilities of SB & NB protocols (Source: ODL)
OpenDaylight recommendations for SDN controller security that are implemented in Helium and future releases include:
- AAA service for applications/users/devices
- Framework to securely and automatically discover, connect and configure the devices
- Secure mechanism to cluster the controller for scalability and availability
- Robust incident response support for controller/devices/user. E.g. A southbound syslog plugin to incorporate capture logs from devices in incident analysis
- Secure communication channel to connect to plugins, common trusted crypto key storage for all plugins, pluggable or built-in Certificate Authority
How is the scale tilted?
Securing networks is becoming more challenging to businesses, especially with BYOD and increased cloud adoption, if not yet due to other mass phenomena such as Internet-of-Everything. Organizations can certainly protect themselves better through automated and dynamic security solutions made possible through SDN, as it provides a centralized intelligence and control model that is well suited to provide much-needed flexibility to network security deployments.
With SDN, we can add agility to network intrusion responses and go beyond the network to protect what is actually of interest, namely applications. Focus on network security was more an interim arrangement as there existed a network visibility deficit at the higher layers. However, by focusing on the network all these years, we lost the most important context awareness which will help deduce if the application or user is doing what is allowed to be done. Security-centric SDN allows an organization to deploy a quick, decisive and deep enterprise-wide response to threat on all fronts. An integrated solution comprising both network and application-layer elements will ultimately provide the comprehensive ‘top-to-bottom of the stack’ security desperately needed to defend against attackers in the dynamic threat landscape.
The key to realizing self-defending networks, however, is “lower false positives” combined with “actionable-threat-intelligence”, given the lack of human element to weed out false alarms or manually correlate event logs to decide on the course of action, in the SDN driven security architecture. The ecosystem of network security vendors, threat intelligence providers, and security professionals should strive for highly accurate intelligence so that automated security remediation decisions are made with a high-degree of confidence. Also, SDN technologies will need to continually evolve to enhance their inherent security capabilities to avoid being a dampener to adoption.
Adoption of SDN will force NetOps and SecOps to work together more closely, even if they aren’t merged into a single organization as few propose or atleast foresee to happen. This could be a bigger change than the driving technology per se, and one that could meet with opposition, given the organizational dynamics involved. Let’s wait and watch how these play out and if enterprises are able to tap into security-centric SDN benefits.
Meanwhile, how do you think the balance is tilted? Will security drive or hinder SDN adoption? Also, a clarion call to security professionals out there to critique my post. Look forward to learning from your feedback too, while I try to get a better handle on security.
