Transforming Privileged Access: A Dialogue on Secretless, Zero Trust Architecture

Join us for an insightful webinar featuring IAM analyst Jack Poller and Teleport CEO Ev Kontsevoy as they delve into the nuances of privilege management and the paradigm shift towards a secretless, zero trust, least privileged architecture for engineers accessing cloud and on-premises compute infrastructure.

In this engaging conversation, Jack Poller will share his expertise on the differences between securing privileges in IT and compute infrastructure, highlighting the limitations of traditional privilege management strategies and the need for a more robust and agile approach when securing infrastructure access.

Ev Kontsevoy will provide invaluable perspectives on how organizations can eliminate attack surfaces while enhancing the daily satisfaction of engineers who access critical resources. Ev will discuss the transformative impact of this architecture on security posture, operational efficiency, and overall business resilience.

Viewers will gain actionable insights into:

The evolving threat landscape and its implications for privilege management

Key principles and components of a secretless, zero trust, least privileged architecture

Strategies for implementing and integrating this architecture into existing infrastructure

The tangible benefits of adopting a modern privilege management approach, including enhanced security and improved user experience

Key topics on Transforming Privileged Access: A Dialogue on Secretless, Zero Trust Architecture

The major cybersecurity threats companies face are ransomware, zero-day attacks, and identity-related attacks, with identity attacks being the most prevalent and easy to execute through social engineering tactics.

Modern infrastructure environments are highly complex, with hundreds of technologies and layers that each have their own identities, authentication, encryption, and access controls. This fragmentation leads to increased human error risk.

All users in modern environments essentially have privileged access due to their ability to provision and manage infrastructure through code. Engineers often build "backdoors" for convenience.

Companies should adopt a "zero trust" security model treating all devices as equally secure on any network, with a default deny-all stance requiring authentication and authorization for any access.

Eliminating secrets by using hardware-backed machine identities and biometrics prevents credential theft from enabling broader attacks.

Consolidating identities across protocols and treating user/machine identities the same way allows implementing consistent access policies programmatically.

Access should be granted just-in-time and intent-oriented, with no standing broad privileges and with access revoked after approved activities complete.

Benefits of modernizing infrastructure access include increased engineering productivity/shorter time-to-market, better visibility into activities for auditing/forensics, and reduced operational overhead as companies scale.

Implementing strong access controls upfront avoids future security risks and technical debt from misconfigured or insecure provisioning by engineers prioritizing convenience over security.

Transcript - Transforming Privileged Access: A Dialogue on Secretless, Zero Trust Architecture

Diana: All right. Well, welcome, everybody, to the Transforming Privileged Access webinar. My name is Diana Jovin. I'm the VP of Marketing here at Teleport, and I'll be moderating today's event. I'll introduce our two guests in just a moment, but first, I'd like to note on the right side of the screen, there is both a chat and a Q&A button for question and answers. We invite you to introduce yourself and let us know where you're dialing in from in the chat, and feel free to ask questions in the Q&A tab at any time during the event. If we don't get to them, we'll follow up with you after the webinar. And as an added bonus, everyone who attends today will receive a white paper authored by our guest speaker, Jack Poller. So this will be available next week and we'll email it to you when it's ready. So now it's my pleasure to introduce our guests. So first, I'd like to welcome Jack Poller. Principal analyst, Jack Poller uses his 35 years of industry experience across a broad range of security, systems, storage, networking, and cloud-based solutions to help marketing and management leaders develop winning strategies in highly competitive markets. Prior to founding Paradigm Technica, Jack worked as an analyst at Enterprise Strategy Group covering identity security, identity and access management, and data security. And previously, Jack led marketing for pre-revenue and early stage storage, networking, and SaaS startups. Jack was also recognized in the “ARchitect Power 100” ranking of analysts with the most sustained buzz in the industry, with information featured in a variety of high-profile media outlets. So thank you, Jack, for joining us today.

Diana: Let me also introduce Ev Kontsevoy. So Ev is the co-founder and CEO of Teleport and an engineer by training. Ev launched Teleport in 2015 to provide other engineers with solutions that allow them to quickly access and run any computing resource anywhere on the planet without having to worry about security and compliance issues. A serial entrepreneur, Ev was CEO and co-founder of Mailgun, which he successfully sold to Rackspace. So welcome, Ev.

Diana: So today we'll talk about six topics for about five minutes each, and at the end, we'll have about 10 minutes of Q&A. So without further ado, let's kick this off. So topic number one is threats. Let's start with the trends in the threat landscape. So the question at hand is — what trends do companies need to be considering when developing their cybersecurity strategy? And so, Jack, let's start with you. When companies talk to you about cybersecurity threats, what type of threats are they most concerned about?

Jack: Sure. I think I boiled down the major threats into sort of three major categories: ransomware, zero-day attacks, and identity-related threats. And ransomware and zero-day attacks get a lot of press — ransomware because it's very, very common and it causes a lot of damage. And zero-day attacks, I think, get a lot of attention because they're unknown and people don't really understand them. The reality is, however, that almost no organizations are attacked by zero-day attacks. They're really less than 5% of all attacks that we've recorded. When we look at threat research from companies like Verizon or all of the major security companies, we find that the cyber — sorry, ransomware — is one of the largest attacks that we get. But most ransomware and most of the other attacks really start with an identity-related attack, where an attacker uses either stolen credentials or phishing or new forms of phishing, SMS-based phishing, which is called smishing. Or even now, the most recent attacks use artificial intelligence voice for impersonation to do a voice-based attack on identities. And all of these attacks are really an attempt to social-engineer a user into giving up their secrets that they've — shared secrets that are stored on a server somewhere to get access to your organization. And once they get access to your organization, all bets are off and they can start wreaking havoc one way or another. So really, I think, the big thing organizations need to be thinking about is how to protect their identities.

Growing interest in privileged access management

Diana: Fantastic. And, Ev, you talked to a lot of companies about threats as well. Have you seen any changes over the last few years that are driving stronger attention to privileged access?

Ev: Absolutely. So organizations are starting to recognize the trend that Jack was pointing out — that the vast majority of attacks, successful attacks, and pretty much all the recent attacks that we've seen in the news lately — I'm not going to name companies, not to make them feel bad — they were all based on attackers going after a mistake that a human is making. It's something that I actually want to highlight — that as any industry, cybersecurity space, we developed our own jargon. And so we say things like identity attack all the time. But I much rather prefer to use the term attacks based on human mistakes. Because for an identity attack to succeed, someone within the organization needs to make a mistake, and therefore — so the trend that we're seeing is that most sophisticated organizations are trying to engineer their infrastructure security, their infrastructure access policies to be immune to bad human behavior. That really is what enables identity attacks — humans’ behavior.

Ev: And the reason why they're also rising in popularity is just because there is no direct kind of technological response to humans accidentally doing the wrong thing. And I do want to mention that the rise in generative AI is going to be a — it will have much bigger impact than maybe most people realize on the cybersecurity landscape. Why? Because AI dramatically lowers the cost of mounting an attack. Because in all forms of security, cyber or physical, it's really kind of an arms race at defense versus offense, which means that the cost of attacking you should be higher than the cost of protecting. And generative AI allows a teenager from Chicago suburbs to be launching identity attacks to several companies at the same time. So it's coming, which means that the trend is to design infrastructure access around the idea that behavior of humans should not — that infrastructure should be resilient to bad behavior of people. That's really what makes you protected against identity attacks.

Diana: Okay. Fantastic. All right. I'm sorry, Jack, you wanted to [crosstalk] —

Jack: Oh, I was just going to add real quickly. I think it's a really important point to consider that from the cybersecurity industry as a whole, we've been very, very focused on tools that deal with computers, not tools that deal with humans. And a computer is going to behave the same way every single time. So it's very easy to make security control to deal with however that computer behaves. When you throw humans into the mix, their behaviors are completely all over the place and they're not very predictable. So it's a lot harder to create a tool to deal with a human failure or human issue or human manipulation or social engineering. And so the industry hasn't been focused on that very lately. It's only now that we see Teleport and other organizations that are looking at this particular form of the issue.

How to approach security and privileged access in today’s infrastructure

Diana: All right. So let's move on to topic two. So in your white paper, Jack, you talk about the differences between the way that technology operates in traditional IT functions versus modern infrastructure functions. Can you talk about what are these differences that influence how companies should think about security and privileged access?

Jack: Sure. Well, we've got sort of a long history of the way corporate IT, enterprise IT, and organizations have grown up to manage their computer infrastructure. And it really starts from the fact that we started with one computer, and we added one computer, and then we added a couple of network devices, and we added a storage server, and then we added a database. And slowly over time, we added these devices, and we didn't have — while we thought about it as complex, it was very standardized. You had a set of storage devices, a set of compute servers, a set of network devices, and maybe a database server, and that was it. Now, all of that was managed manually where an administrator would log into each device and configure the device. When a new device came on, you would put it in the rack, and you would start managing it manually and configure it manually. And even today, till you get to very, very large companies and very large data — sorry, data centers, most companies, their administrators, off the top of my head, they know exactly where every single device is, and they can point to it and say, "I have 20 disks running in that storage device, and I know all the storage, where it's allocated to," and all of that's managed in their heads or by Excel spreadsheets, and it's not a very big, complex problem.

Jack: Then when we turn to and we get the cloud era and we start getting into very, very large scale, where we're talking about not tens or hundreds of devices, but hundreds of thousands to millions of devices, it becomes impossible to do that manually. So over time, we've developed ways to automate this. And we think about these things in terms of — how do we automate and standardize and treat everything so that instead of an administrator configuring a particular server, the administrator thinks about it and says, "This is the state I want this to end up in, and here's a program that can go and take this pile of hardware and software and do all the configuration automatically to put it into the state I want it"? And then if I want to change the state, I just say, "Hey, here's the new state I want it to be in," and I let the tools do all the work, and everything is automated. And that creates a different way of approaching and managing your environment and different problems then, because now instead of just worrying about one or two administrators, we have to worry about the automation tools and what identities they have and what access they have to the environment, and we have to worry about the people and the programs that are doing this instead of the people managing it. So it becomes sort of a different problem space and a different way of thinking about it.

Achieving security in a context of overwhelming complexity

Diana: Okay, and, Ev, you've worked with a lot of companies that start with trying to apply traditional IT technologies to modern infrastructure stack. So what problems have they encountered? And what advice do you give to companies when they're trying to solve this problem in a modern infrastructure environment?

Ev: Sure. So I would categorize modern infrastructure as presenting two major challenges from a security perspective. One is what Jack already covered pretty well. Modern infrastructure is managed with code. It's elastic. It grows and shrinks. You simply cannot dedicate enough attention to each individual device. So provisioning as code, basically, places certain constraints on what kind of tools you could use actually to secure it. So manual configuration is out the window. And the second major challenge is explosion of complexity overall. So gone are the days when organizations could say that "Hey, we're a Microsoft shop," or "We're some microsystems shop where we use Microsoft SQL Server, we use Microsoft Windows, we use everything Microsoft where everything is neatly and tightly integrated." So I could use Active Directory and all these access controls at Microsoft designed to protect my infrastructure. That's just no longer true. In a modern cloud environment, companies have hundreds of different technologies that are built by different vendors. They don't interact with each other. So you could start enumerating every single layer, it's like you have Linux at the bottom, then you have virtualization. There's some VMware involved, maybe OpenStack, then there is containers, Kubernetes, microservices, CI/CD pipeline.

Ev: I almost sound like a stand-up comedian when I start enumerating all these things. But they go up and up and up. So you have hundreds of these layers. Every single layer has its own identity. It has its own authentication. It has its own encryption and secure connectivity. It has its own authorization, its own role-based access control that's not compatible with any other layer. There is an audit layer and compliance implications, and there is a talent shortage. You actually don't have people on your team who understand how to secure every single thing. So this fragmentation of identities then leads to fragmentation of policy. And that basically creates this perfect storm, a perfect environment for humans to make mistakes, which goes back to my earlier point — that your infrastructure needs to be immune to human behavior. And because all of this is controlled by code, you also have to keep in mind that infrastructure is most vulnerable, from a security perspective, when it's getting provisioned, which means that you have engineers who write all these scripts that provision infrastructure, which basically means that any person who is capable of coding can accidentally commit a mistake and you will get exposed. So to sum it up, that's what I would highlight, the fact that infrastructure is elastic and provisioned as code — that presents a challenge. And the second one is that complexity is absolutely overwhelming.

The security implications of privileged access

Diana: So let's drill down on privileged access a little bit further, and, Ev, this time we'll start with you, right? Often when you talk about modern infrastructure environments, you point out that all users are privileged, right, in some way. So in that environment, right, what should companies be looking for as a way to solve the security implications of how to interface with all of this technology?

Ev: So I like the way you put it — all users are privileged. That is the best way to think about privileged access management for modern infrastructure. So separating engineers into privileged and non-privileged simply makes no sense. You may even have an intern who's hacking on or coding on a Terraform script that is part of your production deployment. So that person makes a mistake and that script is responsible for provisioning infrastructure, and now you are going to be exposed. So that's one reason to be concerned. The second reason is — so if we accept the fact that engineers are actually responsible not only for building applications and running these applications, but also they're responsible for securing the infrastructure — and that just simply happens automatically because they're responsible for provisioning it. So my earlier point is that whoever provisions infrastructure is kind of like a super user, kind of like a root user for everything that you have. So which means that engineers, they will inevitably be facing this kind of security versus productivity trade-off.

Ev: So if I'm an engineer working in an organization and I'm building a system that does deployment and provisioning of infrastructure, I have all the incentives in the world to provision it in a way that's convenient for me to use it later, and that's not necessarily the most secure way to access infrastructure. I guess what I'm saying is it's quite common in organizations where engineers essentially build backdoors into the infrastructure, just for their own convenience, so it's easier for them to use it later. So this is why we keep reminding our customers like, "Do not overdo it on a security side." If you make it — if you make your engineers’ life absolute hell, that it's really, really hard for them to get their work done because of all these kind of security controls, all the red tape, constant login, login, login, you are creating incentives for them to commit undesirable human behavior and essentially build backdoors. So we like to remind them that, "Hey, remember that the secure path should be the happy path, or the happy path should be the secure path." They have to be the same.

Solutions for privileged access management

Diana: Okay. So, Jack, we talked yesterday, I think, about privileged access management and how — the problem that people are trying to solve can be different in traditional IT environments and modern infrastructure environments. And I'm using those terms kind of loosely to describe those worlds that you described at the start of the call. So can you talk briefly about what problems people are trying to solve in each case and what that means?

Jack: Well, if you think about privileged access management, it comes about — and Ev was mentioning this as well, is — again, we sort of look back at history and you had a set of group of people who were privileged users. They were admins. They were responsible for configuring your environment. And they had the ability — we call them admins, super users, root users — they had the ability to not only provision things, but turn them on and turn them off. And so we said that we have normal users who can just do normal things. They can use the services IT is providing. And then we have these privileged users who have these extra capabilities. And we said in the beginning of the industry, beginning of privileged access management, we said maybe that those privileged users should be — we should have extra security — we should think about them separately because they have this extra ability. So for example, I was talking years ago at the beginning of the PAM history to one of the major banks, and they had a very large virtual infrastructure with VMware, and they had somewhere around 500 administrators, any one of which could log on to any virtual machine in the environment and any virtual machine server and do a shutdown, and they did that — in the normal course of maintenance, they would have to do that to replace hardware or whatever it is. But because there was no extra controls, if they shut down by accident, they logged into the wrong machine, say VM 13 instead of VM 12, they could actually shut down the bank's complete programs and turn the bank off by mistake.

Jack: So that's very risky, and it's even riskier than if somebody steals their credentials and gets access and can do that. And so we said, "Let's protect those users separately." When we think about what Ev was talking about in the modern infrastructure where you have DevOps, the engineers are building the code, they're instantiating the services and running them as well as using them, and they use the same identity to use the services, create the services, configure and deploy and manage those. So anything that they do is going to be — as I've said, that's essentially privileged access. But even more importantly, it comes down to thinking about, any user has access to your set of data. And so all users should have the same protection in terms of authentication, making sure that they're valid users. And then they should all have what we call the principle of least privileged access. Users should only be given privileges to do what they need to do to get their job done and no more than that, and that's sort of critical for securing your organization, whether it's traditional IT or modern IT. But when we think about it in the sort of modern infrastructure case with DevOps, what does that mean in terms of least privileged access when they really need to have all this extra access? So then you want to think about, well, instead of giving them blanket privileges to do everything, how do I get tighter control over that? And how do I say, "Let's make sure that if they do a shutdown or they do a reboot or something like that, that's a supercritical activity, that they're authorized to do that and they're doing the right thing at the right time, and not give them standing privileges to do that at any time and any place"?

Security principles embedded in Teleport Access Platform

Diana: And, Ev, you've embedded some of these principles, right, in the Teleport Access Platform. Do you want to talk about what some of those security principles are and why they matter in this environment?

Ev: Absolutely. So the first principle is — so going back to — how do we make sure that our infrastructure is protected in a way that it's resilient to bad human behavior? I will probably disappoint the audience by saying that, hey, you cannot do that. Humans are very unreliable, moist robots. We will continue to make mistakes, no matter the amount of training that we go through. So people will be periodically responding to phishing emails and fake phone calls, and clicking on the wrong links, and opening the wrong attachments. That will never be stopped. But not all is lost. You could still make your infrastructure resilient to this behavior by preventing attacker of exploiting bad human behavior. Because remember, all these human mistakes eventually lead to credential theft, because that really is the target of an identity attack — to steal someone's credentials because commonly, credentials and identity basically means the whole thing.

Ev: So therefore, the first principle you have to implement is — just get rid of all the secrets. If there is nothing to steal from someone's laptop, then that identity being compromised is not that big of a problem. So what do I mean by secrets? It's not necessarily just things like passwords. There are all kinds of secrets that attackers are looking for to get access to your infrastructure. That's passwords, yes, but also API keys, private keys, browser cookies, session, token, secret URLs. There are all kinds of information on a laptop that could be used to gain access to your infrastructure. So the first thing that we advise is just get rid of it. Get rid of all secrets. Instead, you have to use a cryptographic identity, which basically means — it's a hardware-backed identity of a machine that user is using. So like every Apple laptop, for example, has a TPM trusted platform module on it. And even if laptops that your organization uses, if it doesn't have those, you could actually use like a biometric YubiKeys to implement same functionality via a USB. So then users would authenticate using combination of hardware identity. So it's like this particular laptop is trusted, but at the same time, they need to provide their own biometrics to get access. So that's first principle. Get rid of all the secrets.

Ev: Principle number two — you have to find a way to consolidate identities. Like I said earlier, you have hundreds of different technologies sprinkled all over your infrastructure. Not all of them are compatible with SSO, because remember, a single sign-on and identity platforms, they are enabled by open standards that exist in the HTTP kind of world, like SAML or OpenID Connect. That's how SSO operates. But that's not compatible with infrastructure protocols like SSH, MySQL, Postgres, and so on and so forth. So you have to find a way — how you can consolidate identities across all these different protocols, and also, how do you consolidate identities of users and machines? You have to treat users and machines exact same way. So that allows you to then implement policy in one place. So having a single source of truth for identity and a single source of truth for policy — that is what allows you to lower the operational overhead — programmatically, automatically managed policy for your infrastructure.

Ev: And finally, if you look at what that policy is supposed to be like — so I do want to agree with Jack strongly — is that the policy should be basically just-in-time access. And I have my own term that I wish I could popularize, basically intent-oriented access. Here's what it means. All of us would love to know that in a steady state where nothing is happening, nobody and nothing has access to your infrastructure. There are no deployments going on, no backups, no maintenance. Nothing's happening. You're in a steady state, which is most of the time. No one and nothing should have access to your infrastructure. So then if there is an event, there is a ticket created or some kind of alert that, "Hey, we need to run a deployment of an application," or "We need to scale up our infrastructure," so then the access needs to be granted on demand to whoever or whatever is involved into completing that task. And once the task is complete, then the access is revoked. So that, again, it's — everyone is dreaming about actually having a system like this, but it's only possible if identity and policy is consolidated in one place, and that's obviously what Teleport is helping companies to do.

The urgency of modernizing infrastructure access

Diana: Okay. Great. So there are a lot of different competing priorities that security and engineering organizations may have. So let's shift gears and take a look at — what are some of the reasons why modernizing infrastructure access is an urgent initiative today? And I'll open that question to both of you.

Jack: Well, I think, we talked about it before sort of in talking about what threats are available, what threats are happening today. And the key really is that identity-based attacks are very, very easy. They're incredibly easy. It's so easy to manipulate humans to giving up these shared secrets, right? Which is how password-based authentication one form or another, and even MFA-based authentication works, is through the concept of the shared screen secrets. And it is so easy to manipulate humans in one form or another that we have to sort of — very first steps really has to be — how do we do something to eliminate that, one way or another? And getting rid of the shared secrets eliminates the problem, and that's really what we have to start thinking about. And to me, tied in with that is also switching the way we think about protecting any part of our organization, particularly our modern infrastructure — is getting rid of the old concept of perimeter security.

Jack: We used to think about security as we had, it was the — we call it the castle-and-moat analogy, where all of our infrastructure is the castle and it is protected by a moat. And in the castle and moat environment, anybody who crosses the moat and is allowed inside the castle boundary is authorized to do stuff, see data, access data, see infrastructure, figure out what's going on. They can see all the different parts of the castle, get anywhere they want, and do anything they want. And that's just really bad for security because once the bad guy manages to cross the moat, they have access to everything. And so we really want to switch that and go to what's now called zero trust. And that's really flipping that concept upside down and saying, "There is no moat, and the only way you can get access to anything in the environment, even the drawbridge or the castle grounds or the castle or anything, is by proving who you are, and that you are authorized to be there and to do things and see things." And that really changes the nature of security to becoming much more strong. And certainly another way to think about it is we're going from a default of, "Allow anything," to a default of, "Deny everything and allow only authorized users to do things." So I think that's where organizations really need to start thinking about it for their entire infrastructure, particularly for modern infrastructure, since once anybody gets inside, they have the ability to do so much so quickly.

Diana: Great. Thank you. And, Ev, are there some other trends that you'd like to talk about that are driving urgency around these issues today?

Ev: Absolutely. Before I go there, I do want to — because Jack just brought a very interesting topic of zero trust. Actually noticing that people are confused by that term simply because it's been used by every single company in cybersecurity space, quite literally. Go to any cyber company and on the front page, they will say zero trust. So naturally, people are confused and some are even dismissing that as always just a buzz term, it doesn't really mean much. No, it's actually an extremely important concept. And maybe to simplify the meaning of zero trust for most people, I would maybe — I like offering this analogy. Zero trust effectively says that any computing device is equally secure being on a private network or on a public network. It basically says that your network neighborhood doesn't matter. And if you want to ask yourself, "Is my infrastructure truly, really zero trust?" The answer is — can you compare it to an iPhone? Think about an iPhone. iPhone is a perfect zero trust device. It's essentially a server built and managed by Apple.

Ev: iPhones run on public networks and private networks. They're not hidden behind any kind of firewall. They're not using network perimeter security to protect themselves. They're equally accessible. And Apple is managing billions of these iPhones all over the world and everything is fine and secure. So if you could open up the gates, you could get rid of all your firewalls and give every server in your production environment a public IP address, and you could sleep at night really well, that means you truly achieved zero trust. Making every server in your organization behave like an iPhone. That's what zero trust is. Obviously, it's hard to achieve, but we should try, because the security benefits are tremendous. It means the blast radius of any successful attack will always be contained within a single device, a single resource.

Lowering operational overhead and scaling without security posture deterioration

Ev: Now back to your question about the sense of urgency, why modernizing infrastructure access is important now. I might maybe offer an unusual view on this, because the general trend is that operating infrastructure is getting more and more expensive over time because of that growing complexity. So having access to my customers, I've always been asking them this question, "How is the size of your DevOps team growing relative to the rest of the engineering?" And almost everyone says that my DevOps team or platform engineering team is growing faster. It basically means that operating infrastructure, securing infrastructure is getting more and more expensive over time. And also, there's a talent shortage. There are plenty of organizations — and I believe we do have some data in Jack's paper on this too, that the talent shortage on the security side is severe. So therefore organizations, they must find a way to lower the operational overhead of securing their infrastructure, and they have to find a way to make their security posture not deteriorate as they scale. Otherwise, they will simply run out of money. Because managing infrastructure, again, is getting more and more expensive generally, and security is a part of it.

Benefits of privileged access initiatives

Diana: Okay. Great. So the last topic before we turn to Q&A — let's talk about benefits. So people do undertake these privileged access initiatives that are geared for modern infrastructure. What benefits can they expect to realize, both qualitative and quantitative? And that question is for both of you.

Increased engineering productivity and shorter time-to-market

Ev: So I'll start. I will maybe let Jack speak on security and risk management benefits, but I will mention something that almost every customer of ours told me. They said that one of the unexpected benefits that they appreciate the most about kind of embracing all these modern access principles that we talked about was dramatically increased engineering productivity, which effectively means time to market. So one of them shared an anecdote with me — that they've been building on this really, really complicated system, and they were extremely excited to launch it. They made all the announcements. Their customers are expecting launch to happen on time. But then their own DevOps team actually halted the progress and said, "Hey, we cannot be launching this because we don't know how to secure Cassandra." Cassandra was apparently the new technology that this solution was bringing into an organization and they operationally just simply didn't know how to do it securely. So that slowed everyone down. Our customers also sometimes use this kind of language that, "Hey, by employing all this zero trust and secretless access principles, we shorten the path for an engineer to do anything around here, which leads, again, to much, much higher productivity." So shortening time-to-market surprisingly could be a benefit of modernizing access to your infrastructure.

Logging and visibility into infrastructure

Jack: I think there are a couple other things that we see happening. We expect obviously increased security, reduced risk, but there's a couple of ways that are not obvious that that happens. One is there's what people think is a trite, but still very true adage in cybersecurity which is — you can't secure what you don't know about. So having visibility into your infrastructure is very important so you can secure everything. And in modern infrastructure, with DevOps, things are changing so very quickly and automatically changing, and new technology is coming about every couple of months. And now with AI, AI is creating new technology on top of AI, and there's all sorts of ways that we're using infrastructure we didn't know about. And when a DevOps engineer or an admin logs into or configures a new system, oftentimes, they do it using a shared identity, whether it's the master cloud identity or a root user on a particular server, or something like that. So it's very hard to know what they're doing and to attribute an action to an actual human who desired that action to take effect, or who did that actual action.

Jack: So with a modern system to control privileged access to your infrastructure and to do authentication and authorization, you also get logging and visibility, and then you get forensics after the fact where you can look and see, "Okay, something went wrong." Now we can see what went wrong and who made the mistake. And it's not necessarily because we want to lay blame. It's because we want to do corrective action. In the medical world, they have something called CAPA, which is corrective action, preventative action. It's after you identify that something went wrong, you figure out what went wrong, why it went wrong, and then you institute a corrective action to fix that particular issue and a preventative action to prevent it from happening in the future. And so we'd like to see tools that enable you to do that in the cybersecurity space, and I think what Teleport is doing does provide that capability. And so that's another benefit that you get that you don't think about in addition to just traditional reduced risk.

Diana: Great, thank you, Jack. So now we'll turn to a couple of questions that have been posted. As we do that, I just would like to point your attention to a survey. It's a very quick one-to-two question survey, and we would invite your feedback on whether you found what we talked about today useful to you. But now let's turn to the first question. So one of our viewers has asked, and I love this question because I talk frequently about the emerging role of the chief trust officer in an organization. And I think it's just such an interesting role with many different dimensions for how you drive trust into the company, into the customers, into the market. So our viewer has asked, "I believe in the field of cybersecurity, counter ransomware and counter deepfake, solutions have become more important than ever this year, referencing, of course, the major elections that are taking place around the world. We are already thinking about zero trust in the cybersecurity area. How do we create human trust around this?" So [crosstalk] —

Jack: I'm sorry, how do we create? I didn't hear you. How do we create human trust?

Diana: How do we create human trust around this?

Jack: That's a really interesting question. And I think the tools help you reinforce trust, not necessarily create the trust, if that makes sense. I mean, what are your thoughts, Ev?

Ev: So [laughter] it's a loaded question because it sits on this kind of intersection of kind of humanities and technology. But I will say, though, that in the field of cybersecurity and computing, in general, trust is — it kind of has a definition. So for example, most of us probably saw older hacking movies where they would refer to this famous orange book. Every hacker had to go and learn what's in this kind of magical orange book. When I started to hear this reference to that orange book, when I was a teenager, I looked it up, and apparently, yes, indeed, there was a book published by US Department of Defense. It was indeed orange in color. And I believe the title was, The Criteria of Determining Trustworthiness of a Computing System. So that book effectively answers the question: What is trust in a digital domain?

Ev: And I'm not going to quote the entire book here, but the point is — all of that criteria that was mentioned in the book traditionally has been implemented by operating systems. Going back to how you, Jack, started to answer the very, very first questions — back in the day, we all had one single computer, one giant beast in the basement. So that beast actually provided us with a trusted computing environment — because that beast ran an operating system, maybe some kind of Unix variant, and the operating system enforced trust. Every process, every user, had an ID. Remember UID, user ID, IID, PID, process ID. So there was a single source of truth for policy, so you could define who can and cannot access what. So the overall system was trustworthy. And that book actually solicited criteria, how do you determine trustworthiness? So therefore, if you ask me, how do we implement a trusted computing in the cloud? I say, "We need to scale up these concepts and make them bigger than a single machine." So if you could reason about your entire cloud environment the same way how a Unix user can reason about the mainframe, then I would argue that you achieve the trusted environment. But how do you scale it to internet scale? So then you say, "Oh, everyone and everything on the internet is trustworthy." So now we're talking about sci-fi, but hopefully it will happen in the future.

Diana: Okay. So one of our viewers also asked if there will be a high-level demo within the session. We will not be doing a demo here today, but we can point you after the call to a couple places where you can get your questions answered about how this works. And so we have a closing question here, and I'll ask this of both of you as well. When you're talking about privileged access with companies, what are the questions that come up the most often?

Jack: Let me give a quick answer and then I'll let Ev talk. But I was going to say the biggest sort of question is always, sort of, where do I start to get more security? Right? And how do I increase my security? And where do I start? And I go outside of privileged access to sort of what I consider fundamentals of security, which is start with mandatory MFA for every user, and really, if you can do it, mandatory switching to passwordless authentication instead of password-based, and it is just — MFA and passwordless are such a huge win. Just a quick antidote. I talked to the CISO, the chief information security officer of a financial services organization with 50 million customers, and when they implemented mandatory MFA for their customers, they saw the volume of attacks, not successful attacks, just the volume of attacks against their organization drop by 95% in two weeks, right, because it just makes it that much harder for attackers to get in. And so that's really sort of the starting point, and I think that that's — when you think about PAM, before you even get there, is — think about eliminating secrets from your environment. And then, Ev, I'll let you give your answer.

Ev: So for some reason, I've always been getting this question in almost every session where I would be talking about the importance of getting rid of all the secrets, because just the presence of a secret of any kind is a vulnerability, in our opinion. And people say, "But you surely cannot get rid of all the secrets. There must be a secret somewhere." Well, those who understand kind of PKI technology and public cryptography and how certificates work, people generally understand that, yes, you could issue a certificate, or you could sign something, and there's an expiration date because certificates have a TTL. So all of those things are ephemeral. So once they disappear, they are disappearing. But there is one secret though that is indeed present, so that's a private key of a certificate authority. And the answer is — the way you could get rid of that one is you stick it into HSM, a hardware security module, or a cloud-based equivalent. So what that means is that that secret now, while it still can be used to issue certificates and to do signing, it's not accessible to software, so which means that no one can steal it by uploading, downloading, cloning, or getting other forms of kind of software access to it. So that really, truly is how you achieve kind of secretless system, where the only secret that exists — it's a private key of CA. And CA is stored in an HSM. And the second question, which almost always comes up in that environment, is that "Hey, if I start migrating my workforce to secretless access, to passwordless access, then we will start relying on biometrics."

Ev: So some of my engineers or other employees — they might be concerned about privacy, because, hey, they would say sometimes, "I don't want to contribute my fingerprint to the company. It's my private information." Because people sometimes don't understand how the technology works. And the way it works is that the fingerprint reader is directly connected to a TPM, a hardware module on a laptop. And so it never leaves the machine. It's not getting uploaded or downloaded anywhere. In fact, software doesn't even have access to your fingerprint. It's the TPM actually that's doing validation of a fingerprint, and then simply produces true or false answer. That could be used for authentication purposes. So there is no violation of privacy. I also noticed there's an interesting question here that I do want to answer, because someone says, like, "Hey, how can Teleport be broken? And please don't lie about your tech weaknesses." So I'm not going to lie. So first of all, Teleport is a piece of software that can easily — and if we truly believe in what we say about the importance of human errors, I will say that misconfiguring Teleport, not using it properly, making a mistake when you're setting it up, when you're provisioning it, that's really probably the easiest attack vector. And the second type of human mistake is that if we made a mistake when we were building Teleport, there's some software bugs in it, and in other words, something we don't know about our own code is vulnerability. So for this reason, we bring external auditors who audit Teleport line by line, and we publish results of these audits on our website, which actually makes us quite unique.

Diana: All right. Fantastic. So with that, we'll end here. So I'd like to thank both of our speakers for joining today and, of course, the viewers. So we hope you found the conversation about privileged access valuable, and we look forward to seeing you at the next webinar. And I'll just remind everybody to expect a link to the white paper within the next week or so. Thank you so much.