Using recent Cisco technology, Software Defined Access (SDA) provides user and device access security and could be the future of your campus switching environment. Enhanced with powerful automation, it provides the potential for significant labor-savings.
What is Software Defined Access (SDA)
I’ve been putting in considerable lab time on Cisco’s SD-Access technology in a proof of concept/design effort for a customer.
This blog is the first in a planned series passing along some of what I learned or figured out, key concepts, etc.
The focus in this blog will be: What is SD-Access, and why do you care?
Keep reading for the details.
We’ll also take a brief look at some competing (or sort-of-competing) products.
So, What Exactly is SD-Access?
SD-Access (“SDA”) is a strategic combination of Cisco technologies and products, the culmination of several years of development and implementation.
Cisco products and SDA:
- SDA requires appropriate Cisco switches, AP’s, and routers.
- Firewalls work with SDA, but so far are not configured by it.
- SDA and Cisco SD-WAN are evolving to support interoperation with SDA.
- The Cisco ISE security management product is a critical component of SDA architecture. It provides for 802.1x or NAC (Network Admission Control) and TrustSec related functionality.
- The DNA Center (“DNAC”) management GUI / controller is the other component in SD-Access. DNAC provides switch and AP management and automation of SDA. DNAC smoothly integrates with ISE for most of the functionality where the two products overlap.
SDA extents Cisco TrustSec (NAC plus group tags) with the automation of deployment.
More specifically:
- Cisco ISE allows campus designs to use ISE to automatically assign users to groups, impose security (“scalable”) group tags (SGT’s) on their traffic, set their switch port’s access VLAN, and optionally apply dynamic access lists. It can leverage other information known about the users or devices. ISE also supports the onboarding of devices, BYOD devices, etc. So, while ISE strongly supports 802.1x or NAC (Network Admission Control), it also provides support for adjacent services (TrustSec: SGT’s).
- DNAC automates that and ties in the creation of VLANs and security groups plus VRF segmentation across one or many sites.
- DNAC also configures BGP and LISP routing at sites, enabling dynamic LISP-based VXLAN tunnels within each site. Consistent use of VXLAN extends VLANs across the site, mitigating spanning–tree instability risk.
- Wireless AP’s are included in the architecture. SDA automates handling WLAN user traffic in much the same way as wired user traffic.
- If desired, DNAC can also automate “SD-Access Transit,” configuring BGP and LISP between sites. Doing so enables VXLAN tunneling between sites, as well as datacenter egress via a pair of “fusion firewalls.” You can think of this as preserving segmentation across multiple sites.
Why Do You Care?
So why would someone do SD-Access?
- Automation. You can reliably deploy complex and consistent configurations across 10’s or 100’s of Cisco switches. The configurations will be correct on Day 1.
- Both of these factors can save a lot of time (hours versus days). They also permit you to offload deployment to less costly/less skilled teams.
- For instance, if you have 3 VRF’s with 4 VLANs (subnets) each, you have 12 entities to deploy on every switch. DNAC does that for you.
- Device upgrades can be automated and scheduled. Run consistent code releases with little effort!
- Device inventory tracking and health monitoring.
- Site-wide roaming. Every VLAN is active on every switch within a site, in a robust way, taking spanning-tree instability off the table.
- ISE-based mapping of users and devices to VLANs and security groups.
- Automated segmentation of users and devices within each site based on the ISE-assigned groups, consistently across many sites. You can specify a policy for traffic within and between user/device groups. The SDA switches enforce SGACL’s to control traffic between and even within segments (groups).
- Fusion firewalls can be used to enforce group-based policies to control traffic between the VN’s (VRF’s) and groups within SDA and to the rest of the data center or network.
- With SDA Transit, you can easily VXLAN tunnel the segments back to one or more fusion firewall pairs.
- AnyConnect can be tied into this in support of assigning groups to remote access users.
- Your switch and firewall access lists (ACL’s) can become security/scalable group ACL’s or SGACL’s, leveraging user groups instead of IP addresses.
This is a huge deal, especially the last item.
ISE allowed classification of users and tying that to VLANs and “SGT’s.” SDA extends that capability to automate matching highly scalable device configuration.
Consider adding a new site. You have to set the switches up with all the VLANs, trunk them to the site core switches, turn up routing on the core, and the links to the rest of the network. And then you have to add the subnets or IP’s to your firewall ACLs.
With SDA, most of the configuration is automated. Your security groups (users, devices, etc.) are likely the same ones across the various sites, although some sites may not implement all of them. All this gets built via GUI in minutes, correctly.
The existing SGACL’s will provide permit/deny rules between those groups. The key thing: nothing needs changing or updating!!! The SGACL’s don’t need to have the new IP subnets added since they are written solely in terms of the security groups.
In comparison to ACLs based on objects: with objects, you have to specify which IP addresses belong to which object, which can be a lot of work and maintenance. With SGACL’s, ISE maps users and IP addresses to the group identity, and the SGACL rules are based on groups. There’s no manual assignment of IP’s to firewall group objects. So yes, this is Intent-Based networking.
Competition
The competition that the author is aware of competes primarily with Cisco ISE for the 802.1x or NAC, Network Admission Control role, potentially including dynamic downloadable ACL’s.
Cisco ISE appears to be the NAC product with the most features and scalability, with a vast number of options and a broad range of supported partners. Some of the competitors appear to claim comparable scaling of the number of endpoints supported.
HPE Aruba ClearPass is Aruba’s answer to ISE, for access control in switch and wireless networks.
Fortinet sells FortiNAC, formerly Bradford Networks. That used to be popular in colleges was affordable, relatively straightforward, and worked well for a lot of people. I lack recent data on it.
Others: ForeScout CounterACT, InfoExpress CyberGatekeepr, Auconet BICS, Impulse SafeConnect, Extreme Networks ExtremeControl.
See also https://www.esecurityplanet.com/products/top-network-access-control-solutions.html#features.
Most NAC solutions provide dACL (dynamic ACL) controls at the point of network entry. This is easy to understand and administer but may have scaling or other limitations.
Firewalls and NAC
Leading firewall vendors have been working to support group-based ACLs in various forms in their products. Cisco started with SGT awareness, whereas CheckPoint and Palo Alto started with Microsoft Active Directory. The latter two reportedly now also can interact with ISE to pick up Cisco group information and use that in ACL’s.
The common mechanism is to use Cisco SXP protocol or pxGrid (now codified as IETF RFC 8600) to get a list of security groups and to map current user IP’s to those groups.
The author found that DNAC and ISE integrated very easily, providing smooth coordination of creation and use of SG’s.
The author attempted to install and test CheckPoint’s Identity Collector solution in a lab, but ran into a problem, and chose not to spend quality time working with their TAC. The installation documentation available at that time was awful.
Palo Alto announced something similar recently. Both rely on an intermediary server that gathers groups and IP to group mappings and passes them on. The author was not in a position to test the Palo Alto solution.
Both CheckPoint and Palo Alto clearly started with the ability to pick up Microsoft groups and attributes and added ISE integration to that framework.
Note that these tools (Cisco, CheckPoint, and Palo Alto) obtain the list of groups and configure it into the firewall for you. They also track IP to group mappings. As far as I can tell, none of the products currently does anything regarding creating policy or SG-based ACL rules in the firewall itself.
Positioning: Where Is SD-Access a Good Fit?
As with many Cisco products, the ISE product meets large enterprise needs, and therefore supports many ways of doing things, and integrates with many other vendors’ products. That brings with it some complexity. DNAC adds some mild complexity to ISE, mostly that of learning yet another GUI and new ways of doing things. The workflows are mostly well-documented in deployment guides and are top-down and left-to-right in the GUI. Mostly.
There are a few things that I found hard to find / non-obvious, buried in obscure corners, so to speak, so I’d give the GUI a B. The dominant paradigm is a list of things which checkboxes and an Actions item, in most place, but not all. All minor and may get cleaned up in a future release.
For my customer, I wrote a supplementary deployment guide with screen captures, filling in some of the gaps.
In terms of skills, ISE is a product that an intermediate level specialist can drive, although an expert might be needed for more complex uses. It is logically organized but can at first be a bit overwhelming due to all the choices.
DNAC entails a moderate learning curve but hides most of the complexity of what it configures.
The author concludes that an organization might need 1-2 people somewhat focused on these two products, and double that if there isn’t an external staffing fallback option. In terms of skills mix, one skillset might be DNAC GUI plus CCNP level switch/AP/router skills. The other might be more of ISE skills. Both with some cross-training on the other. Since these personnel/products would be critical across an organization, most would want two people with each skillset.
Firewall skills would also be needed, either by those personnel or other staff member(s).
For smaller sites, that number of positions could be tough to staff, as well as costly. Training staff adequately, ditto.
Related factors to consider: staff size, staff turnover rate, rate of change in the network, how badly segmentation is needed, and so on.
References
https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/index.html
https://www.cisco.com/c/en/us/products/cloud-systems-management/dna-center/index.html
https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/sda-fabric-deploy-2019oct.pdf
