Upgrade to ISE 3.1 on AWS

Below is the prep work for migrating from ISE2.4 to ISE3.1+ for AWS, and the migration steps are here, but I have summarize them below.

Cisco ISE is available as an infrastructure-as-code solution leveraging AWS CloudFormation making the deployment of ISE a very light lift. I’ll be walking you through how to deploy ISE on AWS in a later post.

Step 1 – Base, Plus, Apex, and Device Admin licenses need to be migrated to Smart Licenses
Step 2 – VM licenses need to be converted
Step 3 – Migration can occur. Once licenses are prepped and converted, you go to the AWS Marketplace ISE BYOL listing and choose your deployment size. 

ISE Licensing

  1. AWS ISE requires ISE 3.1+
    1. If upgrading to 3.1 from an existing 2.X release, it is required that a customer migrate their existing licenses to the new licenses and then upgrade to the 3.0 release. I.e. These are the Base, Plus, and Apex license that need to be upgraded. Device Admin licenses are grandfathered and need to be upgraded to a Smart License as well.
  2. This requires a Cisco Smart License Account. 
  3. Please refer to the Migration Guide for instructions.

ISE VM – You need to register the VM Common license for ISE 3.1 and later.

  1. Customers need to migrate their ISE License to the new “Common License.”
    1. To migrate the legacy VM license to the VM Common license, customers need to obtain the $0 upgrade Product ID (PID), “L-ISE-VMC-UPG=, from Cisco. This is the same PID regardless of what current size of VM license you have today.
    2. https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/ise-licensing-migration-guide-og.html

2. To obtain a VM Common License for a net new deployment you’ll need the new VM PID, “R-ISE-VMC-K9=” Refer to the table below for a 1:1 mapping.

These VM licenses are valid in Cisco ISE 3.0 and earlier releases. Again, when you upgrade your Cisco ISE to Release 3.1, you will need to have VM Common license.  

Upgrade FromUpgrade ToRatio

How to migrate license

To migrate the legacy VM license to the VM Common license, customers need to obtain the $0 upgrade PID, “L-ISE-VMC-UPG=,” in CCW. See ISE Licensing Migration Guide for the detailed process.

Support for VM and License

Q. What support do customers receive with the new ISE licenses?

A. The same as with current subscription licenses. With the new ISE software licenses, customers receive embedded SWSS—which covers 24x7x365 Cisco Technical Assistance Center (TAC) support and software updates. However, now Essentials will also have this support.

More Question and Answers here

Support associated with the legacy VM licenses

When customers upgrade the version of their legacy VM to VM Common license, they can continue to receive support based on the support contract purchased on legacy VM license PID. They can renew the support until the legacy VM license PID is EOL and reaches the last service renewal date per the EOL bulletin. There is no support for migration. For seamless support, the customer should request the legacy VM PID to be replaced with the desired VM PID in order to renew and receive support.


EoS and EoL roll-up for Cisco AirOS Wireless, ASA, and Switching

End of Sale and End of Life dates for AireOS Cisco Wireless LAN Controllers – AIR-CT-3504AIR-CT-5520AIR-CT8540AIR-CTVM 

End of Sale and End of Life dates for ASA 5506, 5512 & 5515, 5508 & 5516, 5525, 5545 & 5555, 5585-X, 5585-X FP

End of Sale and End of Life dates for Cisco Catalyst – 2960X/XR2960L/P3650SUP9E


Protecting the WFH workforce – Defending against COVID-19 malicious domains

Many organizations have implemented work from home (WFH) strategies due to COVID-19. This measure, although enabling business continuity for many, introduces increased risk to cyber threats and attacks.

Cisco Talos has been proactively hunting COVID related outbreaks, educating the public, and pushing these discoveries to all Cisco Security tools for blocking. I encourage you to read the Talos blog, “Threat Actors attempt to capitalize on coronavirus outbreak” and “Threat Update: COVID-19“.

Talos goes as far as to list ways that you can defend against COVID related attacks. Cisco Umbrella, in particular, can leverage threat intelligence from Cisco Talos, to uncover and block these malicious domains, IPs, URLs, and files that are used in attacks. It’s not just Talos intelligence that Umbrella can leverage, however. You can take advantage of 3rd party threat intelligence platforms (TIP) that you may have and create a completely robust, kickass defense for your work from home workforce.

Here’s how –

Turn on – Newly Seen DomainsAs part of Cisco Umbrella intelligence, some domains may be blocked as Newly Seen Domains (NSD). Newly created domains related to COVID-19 will also be flagged as NSD as long as they fit the criteria.

Third Party Integration: Umbrella support integrations with SIEM, threat intelligence platforms, or homegrown systems. This feature utilizes the ‘Enforcement API‘ in Umbrella.

Here are the default integrations.

In this case, I want to show you how to leverage a homegrown system. We’ll call it “COVID-19-BLOCK”

When you add a new integration, an API key is generated. This API key can be used to make requests to and from Umbrella.

Our homegrown system is nothing more than a simple python script that makes POST requests to Umbrella.

# Custom integration - ADD EVENT URL
import requests

url = "https://s-platform.api.opendns.com/1.0/events?customerKey=c988727a-XXX-XXXX-XXXX-XXXXXXXXX";

payload = "{\n    \"alertTime\": \"2013-02-08T11:14:26.0Z\",\n    \"deviceId\": \"ba6a59f4-e692-4724-ba36-c28132c761de\",\n    \"deviceVersion\": \"13.7a\",\n    \"dstDomain\": \"coronadiseasenews.com\",\n    \"dstUrl\": \"http://coronadiseasenews.com/a-bad-url\",\n    \"eventTime\": \"2020-03-31T09:30:26.0Z\",\n    \"protocolVersion\": \"1.0a\",\n    \"providerName\": \"Security Platform\"\n}"
headers = {
  'Content-Type': 'application/json'
response = requests.request("POST", url, headers=headers, data = payload)


After running the script, we can confirm that our request to block the COVID-19 malicious domain was successful.

As you can see, we were successful in adding this malicious domain to our block list.

Now, take a moment to expand on this custom integration that we just made. There are roughly 70,000 COVID-19 malicious domains and growing daily. What if we were able to take all of the published COVID-19 molicous domains and add them to an Umbrella block policy like we did above?

I think that would make any CSO smile.



The Challenge and the Solution

Modern enterprises demand agility. Mobile workforce and bring your own device (BYOD) trend has sparked a digital transformation. Organizations have to deal with a diverse set of users such as employees, contractors and partners who work from anywhere at anytime and on any device. The proliferation of user types, devices and access locations increases security risks for the organizations. 

It’s no longer safe to assume that users are who they say they are and their devices are secure. 

Duo’s focus is on securing access for any user connecting to any application from any device.  The new network perimeter is wherever an access decision happens. Duo protects this new perimeter by verifying user trust (confirming a user is who they say they are) using its best-in-class adaptive multi-factor authentication (MFA) solution.

As a result, Duo integrates with any application with ease, provides self-enrollment and an excellent end-user experience.

AnyConnect with DUO

Where’s the proof?
Options Technology

Demo DUO

Need to know more? https://duo.com


Secure Internet Gateway – Cisco Umbrella

As traffic patters change to a decentralized pattern, there needs to be a way to secure traffic to the cloud.

Today we will be talking about the Secure Internet Gateway (SIG), Umbrella formally OpenDNS.

Umbrella is a recursive DNS service, it resolves DNS queries. Almost everything starts out by making a DNS request.

The process of recursive DNS look-ups are pretty straightforward. Lets walk the process.

  1. A user opens web browser and types in Amazon.com
  2. Umbrella, the recursive DNS services queries a root server. The root server only has top level domain IPs for top level domain servers. Eg. (.com, .net). The root server will reply to Umbrella “I’m not sure, but here is the IP for the .com server, ask them”
  3. Umbrella queries the TLD server (.com). The TLD server stores information on the Authoritative Name Servers for domains that end in (.com). The TLD server will reply to Umbrella “I’m not sure, but here is the IP for the Authoritative Name server, ask them”
  4. Umbrella now has the IP address of the Authoritative Name Server for Amazon.com, Umbrella will ask Amazon’s Authoritative Name Server, what is your IP address of your Amazon web site.
  5. Amazon will reply with the IP of their website. Umbrella will return the web page to your browser.Screen Shot 2018-10-08 at 11.28.00 AM

There are three scenarios when resolving DNS with Umbrella.

  • Safe – Determined as a safe DNS request. Returns IP-to-URL mapping.
  • Block – Determined as unsafe/malicious DNS request and your request is blocked. The request is blocked by a block page. A block page is configured by an administrator.
  • Inspect – Determined as a risky DNS request. Sites like peer-2-peer hosting could be considered risky. In this scenario Umbrella returns the IP address of the Umbrella proxy so that the site can be inspected.

The Inspect scenario is where Umbrella gets interesting. Proxys are now involved in the scenario. Instead of just seeing the top level domain of a URL, the proxies now inspect the entire URL and web content. It leverages AV definitions, AMP and Talos to determine the sites reputation and content.

How does Umbrella determine a site to be malicious vs non-molicous?

This recursive process is processed by algorithms known as “models” that monitors request patterns,  malicious traffic, and abnormal behavior. The output from multiple models is how a domain is determined malicious or non malicious.

Some of these models:

  • Co-Occurance model
  • Spike Rank Model
  • Predictive IP space monitoring

Umbrella Investigate is a built in capability that can give you some offensive tools when responding to security incidences.

Screen Shot 2018-09-26 at 3.00.41 PM

Investigate provides real time intelligence on domains and IPs across the Internet to help uncover anomalies and pinpoint malicious domains/IPs. Access to the intelligence is done through web console or api for you to integrate your current security infrastructure with Investigate.

Screen Shot 2018-09-26 at 3.12.20 PM

How do you use Umbrella?

Simply point your DNS to the Umbrella DNS servers. You can do this in several ways.

  • DHCP
  • The ISR 4K version 16.6.1, any traffic passing through the router will use Umbrella
  • Generate an API key through the Meraki Dashboard, integrate it into the Meraki MR
  • Out of the box integration with  Viptal vEdge
  • Cisco Any Connect (Roaming Devices)
    • AnyConnect Umbrella Roaming module
    • If not using AnyConnect, install standalone roaming client

If your clients are using the AnyConnect Umbrella module, the DNS is intercepted by the kernal driver that is sitting at the network adapter. This is the same process that AnyConnect uses when using VPN.

Screen Shot 2018-09-26 at 3.41.16 PM

If your clients are using the roaming client, all DNS requests from any running application are pointed to and then handled by the roaming client.

Where are the Umbrella DNS servers located?

The Umbrella Data Centers are Co-Located at Major IXPs, this enables best path selections throughout the Internet via BGP. Anycast routing  is used for reliability to the DNS resolvers with no additional latency. Anycast routing improves functionality by sending your traffic to the closest data center and provides redundancy.

You can view the location of the Data Centers and the status of Cisco Umbrella systems through this link.

Data Center Locations

For more information see the documentation page Umbrella Documentation




ISE Posture Troubleshooting

Welcome to the first blog of the new year, sorry for the late start. I’ve been stuck in the trenches trying to figure out the application flow for the posturing module used in the AnyConnect client.

A client of mine is having mixed results when an endpoint authenticates and then attempts to posture to their network. Some of the symptoms that are experienced are as followed:

  • Device and user authenticates, AnyConnect reports incorrect policy server
  • User reports intermittent network interrupts during their working day
  • User receives “Untrusted server blocked!” (certificate issue)

I’ve invested a lot of time absorbing and digesting Cisco’s documentation for Cisco ISE and AnyConnect and believe at this point I have a good understanding of it.

Here is what I found and how you can perform the same troubleshooting steps to help resolve your issues.

We are focusing on Posturing. So after Authentication and Authorization is successful, posturing begins. Posturing is just a way to ensure that your endpoints are complying to your companies network policies before gaining network access.

The AnyConnect Posture Module begins by initiating policy server detection. This is accomplished through a series of probes which are known as discovery probes.

There are three probes in total, and I will show you how they look.

Probe 1 – AnyConnect sends first discovery probe to the clients default gateway. This discovery probe along with the next two are HTTP GET requests to /auth/discovery.


This request will be intercepted by the switch that the client is connected to and present a redirect-url to the client. This redirect is that of your policy node. If your AC is unsuccessful it will attempt a second probe.

Reminder: this is all done in the background and is not known to the user

Probe 2 – AC sends second probe. A HTTP GET /auth/discovery to enroll.cisco.com. This FQDN needs to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel.



Expected result for the probe is redirect-url to your policy nodes.

Probe 3 – HTTP GET /auth/discovery to discovery host. Discovery host value is returned from ISE during installation in AC posture profile. Expected result for the probe is redirect-url

Your AC posture profile lives here.

C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\ISEPosture.xml

Unfortunately none of these probes were successful for my client.

Posture would sometime succeed but not always. When it was successful the client was pointing to an old policy server in their old ISE 1.3 environment yet their clients were Authenticating to their new ISE 2.2 environment.  hmm..

That turned out to be a key part in resolving their issue. My client had recently migrated from ISE 1.3 to ISE 2.2. ISE 2.2 changes the way posturing works.

Posturing in ISE 2.2 assumes that redirects are not needed but does support backwards compatibility for environment that use redirects.


I won’t be going into detail on how posture work in ISE 2.2. But do know that there are two stages.

Stage 1 uses the same traditional discovery probes that we listed above for backwards compatibility.

Stage 2 uses two discovery probes.

Probe 1 – Attempts to discover your PSN through IP/FQDN from the “CallHome list” that are defined in your posture profile located in

C:\ProgramData\Cisco\CiscoAnyConnect Secure Mobility Client\ISE Posture\ISEPostureCFG.xml

Probe 2 – AC tries the PSN FQDNs. It generates what should be a dynamically created file (ConnectionData.xml) upon first posture attempt. That file is located here.

C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\

The goal of both probes is to get FQDN. They are both there in the case where you don’t have your “CallHome List” defined for the first probe to succeed.

So after knowing this. I reference ConnectionData.xml. The .xml file had current ISE 2.3 and Old ISE 1.0 FQDNs.

I could delete and modify this file to exclude old ISE 1.0 FQDNs but it would reappear upon the next posture. I continued my troubleshooting.

I deleted ConnectionData.xml. I uninstalled the posture module from the client. I had the client re-posture so that I would receive the installation of the posture module.

I then referenced my newly dynamically generated ConnectionData.xml and bam! The .xml file only had ISE 2.3 FQDNs. It had no knowledge of old ise. Come to find out, the customer had a off line deployment package that included the ConnectionData.xml file and placed it in C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\…..When AnyConnect is deployed off-line and  includes the .xml file, it creates a static entry in the file even though that file is rebuilt at each posture.

After fixing the discovery probes which was to enable http server on the default gateway where the hosts live and correcting the .xml file to exclude old ISE FQDNs. Clients were posturing to new ISE.

It’s been a long journey in this discovery but things are looking up.