I always tend to bring napkins for meetings with network security & infrastructure teams during an implementation of ITOM.
When they hear you need domain admin credentials to discover windows machines they either cry or spit out their coffee on my suit. Luckily no more wet stories or dry-cleaners. With this simple go-to-guide, I’ll deep dive more into credential security in combination with ServiceNow ITOM.
Before I start rambling about the credentials in ServiceNow specifically – let’s speak shortly about credential management as a general topic from a network security point of view. Depending on the size, mat, rity and industry your organization operates within the habits and practices might vary.
In a good world, one would be sure to use a privileged access solution such as CyberArk in combination with good routines for managing administrative credentials.
In a not so good world, chances are you or your customers are already today storing credentials in password safe, USB-drives or your head.
Access to the right people or systems will often provide a weak link in the chain for attackers – ServiceNow is not an exception. If you use any sort of global administration, you need to store the credentials on other means than post-it notes. Protecting the access to that global administration is key and an on-going security process.
Storing it in ServiceNow instead of encrypted ZIP-files or password safe is not that much different. In other words, you will have a risk no matter what you do and I’m positive that you already have that risk in some sense.
ServiceNow and credentials
With that being said, let us have a look at how ServiceNow is processing credentials. Credentials of various types can be stored in a table in your instance. These credentials are then used in IT operations management to perform a multitude of operations. Such as discovery, service mapping or orchestration.
When a credential is stored in ServiceNow it is of course encrypted. For you cryptography geeks the encryption itself is 3DES and are decrypted on the instance with a password2 key.
The password2 fields are encryption fields using 3DES (192/168), which further encrypt the 3DES key using AES with a 256 bit key size, where the key is stored in the safenet devices (a separate key storage appliance and retrieved by the instance).
Credentials can only be added by administrators and once they are entered – they cannot be viewed.
Encryption and decryption
Below is a schematic of the encryption and decryption mechanism of the credential table (discovery credentials) when a MID-server requests a credential.
Due to it all being handled over SSL man-in-the-middle (MITM) attacks are hard to execute regardless of where you tap in. Furthermore, you need access to both private keys for MID as well as ServiceNow to be able to decrypt the credentials. Impossible? No. Unlikely? Yes.
Luckily, there is additional security to be enabled within ServiceNow in order to do discovery. For Linux- & *NIX devices you can easily rely on SSH PSK rather than username- and password. ServiceNow need very few permissions with sudo, the rest of the permissions are only read. This also goes for network devices.
Regarding windows machines, it is correct that ServiceNow need local administration on all windows servers due to WMI mechanisms – until the release of London that is.
JEA – Just Enough Administration
Since 2014 (!) Microsoft have been developing JEA, also known as “Just enough administration”. This intricate protocol supplied by PowerShell above version 5.0 allows helpdesks, admins and 3rd party application to gain administrative rights without requiring full-blown admin accounts.
Based on temporary roles and privileges the methodology enables restricted access to specific features for specific users – somewhat similar to sudo in Linux.
When using JEA, a non-administrator “runs as” a privileged “Virtual Account.” The Virtual Account only lasts the duration of the remote session. That is to say, it is created when a user connects to the endpoint, and destroyed when the user ends the session.
By default, the Virtual Account is a member of the local administrators’ group. On a domain controller, it is also a member of Domain Administrators.
Now since London this feature is enabled to discover windows machines. This means WMI and Windows admin might not be necessary for certain subnets or IP-ranges.
Why not all, you might wonder? Unfortunately, it still comes with limitations:
- “Test credentials” won’t work with the JEA non-admin credential but Discovery does work. This is a known issue.
- It doesn’t populate installed software. This is a known issue.
- It only works for Windows 2016 and Windows 2012.
London version or higher (duh). The windows machine must be joined to a domain. The MID-server joined to the same domain. Powershell remoting must be enabled on target machine(s) as well as WinRM. Windows Management Framework version 5 or higher and finally the JEA credential must be a domain-level non-admin credential.
For the one who does not mind additional administration in favour of higher security, there is always the possibility to lock down credentials to only be valid in certain subnets.
Let’s say you have one set of credentials only working on “https://www.linkedin.com/redir/invalid-link-page?url=10%2e0%2e0%2e0%2F26” and a MID-server installed specifically for that subnet.
If an attacker theoretically would gain access to the credentials it would only be restricted to that particular IP-range (10.0.0.0 – “https://www.linkedin.com/redir/invalid-link-page?url=10%2e0%2e0%2e63”, 64 addresses).
Depending on the configuration of your network, an idea could be to isolate permissions on each VLAN / subnet like mentioned above. Meaning that you place a MID server in each VLAN and create a Windows account with access only to the servers in that VLAN.
Yes, you will need to create more accounts and MID-servers but at least it gets the security team on your side a bit more easily.
External credential stores
Finally, another option is to simply convince your stakeholders to start with privileged access management and utilize a solution such as CyberArk. You would then have a vault rather than credentials and ServiceNow would be generating session-specific access rights and kill them once the transaction is over.
Yes, it is more expensive and a project in itself to setup but if you are really serious about the security perhaps when implementing ITOM is a better opportunity than ever to expand upon additional solutions.
Summary and last words
As proved many times by the evidence, no credential store is bullet proof in this world and it will always be a sensitive topic.
Hopefully with this guide you can more easily take a decision around ServiceNow and ITOM when it comes to credentials. As a last resort in very sensitive subnets or critical machines, you can always use credential-less discovery which is working via NMAP and network traffic.
It is by far not as comprehensive as when providing credentials in terms of the data generated for the CI’s but at least it gives something.
With the new London release, JEA instead of domain admin, SSH PSK and good routines around the management of credential I personally would say that ServiceNow is equipped to deal with most cases by the built-in functionalities. Slap on an external credential store and you do have a fairly secure solution equipped for the future.
What is your opinion on the matter? I’d be delighted to receive comments and insights.