‍

Video Transcript

Lance Larsen:

Todd, welcome. It's great to see you. I know you quite well, we go back working at places like Hasicorp together. Really excited to have you on today to talk about AWS. Before we get into it. Could you help folks understand your background a bit and introduce yourself?

Todd Thiel:‍
Thanks, Lance. Hey, folks, my name is Todd Thiel. Today, I'm a security architect with Robert Half. I've worked at companies such as Marqeta, Hashicorp and Veeva. And I've always kind of been the resident I am nerd within my organizations.

Lance Larsen:

I'm Lance, I lead our solutions team here. At Opel, I've been here about a year. And prior to that I worked at places like Hashicorp. Todd, you know, we were both there during that run, and then used to work on a lot of security consulting projects at places like Accenture. So I like I like our background, because I think it intersects a lot through these problems with different lenses. But ultimately, I think we have some interesting experiences around the challenges with AWS. And that, and that's sort of what I want to get into with you today. So I think, moving into the first part of this talk, I really want to try to work on this problem in three distinct areas,: One, sort of the historical perspective, and two, what that meant for people operationally trying to meet their business goals. And three, based on those two things, where do we go from here, right, and the first, when I sort of look at, you know why AWS has been historically hard. There's a couple key areas, at least in my experience, where that's been most prevalent. But I think the biggest problem to me was, at least in the very early iterations of AWS, there weren't a lot of scalable solutions available.

Todd Thiel:‍
For the longest time. AWS was kind of organized in the single account boundary world where you needed static credentials and service account users to perform the orchestration. It felt like 80% of the orchestration was at the IDP level and only 20% was at the actual account level. But when you tried to scale that, you started running into hurdles, not only at the AWS level, but also at the IDP level. And so many teams that had the luxury of having the funding, and also the exceptional talent to build their own tools internally, began doing that. The bigger issue with trying to scale and follow what AWS is giving us prescriptive guidance, is you're still beholden to either your own homegrown tooling, and making sure that the feature and functionality can keep up with the way it'd be us evolves? And also, how do you operationalize? How do you ensure that the proper roles and even just entitlements within the AWS account itself are scoped to the proper teams? How do you capture those teams that need that there's a whole lot of operations that goes into play, just to keep up with the model on the on the screen right here. that I feel is has been one of the bigger challenges with some teams that opted to build their own tooling. They have to build a whole heck of a lot more, and they become kind of married to that process.

Lance Larsen:

Yeah. And I really liked that summary, Todd, I think that nails on it just it sums that up nicely, right? I think, you know, we had more, we didn't have a ton of prescription we had people using fewer accounts. Over time, the model evolved to where these multi account boundaries became the correct way to do things. But that put this big burden on teams to scale out the either internal tools or processes, the AWS IAM identity Center, which is now the rebranded AWS SSO, I think that was a great investment from Amazon, in trying to make that process a bit easier to manage. Can you help explain what AWS identity Center did?

Todd Thiel:

Prior to AWS identity center and AWS SSO you had this this federated SAML or OIDC model from your IDP into your AWS accounts. And that just became a burden to maintain as your account scaled. So it also required probably like 80% of the configuration to be on the IDP side, whereas really small amount of the configuration is on the AWS side, right? Whereas AWS SSO made it. So 80% of the configuration is now within your organization. And a little bit is on the IDP side. And you have a lot more flexibility with how you can orchestrate that. And it's also just easier in general to scale using permission sets

Lance Larsen

while we've solved some of the scalability challenge and scalability is still approachable. I haven't seen overprovisioning really be solved with the AWS identities, IAM identity center. And if you had folks who are over provisioned and, you know, 10 accounts, or use the AWS identity center, you made that migration and maybe now you're managing 100 accounts, if you weren't able to solve the overprovisioning problem in the smaller set of accounts, migrating to AWS IAM identity center wasn't a magic fix or silver bullet to solve that problem.

Todd Thiel:
But the bigger challenge is security teams have when they come in with Authz tooling is understanding who are the owners? Who are the teams, what does this account do? What does it done historically, versus what does it do now. And unless you have a robust communication culture, within product teams, where they document what they're doing, keep things accurate. Teams are relatively consistent in both the tenure of the individuals on those teams and their scope and their purpose. If you're in an organization that isn't hitting a lot of the marks, it's going to be increasingly more challenging to just get the context behind an AWS account, because there's only so much that a log can tell you. And there's a lot of investigation, that in itself is a sunk cost, because you have to go dig through the codebase. You got to go dig through historical documents slack. It's challenging.

Lance Larsen:

Yeah, Todd, I agree with that. And, and I put together just a little visual here on on sort of, because I think context, people always ask what it means, right. And I found that the context most people are familiar with Todd is I think the simplest one that you described, are, do they belong to a specific team, right, if you're on this engineering team, you get access to a subset of, you know, accounts, right, or permissions, but I think you called out, if you're only looking at access from a team context, and you want to do fine grid permissions. One, it's really hard to manage all those rules. And that that creates some of that operational burden you talked about, that's one thing I would call out. And I think the second thing I would say is, if access is always indefinite, based on a team, you're probably going to be giving out more access than you need.

Todd Thiel:‍
I think it's accurate. It's also something that it becomes far too easy to kind of templatized on that, in that like, you're on this team, you get full access all the time to all of these resources. Me Maybe maybe the story changes over time, and the individuals that are running your IAM organization are in the loop. So it's really challenging to keep up with static assignment baselines, like I just described. And so that's why having a lot of the myriad of options around how and why people access a given resource, can can help drive a lot of the logs and metrics and also a better understanding of your organization to determine just what are people doing? What do they need more of? How are they accessing it?

Lance Larsen:
I think that's what that's what people want to get to. And I think I think now and Todd, I love how you summarize that, because I've just structure a lot of projects for people, right? So it's trying to find, you know, which things are the most relevant in their organization? You know, what's the low hanging fruit? Oh, we already have our on call, or we have a escalation process or JIRA. Those are great starting points, depending on you know, what everyone's individual scenario is. But I think what I feel like also is the key issue here is moving the integrations are a means to an end. But ultimately, having a platform or tool that you've built that understands the context, and can get those, you know, six things around that circle or whatever context means in your organization, in one system, that it you know, engineering, security, and compliance can all work around. That's when you start to move faster, and lower your risk. Well, ultimately, you know, those those problems that we discussed, that's really why we believe that there's a huge value in sort of unified systems for AWS to solve those challenges. And I think what you highlighted was something that's really developer friendly and supports patterns, like infrastructures code, that's going to help you deploy fast, whether it's onboarding a new AWS account, or getting your existing AWS under management. And then from there, the most important thing isn't going to be how you're integrating, but it's going to be understanding that context in a single place, for security, for compliance for it. Yeah, and for engineering and if it can run that platform engineering loves to use it, security can know there's guardrails and pave roads in place. And compliance is going to get, they're going to be doing less reviews, because of the context access, and ultimately, having a really integrated way to do the reviews. If if you can pack if you're building or buying, but you can do all those things, right, in an access tool for AWS, it's ultimately going to save you time and money and reduce your risk along the way.

Todd Thiel:‍
The real value is simplifying, it's making a relatively complex sensitive process a lot easier in one place, as opposed to having to tie several disparate systems together, using some sort of middleware or building your own processes from scratch. I mean, that takes a long time. So being able to do do this, do all of this in a transparent way where sunlight is the best disinfectant. So people can see what's going on, people can see the changes that are being made by this team, that team and it's approved. But if you provide a platform that is decentralized in nature, so it's not like I have to rely on this security team or that owner or it to do this for me, if you could provide a platform that supports infrastructures code supports a decentralized ownership model, where you're empowering engineers to go in and make the changes they have to in a declarative opinionated way, you're in a good spot. Now, you can enable engineers to move as fast as they need to, with a good platform

Lance Larsen:
Todd, I love the historical view, it was super helpful, just learning from your perspective, you know, the changes in AWS and where AWS investments in new services weren't solving all the challenges. Getting into why that actually matters, from the perspective of you know, too much access slows you down operationally. And that actually became more of the focus than risk, which was a unique and fresh perspective, Todd, and then coming into sort of really focusing on what good looks like driving simplicity across departments. And then getting specific on areas where, you know, things like Terraform, or those contextual workflows can actually help get adoption for security teams, and it that's offering, you know, something like this as a service. Plus, the, don't try to tackle this all at once guidance, but just focus on you know, which context matters to you most or where you think you can make that operational. What, you know, what's the path of least resistance, and if you can build, you know, with those philosophies in mind and put a really tactical, you know, holistic plan about, you know, what good, better and best looks like you can actually, you know, make AWS access. Simple, right? And that's what's going to be the biggest driver for your organization. I loved getting to talk to you. I always love our chats. And you know, this is one of my favorite topics are really having the space to go deep over the past hour with you. I enjoyed it. So thanks to everyone listening. And again, Todd, thank you so much for joining us today.

Todd Thiel:

Thanks, man. Take care

About Opal

Opal is the unified identity platform for modern enterprises. Opal aggregates identity and access data to provide visibility and defense-in-depth infrastructure for mission-critical systems. Enterprises can discover anomalous identity risks with the product and remediate them in minutes. The world's best companies trust Opal to govern and adapt sensitive access.

Want to see it yourself? Contact sales@opal.dev or book a meeting here for a personalized demo.

‍