Storing Password in CMDB

[Sam Ogden]

Hi All,

We are in the process of setting up and configuring our CMDB within SN.   One of the teams have asked if there is the functionality of storing usernames and passwords within the CMDB i.e. for particular servers.   If this is possible what issues are there around security.

We would only want that particular team to have access to read the information.

Does anyone know if this is possible or if it should be avoided?

Thanks in Advance

[Dave Smith1 · Accepted solution]

Yes, there is functionality.   Yes, it should be avoided.

What you possibly want to do is store these credentials on one of your local servers (as a Java properties file), then let your instance know the path to this file - known as External Credentials.

This is a topic covered on our Discovery course: ServiceNow Discovery Training - but if you want to have a go at it yourself, take a look here: https://docs.servicenow.com/search?q=External+Credential+Storage&labels=2&labels=3  

Alternatively, consider an external credential management system like CyberArk.

Lastly, just a warning:

Sam Ogden wrote:
We are in the process of setting up and configuring our CMDB within SN. 

Note that ITIL recommends scoping the project - simply the planning side - for Configuration Management and the CMDB can take anything from 3-9 months.   It's not simply a case of designing and building a CMDB - the database is of no value whatsoever unless there are management processes in place.

People often make the mistake of believing the product is the finished deliverable - and overlook any processes, i.e.: they focus on WHAT to do, but not HOW it will be used, nor by WHOM and WHY.

[Sam Ogden]

Hi Dave,

Hope you are well - Our Sys Admin course seems a distant memory now!

Thanks for your input on this.   My gut feeling was the same on this that it probably would be possible but more than likely should be avoided, but just wanted to check with the general consensus on this.

In regards to the overall CMDB implementation, and the WHOM and WHY questions.   We are constantly asking these as we go through the process to make sure the system will be useable and fit for purpose.

Thanks once again

[Dave Smith1]

Hope you are well - Our Sys Admin course seems a distant memory now!

I'm grand, thanks! Yeah, so much has happened since...

Thanks for your input on this. My gut feeling was the same on this that it probably would be possible but more than likely should be avoided, but just wanted to check with the general consensus on this.

Trust the gut. If instinct tells you something feels wrong, there's a good chance it is - it's just a matter of determining what and trying to explain what's odd about it. But the gut feeling certainly pointed you in the right direction.

From a security perspective, raise questions about "what's the worst that can happen, and how would it occur?" -   then looking for ways to prevent the occurrence (either with more stringent controls or simply seeking a different approach) is your first step towards reducing risk and tightening security.

And sometimes it's not actually about security, but about the perception of control.   Many customers feel safer having credentials stored locally than in the cloud, where they are responsible for safeguarding. It's not quite the same as keeping money under the bed because you don't trust banks, but there could actually be some regulatory compliance preventing organisational credentials from being stored off-site: that may be worthwhile checking.

In regards to the overall CMDB implementation, and the WHOM and WHY questions. We are constantly asking these as we go through the process to make sure the system will be useable and fit for purpose.

Good stuff!   You may recall from my sysadmin (and I do the same on Discovery also) about how the process of Config Mgt is heavily underestimated in many organisations, and yet so much rides on it - can you remember "PICSV"...?

During Discovery courses, this topic always arises towards the end... engineers performing Discovery are happy with data collection and population but there's no policy on outdated CIs, orphaned CIs, etc - they realise they need to begin asking some difficult questions so they have prepared responses when discrepancies are found between the CMDB and the live infrastructure.

Good luck with it all!

[patricklatella]

Hi Dave,

thanks very much for your feedback on this topic.  I also have a client that wants to store password information in their CMDB records.  You are saying this a bad idea always, correct?  Even though the data is secured from the outside, you're saying the risk lies with the data being accessible from within the instance, correct?  And it sounds like you're saying, no matter what, don't store password info in SN, correct?