Network access control with Cisco's Identity Services Engine
The Magic Gate
Access control is a standard feature of networks, with a general need to reconcile strict security requirements with a greater diversity and larger number of terminal devices, even in times of constantly changing threats. In this article, I look at the options offered by Cisco's Identity Services Engine (ISE), including the architecture, feature set, and how to integrate guest devices.
Internal Barriers
The increasing penetration of Internet of Things (IoT) components means new threats. For example, many IoT elements do not support the authentication methods familiar on enterprise networks. The lack of hardening options (e.g., the ability to disable services) and missing or delayed update processes aggravate the situation. At the same time, the larger number of end devices inevitably means more points of access to the network, such as switches and wireless local area network (WLAN) access points. Virtual private network (VPN) gateways also play a major role for system administrators, especially during the pandemic, because of increased use of home offices.
It makes sense, then, to establish a stronger focus on segmentation and "least privileges" as early as possible in the network access phase on top of a classic "allow/deny" policy. True to the motto, "You can't protect what you can't see," increasing visibility on the network and identifying, reporting, and dealing with potential threats at an early stage is important.
Despite cloudification and zero trust approaches, securing internal networks and resources is still very important in many organizations because this is where the crown jewels are hidden away, for which outsourcing to external cloud providers is strictly prohibited. Internal security mechanisms are required to prevent access completely or to restrict lateral movement on the network after the potential infection of a host. These measures must be in place consistently from the client; through switches, routers, and network access controls and up to the firewall. The central link is the network access control (NAC) tool, of which, the Cisco ISE [1] is one example (Figure 1).
In addition to the classic authentication, authorization, and accounting (AAA) services, ISE also offers guest portals, mobile device management (MDM) integration, and various APIs for connecting to the company's own management systems. There is also close integration with public key infrastructures, directory services, and the in-house AnyConnect Secure Mobility Client, for example, for posture services (i.e., for checks at the client level and Layer 2 encryption based on the Media Access Control Security (MACSec) protocol). Additionally, the ISE is an integral part of the software-defined access technology managed by the Cisco digital network architecture (DNA) Center.
Connections to firewall systems can also be established with Platform Exchange Grid (pxGrid), an integration interface for third-party systems that makes filtering decisions on the basis of context information, such as identity and client information. Advanced features such as the inclusion of access times are also available. Last but not least, the approach offers options for logging live and historical data. The goal is clear, centralized policy management with decentralized policy enforcement.
Virtual or Metal
ISE uses a hardened Linux as the underlying operating system. Cisco refers to this as the Application Deployment Engine Operating System (ADE-OS). The current version 3.1 is a Red Hat Enterprise Linux version 8.2. Full root access is reserved for the manufacturer's Technical Assist Center. Some services are run as microservices in Docker containers.
ISE can be deployed on a variety of platforms. For example, the vendor supports implementations on hypervisors such as VMware ESXi, KVM, and Hyper-V. The environments supported depend in each case on which ISE version you use. Cisco also offers three hardware platforms of its own, which the manufacturer refers to as Secure Network Servers (SNSs) [2]. The smallest version, the SNS 3615, comes without a redundant power supply or hard disks. Its Intel Xeon 4110 processor has eight CPU cores and 32GB of RAM.
Its bigger siblings, the SNS 3655 and SNS 3695, come with 12 CPU cores on the Intel Xeon 4116 CPU but differ in terms of RAM size and hard drives: The 3655 comes with 96GB of RAM and four 600GB hard disks, and the 3695 is lavishly equipped with 256GB of RAM and eight 600GB hard disks. On the network side, all of the servers come with two 10GBASE-T and four 1GBASE-T ports.
Persona Determines Function
The exact architecture of ISE can vary greatly depending on user requirements and the size of the deployment. Several nodes can be used for this purpose and are based on the virtual or physical servers just described. These nodes in turn have different "personas" that define the functions that the node performs. In the simplest standalone deployment, one node would handle all the personas. The administration persona is the first and allows system management. To increase availability, you can fall back on a secondary node in addition to the primary administration node.
The workhorses, second among the personas, are the policy service nodes. Classic authentication, as well as the guest service with the corresponding portals, takes place here; that is, these nodes check the policies configured on the administrative nodes and return the corresponding decisions to the active network components, such as switches and WLAN access points. Additionally, profiling functions (Figure 2) can be performed if the appropriate license is in place. Multiple policy nodes can be grouped geographically or by availability zones.
The third persona handles the monitoring functions and is therefore a core component of any AAA system, enabling various reporting and troubleshooting options. These features can also be distributed across a primary and a secondary node.
Finally, the pxGrid persona lets you pass context information from ISE to third-party systems, whether these are compatible Cisco systems (e.g., Firepower firewalls) or products from partners. On the basis of context information, isolation of hosts can take place after a detected infection or in case of undesired behavior.
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.