By Richard Esplin, Head of Product at Dock Labs
The Way We Have Always Done I.T.
Identity and access management (IAM) systems hold sensitive data that is critical for our organizations to function. These systems are juicy targets for hackers who can make a profit from selling the data or holding it hostage.
The traditional approach to securing these systems is to host them in fortified castles surrounded by walls of authentication and moats of firewalls.
Applications that connect to these systems are either deployed within the trust boundary, or require integration through special tunnels that penetrate the layers of security. Each of these integrations becomes a new attack vector that has to be protected lest the entire network becomes compromised.
As a single point of failure, administrators are cautious about making changes to the centralized IAM directory to adapt to new use cases. This lack of flexibility incentivizes the creation of silos that undermine governance policies.
And Then Systems Propagate
When there are multiple external applications, network administrators may try to simplify the management of firewall access by creating a secondary IAM directory with its own security boundary, which then has to be synchronized with the main directory.
There are now two security boundaries that have to be policed, and a vulnerability in either boundary can leave the other one at risk.
It is easier for teams to set up siloed IAM systems than to integrate with the centralized directory, resulting in even more siloed directories and further undermining identity governance.
And Hackers Infiltrate
It has become clear over the past decade that authentication systems and firewalls are not sufficient to keep attackers out of our networks.
It’s naive to trust that systems within the firewall are secure. Zero trust network architectures promote perimeterless security, where every system is authenticated for every interaction.
This provides more robust security, but increases the difficulty of the already complicated integration process.
So We Decentralize
Verifiable credentials are a new technology that enables a decentralized architecture which avoids these problems. Credentials contain signed attributes that are issued from an identity proofing system into a holder’s wallet for identity data.
The holder takes these credentials with them to the applications where the holder needs to interact as a user. These applications verify the credentials, checking the cryptography to ensure that they have not been modified since they were issued.
The applications then provision access based on the information in the credentials.
The wallet is considered an untrusted application, and does not have access into the security boundary. When a user’s identity needs to be checked, the verifying application requests a proof from the user’s wallet and the application can reject the information if anything appears suspicious.
Not only is this a true zero trust architecture, but it is also flexible because it is easy to introduce additional issuers and credential types based on the evolving needs of the organization.
But Isn’t Decentralization Hard?
Introducing an identity wallet into an existing IAM architecture seems like a big change, but credential storage can be integrated into the authenticator app that users already need for password management and OTP codes.
Networks can evolve through a hybrid stage where the federated IAM systems issue and verify credentials across security boundaries, and then provide traditional IAM services to legacy applications. New applications can directly access the user’s wallet.
As use cases are moved to the decentralized architecture, less data needs to be held centrally reducing the IAM database’s attractiveness as a target for hackers.
The centralized IAM directory is easier to secure, and in some cases can be eliminated. If needed, applications can continue using existing tools to centralize governance policies.
Modern threats require new tools. Verifiable credentials not only help us to secure our systems, but also improve our ability to evolve our IAM architectures to address the needs of fast paced organizations. If you’re navigating these same challenges, we’d love to hear how you’re approaching them.
