Trust Mapping

[mdoherty-axiom]

When attempting to use D3FEND to model Axiom’s NullTrust Technologies (NTT) zero-trust authentication and encryption solution a key concept could not be found – the “who” aspect of defensive techniques and digital artifacts.

Although there is an Agent entity that has subclasses like organization, person, and vendor, we need a way to represent the trust involved in the relationships [developing, verifying, etc.] between digital artifacts and countermeasures. We need to associate the Digital Artifacts that enable D3fend techniques showing how trusted Actors can effect the security of the system. Furthermore, these relationships need to be well-defined to support quantifiable analysis.

In addition, if some software is performing verification on another, for example, we then need to be able to illustrate how this verification itself occurs, who developed or controls the verification process, and whether that software is used by multiple subsystems.

We ultimately need to be able to map the chains of trust that are created by different software/hardware components, illustrate who owns/develops/reviews them, and model multiple chains of trust. Showing independence of chains of trust builds confidence that single actors or artifacts can’t individually effect system security (C, I, A).

In addition to being able to use D3FEND as a trust mapping tool we believe trust mapping itself is a technique currently used in industry. Examples of trust mappings include supply-chain risk management (SCRM), third-party code reviews, CI/CD pipeline permissions, and third-party verification of identity in PKI infrastructure.

We believe there are 2 main changes needed for D3FEND to fully incorporate trust mapping. The first is to add generalized defensive techniques and the second is to add the relationships between techniques, digital artifacts, and actors necessary to model trust in system architectures.

The Diagram below shows 4 Application Instances each with a unique chain of trust. Each To help understand the above consider the picture below showing multiple colored trust domains and how separation mapped into multiple chains. Chains are showed by trust domain (Blue, Green, ...) below each Application Instance. Each Trust Domain in the list can compromise the security of the system. The complexity of compromising an Application Instance with Multi-Chain Trust is represented in the lower two diagrams. Domains represented with + (e.g. Blue+Purple) represents a chain where both Domains must be compromised to compromise the Application Instance.

See axiomsecure.com for details on how we use trust mapping to create systems with multiple chains of trust for authentication and encryption, creating data security solutions with no single point of failure from common compromises including zero-days, insider threats, or misconfiguration.