Overcome security challenges with ServiceNow CMDB population

Networks always start off small and simple, but over time they can become increasingly complex. You start with a small network consisting of a simple Virtual Local Area Network (VLAN) with broad connectivity. However, once your security team get involved and add DMZs, routers, firewalls, etc you will find it hard to keep track of the intricate web you have created to support your business network.

If you are using ServiceNow for your ITSM, then the logical solution is to bolt on ServiceNow’s Discovery & Mapping tools to populate your Configuration Management Database (CMBD). ServiceNow’s suite of products are best in class, but they also pose some challenges when it comes to setup and security.

It is important to fully understand the commitment your making if you decide to implement ServiceNow Discovery into your business, and whether it is possible to make the necessary compromises to your security, to fully benefit from this solution.

Getting Started with ServiceNow Discovery

So, you have ServiceNow and your CMDB is all set to be populated with your devices and service data. You now need to get your technical team on board to; support the setup, check network services are relaying accurate data and perform any customization required. You will also need to install a mid server with network access, so it can be used to discover devices and services in your network.

Mid Server Support

ServiceNow Discovery will require full access to your infrastructure to enable it to gather the necessary data to populate your CMDB.  This means mid servers will need to be able to traverse firewalls to find all your devices and services.  For some companies this can pose a problem, as they are reluctant to compromise security measures, to enable this to happen. If this is the case, you may consider using different protocols or unique settings for each domain, to get round this issue. However, this will result in fewer discoveries, eroding the value and increasing the complexity, that this solution will deliver to your business.

As your network grows you will inevitably need to adapt or build new servers, these will also need to be configured correctly, if they are to be discovered. To ensure your network remains secure you will need to build new servers within a firewall, but to give Discovery access you will need to use the ‘any to any’ setup for this zone, which could compromise security. Constantly creating new ports and re-configuring firewall rules can be time consuming, especially if servers are managed by different teams.

Alternatively, you could reduce the number of Server-Server firewall ports, by setting your network up as VLAN-VLAN (Virtual Local Area Network), this would reduce firewall requests for new servers, but also requires you to incorporate a mid server into every VLAN, which can crank up costs!

Credentials & Permissions

Unlocking permissions and sharing credentials are key to ServiceNow performing its process of vertical discovery. This is a key part of the ServiceNow Discovery process, as it uses this to develop a map of all your business services and CI's, from entry/starting point right down to the very last node. This data is especially useful during an outage, as you can track the impact down to a granular level.

This level of insight is where ServiceNow deliver its full value, however it will require you to give ServiceNow full access to your network. For example, if it discovers a SQL server (which are generally protected by higher security measures), it will need all the associated credentials and permissions, for it to continue to delve deeper into your SQL cluster and discover the corresponding databases. This means you will need to assign the ‘Public‘ Server Role to the account that runs the mid server in this environment. This can become a lengthy process, as every time ServiceNow hits a blocker, you will need to reconfigure your security settings, to unlock its path. This process of constant trouble shooting can take weeks, if not months! Plus, the challenges of vertical discovery will continue as your network grows, with the addition of new items needing to be discovered.

Security Solutions

Having such an open security system also means you need to trust the people who it, as it can leave you vulnerable to misuse of this information. But never fear there are some solutions you can implement to avoid malpractice:

·       Limit user access to ServiceNow and use MFA (Multi-factor Authentication).
·       Log all ServiceNow actions and limit user ability to perform commands.
·       Limit access to devices with highly sensitive data (however these will remain undiscovered).
·       Limit Discovery to a change window, so you are alerted to any action outside this window.

Once again, these protocols can become time consuming to setup and manage, as systems and users evolve. 

Simple Integration NOT Security Invasion

Here at Cookdown we develop solutions that integrate rather than discover; as this won’t compromise your network’s security! We don’t use network crawlers or port scanners, so there is no need for extra agents, new accounts, permissions or firewall access.  We simply synchronize System Center Operations Manager (SCOM) and ServiceNow to fast-track the population of your CMDB, enabling us to integrate Configuration Items (CIs) from existing systems, to quickly uncover the breadth and depth of your network.

The benefit of this approach is you won’t experience any of the security concerns you encounter with ServiceNow Discovery, our native integration makes the setup much simpler, so you can see results on day 1!  

To find out more about Cookdown Discovery, click here.

There are a number of other solutions available we will explore these in our next blog: Top Integration Tools, a comparison of solutions to populate your CMDB without security invasion - click here.

Previous
Previous

Top integration tools to populate your CMDB

Next
Next

Bringing override sprawl under control with PowerBI