In my last article, I talked about how Cisco ISE can answer the Five W’s of Network Access Control. Those being:
- Who is accessing my network?
- What devices are being used on my network?
- Where are these devices and users logging in?
- When are these devices or users accessing my network?
- How are users and devices authenticating?
These contextual questions are great when answered individually, but a comprehensive look at the authentications in your environment makes much more sense because that’s how actual authentications occur. After Cisco ISE is deployed in your network, you will have access to a dashboard that shows you live authentications as they are occurring.
Armed with the knowledge of the Five W’s, you’ll be able to start putting the pieces together and examining actual authentications in your network.
Take, for example, the following authentication in your network:
Who: Angela Martin
What: Apple iPhone
Where: Scranton Branch
When: 10:05 A.M. EST
Note: real authentication logs give you dozens of details and attributes for which policy can be written. Brevity is used here for readability.
There are a few things that this authentication tells us. Angela has authenticated with a secure method (PEAP-EAP-MSCHAPV2) utilizing her corporate credentials. For the sake of this use case, we will assume that Angela works in the Scranton Branch office and her office hours are 9 A.M. to 5 P.M. However, Angela has authenticated on an Apple iPhone. How do we know that this iPhone isn’t jailbroken and ridden with malware?
Cisco ISE can leverage external Mobile Device Management (MDM) solutions such as AirWatch to validate whether this iPhone is jailbroken, has pin lock enabled, etc. A simple query to the MDM server can tell us whether the device is registered and what specific settings are enforced. If the device is registered and complies with all MDM policies, we can permit access to the network. But, what kind of access does Angela need on her iPhone? Does Angela’s iPhone need to utilize every protocol and reach every internal corporate server?
Probably not—so we can give her a different Authorization Result based on the device she’s authenticated with. I would consider this context-aware policy since we’re giving Angela a different policy based on the device she’s using. Let’s assume we give her an Authorization Result that permits Internet-Only access with the DNS, HTTP, and HTTPS protocols only. Alternatively, we can dynamically assign a VLAN to Angela’s iPhone that restricts her from having any reachability to internal corporate resources.
Let’s look at another example for Angela:
Who: Angela Martin
What: Corporate Windows 10 Laptop
Where: Scranton Branch
When: 3:47 P.M. EST
How: EAP-FAST with EAP-Chaining (Machine and User Both Succeeded)
In this authentication, Angela has authenticated on a corporate machine (A Windows 10 laptop), and the machine has also been authenticated against Active Directory. Since Angela has authenticated on a corporate issued machine, she probably needs different access than she would while utilizing her iPhone.
We can give her an Authorization Result that permits access to the QuickBooks servers (on only the user-facing ports she needs) and any internal servers (DNS, file share, directory services, etc.) that a corporate machine would need. This illustrates just one device-centric use case for a security tenet called Context-Aware Security—giving differentiated access based on the contextual data we know about that endpoint or user.
The example above also illustrates the Principle of Least Privilege—granting users and devices the least set of privileges required to perform their job successfully. For example, your VoIP phones will likely need access to the VoIP servers, gateways, and other VoIP endpoints utilizing protocols such as SIP, SCCP, and TFTP—they will not need access to SSH to the financial database server.
While we only covered one “what” or device-centric policy here—you could use the other W’s for policy as well. For example, you can prevent guests or contractors from accessing your network outside of business hours [when], deny accounting users from accessing the HR resources [who], deny legacy or insecure authentication protocols that don’t require server validation [how], or even prevent certain types of authentications on an industrial warehouse switch [where].
Looking at authentications from a more comprehensive point of view can provide greater visibility into what’s really happening on your network. Simply authenticating users and endpoints is not enough; start thinking about what access the users and devices in your network really need.