Does your organization put Information Security CIs into the CMDB?

[jandre]

We're about to implement ServiceNow including CMDB.

Our Information Security group is concerned about putting Configuration Items & their attributes related to Security systems (firewalls, reverse proxies, identity & access management systems, etc.) into the CMDB.

They view doing so as "putting a blueprint to hack the company" into the cloud.

I'm curious how other organizations handle Security-related CIs & Attributes and whether you have restrictions on putting those CIs into the CMDB.

I see it as limiting our ITSM/ITIL capabilities but I'm trying to balance the fact that this team is trying to keep us secure.

Thanks for your input.

-Justin

[dmbrost1]

There are two potential issues they should address:

1. Does the Information Security group trust the ServiceNow platform for any sensitive data? If they consider their CI data sensitive and aren't comfortable with it in ServiceNow then this should precipitate and/or reference a full enterprise understanding of the confidentiality terms & conditions with ServiceNow. It's possible there is even more sensitive information in your instances than the security platform CI data. They likely will want to comprehensively address this fact.

2. What are the groups, roles, and permissions (i.e. ACLs) required to view or edit sensitive CI data? Again, this may not be limited to just Information Security assets, so they may want to comprehensively review this fact as well. If they identify the classification parameters for sensitive data in ServiceNow, then they can establish secure, effective handling policies, procedures, and guidelines.

I encourage your security group to become much more familiar with the platform, the service agreement, and the current business use cases for ServiceNow where security is concerned. Additionally, it's an extremely powerful platform for Information Security to leverage, so I would encourage them to consider that the benefits of using not only the CMDB, but incidents, problems, knowledge, contracts, BSM, etc. You may also point out there is an entire ITGRC module available which could greatly assist their compliance and risk management endeavors.

[prdelong]

InfoSec teams, in my experience, have usually been much more leery about allowing access to those assets for Discovery tools than the actual information in the CMDB itself. It would be fairly simple to create a set of ACLs to disallow most users from seeing those particular attributes and possibly adding a custom role to let them manage and add those particular CIs. I've done this many times before for financial data on CI records.

In terms of a blueprint to hack the company, I think that's a bit of a stretch. Information security is at its best when it is multi-tiered, but if someone is in a position to view these particular records, it means they at least have direct access to SN, if not the entire network. They don't really need to worry about the information being *in* the system, rather that the information is secured to their satisfaction.

[kiranbahl27]

hi Jandre

What route did your company end up going. We are implementing Security Response and Vulnerability with Tenable. Any helpful hints, lesson learns, where to start. If youur ok can you please share you project plan - Thank you so much in advance