CMDB Security

[Jon Miller1]

Does anybody have any thoughts, recommendations or experiences on restricting access to the CMDB? Because out-of-box, access is very open, our Information Security group has concerns that if a bad actor compromises a company account with access to ServiceNow (which is basically everybody), they will easily be able to see all of our servers with OS, version, etc. and use that information to gain access to servers with unresolved vulnerabilities.

Has anybody done anything to reduce that risk? Has anybody spoken with ServiceNow and gotten their recommendations? Or does anybody have a good response to that IS argument?

[Mike_R]

There's no great answer to this but all I would say is your company should have some controls in place to mitigate these types of risks and not just for ServiceNow. Do you require MFA to log into ServiceNow? Is your instance only available through your VPN? Does your security team have tools to monitor unusual network activities/detect comprised accounts and automatically lock those accounts?

I would also ask them how are they are handling other systems? If a bad actor compromises a company account, how are they preventing that user from accessing and sending emails, hr/payroll systems, intranet, etc.

As far as the CMDB in particular you can easily modify the ACLs on the server/other tables if they are adamant that only certain users should have read access.

[Jon Miller1]

Thanks Mike. This validates are thoughts. We do only allow access to ServiceNow from company IP addresses and do have SIEM tools to monitor network and application activity.

[Ian Ma]

Every conversation around this eventually come down to two complaints:

1. SN being a cloud provider is vulnerable to external threats
2. Centralized information is easy to access for attacker.

• For point 1, look into IP address access control to restrict access to instance from external networks. i.e. restrict it to known organization domains.https://docs.servicenow.com/bundle/tokyo-platform-security/page/administer/login/task/t_AccessContro...
• For point 2, IMO it's a silly argument. You can't have an IT ticketing system without storing infrastructure information.
• Is it really that far a jump for a dedicated attacker to scrape your incident records vs accessing CMDB?
• Personally I would recommend AGAINST any actions to update ACL, it makes no sense to change a core aspect of system to fit one requirement from security, not to mention the maintenance and various other process implementation you would need to put in place.
• I think the most likely approach is understand how your organization manages cloud security and align SN towards it. 
• If there are certain critical systems with absolute sensitive data. i.e. database that stores customer medical info. One thing I've seen people do is simply not store such info in CMDB, instead store the service name or some sort of internal label for the application, the support team then logs on to internal systems to view required information. 

[Jon Miller1]

Thanks Ian. This validates our own thinking. We do limit access by IP address already and agree with your recommendation to NOT start messing with ACLs. My experience with that is that it starts off all well and good but at some point it will break standard, desired capabilities. We consider internal (disgruntled employee) attacks just as likely as external attacks and the think of IS is to restrict that internal access to the "minimum required". I'm not convinced by that argument.