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 solutions.

Identity Classification and Propagation

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

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 the destination is connected to. The policy is enforced at the network device the destination is connected to.

Figure 2 - Design constraints

 

Figure 3 - Per Hop tag propagation

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 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.

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

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, Secure Network and Cloud Analytics (formerly 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

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