Loading summary
Transcript27 lines
- [00:03]
A
Welcome to Cyberatthettop, a podcast from RSAC. Today's enterprises run on SaaS. From collaboration tools to customer platforms, cloud applications power nearly every part of the business. But that flexibility has come with an explosion of risk. Companies are managing thousands of apps, sprawling permissions and sensitive data flowing far beyond traditional security boundaries. In today's episode, I am thrilled to be joined by cybersecurity legend Brad Arkin, principal at Leversac, who just finished up a stint as EVP and Chief Trust Officer at Salesforce and former chief Security and Trust Officer at Cisco, among many other places. We're going to talk about why SaaS risk has become such a challenge for security leaders. We'll also discuss some of the SaaS issues that companies don't always anticipate and how CISOs can bring SaaS environments back under control without slowing the business down. Let's get started. Brad, thanks so much for being here. Thanks for being a part of this.
- [01:26]
B
I'm excited. Yeah, this is going to be fun.
- [01:29]
A
It will be fun. And this is a big topic. So let me start out by asking you, why has SaaS risk become such a pressing issue for security leaders? Today?
- [01:42]
B
Defenders are doing a combination of looking around the corner and trying to get ready for what's coming next, then playing catch up on stuff that's already happened, and then they're falling behind somehow. And so I think people were originally fighting the battles at the corporate desktop level, employees clicking the wrong email, things like that. And then they moved on to worrying about public cloud and how do they manage the migration from their private data centers into this public infrastructure. The SaaS explosion, and at all the three public companies I've worked at, it was Many thousands of third party SaaS apps that I had at each company. And, and so just knowing they exist, having them connected through your idp, if you use Okta or Microsoft to do your identity, having them connected up to a central identity provider, usually a lot of security leaders and IT leaders will declare victory just at that point, because that's like a pretty heroic feat of governance right there. And what's happened is as the controls are getting better in other parts of the environment, the bad guys are shifting towards the path of least resistance, which is going after valid identities and SaaS platforms that they can connect to directly. Directly and then do things that the platform allows that identity to do. So download data, make changes, whatever it is, except they can get access now to really large amounts of data that are sitting in these repositories. And so the attacker attraction is drawing people there. And the defenders have reached a good enough level in other places. And this is now, I think, an area of opportunity for incremental investment.
- [03:11]
A
Yeah, I love the way you framed it up. It's almost like the new battleground of defense. And let me ask you a question related to that. How do you think and how should people think about SaaS risk differently from traditional infrastructure risk?
- [03:31]
B
Any new technology goes through a maturity phase and you start out, you don't understand it. You may not understand the risk, you may not understand what the bad guys might be capable of. And if you think about something like Active Directory on prem Active Directory, people got it functional and they left it alone. And then after 10 or 15 years, bad guys started attacking it. And then all of a sudden people had to get to become experts. And how do you manage, who are your domain controllers? What are the different privilege groups that exist within your ad infrastructure? How are you managing access to the cluster and preventing bad guys from getting in there? Because getting into Active Directory was the home base for any bad guy event. If you wanted to steal data, do ransomware, wiper attacks, getting to Active Directory was usually part of the playbook. And so now as an industry, I think we've gotten much, much better at caring to our Active Directory hygiene. And I think we're going through the same process on the SaaS side now. Active Directory was one technology from one vendor. SaaS is going to be thousands of vendors, some shared commonalities, and then lots of things that are quirks and differences from one platform to the next. And so figuring out which ones matter the most, where does your data exist in quantity that you need to protect and then what does it mean to protect within that context? And what you do for workday is different than what you do for Salesforce is different than what you do for, you know, what are the other, you know, 10 things that you care about and making sure that you've made the most and Even something like GitHub and your personal access tokens and how are your employees allowed to provision those types of things? These are all little intricacies you have to learn for each of the platforms in order to make sure that you are configured in a way consistent with your risk profile and the goals and the protections that you need to deliver.
- [05:09]
A
SaaS has been with us now for a while and a lot of companies have a significant number of SaaS applications. What do you see? CISO still getting wrong about SaaS risk management today?
- [05:24]
B
There's a lot of confusion around the Shared responsibility model. And it's really clear in the contracts, but usually not clearly understood by the security team within the customer. And so this leads to some confusion because there might be something that goes wrong inside the environment, which is crystal clear in the contracts that this is on the customer side of the shared responsibility fence. But the customer side of the fence includes the work of the systems integrator, the third party consultants that set it up five years ago. There's a lot of different parties that come together to stand up a SaaS implementation for a large complex customer. And making sure that somebody is thinking through the security outcomes of what you've delivered and fielded with this installation and deployment is something where I see people get mixed up and confused as to who's responsible for what. And so working with your vendor, your systems integrator, your in house security team, the line of business, all these different stakeholders have to come together in order to deliver the security outcome you need. And when you're trying to coordinate all those different players and you've got nimble bad guys that break all the rules and they're doing whatever they want and adapting as fast as they can to the latest defenses, that's what's making it really challenging right now for defenders in
- [06:39]
A
this shared responsibility model, what advice would you give for security leaders who are now, rightly so, partnering then with business leaders at the SAS vendors because it is a shared responsibility, how do they partner with them without becoming a department of no?
- [06:59]
B
The Department of no is the best way to be left out of the meeting, and then you've lost any chance whatsoever to influence outcomes. So I'm a big fan of trying to figure out how to work productively and not just fold your arms and pout and then make sure you don't get invited back. So I think the big thing that defenders need to do is more than anything else, stay up to date on the threat landscape. And so when you read in the news about some entity got popped, what did the bad guys do? How did they achieve it? If we were to play that back against our environment and maybe you have to tweak a few things, how would it play out? Do we feel like we're robust against these new techniques? And if you wait for something to happen to someone else and then you get fixed within your own environment to get robust against that attack pretty quickly, that's a great way to live because very rarely would be the very first ever to fall victim to something. And so this is not the most mature posture you can strike, but I Think it is something you can strive for, which is if there's a new wave attacks targeting platform X, then study it, understand it. Are we a customer? How important is our data there? If that exact sequence of events happened to us, how bad would it be? And if the answer is bad, they say, okay, we got work to do, let's figure it out. What can we do to carve off some of that risk and minimize the blast radius? If you're already in that point, congratulations, I think you're in the top 5%. The next level would be to step up to proactive imagination kind of work. So like it hasn't ever happened before, but what might a motivated bad guy do against our particular configuration? And then you can like think proactively about that. So I think that's about as mature as you could hope for. If you're merely reactive after you see it happen to someone else, that's great. If you're only reactive after it's happened to you, now you're paying the price twice because you let it happen to you. You paid the price of the breach or whatever it is, and then you're paying for the cleanup cost. So I'd rather let it happen to someone else. You get fixed internally, quickly, and that way you're only paying the price once. And that's a nice price tag to me. And then I guess the level zero would be governance. You know, it exists, you have everything wired up to one identity provider. And then you do get some benefits from that because for example, you could set rules that say all corporate services, whether they're third party SaaS, apps or on prem, you can only connect to them from corporate hardware. And that will eliminate a lot of the attacks that are happening because the bad guys might be able to seal the credentials, but they're going to try to connect from bad guy computers, then they won't be able to connect. And so you can even at that level zero, implement some controls that are useful. But if you climb that maturity ladder, to me the sweet spot I think in industry right now is being able to react quickly when you see a new technique somewhere in the ecosystem makes sense.
- [09:38]
A
So you need to be able to move fast. Something's happening to somebody else, you better make sure that you're shored up against that. But also think about the art of the possible, try and mitigate the risk. For example, you can only access it from company hardware. It begs the question, do you have some kind of list or set of non negotiables when it comes to configuring enterprise SaaS apps.
- [10:08]
B
Yeah, so I kind of sneaked ahead on that one because when I talked about limiting connections to corporate SaaS endpoints from your corporate hardware. Now this is great advice and realistic for certain environments and it's totally unrealistic for others. Like I remember getting phone calls from companies that have maybe 30,000 employees, but they have 300,000 occasional hourly workers. And so they're not going to provision those 300,000 people with corporate hardware. And so, but they need to connect in to do time cards, you know, figure out what their shift work is, that sort of thing. And so this advice is not realistic for everyone, but for me personally, in the environments that I've worked at before, what I do when I get settled is what is the state efficient, resistant MFA rollout on corporate devices? And so face id, touch ID on Apple Windows, hello, getting that stuff set up. So now you've got cryptographic hardware bound credentials that exist within the security enclave within the corporate hardware device, and then only that device with that crypto secure credential can connect to the corporate services. If you achieve that, you are now in a position where the human, no matter how complicit they are with the bad guy, no matter how well they get scammed or tricked by a clever social engineering attack, they cannot get the crypto secret out of the hardware enclave on their laptop. And so you've just eliminated an entire category of threats. So if you do that, then you've limited the attackers to having to run malicious code on your laptops by tricking an employee to install malware or something like that. But then if you have an endpoint solution like CrowdStrike, it's a lot harder for the attacker. It's also hard to move data around an enormous volume if you're limiting them to using like corporate laptops. And so you get a lot for free just with that single control. And then you can then go further and get the bonus points of configuring. You know, figure out what are your top 30 SaaS apps and then have each one of them configured optimally for the things you care about. And then you can do all of that work on top. But if you just limit the connections to corporate hardware, you've made a lot of the current attacks in the news go away.
- [12:10]
A
And I gotta ask you this as a follow up, because one of the biggest things that I've seen people struggle with is over permissioning in SaaS apps. They're heterogeneous. This permission or this group doesn't Translate into things you shouldn't do in this particular SaaS app over here. And it's different for this other SaaS app over here. How do you detect and remediate over permissioning when you have a thousand SaaS apps? Like how do you do it at scale?
- [12:45]
B
Yeah, so I think you can't do it at scale, you just cannot. And so you've got to prioritize. And the truth is, if you know, when I worked at Cisco, I think we had 4,500 third party SaaS apps, but maybe 3,000 of them were used by fewer than 100 people a month. And so yeah, they might not be configured optimally, but the blast radius if something were to happen is pretty small. And so if you focus your energy on where you have the most sensitive data and the biggest amount of data, that I think is the right way to prioritize. And then you've got to get, and this is the problem is that the people who deploy and configure these apps usually did so 10, 15 years ago in a simpler time where you didn't have bad guys attacking legitimate credentials and they just didn't have that, you know, mean guy security imagination of how good this could go wrong. They were optimists. And so, so think of a call center rep. The call center rep might support any customer who calls in. And so naively you're like, great, let's give them read write access to all customer data. But the truth is they only ever work with one customer at a time. And so having a just in time, one at a time provisioning mechanism would be the smartest thing to do there. But a lot of these things got provisioned with 100% read write access to all customer data. And so now you've opened yourself up, if that account were to get compromised, all sorts of mischief is possible. And so studying what is the true real world experience of what the human needs to do or the account holder needs to do and then what is the current delta to that? And so if you're working with one customer, but you have access to 100 million customers, that's an enormous blast radius that's completely unnecessary by the business. And so figuring out how do you go and retrofit in and shrink wrap the permissions down, that's the outcome you want. And then how you achieve that is going to depend a lot on the details of every platform. And so that's unfortunately where it's a lot of work. This is not a Sunday afternoon project. It's something usually you have to anoint somebody, say, you own this. This is going to be your life for the next, I don't know how many quarters, and just get going and start on the platforms that are most important with the richest data sets and then start working backwards from there.
- [14:52]
A
Let me ask you about the attacker, because you're right. Like the fact that you said the people that configured it originally were probably optimists and probably just had it worked right. As soon as they kind of got it deployed. How are attackers today evolving their tactics when they target SaaS? Environments? Like, how are you seeing the maturity of attackers knowing that the crown jewels may be in SaaS?
- [15:22]
B
Yeah. So in the movies, the attacker would target the SaaS platform directly, get to the back end, and they're in the vault, they can access everything. You know, they're shoveling, you know, piles of cash into garbage bags and running out to the truck for the getaway car. That's not at all what really happens. So this is a low code, no code attack technique where you get an employee who works for the victim organization that you're targeting and then the bad guy will get them on the phone. And they are unbelievably effective at sweet talking these victims that they've targeted into some story, which makes sense. And when you listen to the tapes afterwards, you're like, I get it. I do not fault the person who fell for the scam. This was not a weak moment on their part. It totally made sense as a consistent story. And they use a lot of psychological tricks to kind of bully you through your moments of indecision as the victim is saying, wait a second, something is weird here. And they can push you right through that and say, the best way to wrap up this period of discomfort. I need your help. I'm asking for your sympathy or you're going to get in trouble. I'm triggering fear in the victim. Whatever the technique is that they use, they'll go through that process and if it doesn't work for a person, they hang up, they call right back. They can do it all day long. Then eventually they're going to grab somebody who they're distracted, they're thinking about something else, and then they're going to fall for it. Usually what happens is somehow the attacker wants to gain the ability to use the legitimate credentials of the person they scammed over the phone. And this might be tricking the victim to log into a fake website where now you can just harvest the credentials. It might be connecting a malicious app that's controlled by the attacker. But they're convincing the victim that this is a benign help support situation or something like that. And so then once you have the legitimate credentials, you can do anything that that user's account was provisioned to be allowed to do. And in the scenario of like, well, they're customer support, that means they need access to customer data and so that means they might be able to download all the customer data. The other attack pattern that we're seeing now, which is not phone based, would be to attack a integrated entity. So this would be a third party partner that has some trust relationship or connection. And if you can grab the OAuth secrets, now you're able to connect in with that machine account, which is usually a high powered ability to slurp out all the data that is provisioned with. And so the attacker can attack one hub entity that connects with lots of different services, steal all the secrets and then they connect to all those connection points and then slurp down all the data they have mine through it, look for more secrets and credentials and then keep going. And so it's like a game of risk where you see the contagion spreading from one boundary to the next as they steal more secrets and then use that access to leverage and open up even more access. Access.
- [18:09]
A
It's such a crazy time. And I'm sure you've seen a ton of these demos and tools that are now available to do deep fake voices pretty well. So it may not even just be a random person calling in, could be somebody that you think you know or you think you trust. And it's an interesting expansion of the risk environment and certainly the threat surface. And, and I want to ask about AI, but in a different way. So many SaaS platforms are rolling out these AI co pilots and autonomous agents. What new risks did those introduce into the environment?
- [18:54]
B
Yeah, so I think the AI agent rollout is forcing us to reckon with chronic over permissioning of accounts. And so I'll give you an example. So I get lots of emails and sometimes I get expense like receipts emailed to me. I do a work trip, I need to go through and clean up all my receipts and create a travel expense report. You could imagine an agent could do this for me quite well. And so naively the temptation would be to give the agent my email credentials. And now the agent can do full read, write, delete, access to everything in my inbox, which means a mistake could happen. It could delete everything in the inbox and I'd be very sad because all I wanted to do was look at the three expense receipts that I got in the past 24 hours. And so there aren't today convenient, easy ways to provision ephemeral short lived accounts with very narrow scoped permissions that would allow it to access only the three emails that are relevant. But that's the only thing I need from the agent and that's the only thing the agent needs to serve me in this request that I have. And so I think as an industry we're going to have to figure out how can we create this ephemeral like short lived, narrowly scoped, permissions. Because right now, and it's, you think back, like I remember 30 years ago, I was an intern and I couldn't get something to work, so I ran it as root and then it worked until it didn't and then it completely overwrote the entire hard drive and I got in a lot of trouble. And so, you know, the whole office, the lab was down for days because of that. And so that's where we're at now is that we need to reinvent the equivalent of to root jails and airily scoped, you know, UNIX permissions and things like that. But we need to do it on these vast platforms that are used in production by tens, hundreds of millions of people. And so it's a lot of work. And I think the value and the upside of enabling AI to support us with these workflows is going to be worth the expense to figure out a way to do it safely, because the value is tremendous. Like I'm in no way standing in front of that freight train, you know, like I want to be the person enabling it, but there will be mistakes the same way humans, you know, fat finger or something. And so figuring out how do you narrowly scope the permissions, that's I think, where the real win is. And how do we do it at scale to not slow down the velocity of innovation? Like that's going to be the hard part.
- [21:02]
A
There's such a crazy environment now that comes back to your point. Every vendor, whether it's a technology vendor, a cybersecurity vendor, no matter what, they're under pressure to include these AI features because customers are looking and they're advertising themselves as AI native and AI first. And so now if you're the security leader at the company that's deciding, do I allow this AI feature that's now been introduced maybe in an app that I've been using for a long time, or maybe a brand new app, how do you even evaluate those AI features before you Enable them for folks in the enterprise. And are there any guardrails that you recommend or just limiting data exposure?
- [21:57]
B
So I've got an easy button on this one. So there's this new security standard, AIUC1. So this is Artificial Intelligence Underwriting Corporation. So Basically it's like SOC 2 for AI agents. It's a company that I am sorry, so excited about. So I'm actually working with them. So I have like a commercial relationship with them. And basically they have put together a set of security controls that you should have in place if you're building an AI agent. And then you can get a third party audit, they verify you comply with this. So if you're a buyer, then you should say, hey vendor, show me your AIUC1 certification. And then what I really like about this model, SoC2, you get audited once a year and you can write your own control set and you get control set, could say we don't do controls. And then you get audited to verify you comply with that and then you're good. And so SoC2s are pretty tricky to make the most of it. And every company that's ever been breached had a valid SoC2 for the most part. So it doesn't actually protect us from anything. And so what these guys are doing is they control the standard. They have an industry consortium and they take a lot of feedback. But the main goal is if somebody somewhere falls victim to some new technique targeting some new flavor of prompt injection or something, they fold it into the standard and every certified entity gets recertified according to the updated standard every 90 days. And so as a buyer, if somebody is compliant with the standard, it gives you sort of a minimum bar of what they've put their effort into. And to me that's like really valuable as a buyer. And so I'm evangelizing this to all my friends because I think it's really the best bet we have to get some good security work in place that'll give greater confidence to buyers and sellers when it comes to AI agents and the kind of things that can go wrong. So that's, that's my easy button for you on that one.
- [23:41]
A
I love it. Well, you know, this is great because we really do need the equivalent of the Good Housekeeping seal of Approval that. But one that's living, one that's not just point in time because by definition, SaaS is changing all the time in the back end. So that's exciting that progress is being made.
- [24:05]
B
Yeah. And I think, you know, you look at like most other Standards, even something like pci, it gets updated. But it's a pretty heavyweight process. And so something may be well understood in the industry for a long time before it gets baked into the standard. This model here, you've got, you know, benevolent tyrants that are running the standard and they can just say, hey, this needs to happen. We're going to do it because it's going to protect people and keep people safe and the industry consortium will help avoid ivory tower stuff. But I think it's a model that could really help the industry here, so. So that's why I'm lending my support.
- [24:35]
A
Awesome. Love it. Okay, so let me go back and see if you may have an easy button for this one. If you had to give CISOs in today's world of proliferating SaaS applications, AI agent everything, three, only three practical priorities for the next 12 months, what would they be?
- [25:00]
B
So number one, anoint somebody and say you are now responsible for the security of our SaaS environment. That's number one. So anointing somebody. So this is not a committee. It's not a bunch of different people. It's a single person saying, you are directly responsible individual for this topic. And nothing focuses the mind like having your name on it. So then the second thing is you want that person to go do an inventory and say, what do we have and what is the way we should think about relative risk and opportunity for bad guys targeting us. And you can come up with a dozen different ways to slice and dice, but let that person decide which one seems like the most pragmatic list and say we've got these six, these three, these 30, whatever it is, there's a group that will pop out as by far the most important and then a long tail of other stuff. And so once you've identified who the person is, they've gone through and done an inventory and then some kind of sorting and prioritization exercise. And then you go and work with those vendors and you say, guess what? You're really important to us and partnering with the vendor to say we need to understand our health status in your eyes. I'm going to go get some third party outside expertise to help me understand their advice for me on how I can get more mature and improve the security of this environment. Environment. And you may need to ask for favors of the vendor. And getting that tied to any renewals or upsell that are coming is the best way to focus their attention on your problems and making sure they understand how important security outcomes are to what you're doing. And if you do those three things, you're going to make tremendous progress and the very biggest concerns will start to shrink rapidly. And that gives you some breathing room. And then if you can study what's happening in a landscape and you read about some new attack targeting somebody on some platform and you say, hey, we use that too, I wonder if we're vulnerable. And then you can go and tidy up that little aspect to it. And if you're doing that, I think you're reaching a level of healthy living that would put you far ahead of where a lot of companies are today. And so I think that's a great place to shoot for. And then once you're there, then you can talk about what comes next. But I think that's the right place to target.
- [27:05]
A
I've talked to so many people that are just overwhelmed by the sprawl of SaaS. Some of them, they know about a good set of them, but then they're always discovering things all the time. It's so easy to adopt it inside of the enterprise. For those security leaders who are just overwhelmed by SaaS sprawl, what is the first step that they should take? Maybe it's the anointing of the person.
- [27:36]
B
Yeah, you anoint somebody and say this is your job and that may mean you need to hire someone, you need to take someone off of some other task. But the same way, once upon a time nobody's paying attention to active directory and then you had to focus on it, clean it up, understand what was required because that's the best anti ransomware activity you can invest in. The same thing for SaaS, I think anointing somebody and then maybe peeling back some of the hours and labor you're investing in somewhere else in the security program to make time for this, to me, that's the first step.
- [28:07]
A
Awesome, Brad, thank you so much. This was great. It's such an important topic. I know it's on the minds of folks as they come up to RSAC conference. So I really, really appreciate you taking the time to be here today and also wanted to thank our listeners for tuning in. So please keep the conversation going on our RSAC membership platform by visiting onersac.commembership and be sure to check onersac.com for new content posted year round. Brad, thanks again. Awesome talking to you. Love it.