One of the key value propositions of leveraging a Cisco SD-WAN architecture is the ability to implement a highly effective segmentation strategy. Implementing this allows organizations to separate devices into isolated networks such that there is no communication between each segment without a configuration expressly permitting that connection. This architecture allows organizations to reduce attack surfaces and keep devices that shouldn’t be communicating with each other separate. There has been a lot of work done in putting groups of devices such as Guests, IOT, and Corporate into separate segments and thereby eliminating areas of containment.
With a migration to a SASE architecture and a cloud-first strategy, connecting branch office SD-WAN devices directly to a cloud security platform like Umbrella has become more standard. But the question arises as to how organizations can continue to effectively extend their isolated segments to Umbrella. How can they provide a differentiated level of services for each segment?
Let’s address this question by examining using three key capabilities at Umbrella: DNS Security, Secure Web Gateway, and Cloud Delivered Firewall.
DNS Security
When designing a segmented network at branch locations and then augmenting those locations with a Direct Internet Access solution, there is a need to connect those DIA paths with a cloud-based security solution. This is one of the key tenants of a SASE architecture. In a segmented site however, there may be a desire to provide a different level of cloud-security functionality for different segments. For example, a guest segment might only need DNS protection, an IOT segment might need DNS and Cloud Delivered Firewall protection, a standard employee segment might need Full DNS and SIG protection.
SD-WAN has the ability to provide information up to Umbrella Datacenters about the originating device’s VPN and IP address. It is through providing this information that different Umbrella policies can be enacted to different network segments.
The way to provide a different level of service and/or different policies begins with setting up the SD-WAN environment with different VPNs/VRFs for the different segments. In the example shown in the accompanying videos, there are three different VPNs: Employee (VPN 10), Guest (VPN 20), and IOT (VPN 30). The router is already connected to Umbrella Secure Internet Gateway (SIG) via the simplified templates.
Adding DNS security from users connecting through the router requires a security policy in place that will integrate with Umbrella. The security policy for this integration only needs to include the DNS component. In order to get the information exchanged correctly between vManage and Umbrella, the DNS security policy needs to be integrated with Umbrella via APIs. As of 20.9, only the legacy Umbrella API keys can be used with vManage, and the Umbrella Network Devices API is the one needed for this integration.
The other key item to note is that DNSCrypt needs to be enabled between the devices with this security policy and Umbrella. This is only supported with Umbrella and through DNSCrypt, the router can send additional information via EDNS to Umbrella. This information includes VPN info from the source making the request. Without this additional information, Umbrella would just assume the source of the request is from the router itself.
After creating the security policy, it needs to be applied to the routers where we want DNS security to be added. This is done in Device Templates under the Additional Templates section. Simply enable this new DNS security policy under the Security Policy parameter of the template.
After applying, the different VPNs will show up in Umbrella as deployment identities under Network Devices. But at this point, they are all using the Default Policy for their DNS Policy.
You now need to create DNS policies in Umbrella that will provide different rules for traffic that originates from each of these VPNs. In the example shown in the accompanying video, there is one DNS policy created for Corporate devices, one for Guest devices, and one for IOT devices.
Looking at the Identities for each of these policies, you can select the specific VPNs by looking at the different identities available under Network Devices. From this list of all Network Devices, you can select the specific VPN that should have the DNS policy applied. In the example, VPN10 will be matched with the Corporate DNS policy, VPN20 with the Guest DNS policy, and VPN30 with the IOT policy.
Once the different DNS policies are created and associated with the Network Device, you can see that association back on the Network Device page. Then once devices are connected to each of their respective VPNs and traffic is generated, Activity Search in Umbrella shows those policies in effect. The activity search shows that DNS policy is now blocking the device from reaching these sites and the Identity associated with this block is the Network Device aligned with the DNS policy in the previous steps.
DNS Policy is now denying the device from reaching the blocked sites.
Web Security
For internal devices, Umbrella won’t allow for specific policies by default. It won’t build rules on RFC1918 addresses. So for a use case where a particular segment of a network should have a different policy applied than another, this can be challenging. With PCs or laptops, this might be solved by integrating an identity source like AD or Okta to provide the context of the source device. But for other devices like a Guest Network for instance, there would be no identity to pull context from. In this case, you can add an internal network to Umbrella’s Configuration.
If the source router has an IPSec connection to Umbrella SIG that shows up in the Network Tunnels Identity list, this process is greatly simplified. Rather than needing to deploy a Virtual Appliance (VA) to collect the source info of the RFC1918 address, it can be sourced from the Network Tunnel by configuring the subnet, or even host, and designating which tunnel or tunnels this address might originate from.
If the originating router has multiple SIG tunnels to Umbrella, an Internal Network needs to be added for each one as a potential source of that subnet. The video shows a demonstration where the same internal RFC1918 address blocks have each been added twice. Address 10.109.10.0/24 has been added using two different internal network associations: one for the first Umbrella Tunnel from router SITE309SYS1x3x9x1 (Tunnel 1) and the other is the second Umbrella Tunnel from the router SITE309SYS1x3x9x1 (Tunnel 2).
Web policies can now be created that utilize these internal networks called Site9-Macrosegment-Corporate-Tu1 and Site9-Macrosegment-Corporate-Tu2. In the Web policies page, the ruleset identities can be selected to be these internal networks. For testing, a new Web policy is put in place to block access to dating websites along with a few other categories.
This same type of Web Policy is also created for both the Guest and IoT Internal Networks as well. Then devices in each of the three VPNs are used to try and access dating websites, and through Activity Search, we can see that the Web Policy prevents its access. Clicking into the details, we can even see details such as which ruleset is applied, what is the IP address that made the request, and what site is it trying to reach.
Cloud-Delivered Firewall Security
To block using the Firewall, a new Firewall policy is created. This policy simply creates a block from devices on the 10.109.10.0/24 network coming over the Ryan1100-Tunnels and trying to reach IP address 8.8.8.8. It is then set to block and log that traffic.
For testing, the same client issues a ping test to 8.8.8.8 and it is denied. After that attempt, a new hit can be seen at the policy page.
Investigating the results in the Activity Search page shows more details about this block.
Further details reveal the policy name that enacted the block as well as the identity coming from the SITE309SYS1x3x9x1-Tunnel1 and the source IP address as well as the protocol that is blocked as part of this rule.
Conclusion
Using Umbrella to extend a company’s segmentation strategy is a very effective method to provide differentiated access and controls. When determining what method might make the most sense to any organization, there are a few key use cases that can be considered.
The first is one where an organization may want the full security capabilities of a SIG for their corporate or managed machines. The VPN that these machines end up in can then be the source for the full SIG stack. However, guest or IoT devices may just want to be prevented from accessing malicious sites and key restricted categories of sites. Leveraging DNS security, backed by Talos, would provide enough protection for this use case.
The second is one where the previous use case is mostly accurate, but with a change where IoT type devices still might need some firewall protection. IoT devices contain notoriously poor security capabilities, so this use case might be very critical to maintaining safe operations for the organization.
Whatever the case is, Cisco can provide a robust, easy to implement, cloud security solution for extending an organization’s segmentation strategy. Request a free demo today to see what Umbrella can do for your network!
