Trust
CSAP (the Common Security Architecture for Production) is a Zero Trust architecture but to understand zero-trust, we must first have a common understanding of what “trust” means. OK, so if we take the phrase “zero-trust” and stop there, we don’t need to understand what trust means because we don’t even have it – but that approach doesn’t get us anywhere. “Zero-trust security” means not trusting anything until it has been verified as something trustable and that seems like a better place to start.
Mayer, Davis, and Schoorman (1995) define trust as “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other party will perform a particular action important to the trustor, irrespective of the ability to monitor or control that other party.” This is an excellent definition for our purposes because it hints at the consequences of trusting something that is not trustworthy.
In a debate on a security forum recently, one contributor was claiming that zero-trust is a paradox. The argument being you can’t know with absolute certainty that you can trust something. That’s true but then again, quantum mechanics says you can’t know with absolute certainty what state matter is in, but we don’t need to let either get in our way, unless we are planning to feed Schrödinger’s cat.
Building Trust Relationships
To trust something, we need a trust relationship. There are two factors in creating a trust relationship.
- Determining whether something can be trusted
- Determining whether something claiming to be a trusted entity is indeed that entity and not an impostor
The first of these is a decision, and decision may not be the right word because ideally it should be reassessed continuously, based on factors that vary from one person to another, from one organization to another, from one situation to another, and it all comes down to risk assessment. As in Meyer, et al., the definition of trust is in the eye of the beholder.
Whether formally or unconsciously, risk assessment happens all the time. A threshold is set, factors evaluated, and a decision is made whether it’s above or below the threshold. That doesn’t mean it has to be done with a spreadsheet — we do it in the first second when we meet someone for the first time and whenever we get in our cars, we are subconsciously making a risk assessments like “it was fine last time I drove it.”
Determining whether an entity can be trusted is outside of the scope of CSAP, but the determination must be made. In cybersecurity, we need to be more formal. We decide to trust a server because of its endpoint security and the knowledge that all CVEs have been patched. We do that regardless of the security model.
The second of the two factors is the fundamental role of identity management. It is the thing that makes zero-trust work, and zero-trust means eschewing implicit trust. For example, implicit trust means trusting a device because of the network port or the VPN it is connected through. Explicit trust means not trusting a trusted user’s device unless it has been authenticated as the trusted device it purports to be.
Since trust is central to any zero-trust architecture, including CSAP, robust identity management is a prerequisite.
Trust and Authorization
If I say I trust you, I probably don’t mean I trust you to do everything. I might trust a cardiac surgeon to perform heart surgery (and would want to before they picked up a scalpel in my vicinity), but that doesn’t mean I’m going to trust them to do brain surgery on me. Trust has boundaries.
A trust boundary
In CSAP, trust boundaries are set by authorization. I verify you are the cardiac surgeon you claim to be (authentication) and I’m going to let you do my heart surgery (authorization). Brain surgery falls under deny by default.
So, we now have three factors:
- Determining whether something can be trusted
- Determining whether something claiming to be a trusted entity is indeed that entity and not an impostor
- Determining whether the trusted entity is permitted to do what it’s just asked to do.
In CSAP terms, the first factor is part of the determination of whether something is to be included in workflows. Can a user contribute something to the workflow and have references been checked before they were hired?
When it comes to systems, it is the role of the same security tools we use today. For example, endpoint security is installed on a server, have all relevant CVEs been patched, etc.
The second factor is the role of the CSAP authentication service which uses some combination of identity management and certificate authorities.
The third factor is the role of the CSAP authorization service. Here, the question that must be answered is: how does the authorization service know what to authorize? After all, CSAP is deny-by-default and nothing useful is going to get done unless something is authorized. CSAP supports a wide range of options. At its simplest, authorization is created manually, isn’t very granular and lasts for a long time.
But CSAP is workflow-driven security, and its authorization rules can be created in response to requests from the workflow management. After all, what thing better knows what should be authorized in a part of the workflow than the entity that is determining what should be done in that part of the workflow? CSAP’s authorization rules can be as granular and specific as is required and can be supported by the implementation of workflow management and CSAP components. Trust me.
