In today’s world of distributed denial of service (DDoS), malware, and phishing attacks, along with web application layer breaches and more, businesses are constantly facing evolving security threats. Indeed, 2016 was a defining year for security earning the title “The year of the mega breach.” Underscoring this notoriety, the 2017 IBM X-Force Threat Intelligence Index cited more than 4 billion record leaks, more than the previous two years combined. Faced with these facts and figures, is it any wonder that a large portion of today’s network security expenditure is dedicated to intrusion prevention?

Unfortunately, security attacks will continue to be a pain point for many organizations, especially as it relates to securing networks because mitigating manual errors in today’s increasingly complex networks is extremely difficult. The goal, therefore, is to prevent hackers from being able to further infiltrate the network once inside, a technique known as isolation, and to eventually remediate the infected endpoint/devices and remove any malware altogether.

Yet, legacy network isolation techniques, based on manual configuration of virtual local area networks (VLANs), increase complexity and this continuously leads to increased manual errors. Ultimately, this expands the exposure surface that hackers can attack. In order to reduce the exposure surface, more isolation is architected and implemented using error prone manual configuration, which results in a vicious cycle affecting overall security. In addition, there is not much visibility to east-west traffic within the data center, which makes it very difficult to detect and quickly respond to advanced malware once they enter the network.

So, how does this relate to a container environment? While it appears multiple containers can be supported by a single copy of a hardened host OS to minimize server vulnerabilities, running multiple services that share a single host OS can make things worse due to lack of strong isolation between the various container environments. In addition, there is now a requirement for dynamic security automation for containers since their environments have become highly dynamic, and provisioning is typically automated using container orchestration systems or platform-as-a-service (PaaS) systems.

This is where software defined network (SDN) solutions come into play. An SDN solution, based on a unified policy and visibility platform, can enable software-defined segmentation, visibility, threat detection, and dynamic response across mixed environments including container, VM, and bare-metal. SDN is policy-driven, secure, automated, highly scalable, and thus well suited to address the multifaceted security requirements in dynamic container environments. Unlike other software-defined security approaches that require changes to workload for enforcing policy, such as an agent inside guest OS, an SDN-based approach to network security can enable security without any agents or changes to underlying physical network infrastructure.

SDN based contextual flow visibility, policy enforcement, and automation can enable a “zero trust” security model where explicit connections are only allowed such as between microservices in a container environment. Since SDN-based virtual and physical switches are already inline in the data path and can see all traffic between workloads, it can help discover valid flows to enable whitelist policies. These whitelist policy recommendations can be reviewed and enforced both in the SDN layer and other existing security controls such as firewalls. This further isolates the container and reduces the attack surface. In other words, should one microservice be compromised, hackers cannot easily traverse to other containers. SDN-based approaches can also enable unified policy definition, security automation, and policy enforcement across heterogeneous workload types in data centers and public cloud, as well as control user access to workloads from branch networks.

But, enforcing granular workload-centric policy and micro-segmentation is only part of the solution. Once granular policies are defined, it is important to monitor what is going on in the network to detect new threats. This is an area where SDN can also help by leveraging contextual flow analytics by monitoring traffic flows between microservices within a container environment. SDN can trigger dynamic security policy actions based on the abnormal traffic patterns and policy violations by inserting advanced security services such as next-gen firewalls, intrusion prevention systems (IPS), or it will mirror select traffic using policies like intrusion detection systems (IDS) and security analytics tools for further analysis and detection of advanced malware.

This same formula can be applied when introducing virtual machines (VMs), bare metal servers, or wide area networks (WANs) to the mix. Isolation is enforced by default. The same declarative policies would be intelligently, consistently, and universally applied at the very first network connection point – within the hypervisor host for virtualized resources, within the server rack switch for bare metal resources, or within the customer premises equipment for a WAN. So, workload mobility – whether in a container, a VM, or a bare metal server – is frictionless since security is applied consistently and automatically across the entire network.

An SDN approach addresses the entire IT environment, and implementing this strategy not only provides isolation, it minimizes likelihood of breaches and attacks through early detection and automation of incident responses.