They can also audit policies that enable information of different classifications and access categories to be stored, accessed, and processed on shared storage, compute, and networking infrastructure while simultaneously assuring the data and other resource objects are only accessed by authorized subjects.

Trusted security labels reduce infrastructure costs, promote assured information sharing, and provide a means to comply with ever-expanding data privacy and security rules and regulations.

Learn more about blockchain today

The problem: Shared infrastructure and unlabeled data elevates security risk exposure

As businesses look to cut costs and increase efficiencies by migrating their applications to the cloud, digitizing their operations, making data-driven analytics-based decisions, and monetizing their data, they increase their security risk exposure by:

• Multi-tenant cloud infrastructures that share compute, storage, and networking resources amongst multiple different organizations
• Multiple incompatible classifications of data collected, processed, stored, and accessed. Different classifications such as personally identifiable information (PII), public, sensitive, confidential, proprietary and others, require different storage, handling, audit and access controls.
• Proliferation of data protection controls, audit requirements and non-compliance penalties
• Expanding digital business networks — partnering with organizations and service-providers of unknown or uncertain security risks. Can they be trusted to protect your shared data?

Historically, the government and other risk conscious industries that generate and handle highly classified and sensitive data, have relied on secure computing platforms and multi-level security (MLS) systems to facilitate secure sharing of data. A foundational security control for MLS is OS-level mandatory access control (MAC) that enforces security access policies using security labels applied to all system resources and users.

By comparing the security label of the accessing subject to the accessed object, the OS either allows or denies access. Using MAC and other MLS-specific security controls, data of different classifications and access categories can be co-located on the same storage, compute, and network infrastructure yet subjects are only able to see and access appropriately labeled objects. All object accesses are logged and auditable.

But MLS is complex and difficult to implement and maintain for a number of reasons including:

• Modern systems are large and complex. The number of objects and subjects and their potential interaction combinations makes it difficult to create and maintain labels and policies using traditional OS-provided utilities. Technical documentation recommends minimizing the number of categories and labels for performance reasons.
• Modern systems are networked — they don’t work in isolation. They need to work with subjects and objects located remotely. But availability and trustworthiness of external entities and externally supplied labels is suspect.
• A high degree of reliance and responsibility on the system security administrator who is operating all these utilities and defining these labels and policies. Lack of oversight and governance to ensure labels and rules are correct and properly applied and maintained.
• Policies and labels are simplistic, and rule based. For example, security labels for IBM Z Systems are limited to the association of a hierarchical security level, and zero or more non-hierarchical associated categories. The labels are just system-level attributes — no source attribution or digital signature.

The blockchain-enabled trusted security labeling solution

A blockchain-based self-sovereign identity (SSI) network in conjunction with W3C verifiable credentials would provide an open, governable, system-independent means of issuing, holding, presenting, and verifying trusted security labels for any entity at scale — person or non-person. These blockchain-based security labels may be used by both MLS and non-MLS systems as a trusted basis for access control and authorization decisions to reduce risk exposure.

A blockchain distributed identity ledger binds digital identities of all person and non-person entities (NPEs) to their private/public key pairs and distributes them throughout the identity network without the use of third-party certificate authorities. Digitally signed, verifiable credentials asserting security attributes such as clearance, classification, role, categories and others, can then be issued by an authoritative source entity to a known entity using their digital identity and key pair. Using its own digital identity, a holding entity countersigns the issued credential and maintains it in their digital wallet or other credential repository. The holding entity presents its credentials to verifiers, such as an MLS system or some other identity and access enforcement point.

Prior to authorizing access to a system object, a policy enforcement point such as an MLS system, uses its own digital identity to request security credentials from both the subject and object, validates the digital signatures, and then applies and enforces its security policy. For performance reasons, these credentials may be cached and/or used to populate traditional MLS system security label attributes.

The above figure illustrates a simple example. An MLS stores both classified and unclassified files.

1. Security label for the file in the MLS is populated using signed credentials asserting the file is unclassified. The label takes the form of a W3C verifiable credential.
2. Bill requests access to the file. He includes his DID and a signed nonce in his request.
3. The MLS OS Agent accesses the identity network and using Bill’s DID as the key, looks up Bill’s public key, service endpoints, and other publicly identifying metadata in Bill’s DID document on the identity network blockchain, and authenticates the signed nonce.
4. The MLS OS Agent using the appropriate DID document-identified service endpoint for Bill, looks up Bill’s clearance keyed to his DID. Bill’s clearance is provided in the form of a W3C verifiable credential issued by a trusted clearance authority.
5. The MLS OS Agent, using the issuing clearance authority’s own DID-keyed public key on the identity network blockchain, authenticates the clearance authority’s signature.
6. The MLS OS Agent checks the security label of the requested file.
7. The MLS OS Agent compares Bill’s clearance (TS) to the file’s classification (Unclass) and grants access and recording all pertinent details (including subject and object DIDs) for auditability.

The value to you

Blockchain-based digital identities in conjunction with W3C verifiable credentials provides portable, trusted security labels that will lower security risk and enhance data share-ability.

Collapse IT infrastructure and costs. Trusted security labels, in the form of digitally signed verifiable credentials, can be used by MLS systems to collapse IT infrastructure — eliminating the need to segregate information of different classification on different infrastructure. MLS systems with trusted security labels can make multi-tenant cloud infrastructures more trustworthy by keeping customer data co-located but separate. Trusted security labels can be used with database systems to provide MLS databases. Trusted security labels make widespread MLS viable by providing govern-ability, portability, and visibility to traditional security labels.

Secure data access. Trusted security labels can be used by any access control policy enforcement point, not just MLS, to make more assured, defendable and granular access decisions.

• Facilitate cross domain information transfers. Use trusted security labels at High Assurance Controlled Interfaces or guards to enforce cross-domain policies.
• Public-key enable all your applications and implement application-layer MAC to comply with privacy and data security rules and regulations.

Facilitate data sharing and re-use. Verifiable credentials can be issued for any purpose — not just security. Label your data assets with metadata to facilitate discovery for analytics — accuracy, usage restrictions and others.

Explore more about how blockchain can be deployed as your trusted security labeling solution through the IBM Developer blockchain hub. I look forward to more great conversations on the advantages of blockchain as a trusted security labeling solution.

Learn how industries are revolutionizing business with IBM Blockchain