Author Profile
Image credit: Unsplash
Protecting highly privileged users is at the heart of security 2.0 stack. Easiest way to become the source of a software supply chain attack is to have a compromised privileged user who has access to the code, build or deploy pipeline. Privileged users come in two forms: (i) privileged human users and (ii) privileged non-human users i.e. service accounts. In this post we will look at how to protect the human users. In the next post we will look at service accounts and other non-human users.
There are two main category of threats we need to protect the human privileged users from:
-
- Attacker impersonating the privileged human user. This happens largely by compromising some kind of credentials. Maybe by phishing or social engineering or by stealing an access key.
- Attacker compromising a device of a privileged user with excessive permissions. This is the problem of over privileged users, people who have standing admin like permissions to the infrastructure and applications.
Protection from impersonation
As we discussed in the previous blog post, Passkeys technologies take us in a good direction by protecting against phishing or social engineering attacks but they are not sufficient. They don’t protect against theft of post-authentication credentials. Best way to prevent these attacks is to have a way to attest every privileged action by the private key that’s stored in a TPM. We will need every request, every API call, every action taken by the privileged user to be attested as originated from the trusted device. Sometimes it is too expensive to generate private key based signatures for every request. We might rely on things like mutual-TLS for this reason. This allows you to set up a secure connection with the IDWall by performing a private key signature based handshake and being able to send multiple requests on the same connection.
Device compromise and over privileged users
Continuous authentication technologies mentioned above are great. But they don’t protect you against a compromised device. If the attacker has a presence on the device, attacker can still impersonate the highly privileged users. Compromised devices continue to be a large problem in cybersecurity.
Concept of least-privilege and zero standing privileges can help on this front. But they are harder to achieve due to the scale of the problem. Let’s take a simple example of a mid sized SaaS company which is hosting all its software on AWS. Lets say they have about few hundred developers and devops folks. Let’s say that this company is using a few dozen AWS accounts inside an AWS organization. AWS alone has over 200 fully featured services inside it. They have more than 14,000 different permissions and 1200 different built in roles. Many of the services inside AWS like RDS, EKS, Kafka or Redshift have their own permissions and roles. AWS is just one cloud service, the company might be using dozens of different cloud services. Managing these permutations and combinations is impossible to comprehend for human brains. We humans can process maybe a few dozen different entities. Even though we all can agree that least-privilege is the right goal, it is impossible to achieve in reality. Most companies will end up defining a few dozen broadly defined roles and a few dozen groups and manage members of which group can access which roles. This is the best we can do with a centralized identity and access management.
Just in time access
Just-in-time access is emerging as the potential solution for both managing the privilege sprawl and protecting against the device compromise. Idea of just in time access is simple, no one should have standing privileges to any high risk resources and there is a privilege elevation process for getting access to them on demand for short periods of time. This way we don’t have to spend manual effort trying to manage the permissions and roles. More importantly even when a device is compromised by an attacker, if the device has no access to privileged resources, the attacker can not do much damage.
Privilege elevation process
We want to think of the privilege elevation process as a spectrum of things we might do depending on the risk associated with the privileged action.
For low risk actions, we might be okay with ensuring that the action is performed from a trusted device. For slightly more risky privileges, we might want to ensure that the user is present in front of his device by asking him to touch a biometric sensor or asking him to type a PIN. When we want even more guarantee, we might ask the user to authorize the action using a smartphone. Since modern smartphones have better biometric sensors like FaceID, we might ask him to authorize it using FaceID. We might want to make sure both devices are in proximity. In even higher risk situations we might want a second person to authorize it. For even more risky actions we might want multiple people to approve it and finally we might want to have break glass procedures for emergency situations.
Important thing here is, we should be able to do require these privilege elevation process for each action. Not when they login via a single sign on portal. We need to be able to do this in a friction less way that the users are not frustrated by it and they look to bypass it. Going back to the ApplePay example, the user experience of paying with your phone is so convenient we actually prefer it. We need to be able to reach the same level of friction free user experience.
Procyon Solution Overview
In this section we will dig a little deeper into Procyon’s solution and how it can protect your cloud infrastructure. Treat this as an example implementation of IDWall for privileged users. We are just trying to show where Procyon fits in your overall Security 2.0 stack.
Procyon’s Cloud Infrastructure Access Platform is a privilege broker for highly privileged developers and DevOps users. On the left hand side of this picture, Procyon uses TPM technology to securely identify a user in a phishing and social engineering resistant way so that the human user identities can not be compromised. On the right hand side of the picture, Procyon integrates with popular cloud infrastructure services to provide just-in-time access to specific resources and specific permissions as needed. All of this is done with a privilege elevation workflow that lets customers define who needs to approve which privileged actions.
Mutual TLS based continuous authentication
Procyon’s authenticator app runs on the end user devices and creates a key-pair in the TPMs. This key-pair is used to establish a mutual-TLS connection between Procyon cloud and the device. All subsequent communication between the Procyon cloud and the device happens using this mutual TLS connection. This mutual TLS connection is established using Procyon issued certificates that ensure authenticity of the device as well as the cloud it is connecting to. This form of continuous authentication prevents all known phishing and social engineering attacks.
Session hijacking prevention
Since procyon maintains a mutualTLS connection from the device to the procyon gateways, it can prevent session hijacking as well. We do this by binding the session cookies and tokens to a specific specific device. This is an optional feature that the customers can enable when needed. This is done by translating the real tokens issued by backend services to new dummy tokens sent to the end user devices. These dummy tokens are bound to a specific device. If these tokens are ever stolen, they can not be used outside of the trusted device.
User presence and step up authentication
When you are doing continuous authentication based on a mutual TLS connection, one of the things you need to make sure is that the user is present in front of the device and it is not an attacker who is trying to access the system. We do this with the help of biometric prompts. Customers can set policies how frequently the user needs to re-authenticate using biometrics. Similar policy can be configured to prompt for re-authentication when a user is performing a sensitive action like requesting access to a privileged role. In addition, customers can also set up policies to do step-up authentication by requiring the users to authorize an action using a second device like their mobile phone.
Approval process
Goal of having an approval process is to make sure a single compromised user can not do significant damage to the infrastructure. Assumption here is that an attacker might be able to compromise one user, but it’s much harder to compromise multiple users at the same time. By adding the approval process, you are limiting the damage an attacker can do without anyone noticing it.
Procyon provides a self-service portal to developers so that they can request access to the environments they don’t have access to. Procyon provides integrations with many systems like ticketing systems, on-call systems, incident management systems and messaging systems like Slack and Microsoft Teams. This makes it easy to route the access decisions to the right people in charge and grant access just-in-time.
Privileged session management
When developers need to login to a server, or access a database, or access a kubernetes cluster they will need an access credential like private keys, DB passwords or access tokens. Procyon bridges the two sides by using TPM based authentication on one side and minting short lived access credentials on the other side. Procyon bridges this transparently without developers having to worry about it. Procyon even maintains the session recording for server and database logins for compliance reasons.
Privileged credential brokering
Sometimes developers need short lived access keys for cloud services. They might need to run IaC tools like terraform, or run a script, or run cloud CLI like AWS or GCP CLI, in these cases Procyon can mint short lived access keys based on the TPM based identity and provide it to the IaC tools transparently. Procyon authenticator app integrates natively with tools like Terraform, AWS/GCP/Azure CLI, Kubernetes kubectl CLI and AWS/GCP/Azure SDKs. This way the developers and Devops teams don’t have to worry about access credentials.
Conclusion
In this post, we outlined how to protect the highly privileged human users from compromise. We have also outlined additional controls we can have to limit the blast radius in the event a privileged user’s device is compromised. In the next blog post in this series, we will outline how to protect the non-human privileged users like workloads.
Please click here to read the next post in the blog series.
Here are the links to other posts in this series:
Related Posts
