on
10-30-2020
02:02 AM
- edited on
03-17-2025
04:04 PM
by
thomas
Contents
This document covers information regarding security, hardening and testing of Identity Services Engine (ISE). Information included such as TLS & Software versions, our testing processes, how is it hardened, upgraded paths, password policies, best practices and plus much more. Version-specific capabilities will be identified where appropriate.
For the current ISE Suggested Release based on the software quality, stability, and longevity,
See the Cisco Identity Services Engine (ISE) Software Downloads page (cs.co/ise-software) on software.cisco.com.
See the Cisco Identity Services Engine (ISE) End-of-Life and End-of-Sale Notices page (cs.co/ise-eol) for all ISE-related announcements, dates, and more information.
The ISE underlying OS is based on Redhat Linux but access to underlying OS is not provided. Only required ports open, and rest closed through a firewall.
There is no official hardening document, but we provide this as general guidance:
Refer to the Cisco ISE Installation Guides' (cs.co/ise-docs) ISE Ports Reference section for your version of ISE for all network ports, protocols, and any required Internet URLs.
ISE has different tables for local user management of:
ISE Admin and Internal Users are stored in the Oracle database with below mechanisms for security. ISE CLI users are going to be stored in the Linxux OS and hashed for protection.
ISE does not always use salt. The password of an internal admin users is using salt but not for the internal network access users.
ISE follows the Cisco Secure Development Lifecycle (CSDL) process and vulnerability testing is also performed.
Cisco completes CSDL process testing and verification on all cisco ISE releases before making it available for customers. We fix reported PSIRTs in patches based on the severity and impact. Hotfixes may also be available for some critical fixes via TAC before a patch is released.
Cisco ISE conforms to various protocol standards, Requests for Comments (RFCs), and IETF drafts. See the ISE Compatibility Guides (cs.co/ise-compatibility) for your respective ISE version for a detailed support list.
See the respective ISE Compatibility Guides (cs.co/ise-compatibility) for the specific TLS versions and cipher suites supported per version of the product. It is recommended that clients/servers negotiate to use a higher version of TLS for enhanced security. ISE has configurable options to disable specific TLS versions and ciphers.
Cisco Identity Services Engine provides configuration of password policies for ISE admin users (UI/CLI) and ISE internal users. Cisco ISE already provides default configuration for password policies which enhances your security. Refer to Administration > Settings > Admin > password policies for ISE admin users’ password policies, account disable policies and lock/suspend settings and Administration > Identity management > settings > User authentication settings for ISE internal user’s password policies and Account disable policies.
It is recommended to disable “Disclose invalid usernames” for enhanced security. By default Cisco ISE is disabled to show invalid usernames in case of authentication failures. You can enable this settings to show invalid usernames during debugging scenarios for certain duration or always.
ISE has two independent types of network limits:
Network Limit Notes:
WOW. Nice Job putting this together Jason.
-Krishnan
"ISE 1.2 has passwords encrypted using Block cipher mode (CBC) with the AES algorithm and then base64 encoded, before storing in the database. ISE 1.1 has the same thing except using the ECB mode. Data fields other than passwords are not considered sensitive and not encrypted. Please note that ISE admin users do not have direct accesses to the database in normal operations."
How is the key used to encrypt/decrypt the passwords stored/secured?
I am not sure I understand the question.
AES symmetric cipher using CBC mode to make it a block symmetric cipher. CBC is more secure than ECB. The combination AES +CBC is used to encrypt the passwords.
AES uses different key sizes. The result of this is further base64 encoded to convert binary to ASCII and stored in the db. I am just interpreting what is provided in the ISE security best practices site.
-Krishnan
Thanks Krishnan. In order to decrypt the content stored in the database ISE needs to maintain a key and the IV (I believe). Where and how is the key (or keys) protected which ISE uses to decrypt the encrypted passwords?
Hi Doug/Chris,
Do we know how and where we store the keys for AES+CBC used to encrypt passwords in the db?
There is a question from the community.
I wanted to respond “in a safe place”…☺. Well, that is not the answer I am looking for. Please see the email below.
Thanks
Krishnan
Cisco Communities <https://communities.cisco.com/>
ISE Security Best Practices (Hardening)
new comment by George Bekmezian<https://communities.cisco.com/people/gbekmezi-DD>
View all comments on this document<https://communities.cisco.com/docs/DOC-69521#comment-28500>
Please open up a TAC case if you are looking for further details.
-Krishnan
how about an updated one for ISE versions 2.1 and 2.2
We are looking for a more high level statement that we could provide to the customer . A statement just stating we harden our OS in certain ways and don't open it up to customers to touch . Also we address any issues on a per release basis . Something like that. Is there one and if not , who can we work with to write one up.
somewhat unrelated but I've disabled everything except TLS 1.2 in my ISE 2.3 environment via GUI however I still show TLS 1.1 and sometimes TLS 1 support enabled via an nmap scan. Is there a way to verify this via cli?
Please open a separate thread for this discussion
Your issue seems among those addressed in the upcoming ISE 2.4 so I would suggest you to join ISE 2.4 beta by going to cs.co/ise-beta to learn more.
Can anyone point me to some guidance on how to restrict SSH access to the ISE nodes from a select number of trusted networks? whilst the WebGUI can be configured to restrict access I can't see a way to easily restrict SSH other putting a firewall inline?
The IP restriction configuration in Web UI also imposes on SSH CLI access.
thanks for this post
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: