CyberWire Daily - Zero Trust for cloud assets: Identity authentication and authorization. [CyberWire-X]

Episode Date: January 30, 2022

Applying Zero Trust principles to access rights can be tricky given the volume and dynamic nature of services in the cloud. Serverless computer services, like AWS Lambda, multiply the volume of identities to manage. These cloud services often have excessive permissions to access sensitive data and can become a potential entry point for an attacker to exploit. The CyberWire's Rick Howard speaks with Scott Farber, Principal Cyber Architect & Zero Trust Technical Lead at MITRE about the topic. Show Sponsor Sysdig's Vice President of Security Product Management, Maor Goldberg, brings experience with data center and cloud to a discussion with CyberWire-X on the considerations for managing access rights in this hybrid world. They consider the pros and cons of different approaches to enforcing least privilege in the cloud. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Hey, everyone, and welcome to Cyber Wire X, a series of specials where we highlight important security topics affecting security professionals worldwide. I'm Rick Howard, the Chief Security Officer, Chief Analyst, and Senior Fellow at the CyberWire. And today's episode is titled Zero Trust for Cloud Assets, Identity Authentication, and Authorization. Applying zero trust principles to access rights can be tricky. Amazon's Lambda functions, Google's Cloud functions, and Microsoft's Azure functions multiply the volume of identities to manage. These cloud services often have excessive permissions to access sensitive data and can become a potential entry point for an attacker.

In today's show, we will consider the pros and cons of different approaches to enforcing lease privileges in the cloud. A program note, each CyberWireX special features two segments. In the first part of the show, we will hear from industry experts on the topic at hand. And in the second part, we will hear from our show's sponsor for their point of view. Here's a word from today's sponsor, Sysdig. Sysdig is driving the secure DevOps movement, providing visibility and security to confidently run containers, Kubernetes, and the cloud. Modern cloud apps are built using continuous integration slash continuous deployment, or CICD for short, and run as containerized microservices. This generational shift creates opportunity to get security right by embedding policy

into DevOps workflows. Legacy tools can't see inside containers and slow application delivery. What's needed is a container and a cloud security stack built on open source innovation with deep and unified visibility across workloads and multi-cloud infrastructure. Run confidently with Secure DevOps by visiting www.sysdig.com. And we thank Sysdig for sponsoring our show. Back in the day when I was just starting, call it the late 1990s, securing networks was relatively easy compared to what we're trying to do today. We didn't think so at the time, but after 20 years, our networks have just become more complex. Back then, we had something called perimeter defense, which meant that we stored all the digital organizational assets behind an electronic wall, a firewall usually. Today, though, we have material data scattered all over the place on cloud services like software as a service, infrastructure as a service, and platform as a service. On mobile platforms like phones, tablets, and laptops, and we still have the traditional perimeter in our data centers and in our office buildings. I call these things data islands, and they have exponentially increased

the complexity of securing our environments. How on earth can we manage things like identity and authorization on all of these data islands, but especially in the cloud? To see if I could provide some clarity to the issue, I invited Scott Farber, the principal cyber architect and internal Zero Trust technical lead at MITRE, to the CyberWire hash table to talk about where the rubber meets the road when pursuing a least privileged or Zero Trust strategy in the cloud. And I started out by asking him if he thought identity and authorization on these data islands is complex compared to what we used to have back in the day. I would agree with that. I would actually say it's even more challenging, right? So when you mix in and you start to look at Azure Stack or AWS Outposts, those boundaries get very vague because now you can seamlessly shift data back and forth. And so where does that boundary lie? That's

something all organizations have to answer for themselves based on their risk analysis. But those hard perimeters that I think we're used to looking at, the islands are flexible, right? Is it high tide or is it low tide? Is it one island or two? Yeah, if you talk to most security professionals, by now have at least a single cloud provider. And many, many consider that to be ludicrous. They wouldn't just put all their eggs in one basket. They're going to have multiple cloud providers. So it just adds complexity to the entire conversation. We were having trouble enough doing zero trust when we were all in one spot behind the perimeter. Now we're scattered hither and yon.

What should we be thinking about when we try to deploy a zero trust across all those data islands? My takeaway over the last, like I said, 18 months is zero trust fundamentally is, this may be a controversial statement, but it's not a technical issue. Zero trust really for most people is a cultural shift. For those of us in the security field, we look at it and we say, oh, we have to do the right thing. We have to protect our data. We have to protect our crown jewels. We have to figure out what those crown jewels really are. You know, what we feel is valuable and needs protecting may or may not be what the adversaries, you know, are targeting. But at the same time, we have to be cognizant of how our enterprises work.

And so for MITRE, because we're engaged in solving so many whole-of-nation problems, we have a lot of researchers doing different things. They're tackling interesting problems, and there is no homogenous environment. So we have to be able to protect things safely and sanely and at the same time not get in front of those work programs and create additional friction. Well, let's try to come to some common terms because every time I talk to somebody about zero trust, they think about it differently than I do. So tell me what your – how would you describe zero trust in a Twitter line so that even my grandma can understand it? I'm a bit old school in that I'll say Zero Trust at heart really goes back to those old principles about least access, right? Least privileged access. So that is from the original paper from KinderVog. You know, he wrote that back in 2010. And I agree with you that zero trust is not a technology per se. We can use technology to implement some of this or at least move us

further along the journey, but it's really a strategy. It's really a, what you said, a culture. And it's been a culture shift because permanent defense has been the model forever. This zero trust idea is completely different. Do you have trouble conveying that to leadership in the organization because they're not used to this idea? So our leadership's actually been very supportive. And that's one of the great things about working at MITRE is we've had support from the CEO on down. Everybody has recognized that between the White House executive order, as well as just looking at it saying it's the right thing to do. So we've had immense support.

The key thing, I think, is understanding that if you're embarking on a large scale enterprise migration to a zero trust architecture, having a sound communication strategy and helping people manage change. To borrow the phrase, right? Everybody's cheese is getting moved. Helping the other technologists in the organization, they have work to do, right? You have developers, you have engineers, you have researchers, and how do you enable them to pivot with causing minimal disruption? And so a lot of it boils down to, again, personal change management. That's one of the big secrets. Most of us have technology in place that could do some of this. It's probably not a perfect

zero trust implementation, but you could get a long way down the road by just using some of the technology you have. What you mentioned was that if this is really a change in policy, right, it's a people and process thing. We have to decide as an organization that we're going to resource this idea. Absolutely. So lining up the executive support, you know, why is zero trust important? There are things that zero trust can bring to a large organization. We're very much used to those traditional islands, as you alluded to earlier, right? We all have our data in pockets in different places. What starts to happen when you work your way through these things is those traditional pockets can become less important.

You now have the ability to, again, assuming you've done all your homework and planning, is you can now start to say, hey, I want to, in a targeted fashion, expose a resource in a way that wasn't possible before. Let's use an example. Most organizations have data centers, and that data center may span on-prem or into the cloud. We also tend to have developers or engineers or people doing interesting things, and people want to take that resource and they want to share it. Maybe you've got customers, maybe you've got partner companies, maybe you're working with university or academic researchers, and you need to expose that service, right? So the promise of the cloud has always been that we can operate in a more agile fashion. And I would argue that Zero Trust is starting to do some of the same things. through use of very carefully planned security decisions, we can start to create content and

expose that content to our peer organizations in that same sort of agile fashion, because you now have a much tighter end-to-end security policy. So I think there's some really good stuff there. And when people start to see those business add-ons and those business values, we start to take security and we turn security from a cost center into a business enabler. So one of my pushbacks to, you know, I was reading through the NIST Zero Trust Architecture document. They just released an update like in August of 2020, I think. And everything they say in there is really good. If you want to learn about what Zero Trust is, I recommend everybody reading it. But their diagram for what a Zero Trust architecture looks like is a bunch of black boxes

that not many of us have and most of us don't have the resources to build ourselves. And I kind of push back against that a little bit. I don't think you need to throw out everything and start over with a bunch of brand new technology. Like we said, zero trust is a strategy. My question to you, Scott, is what are you telling your customers internal to minor and external about how do you start without having to spend a lot of money and,

you know, taking five years to design the darn thing? I hate to give you the canned answer, but it all comes down to the basics. It's the same things we've all been preaching, right? The basics. The basics. Come on. Really? The basics, right? Right?

So to use an analogy in music, right? What separates a virtuoso performer from the amateur hacking away at their violin, right? That virtuoso has practiced the basics ad nauseum. What's a basic that you need to get right to get zero trust moving in your environment? Okay. So a real world example, identity systems. When you really start to peel apart identity, I'm going to speak generically here. You know, a lot of people have built great identity systems that do a binary function. Is it Rick or is it not? Is he in or is he out? Have you taken the time to delve into your identity system and figure out, are you

set up to handle roles? And what do those roles look like? Let's use Active Directory as an example, right? So your average corporation, bob.com, comes in and rolls out their AD and they have all of their AD groups baked in that say Scott's team can do X and Rick's team can do Y. Well, what happens if you have a matrixed organization and you now have permissions based on those matrices? Like you're building a dynamic project teams with resources from all across the organization. A lot of folks forget that you have to have an identity system that can handle that. So some of it is just peeling those things apart. And everybody wants to start zero trust activities with, they think about it in terms of like firewall policies. And really where you have to start is

thinking about identity because identity has to be baked in end-to-end to everything to really do it the right way. Totally agree with you that identity is a key and essential part to zero trust. If you don't know who the people are or the machines are that are connected to your systems, you can't do zero trust. And the part that I think most people forget is the authorization piece. It's one thing to know that it's Scott, okay? And they say, I'm sure it's Scott. But do you know all the things that Scott is allowed to touch?

That's a more difficult problem. We've been able to do the identity piece with Active Directory since the 90s. The authorization piece is the hard part. It does depend on your business environment. This is where it gets interesting when you dive in. There's an amazing amount of things out there. So when we move into a zero trust world, I think we would like to believe as security folks that we're focusing on identity and posture checks and all those cool things that, right, new technology has brought us over the last 10 years, right? There's vendors are doing really interesting things with that.

The reality is when you get into it, you're going to find a ton of things out there that are still relying on subnet based authentication, right? Hey, before I let you into my system, are you coming from your corporation's public, you know, NAT pool, right? Then whatever NAT, whether you're doing it at the network or the firewall level. Or SaaS services do this increasingly. Hey, we need to validate that you're coming from your corporation. So put in that slash 24 into the access list, and that's how we're going to let you in.

Except, golly gee, we just sent our entire workforces across the country because of COVID. And you're now telling us that we have to backhaul all that traffic to our corporate data center to pick up a net. Can you still do the other things on top of that? Can you still do posture checks and hip checks and all that? Well, sure, of course you can. Except you've now built such a suboptimal data flow to access those applications, what you run into the risk of doing is going back to the business value statement. You're now going to go to your executives and say, hey, I bought this latest, greatest zero trust widget.

I've enabled my enterprise. And your monitoring folks are sitting there looking at user experience and transaction times and going, boy, everything just got worse by a factor of 3x. So, Scott, you and I could talk about zero trust issues for the next 20,000 hours, I think, because, you know, that's how much of a geeks that you and I both are, right? But we're at the end of this. So give me your overall summary of what people should be thinking about in terms of zero to us? What's the thing that should be keeping forefront on their radar screens? You know, one of the more interesting trends, you know, I've seen is some companies are starting to do, you know, and say,

hey, your inventory management is actually a cyber position, right? So knowing your assets, what are your assets? I would say for most of us, for most people, we have to take that to the next level and say, if we're going to move to a zero trust environment, it's not just knowing what's on the network. Now you have to know how everything talks to each other. And it's a, I think an unfortunate reality that we hit where most applications don't have documented taxonomies, right? So it's not, it's know the flow if you want the catchphrase, right?

You have to know your flows and it's not just in your data center, but it's also what your end users are doing. If you know that and you have a sound identity system, you can get pretty far down the path going back and implementing all those basics that you've always wanted to implement but didn't have the business justification to do before. So key and essential things before you can even think about a zero trust program is to know exactly who's on your network and what they're talking to and know the devices that

are talking to each other and what those flows are. I would call that, you know, layer seven zero trust, you know, application layer zero trust. But that's kind of where we are. Is that what you're saying? Yeah, it really is. And, you know, the other thing is, I think for a lot of folks, you have to, I'll use the dreaded agile word, right? And I know that gets people, you know, sometimes there's bad connotations there,

but zero trust is a new enough thing. And there's challenges, right? When you dive into it, don't be afraid to experiment, right? And at the same time, you want to approach this as a learning organization. For myself, we've been very fortunate at MITRE that because of our broad executive support, we have folks that are out working with NIST and the various sponsors, right? And they're looking at, you know, every government agency has its own architectural framework that fits their business model, right? And at the same time, we've got a lot of different vendors out there that are directly proposing technical solutions. So we've been able to jump in and say, okay, how do we marry those two together and what actually works and what doesn't? So I think for folks that are looking at diving in, and of course, you're going to have your

account manager showing up and everybody's going to pitch a solution. Don't be afraid to experiment, but also don't be afraid to pivot. Understanding that business model, right? We talked about knowing your flow, knowing what's on your network, knowing who's talking to what. That is really going to inform any product decisions you make down the road. And to a certain extent, there's some things we can do in zero trust. And if you kind of go back to the 80-20 rule, right? There's a lot of basic things we can do that are going to mitigate the vast majority of our risks, right? None of us are going to be perfect, right? We can go back to your famous risk management talks from a few years ago. But if we really get to understand what we're doing, the selections and choices people make with technology become

much more self-evident. Well, we're going to have to leave it at that, Scott. That's good stuff. Every time we get together, I learn more about things. So I appreciate you coming on the show. I want to do it more. Thanks a lot for doing this. Rick, thank you very much for having me. It's great talking to you as always. That was Scott Farber, the Principal Cyber Architect

and Zero Trust Technical Lead at MITRE. Next up is my conversation with Maor Goldberg, the Vice President of Secure Product Management at Sysdig. Mayor, thanks for coming on the show. You've been thinking and working on infrastructures, code, and DevSecOps type things for a while now in your career. Why is it so difficult for people like me, you know, a chief security officer, to deploy identity and access management in the cloud? Is it so much different in the cloudy space than it is back in the traditional on-prem networks? Great question, Rikin, and happy to be here. So I think identity and access was, you know, realistically always a challenge.

It's always been hard. I made it sound like it was easy back on-prem. It never was. But now that we're in the cloud, it seems even harder. Yeah, so I think it never was. And traditionally on the on-prem environment, it took organizations years to get to a point where they deploy mature tools and processes to address identity and access management lifecycle and over time meet regulatory compliance requirements and so forth. creates new challenges because cloud typically move faster in a way than traditional environments. Typically with traditional environments, on-prem data center,

you have pretty structured processes to introduce new services, to deploy new applications. So in these processes, you can take care of identity, use your provisioning systems and so forth and so on. With cloud, you want to move much faster. Typically, those traditional tools are not there to meet the challenge or help provision users and access and so forth and so on. So you don't want to delay anything.

You don't want to introduce anything or any bottlenecks that will delay your pace of innovation. So things move much quicker on the cloud. So I think this is one area that introduces a new set of challenges. But then also, in my mind, the way new type of roles or new type of persons are coming into the cloud and share some of the responsibilities that traditionally IT and security teams own, and I'm talking about DevOps and DevSecOps, teams own, and I'm talking about DevOps and DevSecOps, also introduces a challenge because now essentially more people can introduce and make changes to your cloud environment and things are getting a little bit out of control from an IT and security perspective.

So you're saying the cloud has made it easier for non-IT people or non-security people just to throw a workload up in the cloud and make it go for them. So we kind of lose sight of all that. Is that what you're saying? I think so. And some of it, I think it's by design because you're moving to the cloud, you're adopting Kubernetes and containerized workloads,

you're moving your developers to think about microservices. You want basically, as an organization, to introduce new digital services, new workloads, new business applications. You want to do that as quickly as possible so you distribute the responsibility. You're giving smaller teams ownership of their environment so the teams can span up workloads, they define their infrastructure, they decide how they want to go about building and deploying their services. So a how they want to go about building and deploying their services.

So a lot of that innovation drives significant increase in pace of investments and pace of changes. So it's getting a little bit out of control from an IT and security perspective, yes. It seems to me that you're describing a problem in just visibility. All the employees that have to connect not only to the on-prem stuff, but your cloud deployments too. And many organizations of any size are into multiple clouds. Here at the CyberWire, you know, we're just a small startup, but we have over 50 SaaS applications that we're having to deal with. And so just having visibility of all that, and that's a challenge. So what's your recommendation?

How do you kind of get your hand around just seeing what needs to be identified and authorized? Yeah, absolutely. I think this is probably the key challenge we're seeing as well. First and foremost, it's about visibility. Organization needs to understand who are the different individuals that can access their cloud infrastructure.

Typically, we're talking about privileged identities, right? So these will be individuals with a relatively high set of entitlements, the admins and so forth and so on. So you want to understand who can access your different services. Many organizations use multiple cloud accounts across multiple cloud providers. So you want to get a good picture of who can access your cloud environment, who is doing what in your cloud environments. And in the end of the day, you want to

leverage that visibility to make sure that you are driving better security decisions. Because in the end of the day, the end goal will be to make sure that only the right individuals can and actually do what you expect them to do as a a business, but I agree 100%, visibility is the first challenge that you are looking to solve. And I think what's happened too, as we all race to the cloud is there's been this exponential growth in like non-human identities. You know, if you think about cloud functions like Lambda functions, right? And those seem to be outgrowing just adding people to this.

So can you explain what non-human identity is and how we can deal with them? I think you're absolutely correct. So when we're looking at identity, typically we think about a person. So this will be an individual that can do, has permissions and can do a certain set of activities. But we need to remember that software is running with a context of identity as well. And every software component that we are running has an assigned identity and assigned permissions or entitlement for that software to operate. As we move to smaller sized workloads, microservices, serverless functions, and so forth,

what we are also seeing is a significant increase in the amount of these software identities. And of course, by themselves, they are creating another challenge for visibility. So you want to understand how the different software identities can interact with other software identities and your infrastructure as well. And then you want to make sure that each software identity is running in the right security context. This is actually one of the things that will later on contribute to significant security risks like lateral movement and so forth. So what we're really talking about here is preparing the digital space to deploy our zero trust strategies or least privilege strategies. our zero trust strategies, or least privilege strategies.

Is there a different approach to do zero trust in the cloud versus back on-prem, or is it basically the same? I think the goal is the same goal, definitely. You want to get to a point where you can make sure that every specific identity in the cloud, human or not, can do exactly what you expect that particular identity to do. I think cloud introduces two challenges that potentially are not there when it comes to traditional on-prem environment. One will be scale. So we're talking about significantly more identities, especially on the workload non-human side.

And then the process by which you govern and control these identities. With cloud and modern software development processes, you see a lot of these infrastructure identities and workloads created by using infrastructure as code technologies, things like Terraform and so forth and so on. And there, it's not just about controlling the end result, the identity and access entitlements on the production environment, it's actually understanding the flow source to production. So you don't want just to have that lens of looking at my identities

on my cloud account, but instead you want to understand the process that creates and govern and change these identities, and you want to be embedded in that process end-to-end. So when there's a new infrastructure as code manifest that is creating a new infrastructure with identity and access and so forth. You want to be there in the right point in time to highlight issues as early as possible and avoid potentially introducing risk to your production environment.

But also, again, doing that too late in a point in time where you will need to delay deploying new services and delay the business and so forth. I want to go back to something you said earlier, is that typically anything we're doing in the cloud is moving so fast compared to what we used to do on-prem. But if you didn't have a robust change management process back on-prem, you're not going to do it now in the cloud.

It's going to be difficult to catch up. What we're seeing with cloud adoption is that many organizations rushed for very good reasons to adopt cloud technologies because they identified an opportunity to leverage cloud technologies for whatever business goals they have. And we talk a lot about how software is accelerating business and how businesses are using software to advance

their businesses and outmaneuver the competition and so forth and so on. So that rush, you know, quote unquote, to adopt cloud technologies for many organizations spearheaded the later process to go back, look at our processes from the way we do change management, for instance, on-prem. look at our processes from the way we do change management, for instance, on-prem. It's the same for compliance and other security processes and getting to a point where we now need to apply the same type of thinking and the same type of structure on our cloud environments.

With that, many of these processes will have to change because on-prem environments work differently. The way security and IT teams work with developers in some cases is happening differently on-prem environments work differently. The way security and IT teams work with developers, in some cases, is happening differently on-prem relative to how software is being built and deployed on the cloud. So these processes, while the same in goal and looking to achieve the same end result,

will have to slightly change as organizations adopt them to the cloud. And again, just the way we use infrastructure as co-technologies and the ability to meet developers as early as on in the process is different relative to more traditional development processes. What we see more is organizations that had processes or still have processes on-prem and want to adopt these processes for the cloud. And I think that's the most common case in my mind.

When I tried to do this in previous jobs, identity and access management, you know, it kind of spanned across the entire organization. And the question that always came up is, who owns this? Who is the logical organization that should own the steps to establish identity and access management? And then the next step would be who's going to decide what zero trust controls to put in place

for the various groups that are out there? Who typically does it and maybe who should be owning it? So I think a lot of what we're seeing on-prem is happening on the cloud as well, where you have, in a way, at least three key contributors to identity initiatives. First and foremost, for many organizations,

especially the larger ones, you have the identity teams, the teams who are responsible to look at the broader identity initiatives and make sure that identities are managed and governed in a structured way across the organization, both on-prem and in the cloud. And then increasingly, you will see security teams, and in particular today, cloud security teams who are looking to make sure their cloud environments are as secure as possible. And when they look at their security challenges, identity is definitely top of mind for cloud security and security teams.

And then last but not least, an important part of that triangle in a way will be the application owners. Because in the end of the day, when you're looking to establish this zero trust or least privilege for your applications, you want to make sure that the developers and application owners are part of this conversation because in the end of the day, they will be the teams who create and manage these identities and they are an important part in defining and understanding what these identities should and shouldn't be doing. So I agree that all those players should be at the table, but when the CEO says, who's in charge of this? Is it the CISO? Is it the HR person? Is it the CIO? Who would you recommend? It's a great question. I think it's likely to be. Put you on the hot plate there. Well, I think it's likely to be different from one organization

to other. I hate that answer, but it's so true. It depends, but go ahead. I interrupted you. That's fine. I think it's most, you know, it's more important to establish who is leading the effort and who are the different teams that contribute to that effort than who specifically is owning or leading the initiative. As long as there is a clear understanding of who owns the processes, who helps the organization steer identity and access management thinking into the right direction, it's fine. It could be identity leadership in some organizations that are lucky to have identity leadership.

In some other cases, it will be security. And in some cases, I've seen compliance compliance driven efforts to lead identity initiatives as well. So it doesn't matter who or less important who, it's more important to establish that there is someone with thinking and helping the organization be more structured when it comes to identity and access, in particular in the cloud. So good stuff, Maren, and we're going to have to leave it there. Any last thoughts about identity and zero trust in the cloud before So good stuff, Maren. And we're going to have to leave it there. Any last thoughts about identity and zero trust in the cloud

before we let you go? No, thanks again for your time. I just think, again, that as organizations transition to the cloud and adopt cloud technologies, identity from our findings, and it's not surprising that over 80% of users today in the cloud

have access permissions and entitlements, and I think this is something to consider as organizations adopt cloud technologies as they mature their overall cloud security practices. Identity is definitely something that needs to be top of mind.

We'd like to thank Scott Farber, the Principal Cyber Architect and Zero Trust technical lead at MITRE, and Ma'or Goldberg, the VP of product management at Sysdig, for joining us. CyberWireX is a production of The CyberWire and is proudly produced in Maryland at the startup studios of DataTribe, where they are co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Iben. Our executive editor is Peter Kilpie. And I am Rick Howard.

Thanks for listening.