One of the top concerns I hear from customers is that they’re still grappling with point solutions deployed during the pandemic that served time-sensitive needs but have left IT teams with an inefficient and complex infrastructure framework. Consider this: 94% of enterprises offer flexible work options for employees, and at the same time, the applications accessed by these employees are moving from the on-prem data centers to the public cloud infrastructure, and in most cases, it’s more than one.
These trends have significantly expanded the threat surface resulting in new threat vectors in the enterprise. With cyberattacks rising in numbers and sophistication, the job of the IT admin is not just more difficult than ever – it’s more important than ever. Today, the IT admin must ensure employee productivity isn’t impacted, that applications and networks continue to be highly available, all while securing the enterprise.
Enabling a simple and secure zero-trust infrastructure
One of the main challenges today is there are many islands of policies that aren’t connected due to workplace modernization (i.e. IT managed and unmanaged endpoints), hybrid work (remote and on-prem workers), and transition to cloud. This disconnectedness creates a need for distributed trust boundaries that cut across different domains. Most solutions available in the market today focus on enabling the outcome by implementing policies on specific enforcement points in the network such as the access switch, the firewall, the router, and so on. The reality is that each of these are just one of several enforcement points that need to be supported across the campus, data center, branch, and cloud.
One of the key tenet’s of Cisco’s zero trust-based approach to securing the network is Software Defined Access (SDA). SDA is not just the fabric that enables network segmentation; it also includes end-point classification using AI/ML based profiling, policy analytics, anomaly detection, threat detection, and threat response. These capabilities (and more) are available in Catalyst Center, with profiling and micro-segmentation also available in Meraki, with more to be added regularly.
In June we announced that we’re further extending the capabilities in SDA with a new feature called Common Policy. Common Policy easily shares context across domains, thereby allowing end to end segmentation enabled by smooth and domain agnostic policy creation and enforcement. It starts with building our policy constructs around a key Cisco Innovation – the Security Group Tag (SGT), which is widely adopted across Cisco and third-party products. The SGT is just one type of context – moving forward, the same infrastructure will be leveraged to share additional context such as posture of the end-point and Operation System (OS) running on end-points.
We also announced we’re evolving the segmentation constructs in SDA to become even more flexible and extensible, giving users the ability to build fabric either using LISP or BGP-EVPN.
What would a Common Policy deployment look like?
Consider this scenario in the financial vertical – an IP Camera in a bank needs to access two applications: 1) one in the cloud for lifecycle management of the software running in the camera and 2) another in the on prem datacenter (DC) to store the video feed. These videos should only be accessible by specific surveillance personnel and only while they are in the bank. Remote access to the videos should not be allowed for security and regulatory reasons.
Additionally, surveillance operators don’t manage the cameras, so they are not allowed to access the lifecycle management application. To enable this outcome today, customers have to build policies based on IP addresses and implement them across the various enforcement points. IP addresses are ephemeral and are prone to misconfigurations, thereby resulting in security gaps. And when the IP addresses change, customers have to go through the manual process of updating the policy across all the relevant enforcement points.
The common policy architecture enables customers to configure ISE to connect to the application infrastructure in the private DC where the storage app is hosted, and the public cloud where the lifecycle management application is hosted. Both the applications i.e. the storage app and the lifecycle management application, will be represented as unique SGTs in ISE, which are then shared with the various enforcement points across the infrastructure. Cisco Secure Access, which is one of these consumers, will leverage the SGTs to provision a policy that would prevent the remote surveillance personnel from accessing the video storage app that is on-prem. The on-prem firewall, which could be another enforcement point that consumes the context, will prevent the surveillance personnel from accessing the lifecycle management app in the cloud, while allowing the camera to do so. There are many other verticals such as healthcare, manufacturing, and retail where this capability is directly applicable.
How does Common Policy work?
Prior to common policy, customers configured Cisco Identity Services Engine (ISE) to assign SGTs to users and devices that connected to the network, based on various attributes like the type of the device, the organization that the user belonged to, the posture of the device that was used to connect to the network, and so forth. These tags were made available to the network and security infrastructure (e.g. on-prem firewall, security services edge) to implement policies by either passing the tag in the data path, which allowed the solution to scale the performance of the enforcement points; or by sharing the bindings in the control plane, for leverage by the broader security ecosystem across Cisco and third-party platforms.
Common Policy significantly simplifies the process. Policy can be set anywhere, with the same outcome across all enforcement points.
Now ISE can connect directly to the application hosting infrastructure, both on-prem and in the cloud, which allows customers to map the application constructs to SGTs. These mappings are automatically shared, thereby allowing policy definition based completely on SGTs – a significantly simpler experience for IT administrators.
In the latest version just announced at Cisco Live, ISE3.4 can now:
- Connect to Cisco Application Policy Infrastructure Controller (APIC)
- Discover the end-point groups (EPGs) and end-point service groups (ESGs) and allow customers to map these constructs to SGTs
- Connect to the cloud services providers (AWS, Azure, GCP) and on-prem virtualization infrastructure (vCenter) to discover the workload and VMs, and map those to SGT
A continued dedication to the challenges of IT teams
The sharing of context enabled by common policy allows customers to leverage ISE to bridge networking and security domains, which is critical for ensuring comprehensive zero trust security outcomes for the modern enterprise. Many customers have loved and used ISE to secure their user and device access to the network infrastructure. Common policy enhances ISE to extend the same value proposition to applications and workloads, both on-prem and in the cloud. Cisco is the only company in the world who can do this. We will remain dedicated to solving the critical challenges faced by today’s IT teams.
More on Common Policy
You can learn more about Common Policy and other enhancements to ISE3.4:
Share: