Blockchain-enabled self-sovereign identity (SSI) facilitates and secures all IT service management (ITSM) processes by providing assured, trusted identity and credentials for all configuration items (CIs) throughout their entire lifecycle. With SSI, every ITSM-applicable entity — every participating organization, person, and managed CI (network device, software instance, and others) — can be identified, identifiable, credentialed and PK-enabled (PKE).

Although typically associated with organization and people entities, SSI provides scalability and cost effectiveness to extend the capabilities and benefits of trusted identity to non-person entities (NPE) — all managed IT resources and their associated ITSM processes. CIs with immutable digital identity are able to cryptographically mutually authenticate other entities; communicate securely and privately; and issue, hold and verify credentials asserting identity, capabilities, authorized configuration and authorized behavior. They can achieve all of this without the cost, security vulnerabilities, complexity and operational friction of traditional PKI-based identity.

Transform digital identity into trusted identity with blockchain

The problem: Lack of digital identity for CIs

Typically, only a fraction of managed IT resources has a cryptographically-based digital identity. Web servers, email servers, and other networked devices may be issued self-signed or third-party certification authority (CA) signed certificates to enable SSL. But this it is typically only used to establish the secure network connection — the hosted software application instances themselves typically don’t have a digital identity and aren’t PKE at the application layer. Hardware devices have manufacturer-issued serial numbers and media access-controlled addresses that can be used for identification typically for inventory purposes. And CIs of all types may be assigned a unique identifier by a configuration management tool. But other than CA-issued certificates, these other forms of identity aren’t cryptographically bound to their on-line digital presence and useful for authenticating, authorizing and transacting digital interactions between entities.

And any digital identity without associated secure key management processes and capabilities, itself causes security vulnerabilities. SSH, the workhorse of IT management, is notorious as a security backdoor due to the unmanaged proliferation, replication and sharing of static, self-generated private keys.

ITSM discovery tools contribute to security vulnerabilities by proliferating and leaving vulnerable the secrets (administrative and root user IDs, passwords, and private keys) required to connect to and command remote servers for discovering their configuration information. The security vulnerabilities of the tooling itself and associated technical and bureaucratic challenges often delay or prevent obtaining the required permissions to open firewall ports and to connect to hosts to perform effective and complete discovery — leaving potential security vulnerabilities undiscoverable.

Even when discoverable, the absence of comprehensive, assured, trusted digital identity for deployed CIs is a source of security and management problems particularly with regard to software asset and configuration management. Accurate software inventories deployed on managed devices are critical for licensing compliance, configuration compliance and software planning. But software asset discovery, identification and contextualization all rely on accurately identifying units of deployed software. That is, understanding the exact set of executable files, data files, configuration files, library files and others, that together comprise a specific software product, version and patch. Accurate software asset and configuration management remains difficult despite the creation of software identification standard specifications and guidance — ISO/IEC 19770-2:2015 and NISTIR 8060.

The blockchain-enabled SSI solution

The recent advent of distributed ledger technology (DLT) known as blockchain, however, has now made possible a means of immutably binding an entity to its digital representation at scale — securely and cost effectively via a shared ledger. This ledger-based identity binding is called self-sovereign identity because no third-party certification authorities are required to certify, issue and bind entities to their immutable digital identity. Instead, a steward or facilitator registers decentralized IDs (DIDs) for known entities on a permissioned identity network ledger. Then the registered entity’s software agent uses its secure digital wallet to generate its private/public key pair and submit the public key, as well as other publicly available metadata — known as the DID Document — as a proposed transaction to the ledger keyed to its DID. The entity’s private key never leaves its secure digital wallet. The DLT then uses its built-in consensus mechanism to validate, order, distribute and immutably write the new block of information (DID and DID Document) on all network ledger nodes.

These identities live on the distributed ledger network — not tied to any specific system or account. For non-person entities (NPEs) like CI’s, a guardian itself possessing a registered DID, is responsible for and acts on behalf of each NPE to register their DID and associated public key and other publicly accessible DID Document metadata.

As illustrated in the above figure, any entity with a digital identity (DID and DID Document) may now apply the W3C verifiable claims data model to issue, hold and verify digital credentials for ITSM purposes using their private and public keys. Digital credentials could be used to secure and facilitate every ITSM process by asserting identity, capabilities, authorized configuration and authorized behavior for every CI.

For software asset entities, cryptographically signed credentials could be issued by IT operations personnel and ITSM applications throughout their lifecycles. As described in NISTIR 8060, primary and patch credentials could be issued for initial software installation and follow-on patching. Supplemental tags could be issued for any other purpose — such as for issuing security accreditation credentials by the designated approval authority.

Discovery tooling could leverage these identities and credentials for more secure and accurate discovery. Discovery tooling clients and the remote servers to which they connect could mutually authenticate at the application-layer using their DIDs, on-ledger public keys and wallet-held private keys and establish secure private communication channels to securely exchange credentials and retrieve scan information. Using its digital wallet, a Discovery client would present its credential authorizing it to perform discovery scans on designated network segment host entities (DIDs). The remote server would verify the credential, authorize the scan, and potentially present its own credentials of authorized configuration including the DIDs of the software entities it is authorized to host.

The Discovery tool client would then look up the authorized configuration credentials for each of these software entity DIDs and compare to the configuration it has just discovered itself.  The Discovery tool client could issue supplemental credentials documenting its findings and generate signed events for the fault management tool software entity.

The value to you

Blockchain-enabled self-sovereign identity can facilitate and secure all your IT service management (ITSM) processes by providing assured, trusted identity and credentials for all configuration items (CIs) throughout their entire lifecycle.

CIs with immutable identity independent of any system or account can be PKE to mutually authenticate other entities; communicate securely and privately; and issue, hold, and verify credentials asserting identity, capabilities, authorized configuration and authorized behavior. They can achieve all of this without the cost, security vulnerabilities, complexity and operational friction of traditional PKI-based identity.

The benefits of a DLT-based identity network extend to business network blockchains as well. The identity network can be used to provide a permissioned business network ledger such as The Linux Foundation’s Hyperledger Fabric (HLF) with a trusted identity service other than traditional x509 PKI. Also, the identities of the assets themselves being transacted on the HLF can be their DIDs thus providing an identity independent of any particular business network. And verifiable credentials issued to and held by each asset in their digital wallet or in secure credential repositories can be used to keep sensitive information off-ledger, simplifying the design of the ledger itself, and minimizing its storage requirements.

Explore more about how blockchain can be deployed as your ITSM identity solution through the IBM Developer Blockchain hub. I look forward to more great conversations on the advantages of blockchain as an ITSM identity solution.

Start developing your blockchain with the open source Hyperledger Fabric