Network security (who can talk to whom) is a fundamental construct of any data center network deployment. Hence, we have selected Controller-based ACL as the 5th sign of DC network transformation.
What are the typical challenges with traditional box-based ACLs?
A traditional box-based network provides access controls, via ACLs and VLAN/subnet-based policies, but they were hardwired to the port or the switch itself. Managing these ACLs has been quite cumbersome, editing a 100-line router ACL is highly error prone. The need to apply security policies to east-west traffic, in addition to north-south traffic, has further exacerbated the ACL complexity. Deploying dedicated firewalls for east-west traffic can blow up the CAPEX budget, and hence are typically only deployed for north-south traffic security. And it is hard to implement a “policy-follows-workload” model as VMs and containers tend to be highly dynamic (unless of course VLANs are enabled on every switch, which defeats the very purpose of implementing “need to know” security, based on the Principle of Least Privilege).
What have we learned from Cloud Giants?
Cloud Giants deploy a variety of software controllers to both manage the underlying IaaS infrastructure, as well as manage various cloud services exposed to end users, including network security. Security policies/ACLs are applied to subnets centrally from a user’s dashboard, which simplifies policy management significantly (see AWS Network ACLs for VPC). Certainly, there is never any hard-wiring to networking hardware. Cloud Giants have also implemented security group based access control (aka micro-segmentation) based on non-network context (see AWS Security Groups for VPC). These are optional security measures, when granular (sub-subnet) controls are necessary in certain situations. Both these controller-based security functions are depicted in the diagram below. Often network ACLs are managed by the network team, whereas security groups are managed by the cloud/devops team.
Why controller-based ACL is game-changing for mainstream data centers?
When the data center pod fabric is deployed with software controls, the fabric controller manages the entire lifecycle of ACL policies. There are multiple advantages of this modern approach to networking and security:
ACL management is done centrally, in the controller; hence no hopping and hunting required across boxes to determine how security policies are applied fabric wide
During a troubleshooting session, the controller can highlight a specific ACL policy when tracing across the fabric. This makes it very easy to identify whether connectivity issues are related to the physical path or logical path
Controller ensures the “policy-follows-workload” principle. If a workload moves or is elastic, policies are automatically applied to relevant switches on demand. Principle of Least Privilege is enforced without incurring any operational complexity
Policy logs can be made visible in the controller, thus simplifying security policy audits.
There is no change in network topology, subnet map, access control policies, etc. Controller just makes it a lot easier to deploy, manage and troubleshoot security policies.
There is no change in team ownership. The network team continues to apply policies as before (but on the controller, instead of on myriad of switches).
There is no change in established security and compliance best practices. In fact, controller makes it much easier to validate compliance and generate reports for audits.
A thousand+ organizations have deployed controller-based data center fabrics and are benefiting from the simplicity (and hence elevated security) of controller-based ACLs.
What about security groups (micro-segmentation)?
As seen in the AWS diagram, security groups provide granular (sub-subnet) security which is important in certain situations. For example, if subnets/VLANs need to be conserved (to not exceed the 4K limit), applications with varied security postures can be placed in a single subnet and access control can be applied with security groups. Another example is security policy based on application context, such as windows/Linux VMs, which might be assigned to many subnets. These policies have to be created by Infosec team and managed by cloud/devops teams. They don’t replace subnet-based policies due to existing compliance and associated audit requirements. Note that security group policies necessitate a policy/network controller, albeit it is for virtual networks in compute environment. Private cloud solutions, such as OpenStack and containers, have implemented security groups in the compute environment, e.g. in Linux bridge or in Open Virtual Switch (OVS). SDDC solutions from VMware, Microsoft and Nutanix also provide micro-segmentation.
What is Big Switch’s role in simplifying and enhancing network security?
BCF’s API integration with Red Hat OpenStack and Kubernetes based container environment provides security groups visibility to network admins
BCF also supports micro-segmentation use cases as a physical fabric integrated with VMware NSX and Nutanix FLOW.
BCF also programmatically interacts with Big Switch’s Big Mon visibility fabric, for enabling closed-loop security. Upon Big Mon controller detecting a security incident, it can program BCF (via RESTful APIs) to insert an ACL to stop infected host/application’s traffic or quarantine it to monitor its behavior.
In summary, by embarking on a DC network transformation journey, mainstream organizations not only benefit with a modern, cloud-style network infrastructure but also significantly simplify and enhance security posture.
What could be the next sign (hint: verify, verify, verify)?
VP & Chief Product Officer
Prashant is responsible for Big Switch's Cloud-First Networking portfolio and strategy, including: product management, product marketing, technology partnerships/solutions and technical marketing. Prashant has been instrumental in the product strategy and development of Big Cloud Fabric and Big Monitoring Fabric products. Additionally, Prashant is responsible for Big Switch led open-source initiative, Open Network Linux (ONL), to accelerate adoption of open networking and HW vendor choice. You can connect with Prashant on LinkedIn.