Making Ice Cream Out of ISE – Part 1

Introducing Vanilla ISE – a simplified ISE GUI for endpoint technicians

Some people prefer to begin with the end result, and reverse engineer their way backward. If that is the case, let me make your life easy – here’s a link to the Vanilla ISE GitHub repo.

However, if you are interested in the approach we took, our thought process, and tools that led us to the end result – keep on reading! In this blog series, we will describe from inception to execution the journey of Vanilla ISE – a simplified ISE GUI for endpoint technicians.

ISE provides many services for protection from threats

To be honest, Cisco ISE (Identity Services Engine) grew on me over time. ISE has always been there, taking over Secure ACS as the network’s TACACS+ server, or managing VPN policy for ASA appliances. Around ISE 2.4, however, I started working with it more closely, unveiling more and more of its potential.

Nowadays, ISE is the policy engine for your network. It provides many (many!) different services that are all required to meet today’s user expectations while protecting the organization from threats:

• TACACS+/RADIUS for central management of networking equipment.
• True visibility of what you have on your network.
• Network Admission Control (NAC) identifying endpoints as they connect to the network (both wired and wireless).
• Network Segmentation based on devices and roles.
• Group-based policy using Cisco TrustSec.
• VPN policy with Cisco ASA/FTD.
• Guest lifecycle management.
• Device profiling.
• And more…

Where it all began

Our story starts, as always, with one of my customers explaining to me how Cisco ISE’s richness of features and capabilities is highly appreciated. Networking engineers and security experts love it for TACACS+, controlling and auditing who is doing what changes in the network, and who’s allowed to enter which command.

However, now that they are considering replacing their existing NAC solution with Cisco ISE – they have some concerns. The ongoing day-to-day operation of their existing NAC solution is handled mostly by the endpoint technicians and helpdesk representatives. Often, these are part-time students and entry positions at the company. Occasionally, someone gets locked out of the network – due to outdated antivirus updates or an employee computer being replaced/reinstalled – and they do not want to bother networking engineers with endpoint issues.

Their main concern was that many of their representatives would be challenged when introduced to a new system. That it would take too much time for them to get used to Cisco ISE’s UI. Ideally for them, the UI would have no more than four buttons, as the helpdesk representatives won’t be using 90% of the features and menus ISE provides… Ever!

Spoiler alert – we created Vanilla ISE with four menu items.

With Cisco ISE’s open APIs – that does not need to stop us.

Let the journey begin… requirements gathering

As much as it would be convenient to invent my own requirements (and scratch an itch I think it there), I’d rather gather the requirements from the actual stakeholders who will benefit from the program. Making sure I address their needs, not mine. Well, not only mine. I had several conversations with various stakeholders – network engineers managing ISE today, endpoint technicians, even a couple of people using a different NAC system – to understand which features interests them and what would be their perfect UI.

These conversations revealed several interesting findings. Some wanted to leave ISE alone and keep managing it the way they are used to, while others were interested only in specific features. the concept of a “voucher” was a specific capability mentioned by endpoint teams.

A voucher would be a time-limited access token, given to a specific endpoint in order to grant immediate network access (while bypassing security checks). The use case is a distressed user (that is usually an executive) that isn’t able to connect to the network and can’t wait for the endpoint technicians to find and fix whatever’s wrong. A voucher would allow the technicians to ease the immediate pressure and remediate gaps in the endpoint’s posture later.

Summarizing the requirements for the minimal viable product (MVP):

1. Simple.
2. Ability to query a switch for active endpoints.
3. Ability to check the status of a specific endpoint.
4. Issue/revoke temporary access vouchers.

Coming next in Part 2 of this blog series, we will cover the exciting art of exploring documentation to find the relevant APIs we will use.

 

---

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel