Software-defined networking (SDN) has moved up the enterprise IT agenda in recent years. And it’s easy to see why – in theory, SDNs are far quicker and easier to control and alter than traditional networks. By using open protocols to apply controls from the network edge, SDNs enable network engineers to shape traffic from a single centralized console, rather than working with individual switches across the network.
In turn, this makes software-defined networks far more agile than traditional networks, with opportunities for automatic load balancing, streamlined processes, on-demand provisioning of new applications and traffic flows – in short, a network that works much harder for the organization. So it’s no surprise that organizations are embracing SDN: a 2019 Verizon study year found that while just 15% of respondents said their companies had implemented SDN, 57% expected to do so within two years.
However, deploying SDNs can introduce new challenges for network staff revolving around complexity – in particular, complexity in relation to managing network security. Let’s take a closer look at what this means.
A shift in complexity
Any organization that moves to a software-defined environment essentially moves from datacenter-focused firewalls into a model where its security policies are defined by software within its fabric. This requires a far more granular level of security policies, on a much larger scale and with far more agility, than in traditional networks. Why? Because security controls are much more diverse.
In a traditional setup, network security policy is relatively monolithic. A set of servers is protected by a perimeter firewall, filtering so-called north-south traffic that enters the network from the outside. Traditionally, east-west traffic within the datacenter itself is not subject to any filtering – and this introduces security risks, particularly in terms of enabling malicious parties to laterally explore the environment once they have compromised a single endpoint.
By contrast, in an SDN environment, built-in firewalls are considered part of the infrastructure. It is likely that the organization will have multiple tenants, each containing a unique set of granular security policies dictating which assets can connect to which other assets within the SDN fabric. An SDN environment is likely, for example, to incorporate one contract with Cisco Application Centric Architecture (ACI), VMWare NSX distributed firewalls and so on. There is a lot of complexity to manage.
Ultimately, the organization in question needs to identify which elements within the newly software-defined network need to connect to each other, and then create granular security policies that enforce this, dividing the network into smaller zones to prevent lateral infiltration by malicious parties. In short, they need to introduce micro-segmentation.
Managing micro-segmentation
There are two main challenges associated with micro-segmentation from a security point of view. First, the organization needs to define the micro-segmented zones, and second, it needs to enforce and maintain the security policies that enable that micro-segmentation.
How do we define micro-segmentation zones? This is all about understanding the assets within your environment, which databases contain the most sensitive data and therefore need to be segmented off from each other, which assets are talking to each other, and how traffic is flowing throughout the network. Crucially, all this should be contextualized in terms of business applications – in other words, you need to understand the traffic that makes business applications work. This enables you to design a micro-segmentation architecture – and the security roles to enable it – that are centered around your business-critical services. Solutions that automatically discover and map all of the traffic flows within and through a datacenter are invaluable at this point.
Then we move onto enforcement and maintenance of those rules on an ongoing basis, and this is where a security policy management solution is truly critical. All this complexity and dynamism cannot be managed manually. Each time a new business application is introduced, or an existing one removed or amended, the security policies also need to change – and these changes could be happening on a daily or even an hourly basis in a large organization.
Automating the management process
So, given the flexibility and rapid changes that SDN enables, how should organizations approach managing and maintaining security policies across their entire enterprise network? The most effective way is with an automation solution that holistically supports the SDN environment and its security controls, alongside existing traditional on-premise firewall estates.
It’s important to note that the SDN deployment will be subjected to the same compliance and auditing requirements as existing networks, so the security management solution must be capable of providing visibility across both physical and virtual network functions so that the overall compliance status can be centrally monitored and logged for audit purposes.
Automated security policy management solutions generate filtering policies based on enabling only the traffic required for every application in the datacenter. This is a way of approaching intent-based networking, which comes back to looking at the components of each individual application and how they are communicating with each other. Furthermore, automated security policy management solutions audit and record every single change that is made across the network, making it easier to demonstrate compliance continuously.
With the right automation solution, IT and security teams can eliminate time-consuming, error-prone manual security processes, such as connectivity discovery and mapping, migrating, and ongoing maintenance of their environments. This frees up the teams to strategically maximise the benefits of the SDN deployment, and reap its rewards of increased flexibility and enhanced network security.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.