IT Service Management (ITSM) needs reliable and current data, be it for service monitoring, IT documentation or help desk systems. Therefore a reliable current network discovery with very good-quality is absolutely necessary. Like monitoring systems, a network discovery system needs privileged access to the monitored systems in the environment to fulfill its important function.

Agent-less Discovery

Agent-less discovery solutions have the advantage, that no permanently installed agents are needed to perform their work on the system. A central system access, in this case, accesses the systems and collects discovery information about their current state only when needed. This saves the whole effort for installation, update and configuration of remote agents and the security hardening required for their IT security.
Thereby no functionality for the remote discovery is lost, if the discovery system is able to query and discover a large amount of remote systems in a short time to get up-to-date information.

From the perspective of enterprise IT security agent-based systems with discovery agents installed on each system to be discovered, offer a much larger attack surface. A surface that potential attackers can use from outside and inside the company. The hardeing of the agent installation, that usually even run with privileged accounts, to be able to access resources locally, is not a trivial undertaking, especially in a very heterogenious IT landscape with different operating systems and vendors. Therefore an agent-less discovery is already a big progress in the area of IT security. These need though also a short-term privileged access to the system in order to login, make queries to resources and then report the results back to the central discovery server before they retract from the system without a trace.
In this short moment also an agent-less system requires a privileged account with passwords, certificates, SSH-key, API-keys or other credentials. In the best case these are of course stored in encrypted and secured form on the central discovery server for use in discovery jobs.
Furthermore in discovery jobs of a system there is of course a good transport security necessary in addition to a secure authentication in order to secure the credentials on their way over the network.

Credentials are not only stored on one discovery server but potentially also on multiple other server, that cover different parts of the enterprise network, like enterprise IT, networks in branch offices, public or private cloud environments or DMZs. At the same time, not only discovery systems need these credentials but also monitoring systems and other distributed IT management systems in the enterprise. So secrets and key material gets distributed, spread over the whole network potentially.

This fact is of course a big concern for the IT security department of companies, rightly so as it is difficult to maintain the security posture of the whole company, which is the job of the IT security department, in this scenario.
Therefore a company is facing a dilemma. Either collecting management data of good quality, necessary for an effective IT management and compromise the security posture in total or guarantee maximum security but abstain from gaining insights in the enterprise IT.
There should be a solution for such a dilemma, given modern IT technology and architecture, or?
The answer luckily is: of course! But first the individual IT management systems and the organization as a whole need to accept the problem and take it serious.

Central Credential Management

So how does a solution look like?
Centralize the credentials and distribute the access to these instead of distrbuting the credentials themselves. It is much easier to secure the access to a central credential storage thanks to state-of-the-art transport security using TLS (e.g. HTTPS) or modern secure authentication and authorization.
Of largest significance is therefore the introduction of a central credentials management, those core it is to maintain credentials in vaults and password stores. Such a centralization brings advantages and disadvantages with it. Disadvantages are, that such a system needs to be highly available and highly security hardened to withstand effectively any attacks that will of course be more likely as such a system is a highly valuable target.
On the other hand many other systems like discovery and other IT management systems are released from some of their attack surface, which are much harder to secure on the same level as such a specialized credential management system. The vendor of a high security system can certainly do this much better than the many specialized vendors of the IT management products, whose focus is not security.

At last, the IT management systems need also support such a central credential management system and unfortunately there are, in contrast to areas like authentication (e.g. SAML or OAuth2/OIDC), not well established standard on which one could rely. Instead there are many proprietay vendor-specific systems that need to be integrated one-by-one.
Due to the missing standards, the most IT management systems do, as of today, not support central credential management. JDisc discovery has now added this support for the most important credential management systems requested by customer and is therefore a bright exception.

So far JDisc Discovery, as an agent-less network discovery system, did store its credentials well encrypted in its database on the discovery server, where the administrator maintains the credentials in the discovery configuration more or less manually.
As in larger organizations multiple discovery servers are operated in different environments like central IT, branch offices, cloud environments, DMZ and more. There is exactly the disadvantage of spreading credentials over the network because each server needs these credentials for its own environment in order to run the discovery jobs. Credentials are of course well encrypted and stored but nevertheless security can be further improved. This works by centralizing the credential storage centrally and let the discovery server only retrieve the credentials from the central credential management when a discovery job needs to be executed over a secured connection.

Credential Manager Integrations

This is done by several new integrations with the most well-known credential management systems used by customers:

• Cyberark Credential Provider
• Thycotic SecretServer
• Microsoft LAPS (Local Administrator Password Solution)

The setup of the integration with these systems follows the shared sequence of steps:

• Setup of the password stores in the central credential management system with users and their credentials
• Configuration of the client application, in this case the JDisc Discovery Server in the credential manager
  For security reasons we should setup one client per application and not re-use this access
• Thereby a client certificate is uploaded with a unique serial number as identifier for the certificate
• Authorization of the application on the password store with minimal rights, taking into consideration the security principle of “least privilege”, which means only require those rights that are really needed by the client application, e.g. read rights.
• On the other side of the discovery server we need to make the credential manager known as password manager. What needs to be configured depends on the integration but usually is a URL, server and port, username, password for the authentication as well as a client certificate that needs to be uploaded. Plus the connection can be tested before use.
• Now we can configure to use the password manager instead of storing the credential such as a password or SSH-key or certificate for the access on a resource that should be discovered.
  Therefore we need to select a password manager, a store and corresponding account for which we want to use the credentials.

Now, when a discovery job is run, the discovery server is requesting the credential of the account over a certificate-secured connection from the credential provider and uses this credential for the access to the resource. The credential in this case is not stored and only exists for a short time in memory and during transport from the credential provider as well as on the way to the system to be discovered the channel is secured by transport security (TLS e.g. HTTPS).
This way the attack surface of the agent-less discovery is further reduced without limiting the functionality in any way.

It remains to remark that the credential manager Microsoft LAPS does work a bit different. Here the discovery server accesses the credentials of local administrative account via LDAP (Lightweight Directory Access Protocol), instead of solution-specific REST interfaces, as with the other providers.

The central management of credentials in a secured network zone in a specially secured application and password valuts helps to exploit the adantages of a centralization of credential management.
This allows to implement advanced further security measure without negative influence on the complete environment. Examples are the central change of passwords, disable and remove accounts of users that leave the company centrally and company-wide with one click. And this not only in active directory or LDAP servers but also now in all IT management solutions in the environment. This is a new level of improving the companies security posture.

These central security measures allow the IT security department better and more control of security in the company network and the realization of more flexible security policies without getting corresponding disadvantages by increased efforts in change management in other IT systems.

Further information can also be found in a YouTube video on the topic

https://youtu.be/TLpdxfSqrlo