Skip to main content
Cisco Meraki

Adaptive Policy Overview

Overview

This document covers Adaptive Policy at a fairly high level and is intended to be a primer to the configuration and troubleshooting documents that are linked in the Additional Resources Section below. 

 

Traditional network security has been founded on the use of IP based access controls. As businesses evolve to an increasing online presence the need for network security has never been more important for maintaining business continuity. Cisco Meraki has always provided a robust approach to securing network access whether it be through the use of ACLs or through Group Policies on MR and MX appliances. These group policies however become difficult to scale with organizations that continue to evolve and expand. 

As networks grow and the user base and devices multiply in number, traditional security policies become cumbersome and often nearly impossible to enforce due to sheer scale.

How do we solve the scalability problem?

Scaling networking platforms can occur in a number of ways including adding more hardware resources, optimizing software, and enhancing configuration and deployment capabilities through orchestration. These enhancements can improve scaling up to a point, but in the end administrators are still focused on what IP can talk to what IP using which services. While we continue to take steps to further IP policy orchestration and handling, Meraki is also taking advantage of a few of the components of the Cisco Trustsec architecture through a new feature-set called Adaptive Policy. This feature utilizes Security Group Tags (SGTs) to provide granular, IP agnostic security policy and identity propagation that is compatible with many other Cisco technologies.

 

Support and use of SGTs gives Meraki the ability to share and learn the identity of a source of traffic, enforce policy based on SGTs, and provide a similar experience across Cisco domains.

Adaptive Policy Architecture

Adaptive Policy has three key components: 

  • Identity classification and propagation 

    •  A tag that is applied to frames from a source device and acts as an identity or grouping for a user/device

  • Security policy definition 

    • A policy comprised of a source tag, destination tag, and the permissions between them

  • Policy deployment and orchestration

    • An engine that implements the policy on supported network devices 

Adaptive Policy leverages inline traffic tagging to provide the source’s group identity to the next hop in the path. Similar to 802.1q trunking, inline tagging adds an ether-type before the IP header of the packet. The specific ether-type that is added in this process is called Cisco MetaData (CMD). Within the CMD header, the Security Group Tag (SGT) identifies the group that the source belongs to.

 

Figure 1 - Frame Layout

clipboard_e7fc24aa79de6846bcb1e3e9d875a9f8c.png


Inline tagging encapsulates every packet from a source. The encapsulation is maintained on a per-hop basis from the network device the source is connected to, to the network device destination is connected to. The policy is enforced at the network device the destination is connected to.

 

For the Security Group Tags to persist across a network, each hop must support the inline tag encapsulation.

Figure 2 - Design constraints

clipboard_ed23624ce49392ae9b6a24001a59483c6.png

 

Figure 3 - Per Hop tag propagation

clipboard_ea95310b831bcef6c901be2b67dc2c194.png

Security Policy Definition

Once the Adaptive Policy tags are defined in Dashboard the actual policy can be written and applied to the network infrastructure. Below is a visual representation of a simple security policy allowing and denying specific devices' and users' communication.

 

Figure 4 - Policy Visualization

Policy Structure 

Structurally the security policy consists of classifying and defining the allowed behavior for the classifications.

 

The security policy itself is broken down into 3 components:

  1. Source group (SGT)

  2. Destination group (SGT)

  3. Permissions between the groups 

 

The permissions are also broken down into 3 different potential permissions of:

  1. Allow all - the default permission for all tag relationships and permits all traffic (ipv4 and ipv6)

  2. Deny all - dashboard defined permission that blocks all traffic (ipv4 and ipv6)

  3. User defined “Custom ACL”

Policy Configuration

With all of the components created the next step is to define a policy. The default Adaptive Policy permission is “allow all” until the tag to tag relationship is overridden with a specific configuration. All policies are defined in one direction. This means that to effectively block all communications between two tags, the administrator must configure the policy in both directions. The application of a policy is as simple as selecting the source group tag, the destination group tag, and then applying a permission such as Allow or Deny, or selecting custom.

 

Figure 5 - Policy between Two Tags

clipboard_eb51b48ad4fdfd397eef2c2918a09b3c1.png

Policy Deployment and Enforcement

Once the policy is defined and applied, every network in the organization with adaptive policy will pull down the updated security policy for use. Before Adaptive Policy is enabled there are a few requirements that need to be met as outlined below.

Adaptive Policy Requirements

Adaptive Policy has a few requirements for the feature to be enabled on a network including specific hardware and software revisions. On top of hardware and software there are a few licensing requirements to meet including: 

  • Advanced licensing on all MR and MS in a network when in a Per-Device Licensing organization

  • Advanced licensing organization-wide on MR and MS390 when in a Co-Termination licensed organization

 

For more information on Per-device licensing please refer to the following documentation: Meraki Per-Device Licensing Overview

Advanced licensing for MR will not be enforced until MR 27.X firmware is out of Beta and considered the General Availability release. Please reach out to your Cisco Meraki Sales-rep or to Cisco Meraki Support to have an Adaptive Policy MR beta license exemption set up for your Organization.

Hardware Requirements:

  • MS390 - all models

  • MR - all 802.11ac Wave 2 (Wifi-5) and up excluding MR20 and MR70

 

Software Requirements:

  • MR - 27 and on

  • MS390 - 14 and on


Once all of the above requirements have been met, the administrator would need to navigate to Organization > Adaptive policy > Networks and enable the feature set on the network.

 

Figure 6 - Policy Deployment

clipboard_e4f20ce763a6e44484907924c1f4631bf.png

Policy Enforcement Workflow

Understanding policy enforcement and the manner in which tag based policies are enacted is one of the most important topics in designing and building an Adaptive Policy network. Once the adaptive policy tags are created, adaptive policy enabled, and clients are classified with their relevant tags, the next step is for policy to be enforced. The one key policy aspect to understand in a tag based network is:

In an Adaptive Policy network, the policy is enforced at the destination network device. This creates a highly scalable policy framework as the network device only needs to worry about the tags of the clients that are directly attached to it and not of the IP prefixes. This does however come with some fairly rigid requirements for micro-segmentation including end to end support of the CMD encapsulation. This is why from a wired networking perspective, the only Meraki switch to support Adaptive Policy at launch is the MS390. 
 

The diagram in Figure 2 below shows one of the main reasons why the tag enforcement is done at the destination. In an adaptive policy network the means of identity propagation is through the data-plane and so to enforce policy the network device needs to understand the source AND destination tag. 

 

Figure 7 - Adaptive Policy tag enforcement

 

If there is a hop in between Adaptive Policy enabled appliances that does not support the CMD encapsulation, micro-segmentation policy will NOT function as expected and will rely on using (if defined) Prefix to SGT mapping as a last resort method of classification. 

Example Use Cases 

Adaptive Policy has many potential use cases and can be implemented to cover a number of requirements including meeting PCI compliance, device quarantining, IoT device security, and more. Let’s take a look at a few of these in greater depth.

PCI Compliance Scope Reduction

Example documentation of trustsec for PCI scope reduction: Cisco TrustSec for PCI Scope Reduction—Verizon Assessment and Validation

 

PCI compliance has a number of requirements to meet, however one of the most difficult traditionally has been securing PCI devices from the rest of the network. Instead of segmenting with VLANs and firewalls, using adaptive policy this can be done with simply applying a PCI tag to the PCI devices, and blocking PCI from communicating with Non-PCI devices as depicted in the graphic below.

 

Figure 8 - Example Policy for PCI

clipboard_ea82c6beefb0fea44e8df8c158c5bdbf1.png

Device Quarantine

Many environments utilize a Network Access Control (NAC) service such as Cisco ISE to perform posture compliance and remediation. Part of the remediation process is to quarantine the endpoint in question until either the posture has been determined as compliant or non-compliant where remediation needs to take place. 

 

The most common way to perform remediation is to assign the client to a remediation VLAN, and/or assign the user an ACL to their authentication session to limit their access to required services for remediation. This however can prove difficult to maintain as VLAN changes are disruptive to wired clients and ACLs as usual can become daunting as things grow. Instead, using adaptive policy with change of authorization, Cisco ISE can send a re-auth request and send a different SGT value for the client in question. This will be nearly transparent to the end user while being able to reduce the potential impact on the rest of the network by simply changing the SGT assigned. 

 

An example of using tags to quarantine a device along with a number of other components is Cisco’s solution called Rapid Threat Containment. Adaptive Policy can be utilized to perform the segmentation aspect that Trustsec would in a traditional network. Historically however this solution combines Cisco ISE, Stealthwatch, Trustsec, AMP for Endpoints, and even Firepower Threat Defense to control misbehaving clients and users access based on behavior on the network. For more information please see: Cisco Rapid Threat Containment

 

Figure 9 - Device quarantine

clipboard_e05e69b96c7803a20f25625e532a2e6ea.png

IoT Device Security

One of the easiest use-cases to outline surrounds the ongoing threat that IoT devices impose on networks. IoT devices are rarely maintained with security patches and have been utilized as dDoS endpoints as well as mechanisms to spread malware into larger organizations since their inception. Using Adaptive Policy, securing IoT devices is as simple as locking the IoT endpoints down to only the required communications for the platform. An example would be to deny IoT to IoT device communication while only permitting MQTT services to an IoT Server. The reduction of communication pathways for the IoT device means even if it is infected with nasty malware, the endpoint is not able to spread the problem further. 
 

Figure 10 - IoT Security
clipboard_e29ec9f2a081c557573790b042d3a21be.png

Compatibility With Other Cisco Technologies

With adaptive policy utilizing Cisco’s inline SGT functionality the feature is compatible across a number of solutions including but not limited to:

  • Catalyst switching and routing (3k, 4k, 6k, 9k, ISR)

  • ASR and CSR

  • Sourcefire Next Generation Firewalls (FTD)

  • Adaptive Security Appliances (ASA)

  • Application Centric Infrastructure (ACI)

  • Datacenter switching (Nexus)

  • Software Defined Access (SD-Access)

For more information on which Cisco platforms support inline SGTs please see: Cisco Trustsec Compatibility Matrix

For Documentation on interoperability with Catalyst please see: Adaptive Policy and Catalyst Interoperability

For Documentation on interoperability with Cisco Identity Services Engine please see: Adaptive Policy and Cisco ISE

Additional Adaptive Policy Resources

For guides on how to configure Adaptive Policy on your network, please refer to the following: