End device posture compliance, Mobile Device Management (MDM) integration, and supplicant provisioning are crucial in determining a dynamic security policy. Meraki group policy allows the creation and enforcement of network-wide policies across Meraki devices, providing a centralized method for applying rules and restrictions to client devices. These policies support dynamic assignment based on real-time conditions, such as time of day, location, or device posture.
Meraki’s Systems Manager Sentry is a powerful tool and extension of the Dashboard that enables you to directly integrate Dashboard network policies, like Group Policy, with the monitoring power of Systems Manager on end devices. Sentry policies take standard Group Policies a step further by creating a link between Meraki group policies and dynamic tags generated in Systems Manager (Meraki’s MDM solution) that can be used to further enhance the security of the end device. For example, if a device fails to meet certain criteria or compliance requirements, such as geo-fencing, Tor, or OS version, Meraki MDM can automatically assign a dynamic tag to it. This tag, when used in a Sentry policy, triggers specific policies within the Meraki group policy framework, allowing for dynamic policy enforcement, as illustrated in Figure 7-28.
Figure 7-28 Sentry Policy Mapping Between SM Tags and Group Policies in the Dashboard
It is important to note that Sentry policies do not directly apply to MS switches. SM Sentry policies are enforced on Meraki MR access points and MX security appliances. This means that any device connecting to the network via an MR access point or passing traffic through an MX firewall can have Sentry policies applied.
Micro-Segmentation with MS (Adaptive Policy)
Adaptive Policy represents the evolution of traditional segmentation into a modern approach that eliminates the need for constantly mapping ACLs to IP addresses. Traditionally, network security has relied on IP-based access controls. However, as businesses increasingly establish their presence online, the importance of network security for maintaining business continuity has become more critical. Cisco Meraki offers a robust solution for securing network access through ACLs and group policies. However, these group policies can become challenging to scale as organizations evolve and expand.
Micro-segmentation with Meraki switches offers an organization-wide, intent-based policy that integrates seamlessly with the Dashboard in ISE 3.2 (see Figure 7-29). Micro-segmentation is achieved in Meraki using Security Group Tags (SGTs), a feature that is part of Cisco’s TrustSec solution. This enables effective network segmentation and strengthens security by restricting lateral movement of threats within the network. By syncing natively with the Dashboard, Adaptive Policy ensures real-time visibility and control over the network policies, enhancing the overall network security management. Adaptive Policy functions through three key components: identity classification and propagation, security policy definition, and policy enforcement.
Figure 7-29 SGT Tag Propagation Is Supported Across Multiple Meraki Platforms
Identity Classification and Propagation
For Adaptive Policy using SGTs to function, you must first define the groups to be used. An Adaptive Policy group is a class of users or devices in an organization that require access to the same network services. Each SGT relies on a unique number (SGT value) associated with a specific group in an organization that can be defined when creating the group. Adaptive Policy utilizes organization-level policy groups (not to be confused with network-level group policies) defined in the Dashboard under the Organization> Policy Groups page to determine group membership. Here, policy groups can be created and defined based on multiple criteria.
Security Policy Definition
A security policy comprises a defined security SGT, a defined destination SGT, and the permissions for communication between them. Once you have defined the groups, you can define specific access restrictions based on group-to-group communication. For example, devices in the IoT group may have a defined policy that allows communication only to other IoT devices or related servers based on the selected groups within the security policy.
