Can We Trust Your Device? Checking Security Posture

Published: September 2019

You may be able to bring any device through Cisco's doors. But when it comes to connecting to the corporate network, we are working on a solution that provides “full access” to applications and services for devices that we have confirmed meet our Trusted Device standard.

A laptop might have picked up malware from a home network the night before. A mobile device might not have installed a critical security fix or your device may not even be encrypted. "Our goal is to allow trusted devices full access on the network--and to restrict the access of non-trusted devices" says Adam Cobbsky, senior IT engineer.

What's a trusted device?

Trusted devices need to meet a specific set of security standards prior to accessing corporate applications and data, on or off the production network. For example, a device must not be jailbroken or rooted, it should be running a minimum OS version, and have a screen-saver password or PIN lock enabled.

For Cisco IT and many customers, these requirements and others are enforced by device management systems. In addition to ensuring that services such as disk encryption and antivirus/antimalware are installed and enabled, device management gives Cisco IT the ability to remotely lock or wipe compromised devices. For Cisco IT, a managed device is the foundation of a trusted device.

Cisco uses several management systems: Microsoft System Center Configuration Manager (SCCM) for Windows, JAMF Pro for Mac, and soon it will use Cisco Meraki for mobiles devices running iOS and Android.

Laptops, mobiles, and tablets that are registered with the respective device management platforms and are regularly checking in to that management system are considered compliant with the required Trusted Device security standard. Compliance means the device has an acceptable security posture.

Our first approach: integrating ISE and device managers

Since 2014, we've used Cisco Identity Services Engine (ISE) with device management integration. In its simplest form, ISE receives the MAC address of a device connecting to the network from the ISE-enabled switch or wireless access point.

Through ISE and device management integration, ISE can query the relevant management platform to verify the connecting device is registered and active and can confirm it meets our definition of trusted.

"Integrating ISE with our device management systems looked like a simple solution on the surface, but we discovered a lot of practical issues," says Donald Gunn, IT program manager.

One problem is knowing exactly what device is connecting to our networks. The ability to uniquely identify a device is an industry challenge, and the increase in privacy protection within devices and operating systems to obscure unique identifiers is not making this any easier.

Further, MAC addresses may be shared across different devices and even OS types. This can occur due to plug-in network adapter dongles that get used by more than one device, or the use of virtual machines (VMs) that can share the same MAC address as the host. These types of scenarios can make it a challenge to uniquely identify a machine on the network and correlate it to a device in management.

Over 1.5 million endpoints connect to our ISE-enabled network. Not being sure whether the connecting device is a Windows laptop, MacBook, or mobile device, ISE potentially could query all device management platforms looking for a matching device. This isn't an intelligent use of resources, and some device management platforms couldn't handle the burden of that number of queries. We needed a more scalable and dynamic solution for device posture checking.

The two core issues come down to wanting a unique and reliable device identity and the need to focus device queries to device management systems down to sustainable levels.

Our solution: a compliance database that maps the device ID to device type

To address these issues, Cisco IT has worked closely with the ISE development team. For mobile devices, the main challenge was to identify devices that are mobile and ensure ISE looks these up in our Mobile Device Management (MDM) system. When a mobile device enrolls in a management system, our automation tools pass the device details to ISE and a flag is set in ISE to identify the management system this device is enrolled in. When this device tries to connect to the network, ISE knows where to look it up, avoiding unnecessary queries.

For laptop and desktop computers, a different approach is used that utilizes a unique device identifier from the Cisco AnyConnect Client. This allows us to know uniquely what device is connecting. Using this ID, we can verify that a specific device is trusted by our management systems. There is no ambiguity any more.

To further buffer the management systems from device posture queries, we decided to create a central database of devices that meet our posture requirements. Not only does this give us better scalability, it also provides resiliency and availability in our solution without passing this burden directly on to the management systems.

This compliance database is synchronized with the device management systems through custom software and acts as the central database that ISE queries, instead of each individual device management system. We chose Active Directory as the foundation because it scales, has low latency everywhere in our network, replicates quickly, is highly available, and is stable.

Cisco IT has now completed a successful proof of concept using this solution (Figure 1).

A custom script extracts the unique device ID (UDID) from the AnyConnect client on the laptop and compares it against the database. ISE needs to know the device ID to check its compliance status. We use the same posture database to check device status before allowing a connection to cloud services such as Office 365 as well.

Figure 1 We check device posture with ISE, a compliance database, and device management platforms

Validating security posture is more complicated for laptops than mobile devices. "Security configurations on laptops are more complex and assessing compliance can require greater understanding of context to fully understand if a device is compliant or not," says Gunn.

For example, disk encryption alone does not fulfil our requirements. We also escrow the encryption keys, so you need to know if the keys are escrowed to fully verify the device posture. It is this sort of factor that makes verifying compliance more demanding than may be obvious at first glance. To address this, we have to do more checking to make sure the device is compliant. In designing a solution, we're aiming for the right balance of risk management, flexibility, and user experience.

The right balance between risk and user experience

An example of balancing risk and user experience is in deciding how often to check device posture. In real time? Hourly? Daily? Weekly? Frequent checks reduce risk but may inconvenience users by using more computer resources to check management systems more frequently.

"We decided that we don't need real-time checking," says Laurent Sellin, IT engineer. "We're okay trading absolute certainty that the device was compliant 30 seconds ago for reasonable certainty that if it was okay 12 hours ago, it probably still is."

Currently we routinely update device status at least once in a working day--so the first time in the working day that the device connects to the network it will be checked.

The key use case that requires real-time checking of status is when a user has been blocked. They will be notified there is a problem and guided to what is needed to fix it. Once they bring their device back into compliance, we want to get that user connected and working again as quickly as possible, so we update the user device status immediately, on demand, to get the latest data and let that user connect again.

Another way we balance risk and user experience is by allowing a "grace period" for non-compliant devices to remain on the network under certain conditions. Say you've just returned from a vacation. Your virus definitions and possibly your operating system will be out of date.

"If the device was trusted the last time it connected, we don't block it," Gunn says. "Instead, we allow a certain number of minutes for it to update, and in the meantime the user gets to work. ISE watches what the laptop does during the grace period. If it checks in and comes back into compliance, it can remain on the network. If it doesn't, ISE sends a warning that access will be blocked if remediation isn't complete within a certain time.

The grace period feature was our idea. We're "customer zero" for integrating ISE with the compliance database, meaning that we're trying it out before our customers. As customer zero, we suggest features to the business unit and can share deployment guidelines and lessons learned with customers. Based on our experiences, we also suggested a Reconnect button in AnyConnect to simplify reconnection if the grace period expires. The business unit implemented this suggestion as well.

Next steps

We have successfully tested the complete solution--at small scale. The next steps are to measure how ISE handles external database queries at scale and to automate the database updates fully. Recently Cisco acquired Duo and has been implementing Multi-Factor Authentication. Further down the road, we expect that this will give us a pathway to provide the same access controls for cloud and on-premises network-based access.

For more information

Cisco Identity Services Engine

Office 365: How We Made It More Secure than On-Premises Email

To read more Cisco IT case studies on a variety of business solutions, visit Cisco on Cisco: Inside Cisco IT