on 10-30-2020 02:02 AM - edited on 04-02-2023 12:03 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.
This document focuses on the current and latest supported ISE release versions below.
For the current ISE Suggested Release based on the software quality, stability, and longevity, see https://cs.co/ise-software.
Please refer to our EOS/EOL page for more information.
ISE follows the Cisco Secure Development Lifecycle (CSDL) process [CSDL Whitepaper]. Vulnerability testing is also performed.
Follow the same as in the Cisco Prime Infrastructure Admin Guide wherever applicable. In summary, the 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:
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:
It is recommended that clients/servers negotiate to use a higher version of TLS for enhanced security. Please see the respective ISE Compatibility Guides for the specific TLS versions and cipher suites supported per version of the product.
Version |
Compatibility Guide |
ISE 2.6 |
|
ISE 2.7 |
|
ISE 3.0 |
ISE has below user management in place.
ISE admin and Internal Users stored in the Oracle database with below mechanisms for security. ISE CLI users are going to be stored in ADE-OS and is 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.
You can upgrade to latest Cisco Identity Services Engine from your current Cisco ISE release versions. Here are the Paths available for you to upgrade to latest Cisco ISE release.
Version |
Upgrade from |
ISE 2.6 |
ISE 2.1, 2.2, 2.3 or 2.4 Releases |
ISE 2.7 |
ISE 2.2, 2.3, 2.4 or 2.6 Releases |
ISE 3.0 |
ISE 2.4, 2.6, or 2.7 Releases |
Refer to below upgrade guides for each release when you are upgrading to specific ISE versions.
Version |
Upgrade Guides |
ISE 2.6 |
|
ISE 2.7 |
|
ISE 3.0 |
As part of CSDL, ISE undergoes vulnerability testing. This involves both industry standard testing tools and custom testing targeted at the product functionality. Refer to vulnerability testing process as part of CSDL.
Cisco completes CSDL process testing and verification on all cisco ISE releases before making it available for customers. However, Patch releases doesn’t go through CSDL process as we do not introduce new features in patches. Instead we fix reported PSIRTs in patches as per the severity and impact.
Cisco ISE conforms to the protocol standards, Requests for Comments (RFCs), and IETF drafts.
The Cisco ISE Ports Reference for each version of ISE, details all of the network ports and their purpose & usage. Refer to below table for the ports reference for each release.
Version |
Reference Link |
ISE 2.6 |
|
ISE 2.7 |
|
ISE 3.0 |
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: