Trust has been important in computing systems since the first business practices were put into place. Modern double entry accounting was invented in Genoa, Italy in 1340 as an error-detection mechanism. Chinese seals, also known as chops, from 300 BCE were an early technical mechanism to codify and confer trust among business actors. Seeing the red square seal of a business associate meant that you could trust a document’s veracity.
Today’s IT systems also capture trust relationships explicitly, from authentication and role information in LDAP to multi-tiered privileged access management systems. At Conjur we’ve observed our DevOps-heavy users manage trust as a first-class construct. In particular, trust needs to be applied system-wide, validated continuously, and reasoned about definitively. We’ve begun to develop a management language for that purpose — we call it a “trust-forward design”.
In our whitepaper Towards a Trust-Forward Design, we discuss a number of uses across which a trust-forward system can be implemented, from handling small tactical use cases to the underlying components of a trust-forward design.
Take for example the sharing of database passwords from enterprise systems to a temporary public cloud infrastructure. That involves a temporary granting of authority. The ability to audit that transfer of trust and being assured that the grant is automatically revoked when the job is complete is a real-life example of a trust-forward design goal. A mechanised, regular rotation of system passwords or keys is another case of the need for trust-forward design.
Motivations: DevOps, Cloud, APIs
Authentication and authorization have been part of computer systems since the first time-sharing machines. Those techniques like LDAP and RBAC are a good base to start from, but what makes them less capable to handle the needs of trust today? DevOps, cloud network as-a-service offerings, broader data and API integration, autonomous capabilities, and shorter development cycles are driving the need for new trust features in architectures.
DevOps’ strength comes from heavy use of automation to reduce friction in deployment. That automation puts stress on authentication and authorization systems that were not designed for it. A continuous integration process may run many times a day, deploying an application into testing or even production without further human intervention. Similarly, PaaS (platform as a service) enables a development team to instantiate a new application or a new version of an application with a few keystrokes, compressing a multi-step effort into a single-click. As such development cycles are shortened. Manual authorization steps are too slow to keep pace with a system that reacts to changes on the order of hundreds or tens of milliseconds. An advanced trust-forward system is designed to handle detailed delegation of authority to automatic processes.
Cloud network-based “as-a-service” companies have proliferated on the public internet exposing APIs for previously internally managed functions like telephony, payment processing, big data, security scanning, among many, many others. Even internal centrally managed as-a-service functions must document and audit trust for their users who are departmental light-years away. While cryptographic techniques are available for some protection of data at rest or in transit, ultimately data and processes must be uncloaked to be operated on.* A high degree of trust is needed to reap the benefits of these offerings. A trust-forward system helps to make these trust relationships explicit.
Further, modern applications’ value is often in integrating large, previously separate databases and APIs. The breadth of data sources and endpoints ultimately means better experiences for end users. For example, one can book an entire travel schedule from a single interface. With that integration power also comes a need for trust in sharing a potential itinerary or traveler profile. Access to disparate data and APIs crosses silo’d domains. A trust-forward system can get a handle on what is authorized and what happened in the past across a large number of identities.
Autonomous capabilities in the network as with DevOps (not to mention in physical space with mobile devices and IoT sensors) will need better security and trust relationship management at a very large scale and speed. And pace with new architectures like serverless or FaaS computing is accelerating. While initial needs may be small, starting a trust-forward project means that the complexity of future projects’ trust requirements can be considered.
In Towards a Trust-Forward Design, we start with the domain of secrets management, which is a prototype trust-forward system. We discuss business motivations from tactical to strategic, and close with an outline of what constitutes a trust-forward system and some optional capabilities. This is an initial declaration and we invite you to join us in elevating trust as a computable notion.
Please take a moment to download our free whitepaper.
*Until researchers deliver practical homomorphic cryptography, the ability to operate on encrypted data without decryption, that is.