So, let's let people shuffle in and shuffle out. So, hi everyone, I'm Roni. I lead the OWASP project for the Top 10 Risks for Non-Human Identities. A little bit about myself, I'm the co-founder and CTO of Torch, where we helped organizations tame non-human identities and go secret-less. Before Torch, I worked at Google, specifically building security products for GCP customers. And now I'm leading the OWASP Non-Human Identities Top 10 project, which is a cross-organizational effort to categorize and describe the different risks in this new space.
We're working with leaders from Palo Alto to Microsoft to Google and Tenable. So, what are we going to be talking about today? We're going to go over what are non-human identities, why non-human identities matter, how did we get here, and look at the past 30 years of the evolution of the identity market. And then we're going to go over the top 10 risks and tackle a couple of select risks and look at recent breaches that happened that are related to each of those risks. And finally, we're going to talk a little bit about how we build defenses against these kinds of risks.
So, what are non-human identities? Well, in modern environments, modern software environments, just like you need to give humans, your employees and your contractors, identities to access different sources of information, different resources, we have the same situation with applications and workloads and other services. These applications need to be identified so that they can access databases, S3 buckets, file shares to do their function. What are these non-human identities?
Well, they include things like secrets, API keys, SSH keys, personal access tokens to your GitHub, for example, OAuth tokens and service accounts. Now, why do non-human identities matter?
Well, a recent data point that we got from CrowdStrike shows that 80% of all the modern breaches involve compromised or stolen identities. And when you look at what those identities are, it turns out that non-human identities are the Achilles heel of identity security, and they now outnumber human identities 45 to 1. Why are they such an attractive target for attackers?
Well, A, non-human identities tend to be highly privileged. Why is that? Because the people who are responsible for creating these non-human identities are developers. At the end of the day, developers are incentivized to just get their app to work. What's the easiest way to get your app to work? Just give it domain admin across the board. And that's exactly what we see in the majority of organizations where these non-human identities have significantly more privileges than they actually need to do their function.
Secondly, NHIs lack security controls like MFA. You can't give that workload a phone that will then get that MFA code and log into a browser session and do that step up, meaning that if that NHI leaks, anyone in the world, be it in North Korea or other sanctioned countries, can use that to log in.
Thirdly, NHIs don't live in your IDP, meaning that it's a lot harder to track them, and it's a lot harder to off-board them and react to an ongoing incident. So how do we get here?
Well, the whole field of identity pretty much started in 93 when a company named Novell introduced Novell Directory Services and pioneered IAM. They provided a single fabric through which network-connected devices could be accessed by that one identity layer. Fast forward a couple of years, and Microsoft introduces Active Directory and proceeds to dominate enterprise identity. And as in the early 2000s, more and more people run workloads in their on-prem environments. Microsoft notices that people are creating service accounts with usernames and passwords in order to power those services.
The problem with that is that those service accounts very quickly become an attractive target for attackers, just as I explained earlier, for the three reasons why. As a result, Microsoft introduces the concept of managed service accounts, i.e.
MSAs, to tackle those threats and make sure that passwords are long and constantly rotated. A couple years later, they introduced GMSAs to better tackle the case of workloads that are running across multiple servers. And when you fast forward today, you see now with the proliferation of the cloud and the vast variety of SaaS platforms that the modern organization works with, NHIs are scattered. They're in your AWS, they're in your GitHub, they're in your Jira, they're everywhere. And it's become a significant problem to deal with.
So this is a top-level view of the top 10 risks that we put together for NHIs. This is the work of a several-month-long effort of looking at the data, looking at what were the recent breaches that we encountered over the past couple of years, aggregating that, and then putting it in a list that's prioritized by risk. Let's take a look at a couple specific risks and how they were relevant to recent breaches.
So first, let's talk about secret leakage. Secret leakage talks about the case where your secrets reach unsanctioned data stores that they aren't supposed to be at. Everyone here knows that your secrets are supposed to be in the secret manager. But what happens after you pull them out of the secret manager? How do you know that your users aren't sending them over Slack, aren't putting them in a config file, in a publicly available share?
Well, what we see here is the day that Uber's production network was breached by a single secret. It's pretty much a nightmare scenario for the majority of security leaders in this room. As you can see in the bottom right, the attacker proceeded to connect to Uber's Slack and write, I announce I am a hacker and Uber has suffered a data breach. It's a pretty formal way, by the way, to announce that you've hacked into a company's infrastructure. But what ended up happening as a result is their Slack was leaked, monorepos, AWS, lots and lots of damage to the Uber brand. How did this happen?
Well, the initial foothold that the attacker had was VPN credentials that let them into the network. Those credentials gave them access to a low-privileged identity in the network, and that should have been the end of the story. How did they end up breaching all these different resources in the Uber network?
Well, the first thing that they did after getting into the VPN is they scanned the network for publicly available file shares. In one of those file shares, they found a PowerShell script that had hard-coded credentials for Thykotic in that script. Thykotic being the previous name of Delinia. After they found those credentials, the rest was pretty much history. Thykotic had the admin privilege access credentials to all the different systems that Uber was using, and this is what we ended up with. Next on the list is insecure authentication.
Oftentimes, when I build an application as a developer, I can choose between multiple ways to authenticate that application with resources. For example, if I'm building an application in AWS, I can choose whether I want to authenticate with AWS with an access key, a long-lived credential, or an IAM role, a short-lived ephemeral credential. The easiest way in most cases to authenticate will be to just use the long-lived credential, because it works in the exact same way as it does in the cloud on my endpoint. That's the reason we often find these insecure authentication methods being used.
So let's take a look at a recent breach from a couple months ago of Schneider Electric. 400,000 rows of user data was leaked. How did this happen?
Oh, and the attacker asked for $125,000 in baguettes, because I guess they thought that was funny. How did this happen?
Well, how many people in the room here have heard of the concept of infostealers? I see no hands. What is an infostealer? An infostealer is a special kind of virus that is not used to target a specific organization, but they're used to attack in a widespread manner. For example, by pushing a cracked version or a fake cracked version of Adobe to the internet, and then the credentials that are stolen through that infostealer are sold on the dark web. We see a lot of these kinds of campaigns in recent years, because it's become a profitable business for criminal organizations.
And that's exactly what happened here. One employee in Schneider Electric tried to download a cracked version of Adobe Premiere Pro. This is the video on YouTube that he watched in order to find that cracked version. And along the way, he downloaded an infostealer. Why was this such a bad situation? On the face of it, one employee doesn't have that wide access, doesn't have access to 400,000 rows.
Well, that one employee had on his endpoint an API key to Jira. That API key could be used from any place in the world. It wasn't connected to his endpoint in any way, shape, or form. The attacker just used that API key from the comfort of their home, scraped all the data from Jira. Among that data, they found credentials to the IDP of Schneider Electric and scraped data from that as well. Next on the list, overprivileged NHI. We touched on this a bit before, but developers are often incentivized to create NHI with the maximum amount of privileges just to get their applications to work.
And this causes those initial footholds that attackers get to be a lot more devastating than they need to be. We need to assume breach, and we need to make sure that every single workload has the minimum amount of privileges so that we can tamper down the blast radius as much as possible. So where do we see this recently? The day 150,000 cameras were hacked. A recent breach that we saw was Verkada, a security camera company, where an attacker managed to get super admin-level control of all their security cameras.
What you can see here are fees that the attacker tapped into, from prisons to hospitals to even high-tech companies like Cloudflare and also Tesla. What happened here?
Well, the attacker, while scanning the public internet for IPs of Verkada, found a publicly facing interface on their customer support server. When looking into that customer support server, they found a Python script with super admin credentials to their back-end admin portal for accessing these cameras. Once they found those super admin credentials, they managed to log into any camera they wanted at any time they wanted from any place they wanted. This is a classic case of overprivilege.
Why does that one customer support server need access to all the different cameras without any kind of access control in place? And last on the list, let's talk a little bit about environment isolation.
So, in modern software environments, we see a practice of splitting out the applications to, for example, dev, staging, and prod, or pre-prod and prod. And in the majority of cases, production has significantly higher fences around it than the other environments. The problem arises when you mix these environments in unexpected ways. For example, sharing the same secret across dev, staging, and prod, or giving an application and test access to something in prod. We saw this about a year ago when Russian hackers managed to leak both executive and customer emails from Microsoft.
What happened is those hackers managed to brute force their way into a test environment of Microsoft, and on that test environment, they scanned the account and found an OAuth application and looked at all the places that this OAuth application is installed. One of the places that the application was installed, apparently by the Microsoft engineers that were testing it at the time, was Microsoft's production network. That OAuth application, by the way, had access to exchange, the access to read emails across the board.
And, well, the rest was history. So, as an industry, what can we do against this? How can we build defenses against these kinds of non-human identity attacks?
Well, the number one thing that we can do is adopt secret lists and passwordless authentication wherever possible. Some immediate steps that you can take in your organization is look at, for example, the CD pipelines, which tend to be pipelines that have extremely high privilege because they have to log into your cloud accounts or log into your production servers and bring up new versions of software.
If possible, wherever possible, implement OpenID Connect for cloud identity and for those CD pipelines so that you go from a secret-based authentication, monolith credential-based authentication, to authentication that is based on the worker itself that's running the pipeline. In the case of OIDC, even if they manage to take over that CD pipeline and leak that credential, that credential will expire within minutes, meaning that you reduce the attack surface significantly.
Second on the list in the area of secret list methods is implementing Spiffy and Spire, which are two new technologies in the workload identity space that allow workloads to authenticate with each other in a secret list manner. As with OIDC, when you adopt Spiffy, there is no credential or no long-lived credential that an attacker can steal. That credential itself under the hood is something that evaporates within minutes.
And wherever possible, when you have API keys in your environment, for example, in the Jira API key example, do what you can to migrate off of that long-lived credential to a short-lived credential. A good example of that would be if you have engineers or devs that are connecting to AWS, migrate away from access keys to SSO-based authentication for that use case. Next on the list is implementing least privilege for NHI.
Although it's difficult to convince devs to change their mindset and embed security into the software development lifecycle, it's critical to do that in order to reduce the blast radius in these kinds of attacks. Take inventory of all these NHI that you have across your cloud providers, across your SaaS platforms, across your on-prem environments, and make sure to prioritize them based on privilege. Do you need so many identities with domain admin? Do you need so many identities with global admin in your Microsoft accounts? You probably don't.
And the result of least privilege for NHI will be that even if you are breached, even in the case of that workload being breached, the damage will be significantly lower. And with that, questions?
Well, thank you very much. Can you still hear me? I think we have a question. Yes. Thank you. Very interesting talk. We are currently looking into Spiffy Inspire, and one of the concerns we have is that there are not sufficient enterprise solutions out there which could be used. What's your thought on that and on the adoption in general of Spiffy Inspire? It's a good question. I think as with all emerging standards, you're always going to have the risk of vendors not properly supporting the standard.
And although you do have some players in the field of Spiffy, I've seen, for example, Teleport have been talking at this conference, and they've released a Spiffy-compliant offering. You have, I believe, Spiral, another company in the field. But at the end of the day, it's completely open as a standard, meaning you can just log into their website, follow the Getting Started guide, and bring it up on your own infra and get a feel for the technology. I think the main gap there right now is widespread adoption in third-party vendors.
So it's more ideal for a use case in which you need to authenticate one of your workloads to another one of your workloads, not so much in your workloads to a third-party provider.
