Building Cyber Resiliency into Modern Engineering Environments

Building Cyber Resiliency into Modern Engineering Environments

As cyber threats grow in sophistication, organizations must evolve to stay ahead. This session focuses on preparing for future challenges by adopting strategies that prioritize adaptability, proactive defense, and a robust security posture.

Explore how cutting-edge technologies, shifting regulatory requirements, and emerging best practices can empower organizations to mitigate risks and respond effectively to incidents. Attendees will gain actionable insights into strengthening their cybersecurity frameworks, fostering a culture of resilience, and future-proofing their defenses against an increasingly dynamic threat environment.

Whether you're an IT professional or a manager, this session offers valuable guidance for navigating the complexities of cybersecurity in the years to come.

Transcript - Building Cyber Resiliency into Modern Engineering Environments

Introduction

Mackenzie: [music] We have got Teleport. So Teleport, we have Eddie Glenn, who is the Director of Product Marketing. We also have Dan Johns, if I didn't mess that up, Senior Solutions Engineer. Come on up, you two. All right. Welcome to the stage. I'm going to take my leave, let you two kind of introduce yourselves further, and give us all the good information, and then I'll be joining you as well for Q&A, you two.

Eddie: Great. Thank you very much. Hey, I'm really excited to be here. I'm Eddie Glenn, Director of Product Marketing at Teleport, and I've been a longtime software developer before moving over to cybersecurity companies like Teleport. And today, we're going to switch gears a little bit and talk more about resiliency around the engineering perspective of what common engineers encounter when they're trying to keep their modern engineering architectures and infrastructure up and running. So that's what we're going to be talking about today. Okay, one second here. So for those of you — I saw there were a lot of engineering titles in this call, so I'm really excited about that. But for those of you that might be in IT, I just thought it'd be useful to do a quick overview of what makes modern infrastructure and modern architecture so different and hard to protect from a resiliency perspective.

Modern engineering architecture

Eddie: First thing, and we heard a little bit about this in the previous conversation, is the presence of multi and hybrid cloud environments — pervasive. No longer are we protecting individual server machines in locked rooms, but these are spread across the internet. They're ephemeral, so they're constantly being spun up and spun down. So it's hard to know at any given time what's running, what's not running. They're distributed around the world, many different distributed teams that are touching them, and you still have to support physical machines. So that part hasn't gone away. So this makes protecting modern architectures very challenging. On top of that, we now have this issue of identities. So in the past, there might have been engineering teams of 50, 100, maybe 1,000 people that need to access infrastructure resources, but with modern architecture, that is very different. I mean — we're now dealing with non-human identities.

Eddie: And when I talk about non-human identities, I'm talking about things like service accounts, the scripts that build software that gets pushed out to our platforms, system accounts. It could be containers like Kubernetes containers, microservices, databases. Basically anything that runs your infrastructure is a resource that needs to be protected from compromises that can come through either human identities or non-human identities. So when we talk about non-human identities, frequently, we're meaning things like API keys, tokens, SSH keys. In addition, on the human side, obviously we're talking about passwords. So why does trusted computing matter now? And I'll tell you a little bit more about Teleport in just a second, but obviously there's one aspect here that the infrastructure is very complex now. So protecting that—making sure it's resilient — becomes very difficult. But the other thing that we're seeing is identity has become the primary target for threat actors. And not only is it a target for threat actors, but it's an issue around just human error. Someone accidentally includes an identity, an SSH key, and a script that gets published to a source code repository.

Why trusted computing matters now and what Teleport does

Eddie: So we're dealing with this both from two angles, threat actors compromising identities, as well as just accidental bad practice. Then, obviously, we've got AI, it’s here to stay, and it presents a set of unique challenges that impact — some of these identity attacks are becoming more sophisticated, and then we're all experiencing that. For many industries, the amount of regulation is increasing, which impacts how engineers have to log and keep a record of the security of their infrastructure systems. So that leads me into what Teleport does. I just want to make this really quick and simple. We're focused on making computing trustworthy primarily around the infrastructure access for engineering teams. We're focused on modernizing how identity access and policy is handled for engineering infrastructure, and we're doing this for both human and non-human identities. And a benefit of using Teleport for your organization is that we not only improve the resiliency of your infrastructure, and we protect it from compromises and attacks, but we can also improve the velocity that your engineering teams can go.

IT-centric solutions do not scale for infrastructure

Eddie: And this is one of the things that we hear over and over from our customers — is that their engineering teams need to be able to respond faster to the work that they're doing. They need to have access to critical infrastructure resources when they need them. So that is what Teleport does. We're focused on that engineering infrastructure space, a little bit different from the IT space. And why does that matter? So when we think about IT-centric solutions, they were created for a very specific use case. Engineering solutions are focused on a different set of use cases. And again, we still have the issue around resiliency, making sure that identities don't get compromised. But we also, for engineers, have to take into account that need for speed, that they can't be slowed down in what they need to be able to do. And this is one of the complaints that we frequently hear from our customers — is that their companies are trying to leverage maybe older or legacy systems that were designed for IT use cases, and they're having a hard time doing that for modern infrastructure. So that's really what Teleport is focused on and the rest of the demo here that we're going to do, and I'm going to speed this up really quickly because I want to leave Dan plenty of time to show you a really cool demo.

What is infrastructure identity architecture?

Eddie: So what do we mean by infrastructure identity architecture? And there's four key things, and this will help you understand what Dan's going to show in just a few minutes. But at the foundation of what Teleport means by infrastructure identity architecture is that every identity is based off of a cryptographic identity, and it's not tied to a static credential like a password or an SSH key or an API token. So Teleport generates cryptographic identities for every resource within the infrastructure. And the other important aspect of this is that we unify this across many different systems. If you remember, I just said a few minutes ago that modern systems are very diverse in the kinds of assets that are used for infrastructure. It's multi-web, hybrid, still have physical servers, software services, Kubernetes. And traditionally, those have all been handled kind of individually in their own silos, and what Teleport is able to do is to bring all of those together into a single identity platform where these identities are tied to cryptographic tokens.

Eddie: The next step above that is the ability for us to provide that Zero Trust Networking. We call it Zero Trust Networking+ in that we're providing system-level encryption, session-level encryption, and authentication constantly across and between all resources within your engineering infrastructure. So it's just not one time, it's constantly, and that's why we consider this a plus to ZTN. And then the next important step here is making sure that privileges are short-lived. I'm an engineer. I love having that access to that database because I just might need it one day. Maybe not for a couple of months, but if I still have that access, it's a longstanding privilege, and if I get breached, it makes me susceptible to having that entire database breached. So Teleport's able to provide very efficient, short-lived privileges that are needed only when tasks are being done by those particular engineers, and this extends to machines. So if there's a build script that needs to access a particular infrastructure resource, we can give that build script that permission or that privilege just for the time that it takes for that script to execute.

Teleport infrastructure identity platform

Eddie: And then finally, the final tier for what we consider identity infrastructure, identity architecture, is providing the audit proof that's frequently needed by regulatory agencies now that shows a record of everything that's been accessed, by whom it's been accessed. And basically, we're eliminating this whole idea of anonymous computing. So there's no more shared passwords, there's no more shared SSH keys. We're able to track all access requests across an entire set of engineering infrastructure. And with that said, what does that get customers? We see two primary benefits. I've mentioned them already, but I'm going to break them down, in a little bit more detail. We allow engineering teams to move faster. So they're not waiting for access to certain infrastructure resources. They are able to move faster because they're not using legacy systems that weren't really designed for modern infrastructure like VPNs and bastions, which has been a very common way to provide some of that security. Eliminating the need to use legacy PAM solutions that were more built for IT use cases — we allow engineers to be more efficient and be able to move faster by eliminating those access silos that I've talked about. So that's one aspect of it that's very important for engineering teams that may not necessarily be as important to IT teams. And then the other aspect is the security, the resiliency. We're allowing our customers to transform their security model by eliminating completely static credentials by being able to enforce this privileged Zero Trust Access across everything, not just a few parts of their infrastructure, but everything, and then doing that across the full multi-cloud. And with that, I am going to turn this over to Dan so he can use the rest of our time for our demo. Off to you, Dan.

Teleport demo

Dan: Sure. Thanks, Eddie. Can I get a screen share — that button? There we go. All right. So here is my authentication screen for Teleport. I want to emphasize exactly what Eddie was talking about, which is the different ways that we can log in to each infrastructure. You can see here this is pretty basic for like a human user, and that here I have a couple of single sign-on providers. We support passkeys and usernames and passwords and things like that. And I'm going to start by authenticating with Okta. And I think that really lends to that conversation about, how do we do identity? On the human side, this problem is generally thought of as like, well, identity is your single sign-on user, something like Okta, Entra, something like that. On machines, it can be a bit more complicated. How do we identify a machine if we're not relying on like a static password? And for things like that, we say things like, how can we do a further step of identity? Maybe something it's like an IAM role in AWS or a TPM on a physical piece of hardware inside of a data center.

Dan: And here within Teleport, sign-in with Okta, I'm always suspicious of that. What if my Okta session potentially has been stolen? What are some additional steps we can do to validate? Teleport supports something that we call Device Trust, for example, where we can validate not just that Okta session, but also the physical hardware that I've used to authenticate, really taking this identity policy to its logical conclusion. How many ways can we validate that a person or a machine is exactly who they say they are? And then how do we grant them appropriate access based on that identity that we've validated? So here, within Teleport, you can see that I now have access to all the resources that I would access day-to-day. We do all of this using sophisticated encryption methods. There are no passwords here at all. We are not a vault. We do not store any kind of long-term credentials. Everything that I access today will be granted ephemerally, temporarily. Here, for example, I have this Linux server that's just labeled cloud. And here in the web UI, I can hit, "Connect" and can go ahead and connect to that as the shared user `root`. Generally wouldn't do this, but I'm going to do it for the webinar today just to wake you all up with accessing a `root` user. Feel free to shout at me in the comments.

Dan: So with the web UI, what you will see here is I've just signed in with Okta. My identity has been validated using multiple steps. Once that identity has been validated, I'm then able to gain access to this Linux server as root without ever typing in a password. And I have that access because of my identity and who I am and traits about me, which I'll cover shortly. Because I'm using the web UI here, I do also want to validate that everything that I do within Teleport can also be done through the command line. For example, if I do `tsh login`, and I specify my auth mechanism of Okta, you'll see what happens — is it opens my browser, finds me in through that same single sign-on source, again, validating my hardware, and that [inaudible] me a Teleport session. And from here, I can then go ahead and sign into whatever server I need to connect to, same as what we just saw using the command line accessing that system.

Dan: I'm using SSH as my example protocol today, but what I'd like you to keep in the back of your head is that Teleport supports a wide variety of protocols, everything from like MySQL or PostgreSQL databases to Kubernetes to web applications to Windows desktops. We want to touch as much of the infrastructure as we can to create that identity authentication to get you into those pieces of your tech stack. We want to do this with native tooling. For example, what you're seeing here, I'm using a terminal. This is Warp. This is publicly available software. There's nothing special about me authenticating through Teleport. We're meeting the engineers where they are as a part of this authentication. This works the same for something like bot users. If I wanted to grant, say, a machine access to SSH or Kubernetes or a database through something like Teleport, we have a service that we call Machine ID. Machine ID can validate based on IAM role, based on a TPM chip, based on a wide variety of different things that we can use to identify that machine specifically. Again, that way there is no password vault. I don't ever have to hard-code my username and password into a GitHub file or something like that. I never have to commit those credentials long term. Everything is done based on a repository URL, something that we can easily identify as the machine is what it says it is, without the use of a static credential.

Dan: One other thing I want to emphasize is additional validation steps. For example, as we mentioned here, I have this Windows machine here. I'm going to connect to this Windows machine as administrator. What I'm doing here is I have a policy called per-session MFA. This requires me to have an extra step of validation when I go to connect to this machine. In my case, it's going to be a passkey. Now, this can be something like a YubiKey, as you can see here with MFA device, or I can hit this passkey button, and it's going to open up my 1Password passkey vault. And authenticate through that, hit, "Sign in," and it logs me into the Windows machine, and then I can go ahead and do whatever it is I need to do. This is all through the browser. This is all based on information about my user that's granting me this level of access — that specifies not just that I'm allowed to access this machine, but I'm allowed to access this machine as administrator.

Dan: Back here in the UI, I can go to my audit logs here, and you can see I have this audit log field, and this tracks everything that happens while I'm signed into my session. For example, when I signed into that Linux session earlier, we can see all the commands that were executed as a part of that session. I can, for example, open details here. Here, you can see the path of the command that I ran. You can see the machine that I connected to. Its host name was cloud. You can see that I signed in as the user of root tied to my login here, along with this user path, which is my original single sign-on user that I signed in with. And this is a common trait across Teleport. We can do things like dynamically create users across things like Linux boxes and databases, or we can use pre-existing users like I did here with `root`. But the common theme will always be that I can associate whatever action is taken back with the original single sign-on user who connected to Teleport. So no matter who I am or what I do, if I signed into Teleport, you're going to know it was me based on my identity.

Dan: I want to touch briefly on how we perform role-based access control, and this is all attribute-based. So for example, if I go over here to my Zero Trust Access and I look at my auth connectors, you can see I have connectors for things like Okta and GitHub. If I open this GitHub connector here, you'll be able to see — I'm going to go ahead and drop that for a moment. You're able to see the `teams_to_roles`. And this is looking at the attributes from my Okta connector that specify what I'm actually able to reach. So in this case, we're looking at — I'm on this team of `everyone`. And then I have these roles within Teleport that I map to. If I cancel that, what we're doing is — when I open these roles, you can see we're looking at the attributes about me that grant me a specific level of access. For example, I have a role in here called `contractor`. If I connect to Teleport using an attribute that has this `contractor` role, you'll see this user is able to sign into Linux servers. That's this `node_labels` field here, this login of `root`, `ubuntu`, `ec2-user`, or this variable, which is their username. But only to servers that have been tagged as `dev`. And when I say servers tagged as `dev`, this is done on the actual server itself.

Dan: So when I provision a new, say, Linux box or an EC2 instance, I'm labeling that either through cloud-based tagging or static tagging in configuration file, saying, this `env` equals `dev`. It's not something that I can ephemerally add to a wide variety of servers if I wanted to commit a security breach. I need to have access to grant access. And then here under the roles, I also have this `request` field. This allows me to request additional resources through what we call Just-in-time Access. So what I'm going to do here is I'm going to grab the secondary window here, and this is the second session that I have open, and this is signed in with that `contractor` user. And you can see here I only have access to this one server called `dev`. But if I hit "Availability" I have this field called “Can be requested”. This is the ability to temporarily escalate my permissions to ask for additional resources. For example, if I wanted to gain access to that same cloud server that we accessed before, along with maybe the AWS console or MySQL database, I'm just going to add these to my cart and hit "Proceed to request."

Dan: What I'm now going to do is I'm going to submit this as a request to an approver, potentially my manager, to say, "I want to access these particular resources." I'll say, "I need this for today's work." And I can then do something like tag an individual who can approve this, something like — if I wanted to tag Eddie, say, "Eddie, please go approve my request." That can be routed here. This supports a wide variety of plugins. So within submitting this request within Teleport, I can also then have this forwarded on to something like Jira or PagerDuty or Slack message to say, "Hey, Dan has requested access to these resources." I even have that here in my Slack window. You can see, "I need this for today's work." Here's a list of resources that I've asked for and a link to the approval flow. And if I jump back over to Teleport here, close out of the role editor, if I do a refresh, there should be a little bell here that says, "Dan has asked for those resources." Go ahead and approve that access. I'm going to say, "Start it immediately." I can specify an access duration as well, both in my request and in the approval.

Dan: So in this case, I said I needed this access for my session length, which was 12 hours minus the 13 minutes I was connected for. I could also say, "I need this for less time," something like — maybe I only need these privileged resources for the next two hours to do my deployment or something like that. That's also something we can specify at that review. And again, all of this goes into those audit logs. So we know not just what was accessed and what was done, but also, who had the access? And when was it approved? And when did it expire? All of this is included in those JSON-based audit logs. I'll come back over here to my less privileged user and I do an assume role. When I open a new tab, sure enough, there are those three servers I requested, AWS Console access, the Linux cloud server, and this MySQL database. One last thing I want to highlight briefly is our identity security tool here. So here, for example, I can see that same level of access that I have been granted. So for example, if I wanted to know who has access to what, either standing credentials or through short-lived credentials, here I can hit, "View access," and here's that contractor user. And you can see that through `contractor`, I have these dotted lines showing what I'm allowed to request, along with this solid line showing environment of `dev`, showing what I am able to have long-term. So I know that I have long-term access to anything tagged as dev.

Dan: If I go over here, I see that reflects this server, along with these dotted lines that show all the things that I could potentially request. This really helps to enforce the law of least privilege. So we're not only enforcing things like identity based on attributes, based on the workload that should be performed, but then we're able to visualize that as well. We're able to say like, "Hey, should anyone ever be able to access the prod environment with standing credentials?" If the answer is no, here's a way to easily visualize that and then clean that up in our roles. And we can always trace it back to the resource group and the role that grants that access. So that's something that can easily be revoked. And I'd go so far as to build on this by mentioning our Crown Jewels tool, which allows you to monitor specific resources and then get log entries to say like, "Hey, the production database, which should never have access, someone was granted access to it." And then you can create alerting based on those notifications to say like, "Hey, let's go and get that cleaned up immediately." And in a very quick nutshell, that is Teleport. Have we gotten any messages in the chat or any questions?

Key takeaways

Mackenzie: I'm going to join you for some questions. I know that you have maybe one slide in here for some final key takeaways. Did you guys want to touch on that now?

Eddie: Yeah. We can, if we still have a few minutes. I know that we're running behind. So key takeaways. Trustworthy computing is an infrastructure necessity in today's landscape of identity attacks. Can't stress that enough. Every day we're seeing identities that are compromised that are impacting critical infrastructure across large, well-known brand companies. So key takeaway — if you continue to rely on static credentials and standing privileges, you're going to have a problem. No matter how many vaults you use or how many password managers you use, there's going to be a problem, and they don't scale for infrastructure. And again, with kind of an older infrastructure, it might have been manageable, but with modern infrastructure, we're dealing with thousands or tens of thousands of identities and resources. And so you really need a solution that supports eliminating static credentials and standing privileges. And then the final key takeaway is the importance of unifying all of this into a single place. That's one of the problems that a lot of companies have today — is that they've spread these tasks across different silos, and there's not a unified way to control that access and identity across the different silos. And Dan showed us in his demo that, from our perspective, they're all the same. It doesn't matter if you're accessing a database, if you're accessing an AWS Cloud Console or a server or your machine service account, it's all going to be treated the same. So those are the main takeaways, things that our platform has targeted. And then I also just wanted to remind that we have a resource that could be downloaded from the docs tab.

Mackenzie: Yeah, beautiful. Thank you. And that's a solution brief, if I have that correct. Secure machine-to-machine communication from you guys at Teleport. I have to say, love the demo, by the way. Love seeing the flows and how they're all connected. Super visually satisfying, but, of course, based on top of so much data and so much user functionality. So great job, you guys. We've got several questions. So I'm going to pitch a few here. First one here is from Doug Mounts. He's saying, "Any frustrations between accessing Linux and Kubernetes versus Windows? Apologies for expressing any prejudice." [laughter]

Q&A

Dan: Yeah, and I share your bias. The nice thing about Linux and Kubernetes is we can integrate very easily with all of the native tooling that is there because these are open source protocols. So when I want to access Kubernetes, all I have to do is create a `kubectl` profile and a `kubeconfig`. And then that can be easily reached through Teleport, and all the Kubernetes native tooling is open to me. Teleport integrates seamlessly with that. No frustration, no mess. Very similar with SSH, our tool is utilizing a fork of open SSH when we make our connections. Again, very easy for us to create that connection just using the OpenSSH tooling. So if we wanted to do something like forward a port or an SCP transfer or something like that, we can easily be a drop-in replacement for SSH connections. With Windows, we are currently using the browser for our RDP-based connections. The reason being Microsoft is not as friendly with having a middleman in between the user and the target machine, and they want to control a lot of that, RBAC and things like that. So we do support connectivity to Windows servers, especially in complicated environments, but I wouldn't say we're a good drop-in replacement for something like TeamViewer, for example, where it's going to be a lot of desktop users accessing remote services.

Mackenzie: Awesome. Thanks for clarifying that. Mark has a question here saying, "How do you ensure the resilience of the Teleport's network infrastructure against potential disruptions?"

Dan: Great question. So there's a couple of answers here. The first one is Teleport is both cloud-hosted and self-hosted. So you can either do a full SaaS offering in which we host the infrastructure for you, and we have 99.9% uptime on our platform. And we host that in AWS for the DynamoDB backend. So we have a lot of the protections of AWS's SLAs behind us when we're supporting these tools, and we are globally distributed. And then on the actual infrastructure side, the connections come to us outbound when we're a SaaS tool. So this is then exposing things like Port 443 outbound from a Linux server to connect to Teleport to grant conditional access. That way, if there's a hiccup in the network or something like that, or if someone creates an inbound firewall block, Teleport remains online. The other answer is you can also just completely host our entire tech stack within your own data center if you're so inclined. And that really is the flexibility of Teleport, and that you can choose to deploy the entire thing inside of your data center. And this is what a lot of our customers when they have complex compliance requirements, something like FedRAMP, have chosen to do, because then they can say, "We own the auditing. We own all of the connectivity. It never leaves our site." We meet a lot of compliance requirements with our cloud tool as well, things like SOC 2 and PCI. But for those really high-moderation environments like FedRAMP, self-hosting is also a very good option.

Mackenzie: Great. Cool. Actually, this isn't exactly the same, but kind of connects in mentioning kind of self-hosting versus cloud. I have a question here about scalability and some — basically, how does this scale for like hundreds or thousands of users?

Dan: Great question. So the first part is Teleport scales statelessly. We are based on a proxy layer and an authentication layer. The proxy is what performs the connection, and then the authentication layer performs all of our identity checks. Combined, those two things are stateless. You can deploy as many proxy layers as you'd like. You can scale the auth layer as far as you'd like. So hundreds of users across like a large-scale enterprise are able to utilize Teleport, and many of them do. We are in Fortune 500 companies today, across hundreds and thousands of users being utilized at scale. The other question is — how do we map things like policy? Which can be very complicated, because what Team A needs can be very different from Team B. Because of that, when you're trying to operate at that type of scale, we support attribute-based role mapping. For example, if I wanted to sign in as like the site reliability team, I can be informed that I'm on the site reliability team as a part of my single sign-on flow. So when I sign in through Okta or Entra, I get the group information that says, "Site reliability." What I can then do is create a policy that says, "People on site reliability are allowed to connect to servers that are labeled as site reliability." That way, there isn't management overhead for every single individual as they're trying to map these things. And this is very different from this traditional pattern where when someone, say, joins a new team or onboards to a company, and it takes weeks or months to grant them appropriate access. With something like Teleport, they get added to a group and they have their access, and they're off. There's nothing else to onboard.

Final thoughts

Mackenzie: Nice. Nice. Thank you. Well, this is great. I've really enjoyed seeing all this in action and also getting to pick your brain here. We do need to kind of wrap this up, but any sort of final either call to action or if there's just anything you're particularly excited about, you guys want to share as a final mic drop moment, if you will, to the audience? Eddie and Dan, I'll give you both the opportunity there.

Eddie: Yeah. So my excitement as a former software developer is a solution that really addresses that market need around engineering infrastructure. I remember trying to use IT-centric tools and they're hard for engineers. So that's one aspect. The other thing for call to action is that we do have a free 14-day eval or free trial on our website. So if anyone wants to try this out, they can register it and give it a try in their environment. Dan, anything else to add?

Dan: Yeah. I'm really excited about where Teleport is going with our machine-to-machine access. I think we've gotten very good over the years at granting individuals access to machines that they need. What I'm more excited about is this kind of historic problem of, how does Machine A connect to Machine B? And how do you identify what Machine A is? The historic way of doing this has either been like vendor-locked with something like AWS roles, or it's tied to something ephemeral, like an IP address, or if you really have no other choice, maybe it's a password, which is easily leaked in a security breach. Teleport's really trying to solve these problems using certificate-based auth, and we're exploring the SPIFFE protocol, if anyone has heard of that. I would really encourage you to check us out specifically for machine to machine as well. I think there's going to be some really critical breakthroughs in the coming years in that space, and I'm excited to be part of it.

Mackenzie: Nice. I love that. Thank you. I feel excited. Third-degree excitement. I don't know if that exists, but I've made it up today, so. [laughter] Awesome. Well, thanks again, Eddie. Thanks again, Dan. It's been so great, and looking forward to the next time and hearing more about this as it evolves too.

Eddie: Okay. Great. Thank you.

Mackenzie: Cheers, you two. [music]