M
Privileged Access Management

Out of the box Multi-Cloud Privilege Access Management (PAM) solution for AWS, GCP and Azure.

Identity Analyzer

Visualize, detect, prioritize, and remediate identity risks.

Integrations

Connect Procyon with the tools you already use and love.

How it works

Secure, cloud-centric privilege acces management platform provisioning acces to user through a self service portal.

Self-Service Page Icon
Self-Service Portal

Minimize your organization’s attack surface and secure your sensitive data by limiting who gets access and when.

Passwordless Access

Scale faster and stop credential sprawl by eliminating shared accounts and static credentials that are challenging to track.

Compliance

Visibility into every resource, every user, and the policies that define and govern access in today’s dynamic multi-cloud landscape.

Cloud Identity Governance

Protect your cloud infrastructure by automating risk analysis for all permissions granted to all resources across multi-cloud.

Kill Switch
Kill Switch

Terminate sessions immediately if suspicious activity is detected to stop any user, anywhere, anytime.

Kill Switch
Simplify Workload Management

Manage workloads at scale with centralized management.

Why Procyon

All Resources
Blogs
Press Realeases
News & Articles
Videos

Company

EXPLORE RESOURCES

All Resources
Blogs
Press Realeases
News & Articles
Videos
Documentation

PLATFORM

Privileged Access Management

Out of the box Multi-Cloud Privilege Access Management (PAM) solution for AWS, GCP and Azure.

Identity Analyzer

Visualize, detect, prioritize, and remediate identity risks.

Integrations

Connect Procyon with the tools you already use and love.

SOLUTIONS
Self-Service Portal

Minimize your organization’s attack surface and secure your sensitive data by limiting who gets access and when.

Passwordless Access

Scale faster and stop credential sprawl by eliminating shared accounts and static credentials that are challenging to track.

Compliance

Visibility into every resource, every user, and the policies that define and govern access in today’s dynamic multi-cloud landscape.

Cloud Identity Governance

Protect your cloud infrastructure by automating risk analysis for all permissions granted to all resources across multi-cloud.

Kill Switch
Kill Switch

Terminate sessions immediately if suspicious activity is detected to stop any user, anywhere, anytime.

Kill Switch
Simplify Workload Management

Manage workloads at scale with centralized  management

How it works

Secure, cloud-centric privilege acces management platform provisioning acces to user through a self service portal.

Sukhesh Halemane

Author Profile

Share:

Last updated date:

January 5, 2024

Subscribe to Our Newsletter

Keep up to date with Privileged Access Management (PAM) and other Cloud Identity topics.

Passkeys and Security 2.0 concepts

Image credit: Unsplash

Passkeys are emerging as a popular passwordless phishing resistant authentication technology. Passkey is a friendly brand name for a set of standards supported by browsers, web services, identity providers and more. The standards like FIDO2, WebAuthn and platform authenticators dont have the same ring as “Passkey”. At the heart of these authentication mechanisms is a technology that Apple calls “Secure Enclave” chips and the broader industry calls TPM chips. The TPMs are like mini HSMs that sit inside our laptops, tablets and mobile phones. They can create private keys inside these TPMs in such a way that no one can read the private keys including the attackers. 

These TPM chips can be used for much more than phishing resistant authentication. They are used by Apple for the ApplePay payment system. They are used for verifying integrity of software that’s installed on the devices and much more. We estimate there are more than two billion devices in consumer hands that can perform these secure signature operations. For the first time in the history of the internet we have a reliable way to identify users using these chips and attribute their actions. This will allow us to approach cybersecurity in a fundamentally different way.

 

Why is this important? 

One of the biggest reasons this is important is the evolution of generative AI technologies. The voice, image and video generation capabilities of generative AI technologies have gotten so good that we can not tell the difference between a real person and a deep fake online. This will lead to all kinds of social engineering attacks. Every form of digital interaction we can have today can be deep faked. We can not tell if the person on the phone is our boss or an AI. We can not tell if the person on the zoom call asking us to wire money is our CEO or a generative AI bot. This can lead to huge explosions in social engineering attacks. We currently have no way to protect against such attacks. 

But no amount of generative AI can deep fake a private key (assuming the key is big enough). Using non-extractable private keys in a TPM is the only way we can defeat the AI bots. But to defeat the social engineering techniques we discussed above, we need more than phishing resistant authentication. We need reliable ways to attest facts and prove possession for every action or transaction. For example, a HR person could attest he/she has checked an employee’s government issued identity. A hiring manager could attest they have issued a specific device to a new employee. A finance employee could attest he/she has approved a wire transfer. A good example of this is iMessage contact key verification feature recently introduced by Apple. It provides you a way to verify a person’s authenticity cryptographically using secure enclaves. It is unfortunate that consumer technologies are doing this better than the enterprise identity systems.

 

Attestation

Whatever is your view of the blockchain technologies; maybe you are a skeptic and you think Bitcoin and other shitcoins are all a giant ponzi scheme. Maybe you are a believer and you think blockchain technologies will fundamentally change financial services as we know it. Whatever is your view, you have to give credit  that Blockchain technologies have made a few cryptographic concepts mainstream. We could make use of them more often in the cybersecurity world. Three of them in particular are very relevant:

  1. Concept of hardware wallets: Store a private key in a hardware wallet and it becomes your identity.
  2. Signing every transaction with the private key stored in hardware wallets. This attests the transaction was performed by a specific identity.
  3. Maintaining a tamper-proof audit log of all signed transactions as an immutable ledger. This becomes the source of truth in terms of knowing who performed what action.

These cryptographic concepts are not new. We have known how to do these since the 70s. What is new is that our devices can act as hardware wallets now because of TPMs. This means that we can sign every action we perform online using these hardware wallets. We can maintain an audit log of these signed actions as a proof of who performed them.  More importantly, we can do this with a really good user experience. It can be as simple as paying with your Apple Pay on your phone.

In this blog series you will see this pattern of signing actions/transactions using hardware wallets being used repeatedly for various attestation purposes. Everything from authorizing specific actions, to certifying code commits to signing images. We will use the example of the Procyon solution to describe how we implement some of these techniques. In theory, you can do this by yourself too.

 

User impersonation and social engineering

Most common way the attacker can impersonate a trusted user is by compromising the credentials associated with the user. Luckily passkeys can solve the problem of simple credentials like passwords. They can prevent the basic phishing attacks. But they don’t address two other common forms of impersonation attacks:

  1. Session hijacking attacks like stealing post authentication tokens like session cookies, bearer tokens, kerberos tickets etc. 
  2. Attacker adding themselves as a trusted user by social engineering.

We will discuss ways to prevent these attacks in this section.

Session hijacking attacks

As recent Okta support systems breach highlights, session token(or cookie) theft is the easiest way to bypass all authentication systems. According to publicly available data, the Infostealer malwares are posting 17 million stolen credentials every month to the dark web. Most of these are post authentication credentials like bearer tokens. You might have the most secure phishing resistant authentication system. But if the attackers steal the post authentication session token, they have effectively bypassed it. 

One way to solve it is to not rely on session tokens and use TPM based signatures to re-verify every subsequent session is coming from the same trusted device. But doing this for every request becomes too expensive computationally. Better way is to maintain a persistent connection, something like a mutual-TLS connection to the IDWall so that the IDWall can verify the requests are coming from the trusted device and send this attestation information to the backend servers in request headers. Procyon’s solution follows this approach to prevent session hijacking attacks.

Attacker adding himself as a trusted user

Second problem is how do we prevent the attacker from adding himself as a trusted user. In the enterprise context, we can rely on something like the HR department to attest to the users. Or maybe it is the hiring manager who attests for the employee and so on. We would also need to have a good process to make sure the devices associated with the user are also attested by someone. Ultimately the security of our system completely depends on how reliable this process is. Imagine if the attacker can call the corporate help desk and pretend to be one of the employees and say he has lost his previous device and needs to be on-boarded on a new device. If the help desk person onboards the new device(which is owned by the attacker) without verifying the identity of the caller, the attacker can bypass all security controls.

This is another area where the Procyon solution excels at. It has a number of techniques to prevent the attackers from social engineering their way into impersonating trusted users. Procyon also has the ability to prevent attackers adding themselves as trusted users by compromising Procyon itself. We do this by maintaining an immutable cryptographic signature log of which user onboarded the new user and device. Even if an attacker compromises Procyon, without the private key of a user, they can not modify the immutable log.

 

IDWall and gateways

We introduced the concept of IDWalls in the previous blog post and we described how we want to identify the user before they can exploit the vulnerability in the software. Putting the entire software ecosystem behind an IDWall is quite a complex challenge. The software ecosystem we have built over the last 50 years is a complex beast. At a high level it is easy to say that we have applications in the cloud and users are accessing these applications from their devices, we need the IDWall between them. On the surface, this looks like an API gateway pattern that most modern microservices based applications use. 

In this pattern, Users on the left hand side of this picture all come through the API gateway. API gateway knows how to authenticate and authorize the users and then handoff the API calls to individual microservices with some user metadata(in the form of a JWT) so that individual microservices can make more fine grained authorization decisions based on the user’s role or attribute. API gateway also maintains an audit log of the API calls made by the users.

But the challenge is, the existing software ecosystem doesn’t look anything like these modern microservice applications. There are a lot of legacy softwares that were developed over decades. Many of them use legacy protocols other than HTTP used by modern webapps. Many of them use legacy authentication methods. Sometimes the demarcation between the user and the application is not clear. It might be an application making the call to another application on behalf of a user. Or it might be a user logged into a remote virtual desktop service. Maybe it’s an RPA bot that is acting on behalf of a user.

What we really need is an IDMesh that understands these legacy protocols and authentication methods and can translate them and interop with existing software without requiring them to be changed. This IDMesh will need to understand the context of the request to know who is actually performing them. This is what solutions like Procyon specialize in. We have connectors for many forms of legacy applications and protocols. Since Procyon focuses on highly privileged users our connectors tend to favor developers and devops teams. We don’t claim to solve all of your identity threats. But we are confident this is the right direction to move forward.

 

IDMesh

In an ideal world, we would need to protect every network call using some form of IDWall. ServiceMeshes take this approach and have a sidecar process running inside every workload that acts as an identity checkpoint. This approach may not be practical in all scenarios. Some might prefer to do it per application, per subnet, per VPC, per cloud account etc. this is the same as how do you define a trust boundary during threat modeling exercise. 

You can think of these trust boundaries as cells and all communication between these cells need to contain identity information. If we take the example of the Procyon solution, it looks like a mesh network of gateways. We call some of the smaller gateways as relays. These can be co-hosted with the workloads as sidecars or inside private VPCs. All these gateways discover themselves and establish a mesh-like overlay network between them. Once this mesh network is established, all communication between the workloads and services contain identity metadata about them. Some of this metadata contain workload or service identity and some contain the user identity. We will discuss different types of metadata in subsequent blog posts.

 

Next

In the next post in this blog series we will look at how to secure highly privileged users in the Security 2.0 stack and start discussing how the IDMesh takes shape.

Please click here to read the next post in the blog series.

Here are the links to other posts in this series:

  1. Security 2.0
  2. Passkeys and Security 2.0 concepts – this post
  3. Privileged users in Security 2.0 Stack
  4. Workload Identity in Security 2.0 Stack
  5. Code to cloud: verifiable deployments

Related Posts

Evolution of modern identity stack

Evolution of modern identity stack

Identity and access management traces its roots back to the mainframe era. DoD first employed logical access controls by mandatory and discretionary access control(MAC/DAC). This eventually evolved into what we now call Role Based Access Control(RBAC). More modern...

read more
Code to cloud: verifiable deployments

Code to cloud: verifiable deployments

Image credit: Unsplash Ken Thompson the creator of Unix operating system and C programming language gave his now famous Turing award acceptance lecture in 1984 on the topic of “Reflections on Trusting Trust”. In the lecture he said: “To what extent should one trust...

read more
Workload Identity in Security 2.0 Stack

Workload Identity in Security 2.0 Stack

Image credit: Unsplash In the previous blog post, we discussed how to protect against the compromise of highly privileged human users. In this post we will discuss how to protect against compromise of highly privileged non-human users or workloads. As we discussed in...

read more