Modernizing Access to Mitigate Security Risk and Speed Threat Response

Organizations face increasing risk of data breach, with threat actors taking aim at credentials and standing privileges. So, what can companies do to protect their infrastructure?

Join Melinda Marks, Practice Director of 

, Ev Kontsevoy (CEO), and Aleksandr Klizhentas (CTO) of Teleport to explore:

The current breach and PAM landscapes, the top security challenges companies face, and why modern access architecture is needed today

What modern access is, and how it both hardens infrastructure security, eliminating common attack vectors and improves engineer productivity

How built-in rather than bolt-on policy governance delivers powerful, real-time insights and controls to security professionals that stop threat actors in their tracks

Transcript - Modernizing Access to Mitigate Security Risk and Speed Threat Response

Ev: Good morning and good afternoon, everyone. Thank you for joining us. Let's give it maybe one more minute because folks are continuing to join and then we'll resume.

Ev: All right. Good morning, good afternoon, or good evening, everyone, depending where you're joining from. Thank you for being here with us today. So we have a very interesting topic to discuss on this webinar. We're going to be talking about modernizing access to mitigate security risks. I'm Ev Kontsevoy, CEO and founder of Teleport, the Infrastructure Access Platform company. And joining me, we have Melinda Marks, the practice director at Enterprise Strategy Group. She will be sharing her experience with access challenges. And also, we have Sasha Klizhentas, Chief Technical Officer at Teleport. So let's start with you, Melinda. So why is modern access needed? Why is this modernization such a big deal? What is happening in the market? And feel free to let me know when you need the next slide.

Melinda: Yep. Sure. We can go to the next slide here. Yep. So I'll just kind of give you guys an overview of what we're seeing at Enterprise Strategy Group. We do a lot of research on what organizations are experiencing and what their big challenges are. And account compromise is really a major issue that they're facing. The access and permission issues are having a really big impact on cybersecurity. You can go to the next slide. And what we're seeing is that most organizations are facing credential compromise. This is a big concern. Basically, once an account is compromised, if an attacker is wanting to hack into your systems, once they have that credential compromise, they can look like any insider.

Melinda: So when they're indistinguishable from an insider, they can get access to all kinds of things: data, everything that you want to protect in cybersecurity. So our data shows that they're really failing to learn from and respond to account and credential compromise. So here you see 20% experience account or credential compromise. And the part in pink here shows that even more encounter multiple credential compromise. And this is scary to see, and we continue to see this every year when we do this research on identities, and we do a lot of research on things like how you're managing your access and your passwords. We can go to the next slide.

Melinda: And when we look at how this happens, when we look through this list of — so this is a question which was — which of the following contributed to the compromise of your organization's accounts or credentials? You think of all the controls or tools that you have in place. And what's interesting to see here is that the ones that are the highest percentages, the ones that we've kind of highlighted here in red, are things like credentials as a result of a phishing or social engineering attack; compromise of credentials as a result of a data breach or data dump; customer account password sharing; workforce account password sharing; phishing attacks as precursors to ransomware. And those are things that are more complex to control. It sometimes involves more training because the tools can't really keep up with it. Something like phishing, you need some social awareness and training to understand what phishing looks like. And those are problems that are a lot harder to solve for organizations and enterprises who want to protect all their assets and resources. We can go to the next one.

Melinda: And then what we see is that that account or credential compromise is often a precursor to successful cyberattacks. So here we ask the question: have any of your organization's compromised accounts or credentials over the past 12 months led to a successful cybersecurity attack? And 37% said yes, 1 attack. 22% said multiple attacks. What we thought was really interesting is that some people indicated maybe, so they aren't sure whether it resulted in attacks. So this is really scary to us. Yeah. And I've also seen other data from some of my other studies where we know that people recognize that it doesn't just cause the attack; it often causes the lateral movement once somebody has attacked. So, Ev, what's your view on credentials?

Ev: Well, our view of credentials and all other forms of static secrets is formed by our background. So prior to starting this company several years ago, we came from a hyper-scaler world from organizations who manage massive amounts of data, massive infrastructure, massive complexity. In those environments, as you add more and more computing resources, technologies like virtual machines, containers, Kubernetes clusters, dashboards, and so on and so on, all of them have their own way of managing access. Every component has its own authentication and authorization. It has network security requirements and compliance requirements. And then you have engineering teams where engineers have different roles.

Ev: So all of this leads to proliferation of just accounts across your organization. And access to these accounts is governed with static credentials like passwords, or private keys, or something like this. So then you have to think about this kind of surface area because all of these credentials are exposing you to bad human behavior, which means that someone opens the wrong attachment, someone clicks on the link, their laptop gets compromised, and attackers are usually looking for these credentials. So in our view, again, credentials make you vulnerable to human behavior. So as your organization gets bigger, complexity goes up. And as we all know in computing, complexity always goes up. So that inevitably leads to having more secrets, more credentials. And that elevates the probability of some human — because human is the weakest link— some human leaking that credential as a result of an attack. So again, to sum it up, credentials or secrets make you vulnerable to human error.

Ev: By the way, I understand that you actually do have some data supporting why. Because I've been talking about infrastructure and specifically cloud environments, and I understand that you have some data supporting that protecting infrastructure and protecting cloud workloads is different from traditional IT use cases.

Melinda: Yeah. Absolutely. And we can move forward here. I have some slides to show that. So a lot of the things that I talk about is why organizations or how organizations are moving their workloads into their production workloads into the cloud. So they do this for the benefits of increased productivity. They can get the benefits of using cloud services instead of building the infrastructure themselves and waiting for IT and operations teams to set up compute infrastructure. They can use the cloud services and empower developers to build and release their software more quickly with more collaboration and better tools. So this means everything is moving faster; everything is scaling. You talked about the human element. That means more chance for mistakes, more cause for issues, and that need to move fast and be productive. So we can go to the next slide here.

The need to modernize cloud adoption and faster application development

Melinda: And what we see is the top five security challenges with the cloud adoption. So this was just a question in my cloud security posture management study of what represents the biggest cloud security challenges for your organization. And it was maintaining security consistency across our data center and public cloud environments where our cloud-native applications are deployed; overly permissive service accounts; manual cybersecurity practices and processes can't keep pace with cloud-native application delivery; overly permissive accounts; and our application development and DevOps teams don't always involve the cybersecurity team. So the things that you were talking about with identities and where it ties into cybersecurity is that, with cybersecurity, you always have to think of all of that risk that you have and making sure that you can get ahead of that so you know that these mistakes are going to be made. How do you put controls in? How do you make sure that you can reduce the risk and the chance of these problems to happen? So we can go to the next slide here.

Access-related issues dominate misconfigurations

Melinda: And when we look at organizations and misconfigurations, it's interesting to see how cybersecurity has kind of evolved. We used to talk a lot about vulnerability management. Well, any kinds of mistakes or developer issues can become vulnerabilities. They leave you vulnerable. There's a lot of discussion around this. And access and identity are really big. Really make you vulnerable. So when we look at what types of misconfigurations people faced in the past 12 months, a lot of them were identity- and access-related. So here you see the list of what types of misconfigurations did you detect in your cloud-native applications. And the top one is externally facing server workloads, but you can see a lot of the things in the red boxes here are related to access and permissions. So things like overly permissive user accounts. So when the developers are working, and they're building their applications, they often over-provision access so they can build quickly, and then it's very easy to forget. There's things like entitlements that you set up for access to different tools and software and resources.

Melinda: And it's just very easy to forget to — again, these are mistakes. These are human errors. And there's issues with secrets. You can kind of read through this. I know it's a little bit of an eye chart, but things like lack of multi-factor authentication for access to cloud or Kubernetes management consoles. Sometimes people just want to cut corners, or they're too lazy to do the extra steps. Or there's a lot of issues around there where it just causes problems for security. And these are IT and operations issues, but it's also tied to cybersecurity. Because when there's a threat or a breach, it becomes a cybersecurity issue. So I'll just read a couple more of the things on here. So default or no password for access to management consoles and improper access control lists or ACLs leaving object store resident data exposed. We see a lot of that type of thing. And so It's hard for organizations to — when they get this list for security teams to get a list of all these things that need to be fixed, they don't know how to prioritize it because they don't have that perspective of what can lead to a breach. And so it makes it very difficult when you don't have controls or better tools to help prevent this. So we can go to the next slide here. So are your customers experiencing these misconfigurations?

Ev: So when we meet with Information Security Officers or with kind of head of infrastructure teams and we ask them — sometimes I even ask them on a very high level what's top of mind. The one problem that everyone wildly acknowledges is, again, human behavior. What we talked about earlier. How do you protect infrastructure against mistakes? But the second one is what people sometimes call access silos. So essentially, what they're referring to is back in the day, several years ago, to build a web application, all you needed was a LAMP stack. We probably remember all of that. All you needed was Apache, MySQL, PHP, and Linux, right? So securing those four components — that's all you needed to do for very simple applications to be up.

Ev: But modern stacks are incredibly complex. You have dozens, if not hundreds, of layers of technology. You have, again, virtual machines. Then, you have containers. Then, you have a container registry. Then you have Kubernetes. You have multiple databases. Then, you have your DevOps tools, like dashboards. And then you have to multiply this by how many accounts in the cloud you have and how many cloud providers. So all of these things, you have to manage access to them separately. That's the state of the world today.There's not a single solution that allows you to make sure that your privileges are minimal required privileges for everything in one place.

Ev: So for example, you would need to — let's just assume you have a very simple policy to define. Developers must never touch production data. Where do you actually go to find this policy? You have to do it separately for different workloads for different protocols. Even identity of users is fragmented because it's in many different places. So as a result, security leaders are complaining about high costs because you need to bring multiple vendors to implement security. So you need something like a zero trust solution for network security. Then, you need Okta or Active Directory for identity. But that's only identity for people. It doesn't do machine identity. For that, you need something else. Then, you need privileged access management, but it's not cloud-native. So for cloud, you need cloud entitlement management. So all of these tools pile up. So now we need the high-cost issue. So you need to actually write multiple checks, maintain multiple vendors. Build expertise on your team to manage all of these different solutions.

Ev: The second problem is that the resulting contraption that's helping you to manage all these siloed access problems — it just gets in the way. So developers begin to complain. We talked about the importance of productivity. So they're not compatible with the cloud-native way of doing things. A lot of them, particularly PAM solutions, are simply not compatible with the kind of variety of workloads that exist in the cloud. They are not compatible with the elastic nature of cloud environments. So as a result, now you have your engineering team that basically hates your security solution and has all incentives in the world to add backdoors to it effectively to make their life easier.

Ev: And finally, the resulting solutions just represent high risks. They're not secure enough because, as I said earlier, they're not doing anything to shrink your exposure to secrets, exposure to bad human behavior. So essentially, you continue to be immune to human errors. This is why everyone is investing in observability tools, anomaly detection, employee training — it’s because there's this belief that access enforcement is kind of broken because of this fragmented nature. Melinda, do you have any data or maybe customer stories that kind of reflect our view?

Melinda: Yeah. Definitely. And it's exactly what you were talking about. Where people get kind of in reactive mode instead of being proactive. Again, the goal should be to minimize risk and be able to manage your security posture. So we can go to the next slide here. So when we think about cybersecurity attacks, this is some data from our security posture management study and what types of attacks did you experience over the last 12 months. And unfortunately, a lot of them, again, are results of misconfigurations that are related to access and permissions. So exploits of a misconfigured cloud service, workload, security group, or privileged account; misuse of a privileged account by an employee; misuse of privileged accounts, secrets, or access keys; unauthorized access by a third-party consultant and/or vendor.

Melinda: And again, those are those things where it's hard to figure out a way to better incorporate it into a developer process. A lot of the measures that they have now are things where they'd have to be thinking about it and take certain actions, or it's just very hard for organizations to create that consistency across development teams. So developers are skilled or less skilled in security, and understanding the role of access or making sure that they're checking their entitlements and other things that they need to do that would help reduce security risk. They just want to get their applications out the door. So the easier that you can make that for them, then this is where we want to improve so that you don't see these attacks from misconfigurations that should have been easily prevented if you had the right tools and processes in place. So we can go to the next one.

Melinda: And then the impact on security posture. And this is something where, to me, it's sometimes frustrating because we have a lot of cybersecurity tools that now they're starting to realize that there's identity issues and there's ways that they can kind of tie that in. But this disjointedness and also an evolution of where IAM was owned before and how it's kind of become more of a security problem as you move to the cloud because it's such a big cause of the security incidents or cause for misconfigurations — is that it really has an impact on security posture. And cybersecurity professionals and teams are recognizing the importance of making sure that their strategy with identity is aligned, so they're tying to the right tools and they're talking to IAM or other groups who are involved in setting controls and policies so that they can mitigate risk.

Melinda: So when we asked about some sentiments about the challenges of moving to the cloud, there were two statements that were related to permissions. And the data here, the dark blue is strongly agree and the light blue is agree. So high percentages are agreeing that overly permissive service accounts introduce significant security and compliance risk. And our developers have highly permissive accounts, making them susceptible to credential theft attacks. And then also some other sentiments that are kind of related here — is just again, that extra complexity and scale of the cloud that makes this more challenging. So things like the differences between cloud-native applications and the rest of our apps and infrastructure require a different set of security policies and technologies, and then it's difficult to track and manage security configuration through the lifecycle. And then it's difficult to manage cloud security posture because of the increasing speed and volume of releases. So this is something where a lot of work needs to happen, and this is why I'm so glad to be on this webinar with you guys. So you guys have a solution that addresses a lot of these things. So can you tell us about that?

Ev: Yeah. We're certainly trying. We're certainly trying. Yes. And by the way, you mentioned another source of siloing of access that is a machine-to-machine accessing. So like you mentioned, service accounts. But there are things like CI/CD pipelines, like how code gets deployed. Essentially, any kind of automation that's running in your cloud. That's another way to get in. And —

Ev: — those things also have credentials, also have secrets, and they're frequently —

Melinda: Yeah. I was going to say, we have a study coming up just on that topic. The non-human identities. Because I think there's a lot of better understanding that we can get from our data and sharing that with people to help them understand that.

Ev: Yep. So back to our view. So we believe there are two biggest challenges that need urgent solutions right now. One, what I've already talked about, is human behavior. How do you prevent — how you make your infrastructure resilient to human mistakes. And to do that, we believe you need to get rid of all static credentials, all forms of secrets. That's one. And the second one is: how do you address this siloing? Because the probability of you getting hacked due to having these credentials gets multiplied by complexity. So having a lot of different accounts, having a lot of different workloads, that only makes things worse.

Ev: So here's our approach. So at the foundation, we introduce this concept of a single source of truth for all identity in your organization. When I say all identity, I truly mean everything that is involved in the process of computing. So you have to consolidate identities of your employees and identities of hardware they're using to access infrastructure, like laptops, for example. Then, identities of workloads. Things you're running on your infrastructure. That includes databases, DevOps dashboards, Kubernetes clusters, Linux and Windows boxes. All of those things — they need to have identities too. And then identities of service accounts. Essentially, identities of code you are writing. And we believe that identities of all of these things — they have to be in one place because it allows you to actually implement policy in one place. You cannot have policies sprinkled all over your infra because that exposes you, again, to misconfiguration, which is yet another form of human error, human behavior. So that's the first thing. We believe that identities for everything need to be consolidated.

Ev: Second, that identity should not be represented as a password or any kind of secret, because what's the point of doing it? Because we're going to end up with the same problem. So Teleport instead uses cryptographic identity. What we mean by that is essentially using a combination of biometric and secure enclaves, like TPM on a laptop or HSM on a server. And then you combine that technology with PKI, essentially. So Teleport is a certificate authority at its heart, where we issue short-lived credentials based on physical world properties. Again, biometrics or TPM or HSM. And that is the foundation for this cryptographic identity layer. So that's the first thing you get. Essentially, a live inventory of all live identities that exist in your organization. Again, laptops, servers, databases, users, all of this — it's all the same to Teleport.

Ev: Then, on top of this, we implement what we call the Zero Trust networking Plus. Because once we have identities of everyone, then we can ensure that all of your connections are always encrypted, always authenticated, no matter who's talking to whom. And the reason we call it Zero Trust Plus is because traditional Zero Trust implementations are kind of focused on users accessing applications. But this implementation ensures that the entire tech stack that application runs on, the layers of the stack when they talk to each other — because remember that machine-to-machine access is really important — that's zero trust as well. So we enforce identities for everyone, for every single network connection.

Ev: And then, on top of this, it allows us to implement things like just-in-time access. Where we believe that by default, actually, in a steady state, when nothing is happening, no one or nothing should have access to your infrastructure. And only when there is work to do, some kind of task to be completed, then access needs to be created on the fly given to the identity which needs to go perform that task, and then access needs to be revoked. So all of this is implemented on this kind of third layer. And obviously, there is a full audit of what's happening with the session recordings and security alerts. And finally, on top of this, we offer the intelligence layer that allows you to essentially govern your identities and allows you to actually get kind of these intelligence reports of how we are doing. Did I configure everything properly? So you do have this one single place where you can control what is going on.

Infrastructure: easier to access, more secure

Ev: And the result of this approach, as reported by organizations who've adopted Teleport, essentially there are three major benefits. And I will start with the one on the left, which was unexpected even for us when we started several years ago. That, normally, security and productivity, they are at odds with each other. But our customers have been reporting that, "Hey, by consolidating identities and authentication authorization in one place, engineers love it." They're actually reporting higher productivity because they don't have to juggle different credentials, different config files, different VPNs. It doesn't matter. They feel like they get teleported into the exact same environment. That's why we called the product Teleport. So onboarding, offboarding is not a problem. You don't have any credentials to manage. So employees love it.

Ev: The second benefit is probably the most obvious. It's the security. So in this system, there is nothing an attacker can go after. There is not a single private key, no API keys, no browser cookies, no passwords, no nothing. So if you have a compromised identity due to human error, again, human behavior, that leads to very little, maybe even nothing, because attackers cannot have any secret that they can go and steal. And finally, it allows you to significantly reduce the burden of being compliant. So there are numerous compliance standards out there, PCI, FedRAMP. All of them have these AC controls, access control, requirements. So essentially, we just tick all of these boxes that allows you to pass the kind of audit with flying colors. But I do want to pass the mic to Sasha, our Chief Technical Officer, who will be able to go a little bit maybe deeper into it. Sasha, I will stop sharing, and you could take control from here.

Remaining mindful of developers' and engineers' productivity

Sasha: Yeah. Sounds good. Yeah. Melinda, I was listening and there was one interesting thing you said and showed on the chart that one of the sources of the issues that folks experience is that they failed to set up second-factor authentication for infrastructure protocols like Kubernetes. And I was thinking about this. It is actually extremely hard. Anyone who tried to set up MFA for what is traditional infrastructure protocol knows how hard it is to do for a couple of reasons. The first one, there's no concept of a session in many of those new protocols. Kubectl execution does not have a session. So when we were building and approaching this problem, we recognized the key reason why folks were not able to do that just because it's extremely hard. We had to build the whole concept of a session for kubectl. We had to make sure that when folks are asked to tap MFA, their work stream is not disrupted because you can implement this in a completely wrong way, completely disrupting the productivity of an engineer. For example, if you ask them to tap on every kubectl command, you might think it's very secure. But in practice what happens, people just get tired really quickly out of this flow, and as I've said, they just find backdoors. So any solution that we build should be mindful of developers' and engineers' productivity because you just incentivize them to work around or hack around your solution if you do it wrong. And that's one of the reasons a lot of those traditional IT approaches fail. [crosstalk] —

Melinda: Yeah. It's very relatable. I mean, when you're trying to log into an email and it makes you do two-factor and, "I just set this up, so I shouldn't have to do that from this browser," I mean, I think everybody kind of gets that. But then for developers, it's even more complicated. So yeah, it was good to see that benefit that you showed. That the employees love it, the developers love it.

What industry is paying attention to vs. what's actually happening

Sasha: Exactly. And another thing that came to mind is when we were talking about S3 misconfigurations and other things. Iin the industry sometimes we hear a lot about quantum computing and how it's going to disrupt our cryptography and how we should act urgently. But in practice, most of the times we're getting hacked is for somebody forgetting to set the proper IAM policy on their S3 bucket or forgetting to reset their password or phished. There's a big disconnect between kind of what we are paying attention to versus what's actually happening.

Protecting identities with access to critical infrastructure

Sasha: But I'm just going to start with an overview of the challenges that we have in this new system where most of the attacks or a significant percentage of those attacks are targeting identity. So as you mentioned, Melinda, this is a new threat. Although, while it's a new threat, the way we address this is quite familiar for us. So it's basically a systematic approach where we have to address this problem in steps. And the steps are really familiar for us where we initially start on systematically diminishing, as I've mentioned, the attack surface. Ev said one important thing. Our opinion is if you don't have anything to do on this infrastructure or a service doesn't have to do on this particular infrastructure at this given moment, they shouldn't have access, or the system shouldn't have access. So we should start with reducing the unnecessary exposure, reducing the attack surface. And the way we do this is by using just-in-time access requests or ephemeral joining or secret list joining for CI/CD systems.

Sasha: The second aspect involves monitoring of weak access patterns. And Melinda, as you mentioned, those are one of the core reasons anybody gets hacked through the identity vector. Missing MFA, or maybe over-provisioned access, or maybe someone even forgot about this identity that has been provisioned. Maybe the CI/CD job, Jenkins box hasn't been patched for months and has longstanding access privileges. We think of it as something we will probably get to when we have time. That's our view as engineers sometimes. Attackers view — that's the first thing they're going to go after. So when showing those access patterns, we actually have to point everyone's attention and focus their attention on what we think will be the biggest risk for them.

Sasha: And as a final line of defense, we have to have rapid response. As research shows, we have about 84 minutes on average, from the initial breach of identity or any other breach to the lateral movement across the infrastructure. So we have to quickly understand the blast radius and react. So understanding the blast radius is also really important. For example, if we don't know what the blast radius of the compromised identity is, our blast radius that we have to consider as many of the remediations we have seen in the industry is the entire infrastructure, the entire workforce, and you have to lock everything for many days while you're doing this remediation. It's a very expensive exercise. So we have to be mindful of that too.

Sasha: And one other thing that Ev has mentioned, which I want to point everyone's attention to, is that if you don't build the system on a strong foundation, it's really hard-to-impossible to secure all those access paths in your infrastructure. For example, if you have 10 protocols, which is not unusual for the modern infrastructure, and each of those protocols requires different authentication, different authorization, different secret to access, it becomes a never-ending story of you trying to patch holes. And then the new ones emerge because folks just have to, as Melinda you said, to get work done, and they need to get their app as soon as possible to the market. And then they just deploy whatever's available for them.

Sasha: So the first thing we do, as I've mentioned, is build a strong foundation with Teleport Zero Trust at the foundation of everything. Where we, first and foremost, try to eliminate all those protocol inefficiencies or deficiencies and replace them with strong security invariant. So in Teleport, the strong security invariant is to keep things simple. We are basically using mutual TLS with short-lived certificates bound to either user identity through WebAuthn and security devices like QB codes with proof of presence and biometrics. Or for machines, we're trying to leverage as much as possible secretless joining methods, like IAM joining, or GitHub joining, OAuth joining, with additional protection of binding that specific workload, if available, to a virtual TPM device, which basically gives us strong proof that this specific identity is what it claims to be.

Sasha: So once we have that, lots of those things become possible. I wouldn't say easy, but at least we can start having this conversation. Where instead of protecting Postgres protocol and Kubernetes protocol and Jenkins web UI — and I can go on and on, right — with AWS API and SSH of different variety and legacy implementations, we can start with first having the strong security invariant, and then on top of that, we will have the visibility and control we need to start addressing those problems in more detail. For example, once we have full understanding of the protocols, Melinda, you mentioned that, for example, Kubernetes API codes without MFA are one of the critical issues.

Sasha: Another thing we've seen is SSH sessions that are using `root`. So over-permissioned without device trust, without per-session MFA. So that's what we've launched last year with Teleport Identity products that helps leaders in the organizations to understand what is the actual setup across all their teams and start the conversation. For example, they can take a look at who is launching those SSH sessions with `root` without per-session MFA. Or maybe they have privileged Postgres sessions without device trust. Or maybe someone is overusing Kubernetes execs. That is always a little bit dangerous because that's an interactive session. In addition to that, maybe they are using long-lived certs, long-lived joint tokens with SSH sessions. Kubernetes System API calls that are using things like `system:masters` instead of `view` or `edit` permission that is less dangerous, and so on and so forth. And that will start the conversation, and that will help folks to understand and maybe even automatically remediate some of that with the help of the Teleport response system.

Sasha: However, I found in my conversations there was one question that still remained even with all of those dashboards and introspection that we had. And this is a question I would just like to ask the audience as well. Folks, if you choose, at random, a person in the organization, I would ask you this. Can you tell me what access do they have to your systems right now? Would you have tools to answer that question within a reasonable timeframe? And how long would you think it would take you to answer that question? I'm going to pause for a second and let you think about it, and then I'm going to tell what I've encountered in all those conversations.

Sasha: So what I've encountered is that the best of the best teams we work with maybe can say, "Well, you know what? It will take us a little bit less than an hour, maybe a little bit more, and we'll give you an approximation." The median response was, "It will take us a couple of days to get that answer." And finally, most of the responses we've been getting is that: "We actually don't know. And why is it a problem for us that we need to solve?" Back to your point, Melinda, if you don't know the attack surface in seconds or in minutes, it will really be impossible for you to understand where you should start with this transformation and helping your organization to be more secure, identify vulnerable identities, identify vulnerable systems that can be a target of the compromise.

Teleport Policy and Teleport Access Graph

Sasha: And that's why we launched Teleport Policy. And what you're looking at is what we call Access Graph, which is part of our Teleport Policy initial release. We launched it a couple of weeks ago and announced it in Preview and Teleport Connect October 25th conference last year. It’s the system that can help organizations to start that conversation and understand their exposure of their identities. So for example, if I would like to see what `sasha` has access to across all of my Okta identities, across my IAM presence, across AWS, across on-premises, Access Graph collects all this information and imports it for you so you can start asking those questions.

Sasha: And the opposite is also really important to know. For example, if I would like to ask a question, who has access to this specific computing resource? Let's assume that's a crown jewel of my infrastructure, with access to critical PII data or databases. We can build this attack vector tree in seconds across all of the possible attack vector paths that Access Graph is aware of. And here, we can also start more nuanced conversations. So let's just take a look a little bit closer at what Access Graph actually shows. The first — it shows you possible access paths. And we can quickly observe that those two access paths are not identical. The first one is the long-standing access path for this group of folks. And the second one is a potential access path where this group of folks is only allowed to request access that is subject to review by this group of folks.

Sasha: So the obvious thing we want the organization to start having is to open this UI. Bringing their teams in a collaborative way, not an adversarial way. We don't want anyone to blame anyone, right? Because, Melinda, as you mentioned, folks have work to do. But what we can start having is this conversation. Whoever's the owner of this access group, let's change it from the long-standing privilege to the one that only is available on demand on just-in-time access. And then just one other part of Teleport Access Graph: we have built a more advanced system on top of this, what we think is a nice start. The more important piece is for folks to build long-term automation and long-term linting of their access across all their infrastructure. That's why we incorporated and built this on top of the foundation of SQL. So we built a SQL representation that allows us to ask more nuanced questions automatically. For example, let's see what `sasha` has access to, the specific identity, or let's see who can SSH into resources as `root`. In this case, it's again, unfortunately, me, who can SSH into all of those resources and `root`.

Sasha: Or even, let's see who can SSH as `root` from non-trusted devices. And what we want folks to start doing is, as they think about their code from the perspective of we need to build security scanners for this code, we want them to think in the same way about their IAM and policy posture. For example, this could be your security invariant or GitHub or Jenkins job that will return a non-empty set whenever someone is applying this policy. So you can raise an alert and say, "Folks, somebody has just provisioned a policy that allows somebody this `root` to the crown jewels of my infrastructure, and let's prevent that, ideally, right? Or let's at least have this conversation — have visibility — that this just happened." And that's the start of Teleport Access Policy.

Sasha: So the first six months of this year, we're focusing on incorporating more and more information. So we started with Teleport Policy incorporation in Access Graph, Okta, and other identities, AWS computing resources. We will expand to other clouds and other computing resources the first half of the year. And our second half of the year will be dedicated to making sure folks can use a similar interface to actually define policies, as I've said, in a unified way across all the infrastructure. Anyways. I'm going to pause here because I think I demoed a lot. And maybe we can have a discussion about some of those things that are interesting to the audience, or questions that you, Melinda or you Ev, or maybe ideas you have based on what you've seen.

Ev: Yeah. Thank you, Sasha. For us, cybersecurity people, it's always obvious that, "Hey, these problems they need to be solved." And we're looking at them, and we're screaming. And then we have these geeky discussions about the best ways of doing it. But, Melinda, I have a question for you. Based on the data that you have, are organizations beginning to realize that these are urgent problems to be solved? So what are they doing about it?

Melinda: Yeah. Yeah. Definitely. And I think organizations really are recognizing that they need some kind of modern approach compared to the solutions they have in place. A lot of them do have PAM solutions. So they realize that they need some kind of modernized approach to deal with scale and the complexity of developers quickly building their applications, resources changing around different cloud environments. It's a very dynamic atmosphere that traditional IAM and PAM approaches just don't really work well. And again, what was impressive to me about the demo and what you guys were talking about is building that foundation.

Melinda: The move to the cloud and the reasons why we move workloads to the cloud is all about efficiency and better tools for collaboration. And the challenge for cybersecurity has really been that we don't have that efficiency. A lot of the stuff that we're seen as being able to do is seen as, "Oh, now we're going to slow things down, or we have to put controls on, or we have to enact multi-factor authentication." So those are the things that are slower. And again, for me, it's kind of frustrating sometimes to see tools that are very focused maybe to support developers, but not really in the running applications, or maybe they're just all on the runtime. So it's very nice to see that you guys have kind of that lifecycle approach. Because if you do have that foundation built in, and you have that visibility, then it makes it a lot easier because you're reducing the chance of problems and misconfigurations in the applications that you're deploying. So those access points, that attack surface.

Melinda: When you deploy it to the cloud, those are things that are scaling. Those are all the things that scale with modern software development. And security needs to gain visibility and control of that to manage risk. And then, if there is a threat or an attack, they can respond quickly. And if they're only monitoring and catching things in runtime, then by the time things are deployed, there are already problems in there. Versus, oh, we'll have fewer problems materializing in production in the cloud when the applications are deployed, and then we can just only — there are threats and attacks that inevitably will happen, but the fewer of those that you have to address versus the things that could have been prevented, all those misconfigurations that could have been caught with the right tools and processes in place, then that is what makes an effective security approach.

Melinda: So you have to support digital transformation for security people, for CISOs to be successful. They need to be seen as enablers, not blockers, to modernizing that digital transformation because they want to enable the businesses to grow, and that is the key to their success. And again, you need to support scale and growth without disrupting the actual users. So the more that you can do so that developers can focus on building their applications instead of — I mean, it's good for them to be aware and be trained. But for them to actually have to do extra stuff that takes away from their time where they want to be building awesome applications, feature-rich applications without adding extra attack surfaces, the better success will be for security. And this is what excites me about covering this space: is seeing those modernized approaches that are coming out that are disruptive to traditional security and the old ways of thinking of just doing lots of things to test and alert for different attack surfaces. Now everything has to scale and has to keep up with that speed.

Attacks targeting identities are driving organizational commitment

Melinda: So we can go the — I have one more slide here to share. So when we ask, as a result of the cybersecurity attack tied to compromise of account or credential theft in the last 12 months: Did your organization have any business impacts? And you can see there's a lot of business impacts here that they suffered, which is bad to see. But I guess the positive thing is that there are people who are really increasing their cybersecurity budget around these issues and additional cybersecurity technologies invested in services. So you were asking about whether organizations realize the urgency and that they need to invest it. They absolutely do. And again, it's exciting to see that this is something people are addressing because it is such a — we see this as the top reasons for attacks and misconfigurations. And before, it wasn't a big part of — we have other things that we think about in cybersecurity. But to see people realizing how central identity is to thinking about how things are connected. Again, you talked about the machine identities in addition to the human identities. Those are big issues for cloud-native and the way that things scale. So it's definitely a priority that we see.

Sasha: Yeah. There are two other positive trends that we observe. I think the good news is that good security in the cloud actually is also a good user experience for folks. So we don't need to necessarily think of those as you have to trade one for another. And I'll just give two examples. The first one is when we started Teleport, this idea that password managers and vaults are obsolete was seen as somewhat controversial. Folks have been responding to us that this is just not possible. But over years, we've observed clouds getting on our side with the primary form of authentication to the critical infrastructure being IAM, which is essentially a passwordless system.

Sasha: So AWS IAM covers most of the databases [inaudible], for example, which is really great news for us and for the entire industry and our customers because they no longer need vaults. And the same applies to authentication. We've been one of the first infrastructure access tools and platforms that release completely passwordless access. And again, it has been seen as a little bit of a controversial move initially. But as I've been using access to Teleport, now it's really hard for me to go back from WebAuthn passwordless tap through Touch ID to access everything to going to 1Password and finding the credential or using some sort of clumsy plugin.

Sasha: And another positive side of that change and this tailwind is that it is actually phish-resistant as well. It's not phish-proof; nothing is, but it's actually really hard for an attacker to exfiltrate or almost impossible to exfiltrate the WebAuthn credential because of the challenge-response protocol baked in. So compared to other systems, like passwords, or SMS, second factors or TOTPs, the most secure one, in our opinion, is actually the easiest to use and preventing most of those identity attacks and stopping lots of them in their tracks.

Melinda: Well, great. So I think we're ready to take some questions. So if anybody has questions, you can enter them into the Q&A. But we do have a few more minutes for questions. So I see one question here. Should people think differently about privilege access and their IT and infrastructure strategies? And I'll start with this one. Yes. Absolutely. We see a lot of the challenges that I showed in my slides. And I think a lot of it is that just traditional PAM can't keep up with that complexity and speed and scale. And they need, again, a new modern approach that many of the things that we discussed address. I guess Ev and Sasha, anything to add there?

Melinda: Yeah. We spent a lot of time talking about the pains and challenges there. Another question here. What will the future hold for passwords? I know my opinion is just everything is about ease. And again, it's very relatable. I think everybody deals with trying to manage their passwords and do the things that they want to do, and they kind of know the headaches around that. Ev and Sasha?

Ev: So as I said earlier — first of all, let's be crystal clear. It's not really about passwords. Passwords is probably the most obvious, the most laughable form of credential that everyone just makes fun of passwords all the time. We're talking about getting rid completely of all forms of static credentials. That includes private keys. Public-private key authentication, we believe, is insecure because private keys are exposing you. We're talking about API keys. We're talking about browser cookies. Because people keep forgetting that, yeah, sure, you could have MFA, you could have a bunch of stuff implemented when someone is authenticated, but if all you get back is a cookie, that could be stolen and used somewhere. So then no, you're not passwordless. You're not secretless. So getting rid of all forms of static credentials, getting rid of all secrets — that is our view. We believe that presence, the mere existence of a secret, is a vulnerability. Managing them, rotating them, encrypting them doesn't work. We have data now. If you look at the frequency of breaches, it's on the rise. So cybersecurity industry right now, we are losing. And we believe that the two major reasons are relying on credentials, and the second one is siloing of access.

Ev: There was also a question here from Simon. Is Teleport Policy an included Teleport PAM solution, or does it require an additional license? So first of all, Teleport is not a PAM because we believe that PAM solutions themselves — they're just silos. So the way Teleport is packaged is that you have to purchase Teleport Access. That's the foundation that gives identities to everyone, enables the secure connectivity. So Teleport Access is a basic product. It does not include Policy. And then you can add policy to it later. So it's an add-on.

Sasha: By the way, you can try Teleport Policy just by signing up for Teleport Cloud. Although, for Enterprise, it requires a separate license. You can actually get a preview of that through a Teleport self-signup trial and see for yourself whether it helps you or not to understand the surface. Another thing I've mentioned is public-private key authentication. But I think what we mean by this — not all forms of public-private key authentications are the same. For example, if your private key is on disk and you share, or maybe even share the private keys on password manager, or maybe you never rotate it or have no idea how to rotate your private key with an appropriate public key, it is not as bad as password, but it's not much better. Let's put it this way. However, if your private key is secure on cloud, if it never leaves a YubiKey, for example, or Touch ID where you're using TPM, and on top of that, you issue short-lived certificates and you're using different form of attestations, that's a very different way of authenticating. Where it's really hard to — almost impossible — to exfiltrate this private key in the first place because the only way to do that is to try to break through the physical security or some bug in the secure on-cloud implementation. Just to clarify a couple of those points.

Ev: Okay. So we have time, maybe, for one more question before we run out of it. Okay. If there are no other questions, well, thank you so much for joining us. I hope this was educational, maybe even a little bit entertaining. Thank you, Melissa. Thank you so much for bringing us some hard data from the field. And that concludes our webinar. Thank you.

Organizations face increasing risk of data breach, with threat actors taking aim at credentials and standing privileges. So, what can companies do to protect their infrastructure? 