Modern SaaS Risks - CISOs share their SaaS security checklist

Oct 7, 2021

Oct 7, 2021

We’ve got SaaS. You’ve got SaaS. We’ve all got SaaS! But is it safe? Saas adoption is outpacing our capacity to manage its mounting risks with adapted technologies, policies and processes. Discover what some of cybersecurity’s most influential leaders intend to do about it.

Sounil Yu
CISO & Head of Research at JupiterOne
Link to Linkedin
Frank Kim
CISO at SANS Institute
Link to Linkedin
Lior Yaari
CEO at Grip
Link to Linkedin
Modern SaaS Risks - CISOs share their SaaS security checklist
This webinar will cover:

We’ve got SaaS. You’ve got SaaS. We’ve all got SaaS!

But is it safe? Saas adoption is outpacing our capacity to manage its mounting risks with adapted technologies, policies and processes.

Discover what some of cybersecurity’s most influential leaders intend to do about it in this live event. Join Sounil Yu CISO & Head of Research at JupiterOne, Frank Kim fellow and former CISO at SANS Institute and Lior Yaari CEO and Co-Founder at Grip Security as they share their SaaS app security checklist and the practical steps they’re taking to get a grip on their SaaS.
We’ll discuss:

✓ The current security landscape’s top SaaS risks
✓ Offboarding SaaS users the right way
✓ The impact of vendor evaluations
✓ Operational SaaS security for security teams
✓ The benefits and shortcomings of policies like BYOA

Fill out the form and watch webinar
In this webinar:

Lior Yaari:

Hey, everyone. Let's give a few seconds for everyone to join. Then we could start. So, welcome to the webinar, Modern SaaS Risk, CSOs Share Their SaaS Security Checklist. I'm honored to have our distinguished guests here. We have Frank Kim, fellow and former CSO at the SANS Institute, and [Sounil 00:00:29] Yu, CSO at JupiterOne and creator of the Cyber Defense Matrix. My name is [Lior Yaari 00:00:34]. I'm the CEO at Grip Security. I'll be the moderator for this webinar. So, Frank, Sounil, thank you very much for joining today. We're honored to have you here. Maybe just to kick off the webinar, I would love to ask, what do you see as the main risks of SaaS being used today within your organization? Sounil, maybe you can take the question first.

Sounil Yu:

Sure. Well, I think the one risk that most people care about is just where their data is going, and when it comes to SaaS applications, nearly all of them are data sinks, in some way, meaning data sinks into it and rarely comes back out, or it gets purged. So, as you have more and more SaaS applications being used within an organization, more and more of your data proliferates to all of those SaaS applications. As it proliferates, we lose control. Right? More so, there's a ton of SaaS applications, which are great for helping us accelerate our business, and the other aspect of the risk associated with SaaS is just knowing what SaaS applications are being used within the organization. That's, oftentimes, difficult to manage, as well.

Lior Yaari:

Thank you.

Frank Kim:

Sounil, with you talking about the data, it made me think of this famous quote. The only thing we have to fear is fear itself. Really, to me, a lot of that is about the unknown. I'm going to date myself here a little bit. In a prior life, in a prior organization I was working at, there was a data center, but this was a data center that nobody else ... We knew about it, but a different business unit had stood it up all on their own. There's a risk here of shadow IT, and it's just SaaS, and the cloud is making shadow IT even more easy for all of these different business units to do. So, in terms of the risks, I really think that you mentioned it in terms of the visibility, the lack of understanding of what we actually have in our environments, and then correspondingly, that lack of control that you said. Yeah. I couldn't agree more.

Sounil Yu:

I think one thing to be mindful of where shadow IT is, back in the day, we would have shadow IT because our IT department couldn't deliver IT services fast enough for the business. So, essentially, if you think about what SaaS is, if the IT function within the business could deliver something like Salesforce, if they could deliver something like Slack, if they could deliver something like any of the number of SaaS applications that we have out there, at the speed of the market, then we wouldn't ever have a need for a SaaS application. We all know that's completely unrealistic. When we saw shadow IT, the other way that it was also framed was this notion of shallow IT, meaning it provided a view of where the CIO function fell short in terms of being able to deliver the services that the organization needed.

Sounil Yu:

The reality is, the CIO organization really can't keep up with the variety and the value that SaaS applications bring. We're going to always be in this situation because these external companies are going to be able to provide value much faster, at a speed that meets the need of business, way faster than any internal organization is going to be able to deliver. So, I think this is a state that we ... There's no turning back from this. We need to figure out how to manage the challenges here. This is not a problem that can be solved. It's something that we have to manage.

Lior Yaari:

Yeah. I really agree. Frank, do you want to continue to reply?

Frank Kim:

Well, hey, it just makes me think. I've had, maybe, this mindset early in my career. I've seen other security teams with this mindset of saying no, and that saying no just leads the business to go someplace else. There is no way to continue to say no. We might have this list of approved SaaS apps that we hope, that we want, the business to actually follow and use. Sure. For the bigger problem domains, the well-established SaaS providers, we can set some guardrails, but there's always going to be that long tail of applications that, because of innovation, because of business needs, that they're going to go to. Yeah. For sure.

Lior Yaari:

It's very easy for me to relate. One of the solutions we're building here at Grip is the ability to almost immediately build an inventory, or do a discovery process for all of the different applications our customers are using. Every time we do that, we find dozens or hundreds of unsanctioned applications used as the new generation of shadow IT, shadow SaaS. Maybe shining a light on those applications leads me to the next question. Every time we do this process, we find that users are using applications without the IT or security team knowing that. Once those users leave the company, they basically retain their credentials to each and every application that they used, just because they can remember the password. What I'd love to ask, Frank, maybe you can start, is how do you deal with off-boarding of users from all of the different applications that they used?

Frank Kim:

Yeah. Great question. I think it also depends on the type of organization, the maturity of the organization. To be honest, to be upfront, in prior lives, we didn't deal with it very well. We knew that people were leaving, and we knew that there was different access, different permissions, different entitlements that were needed at different times, but a lot of times, sadly, once they got that initial access, unless there were some corresponding business processes in place for those specific scenarios, we wound up playing a lot of catch-up. A lot of it was ... I also, in years past, made the mistake of deploying a first-generation [CASB 00:06:28], and the reason it was a mistake is because we focused too much on technology.

Frank Kim:

We said, "You know what? Hey, let's get this. This sounds cool. Let's deploy it." Sure, while it gave us some initial visibility, what then? Right? We didn't develop the processes. We didn't develop the relationships with all of the other parts of the organization to figure out what to do after that. So, to be honest, off-boarding was a mess, and it's only until we get connected with HR, we get connected with those business processes, that then we figure out, "Oh, okay. This is what we need better insight on in terms of working with the various business partners."

Sounil Yu:

Yeah. Off-boarding, there's a question that is often asked, which is, how do we know if a security program is functioning well? There was a survey, I remember, where it would say ... Rather, how do you know if a security function is not performing well? You rank, order, and say which characteristics would demonstrate that it's not working well? Anyway, to shorten the story, the off-boarding of users, if you fail to off-board users, that was considered to be the worst indication, or the strongest indication, of a poorly-performing security function. Okay? Your inability to off-board users from all the places where you have corporate footprint, your inability do to that is a really bad sign for a security organization.

Sounil Yu:

All right. So, then the question that you're asking is really a dagger to a lot of people, a lot of security teams, because that's the number one challenge that we face. Right? How can we ensure that we fully off-board all users? Now, in my company, in my team, I have the fortune of using our own product to help us do that. There's a certain query that we run that says, "Show me all the users that are de-provisioned from my IDP, that still have accounts elsewhere." Okay? Boom, I get a list. That lists should be zero. Right? Any time someone shows up on that list, then we quickly go and de-provision that user from that SaaS application, wherever that might be. But that's presuming, of course, that you know that they're using that SaaS application. Right? How do we know?

Sounil Yu:

Well, one of the ways that we know is by, again, using our IDP. So, we fully encourage everyone to use SSO through our IDP to authenticate into a SaaS application. If a SaaS application supports it, great. We have some view, or visibility, into, "Here's a user that's using this SaaS application, and we noticed that they went through our SSO provider. Bingo." But as you know, we can also have people just sign up for an account, and we wouldn't know if that ever happened because we just don't see that through our IDP. To some degree, that's a policy, and we try to exercise some degree of controls to ensure that everyone does go through an SSO provider, but again, as you probably know, there's many different ways to bypass that, as well.

Lior Yaari:

Yeah. I do. I think when we look at the problem, traditionally, organizations base their security program on having an organizational network. So, if you had a [GitHub 00:09:56] server on your network, and someone left the company, even if you didn't de-provision the user, they still didn't have access to the server itself. Now, when this GitHub server moved to the cloud, moved to the internet, now there's a need for new processes within the organization, which of course, we are trying to solve and automate at-scale to actually off-board them, or revoke their access on the application, to each and every other different application they sign up to. So, I really appreciate the answer. I think it makes a lot of sense.

Lior Yaari:

Frank, you mentioned before, building this list of approved SaaS vendors. I know many organizations are building, moving, or sending SaaS applications to go through vendor evaluation process, or a SaaS risk assessment. So, what I'd love to ask is, what are the parameters that enterprises should look for when deciding whether an application should be an approved application or whether they should decline the users from using it?

Frank Kim:

Man, that's a good question. I think it depends on those parameters. Right? You're asking, what are the factors that you use to evaluate the security, the viability, the trust that you should have in a SaaS app. If you're a large, traditional enterprise, you're going to send that long questionnaire, and you're going to ask people to fill it out, and you get this cumbersome, ridiculous set of questions. There's typical things on there, like, "Hey, did they have their [SOC 2 00:11:30], and do they have certain third-party attestations, reviews? What's their process for testing," and all of that. I think that the main thing outside of all of those, maybe, common things that people actually look for is think about breaking it up into different buckets. What are those bigger, primary workflows that the organization is handling?

Frank Kim:

If we think about the different organizations, if you're at a traditional enterprise, a horse, if you will, in DevOps parlance, versus maybe a cloud-first company, a unicorn DevOps-wise, it's going to be a little bit different in terms of what you want to enable, and the speed at which you actually want to move. So, I think in terms of those first principles, yes, those larger enterprises are going to take a little bit more of that heavyweight approach. So, there's the third-party certification, how's the data handled, how's the data processed, what's the risk of the data that's actually there? But if you're looking to support in a more nimble environment, I think you want to look at some of the principles in terms of that API-driven, cloud-first approach.

Frank Kim:

At SANS, for example, we use Slack a lot. Slack, how it trickles out to integrate, and we use it, and set it up with other SaaS services, is one of our parts of our process engine internally, if you will. Right? A chatbot, ChatOps, and so on. So, with that, I think it's API-driven. What's the security around that? Thinking about what's that speed to delivery in terms of those metrics. I guess I'll leave it here, because I know Sounil has a lot to talk about in this area, too.

Sounil Yu:

I have a lot to complain about. So, one of the more, seemingly, straightforward ways to do a risk assessment is the permission scope that the SaaS application is asking for. So, when you, for example, SSO into a SaaS application, before it allows you in, it says, "I want access to this," whatever that might be. The challenge or the complaint here is that understanding the permission scope is wickedly hard, because there's so many different parameters that need to be examined and looked at. What is the risk of allowing someone to have read access to some repository or some data that you have associated with your IDP? What's the risk of giving them write access to that same thing? What's the risk of giving them read access to a certain Slack channel, or write access to a Slack channel?

Sounil Yu:

There's all these different permission scopes that come whenever you work with these SaaS applications. Understanding the permission scope, de-conflicting them, understanding what transit of trust relationships are created with them, it's a pretty hairy mess. I doubt most people even take much of a glance at them. If you do look at them, you'd be quite surprised. There are some SaaS providers, which I won't mention, that are very, very permissive, or promiscuous, in terms of their permission scope. In one case, I remember seeing this one where it not only asked for access to your calendar, but access to all the other calendars that you can see. Okay? So, it's not just your account. If it happens to be that your organization allows you to see everyone else's calendars by default, that means that provider can see everyone's calendars, as well.

Sounil Yu:

Is that something that you want to allow? Right? The type of exposure that you might create by ignoring the permission scope is at your own peril. Okay? Again, the number of permissions, the volume and the esoteric nature of some of these permission scope declarations, is extremely hard to parse, and extremely hard to understand, and extremely hard to understand how they relate to one another. Again, what transit of trust relationships might be created because you're giving somebody read access, and you don't understand that permission scope will tip to everything else in your environment.

Frank Kim:

Yeah. Super hard. Sounil, earlier, you mentioned SSO, single sign-on. I think I'll part argue that single sign-on, that authentication, is largely a solved problem. Right? In terms of that core-screened access, there's lots of different ways to do it. We, in security, as an industry, we've largely ignored the fine-grained access control, the authorization, the specific entitlements, for the most part, for many things, and I think this is a good example of it, because it's been too complex. How do you think about this? What has access to what? What service, maybe, is calling another service? What's calling another service? What's that downstream, trickle-down effect of all that blast radius of all this access you might have in your environment, that goes unseen? Right? Yeah. Definitely.

Sounil Yu:

I guess we have to be careful what we ask for. So, we wanted granular access controls, and we got them. Now what?

Frank Kim:

Yeah. Now you've got the equivalent of the Facebook permissions menu.

Sounil Yu:

And it's a nightmare. Right? Just think about just the extensive number of those across every SaaS application you have to deal with. Again, it's a nightmare. There's no way that, I think, we can expect security practitioners to have to try to understand or manage this on their own.

Frank Kim:

Right. Hey, they say, "Go configure Salesforce." I can barely use Salesforce.

Sounil Yu:

That's right.

Lior Yaari:

Yeah. I think if we look at the market of companies who spent two years learning the Salesforce configuration model, just to build a solution for it.

Sounil Yu:

Wow.

Lior Yaari:

It's definitely a challenge for security leaders and security teams. I want to throw another problem into the mix when you're looking at vendor risk assessments, specifically for SaaS, and that is often, the timing in which those applications get to the GOC, or to the risk team, is after the users, like 50 users, have been using it for a while. Someone discovers they're doing it, and they've asked the owners of the application to submit it through, or to process it through a vendor risk management process. Once they've already invested so much effort into using the application, and collaborating over it, is it realistically going to be declined? Is there a way to revoke or remove the application?

Sounil Yu:

Well, I was mentioning, there's actually ... One of my team members characterized it this way for me. There's problems, and there's predicaments. Problems can be solved. Predicaments have to be managed. So, what you're explaining is a predicament. We're not going to be able to solve that problem, we just have to find a way to manage it. Managing it means to know that it's happening as soon as possible so that, in the event that you actually did want to roll that back, you have a chance. You at least have a fighting chance, because you know about it sooner than ... soon enough that people haven't committed to using and having that entrenched within the organization.

Sounil Yu:

If it has been entrenched, at that point, you really are just managing the associated risk, or sending policies on, "Hey, make sure that you don't upload or send the most sensitive stuff into this environment," or to be able to gate who should have access to certain things. I could say, "Look, if you're on our marketing team, or the sales team, this is appropriate for you to use, but if you're on the engineering team, you have no business using these particular applications." Those ways to manage the predicament that we're in is what we had to do when we were dealing with post-facto situations where the team has already been using the application.

Frank Kim:

Sounil, you always have the best way to frame things, the problem and the predicament. Lior, you were asking about the GRC, and hey, operations is not the same. IT is not the same. Development is not the same. These current modern practices, in terms, need to also be applied to audit and compliance, I think. So, automation, API-driven, and so on. It's going to take some time to get there, but I think, hey, if you've got a GRC program, you want to think about, how do you capture this information automatically on a continuous basis to inform that assessment, that review, that reaction, as well, to manage that predicament? I think we're getting there, but it's slow going, I think, in a lot of organizations.

Lior Yaari:

Yeah. We really believe in the value of knowing about the use of an application from day one. So, a second after the user has started using it. This is one of the values we push for here in Grip, just because our technology enables for it. I think it's a new trend companies will go through in the next few years or so. When thinking about it, and thinking about SaaS becoming a bigger and bigger problem for companies today, I wonder if you think SaaS security is becoming a knowledge niche that requires a dedicated person to handle? Like the same shift we had with cloud security, and with identity and access management, where it started small, and now eventually, almost every company has a dedicated engineer working on this specific problem. Will we see SaaS security engineers? We've certainly started seeing those for several of our customers.

Frank Kim:

I'm just pausing for a sec because that's an interesting question. A lot of the customers and people that I talk to in the industry, when they think about cloud, they're still at the early phase, relatively early phase, of even thinking about, "Well, what do we do from our cloud infrastructure and platform security perspective? What do we do in AWS, Azure, and GCP?" While, certainly, we know that every organization has dozens, hundreds, of different SaaS services that they're using, a lot of security teams I see are really ... Their mind share is focused on other areas of the cloud. I think that in terms of the solutions that are available, we're still at that point where the market has to reach that slope of enlightenment, I guess, to use the Gartner term.

Frank Kim:

I think, with that, usually follows on, "Hey, we've got cloud security engineers, and architects, and so on, for traditional infrastructure and platform cloud." Yeah. It's very specialized. It's very niche. I think what I mentioned earlier, in terms of SaaS is an area where you need even more partnership with the business to understand what that permission model should be. Who has access? What's the data, and so on? So, I could definitely see more happening there from an overall process and a skillset perspective.

Sounil Yu:

I think the answer is going to be tied to how general purpose that SaaS application might be, versus how niche or how focused that particular SaaS application might be. So, if it's a very niche SaaS application, then I don't think you need a niche person. Rather, I would expect to actually have some technology that will satisfy my needs to secure a niche SaaS application. What I mean by that is a SaaS application that has a very specific focus and purpose. There isn't an opportunity for people to build additional applications on top of it. So, the more general purpose SaaS applications like Salesforce, like ServiceNow. You can even think of the infrastructure service, AWS and whatnot, as more general purpose.

Sounil Yu:

In those situations, I do think you need a dedicated person that can handle some of those environments, because those are ever-changing. Because of the ever-changing nature of them, I can see why it takes a startup that's trying to do Salesforce security two years to just understand it. By which time, things have changed because Salesforce has introduced new features, or AWS has introduced 20 new services. Right? So, it's an interesting reversal, if you will. If it's a general purpose SaaS application, then you need niche skills for that general purpose application. If it's a niche SaaS application, I think you can use either a general purpose person or, ideally, a technology that knows how to configure that environment quickly and easily so that you can move on and not have to worry about has it been secured properly?

Lior Yaari:

So, if I'm understanding correctly, what you're saying is that there's no need for a pair app engineer, unless the application is used widely enough within the organization, and it's ever-changing to have a dedicated person responsible for it? But I wonder, is it a good decision for an organization to appoint a SaaS security specialist, someone who's responsible with engineering challenges and the ongoing challenges of just managing SaaS in general within the company?

Sounil Yu:

Yeah. Actually, let me add one of additional piece then, as far as those niche SaaS applications. Where I would want a SaaS engineer, a SaaS security engineer, is when it comes to the integrations among those niche applications. Those integrations are where you have lots of non-deterministic outcomes that you actually do need a person to figure out, and manage, and triage, and address. So, the integrations among different SaaS applications, then is that general purpose view that requires a person, a dedicated person, to handle. Are there any security issues when I hook up [Zapier 00:26:01] with ServiceNow, with Slack? Okay? That's where it starts getting hairy because now you have all these different combinations that most technology companies, or most startups, or service providers, won't necessarily be able to anticipate.

Lior Yaari:

Yeah. Frank, do you have any comment about this?

Frank Kim:

No. I think that's pretty well covered. It makes sense from a complexity and trade-off perspective. Of course, as things get more complex, certainly, you need to specialize in it a little bit more. So, yeah. It makes sense.

Lior Yaari:

Mm-hmm (affirmative). So, an interesting topic I'd love to cover is the now-emerging concept of BYOA, bring your own application. The same ways companies moved from issuing corporate devices to BYOD, bring your own devices, there's this general thought today of allowing users to use the applications they need to use to do their job best. This is, of course, contrary to how companies have, today, a list of approved applications. I wonder, thinking about that, what do you pick, and how the choice changed across different companies, and why? How can a company decide they want to have a loose SaaS policy, allowing users to use what they want, what they need to do in order to approve such a policy, and what types of companies choose to keep the strict list of approved applications instead?

Frank Kim:

It strikes me that it really depends on the data, the importance of that data and the crown jewels. What are the crown jewels for an organization? I don't think I've seen, and I don't expect, any organization to say, "Hey, sales team, sure, you can use your own way to do customer relationship management. Forget about Salesforce." Right? There are benefits to the organization having that all centralized. On the other extreme end of the spectrum, depending on the job role, there's lots of SaaS. There's a SaaS app for everything. So, if you're using Canva to make some graphics, I could see why, "Hey, sure. If somebody wants to use that, hey, let them go ahead and use it, because it makes them more productive."

Frank Kim:

This is where I would be thinking, from a security perspective, what are the top five, top 10, most impactful and most widely-used SaaS apps that have the biggest impact? Think about those as a category in terms of those workflows, versus that long tail of just general purpose productivity apps that might be useful in one-off cases.

Lior Yaari:

I had a conversation with a CSO a few weeks ago, which was [Bradley Bosch 00:28:47], who told me, "When you hire a plumber, you expect them to bring their toolbox. Why didn't you expect the same from a data analyst or a data engineer?" I like that quote because it is true. It's true for salespeople that work together, that collaborate together. It makes sense for them to use the same platform. But for many of the dedicated professionals that we hire, they have a wide variety of applications that they can use to do the job efficiently. If we could allow it, the organization might benefit. It could move faster. It could get better outputs and better results. Sounil, I saw you thinking. I wonder what you think.

Sounil Yu:

Yeah. I was trying to think if that was the right analogy, with the plumber. Let me answer the original question, and then I'll come back to the analogy, and why it doesn't fit right for me. Anyway. I think it ultimately comes down to one's risk tolerance. The risk tolerance is also tied to how fast you want the organization to grow. So, if you have a relatively static environment, slow growth, very large enterprise, organizations that I used to work with, work for, they're going to be a lot more risk-adverse. As a result, we will move slower, and we will have time, actually, to make a decision as to whether this application is something that we want to use, or not. Things just move slower. Procurement runs slower. We have an opportunity to do a thorough review, and as a result, we can pre-approve apps ahead of time.

Sounil Yu:

Unfortunately, that just won't work for other organizations that are more risk-taking. For those risk-taking organizations, we want them ... It's a matter of business competitiveness for them to be able to find the best tools to help them do the job as quickly and efficiently as possible. Now, let's consider, going back to the plumbing example, maybe, why is that not ... Sure, they bring their own tools, but they're not going to bring the latest, newest tool that you might imagine. I think that's partly because, one, plumbing itself, or that industry, is highly regulated. You've got to have a license. You've got to have ... There's really not much innovation there. If there is to be innovation there, if there's some new widget or new gadget that someone can use to fix your plumbing problems faster, I would imagine that company, or that service, would actually be more innovative, or willing to take risks, or willing to try new things.

Sounil Yu:

Now, would I want them to try that on my house? Probably not. But if they said, "Hey, we can do this for much cheaper, and must faster, than Joe Plumber over here," okay, maybe I'm willing to take that risk because I'll get a better price and faster service, because they're using the latest app or the latest tool to fix that problem that I had. Again, like I said, I think it comes down to one's own risk tolerance. When you look at different companies, whether it's at a startup or a big, large organization, you're going to have different risk tolerance, and thus, different choices on what you pre-approve or what you allow.

Frank Kim:

When you mentioned that plumbing analogy, it made me think about, immediately, a chef. A professional chef always travels with their own knives. But how much do those knives impact other chefs or other workers in the kitchen? Not at all. It's just about making that chef more effective with the tools that they want to use. So, I think that there's that risk tolerance, but there's that productivity spectrum, as well, in terms of why should we prevent the installation of VS Code, if that's what somebody wants to use? There are organizations that I've worked at that will prevent you from installing anything. Right? But there's no impact. There's no larger impact to the organization, like with using something other than Salesforce, for example. I think from that productivity, risk spectrum is where that question really, really lies.

Lior Yaari:

One comparison I thought about over the weekend is how SaaS applications, and allowing or disallowing the use of them, is similar to how companies in the past prevented users from installing software on the laptops, back in the days before everything was in the cloud. What I thought about it is that the risk back then wasn't data moving outside of the company, it was users being able to install malware on their machine because they accidentally downloaded the wrong file. I think that with SaaS, the threat is different, because I don't think the threats we look at, or the risks we are afraid to take, other users would use a malicious SaaS application. Even though possible, it's not the main risk. The main risk is them extracting data to a location we are not aware of, one, and that could be breached by a third party. I wonder if you agree with this statement, because if that's the case, it might make sense to disallow installation of software, even though we want it, and do allow users to use applications that they need to use in order to do their job.

Sounil Yu:

Right. I'm sorry. Are you saying should we prefer SaaS applications over thick clients, or what?

Lior Yaari:

I think the risk model is different. So, the reasons we disapprove those are different from the reasons we disapprove SaaS. Maybe that should change our approach to why we could approve SaaS, because we're not afraid the users would use a malicious one.

Sounil Yu:

Sure. Going back to the risk tolerance question, if I can install a thick client that helps ensure that the data stays within my environment, then I may actually choose to do that. But the reality is, most thick clients today beacon out to, and send all the data, out anyway. So, there's almost no practical difference. I mean, if you're using Slack, the desktop client versus the web client, you're still ... It doesn't matter. Right? You're still using it. You're still sending out data. But if there's a way to contain that data, is it work the trade-off to have a thick client that may also be malware? I guess at that point, then that's where some of the vendor assessments might come in handy. I may choose not to do business with a Russian entity versus a US one, because in theory, one might be safer than the other.

Frank Kim:

Lior, are you saying that, "Hey, we're talking about what is the risk in either scenario?" If we break down risk, we know it's likelihood and impact, and we can further break down likelihood into vulnerability, what vulnerabilities, what weaknesses, mis-configurations, and so on, do we have in our environment, and the threat. What is the threat actor? What are the techniques and tactics that they're actually using? So, you're saying that if something is in the SaaS provider, well, then what is the threat? What's the technique that the attacker is going to use? Well, they've got to, maybe, compromise the cloud provider, compromise that application, or steal some credentials to get access as the user, versus on the endpoint, you're saying, "Okay, well, hey, the threat actor is still trying to get in with a different technique, but that vulnerability is different?" That's what you're getting at?

Lior Yaari:

Exactly. It is.

Sounil Yu:

Sorry. If that was the difference, if that's the dichotomy, I would strongly suggest people move to the SaaS-provided service, and whether it's their most recent [Jira 00:37:08] issue, with Confluence being compromise-able, if you had your own on-premise instance, or Exchange earlier in the year, I mean, if you're running an on-premise instance of some software that you could actually get at a SaaS service, unless you have a dedicated person that's going to be constantly attending to the security needs of Jira or Exchange, you're much better off outsourcing that to somebody else, like Microsoft and [Atlassian 00:37:42].

Frank Kim:

Exactly. That person can't do it as well, comprehensively, as effectively, and they don't have the incentive to do it as well as a Microsoft or an Atlassian.

Sounil Yu:

That's right.

Lior Yaari:

So, moving on to one of our last questions, I wonder, if looking back in hindsight, did you make any mistakes in how you designed your SaaS security program? What would you advise to the past you to do instead? Frank, maybe you can start.

Frank Kim:

Well, I guess one big mistake is that we didn't have a SaaS security program.

Lior Yaari:

That is a mistake.

Frank Kim:

We were constantly in firefighting mode when it came to SaaS applications. Things would come up. "We're using this." Now, eventually, over time, that got more mature. Certainly, the main ones, Salesforce, Slack, whatever, whatever else we were using, we got a better handle on that and helped put together some best practices, review, assessment, and so on. But that happened, to be honest, organically or by accident. We didn't think about it proactively. So, I would say the advice would be get a handle on what's the SaaS in your organization? What percent is used by what different areas? Better understand not just that long tail of visibility, but what's actually used the most, and where does that important data lie?

Lior Yaari:

Get a Grip on your SaaS, is the advice I give, as well.

Sounil Yu:

I don't know what mistakes we've made, only because if we've made a mistake, it hasn't cropped up to haunt us yet. But if there is a ... It's not really a mistake as much as it was a question of timing. I mentioned this notion of risk-adverse, risk-taking. In the life of a startup, you'll, of course, be risk taking. Right? That's the whole point of a startup to begin with. When it comes to SaaS security, having a lot of tight controls over SaaS security, it may be a hindrance to the growth of a startup. At some point, we actually changed our posture to say, as I hinted at earlier, "We're going to preapprove SaaS applications before you're allowed to log into them." It's definitely a nontrivial hurdle, but it was a decision that we made once we reached a certain number, a certain size of our organization, or a certain number of SaaS applications, where we felt like, "You know what? Okay. We need to start locking this down. We're starting to see some really weird SaaS applications that seem sketchy."

Sounil Yu:

There's something that will trigger your organization to say, "Okay. Let's start locking this down." The timing of that is really what, I would say, needs to be considered. Should it happen at the very beginning? I would argue no, because that, again, slows down the life of the startup, and that's something that's going to be really hard to swallow. But what's the right timing to switch from one that's just a free-for-all to one where it becomes more controlled? That is something that, I think, everyone will have to figure out for their own organization. We made that switch about a year into the life of the organization, and it was a painful switch, but one that we're now comfortable with. It's at a steady state. Earlier on, we would see these interesting jumps in SaaS application usage as we brought on different teams. Right?

Sounil Yu:

The sales team comes on. All these new SaaS applications. Marketing team comes on? Another bunch of SaaS applications. But over time, that starts to dwindle. When it starts to dwindle is when, I think, it might be worthwhile to say, "Okay. I think we have a good sense of what SaaS applications we use. Let's start tightening the ship down a little bit and be a bit more proactive in approving SaaS applications as they come in, because the volume is much lower," and so on, so forth. Again, that timing is something that each organization will need to think through and decide on their own.

Lior Yaari:

I can strongly relate to the example you gave about each function in the organization bringing in their own group of applications. One of the features within our platform is the ability to see a graph of how SaaS grew within the company, and every time we opened a new function, being engineering, design, marketing, you just see an immediate jump in the number of applications that we used. Those, of course, stack up on top of each other as the organization gets bigger and bigger, with different business units using their own things. So, I'd love to move to the last question, which is, if you had one tip, and a short one, for CSOs and security leaders who want to secure their SaaS applications, what would it be? Sounil, maybe you can start.

Sounil Yu:

I don't know. Get a Grip. I think it's ultimately use SSO. Try to make sure that you get everyone to use SSO. That is the one thing I would strongly advise.

Lior Yaari:

Frank?

Frank Kim:

I'll try to keep this quick. I would say, figure out how to say yes. Figure out how to say yes from a security perspective. If I think back, step back and treat ... You've got all of your different security tools. Maybe treat your security program like a portfolio of investments. Maybe you've got some small percentage in "riskier" bets, and that would be making a small investment of not a big bang deployment, but find a tool that you think will meet your need and test it out, and play with it, and see if it helps address, and help you get to saying yes.

Lior Yaari:

Yeah. So, thank you very much. I want to thank everyone who joined so far. I want to thank, again, Sounil and Frank for taking the time to speak about this important topic. My name, again, was Lior Yaari. I'm the CEO at Grip Security. We help companies discover our SaaS application, and then build access management and data governance capabilities to all of the different applications at an identified scale. If you're interested in learning more, you can go on our website, grip.security, or you can directly message me on LinkedIn. Thank you, everyone, for joining. We'll see you next time.

Frank Kim:

Thanks a lot.

Lior Yaari:

Yeah.

See More
See more
Oops! Something went wrong while submitting the form.
Register now and save your seat!
Registration successful!
Webinar link will be sent to your email soon
Oops! Something went wrong while submitting the form.
In this webinar:

Lior Yaari:

Hey, everyone. Let's give a few seconds for everyone to join. Then we could start. So, welcome to the webinar, Modern SaaS Risk, CSOs Share Their SaaS Security Checklist. I'm honored to have our distinguished guests here. We have Frank Kim, fellow and former CSO at the SANS Institute, and [Sounil 00:00:29] Yu, CSO at JupiterOne and creator of the Cyber Defense Matrix. My name is [Lior Yaari 00:00:34]. I'm the CEO at Grip Security. I'll be the moderator for this webinar. So, Frank, Sounil, thank you very much for joining today. We're honored to have you here. Maybe just to kick off the webinar, I would love to ask, what do you see as the main risks of SaaS being used today within your organization? Sounil, maybe you can take the question first.

Sounil Yu:

Sure. Well, I think the one risk that most people care about is just where their data is going, and when it comes to SaaS applications, nearly all of them are data sinks, in some way, meaning data sinks into it and rarely comes back out, or it gets purged. So, as you have more and more SaaS applications being used within an organization, more and more of your data proliferates to all of those SaaS applications. As it proliferates, we lose control. Right? More so, there's a ton of SaaS applications, which are great for helping us accelerate our business, and the other aspect of the risk associated with SaaS is just knowing what SaaS applications are being used within the organization. That's, oftentimes, difficult to manage, as well.

Lior Yaari:

Thank you.

Frank Kim:

Sounil, with you talking about the data, it made me think of this famous quote. The only thing we have to fear is fear itself. Really, to me, a lot of that is about the unknown. I'm going to date myself here a little bit. In a prior life, in a prior organization I was working at, there was a data center, but this was a data center that nobody else ... We knew about it, but a different business unit had stood it up all on their own. There's a risk here of shadow IT, and it's just SaaS, and the cloud is making shadow IT even more easy for all of these different business units to do. So, in terms of the risks, I really think that you mentioned it in terms of the visibility, the lack of understanding of what we actually have in our environments, and then correspondingly, that lack of control that you said. Yeah. I couldn't agree more.

Sounil Yu:

I think one thing to be mindful of where shadow IT is, back in the day, we would have shadow IT because our IT department couldn't deliver IT services fast enough for the business. So, essentially, if you think about what SaaS is, if the IT function within the business could deliver something like Salesforce, if they could deliver something like Slack, if they could deliver something like any of the number of SaaS applications that we have out there, at the speed of the market, then we wouldn't ever have a need for a SaaS application. We all know that's completely unrealistic. When we saw shadow IT, the other way that it was also framed was this notion of shallow IT, meaning it provided a view of where the CIO function fell short in terms of being able to deliver the services that the organization needed.

Sounil Yu:

The reality is, the CIO organization really can't keep up with the variety and the value that SaaS applications bring. We're going to always be in this situation because these external companies are going to be able to provide value much faster, at a speed that meets the need of business, way faster than any internal organization is going to be able to deliver. So, I think this is a state that we ... There's no turning back from this. We need to figure out how to manage the challenges here. This is not a problem that can be solved. It's something that we have to manage.

Lior Yaari:

Yeah. I really agree. Frank, do you want to continue to reply?

Frank Kim:

Well, hey, it just makes me think. I've had, maybe, this mindset early in my career. I've seen other security teams with this mindset of saying no, and that saying no just leads the business to go someplace else. There is no way to continue to say no. We might have this list of approved SaaS apps that we hope, that we want, the business to actually follow and use. Sure. For the bigger problem domains, the well-established SaaS providers, we can set some guardrails, but there's always going to be that long tail of applications that, because of innovation, because of business needs, that they're going to go to. Yeah. For sure.

Lior Yaari:

It's very easy for me to relate. One of the solutions we're building here at Grip is the ability to almost immediately build an inventory, or do a discovery process for all of the different applications our customers are using. Every time we do that, we find dozens or hundreds of unsanctioned applications used as the new generation of shadow IT, shadow SaaS. Maybe shining a light on those applications leads me to the next question. Every time we do this process, we find that users are using applications without the IT or security team knowing that. Once those users leave the company, they basically retain their credentials to each and every application that they used, just because they can remember the password. What I'd love to ask, Frank, maybe you can start, is how do you deal with off-boarding of users from all of the different applications that they used?

Frank Kim:

Yeah. Great question. I think it also depends on the type of organization, the maturity of the organization. To be honest, to be upfront, in prior lives, we didn't deal with it very well. We knew that people were leaving, and we knew that there was different access, different permissions, different entitlements that were needed at different times, but a lot of times, sadly, once they got that initial access, unless there were some corresponding business processes in place for those specific scenarios, we wound up playing a lot of catch-up. A lot of it was ... I also, in years past, made the mistake of deploying a first-generation [CASB 00:06:28], and the reason it was a mistake is because we focused too much on technology.

Frank Kim:

We said, "You know what? Hey, let's get this. This sounds cool. Let's deploy it." Sure, while it gave us some initial visibility, what then? Right? We didn't develop the processes. We didn't develop the relationships with all of the other parts of the organization to figure out what to do after that. So, to be honest, off-boarding was a mess, and it's only until we get connected with HR, we get connected with those business processes, that then we figure out, "Oh, okay. This is what we need better insight on in terms of working with the various business partners."

Sounil Yu:

Yeah. Off-boarding, there's a question that is often asked, which is, how do we know if a security program is functioning well? There was a survey, I remember, where it would say ... Rather, how do you know if a security function is not performing well? You rank, order, and say which characteristics would demonstrate that it's not working well? Anyway, to shorten the story, the off-boarding of users, if you fail to off-board users, that was considered to be the worst indication, or the strongest indication, of a poorly-performing security function. Okay? Your inability to off-board users from all the places where you have corporate footprint, your inability do to that is a really bad sign for a security organization.

Sounil Yu:

All right. So, then the question that you're asking is really a dagger to a lot of people, a lot of security teams, because that's the number one challenge that we face. Right? How can we ensure that we fully off-board all users? Now, in my company, in my team, I have the fortune of using our own product to help us do that. There's a certain query that we run that says, "Show me all the users that are de-provisioned from my IDP, that still have accounts elsewhere." Okay? Boom, I get a list. That lists should be zero. Right? Any time someone shows up on that list, then we quickly go and de-provision that user from that SaaS application, wherever that might be. But that's presuming, of course, that you know that they're using that SaaS application. Right? How do we know?

Sounil Yu:

Well, one of the ways that we know is by, again, using our IDP. So, we fully encourage everyone to use SSO through our IDP to authenticate into a SaaS application. If a SaaS application supports it, great. We have some view, or visibility, into, "Here's a user that's using this SaaS application, and we noticed that they went through our SSO provider. Bingo." But as you know, we can also have people just sign up for an account, and we wouldn't know if that ever happened because we just don't see that through our IDP. To some degree, that's a policy, and we try to exercise some degree of controls to ensure that everyone does go through an SSO provider, but again, as you probably know, there's many different ways to bypass that, as well.

Lior Yaari:

Yeah. I do. I think when we look at the problem, traditionally, organizations base their security program on having an organizational network. So, if you had a [GitHub 00:09:56] server on your network, and someone left the company, even if you didn't de-provision the user, they still didn't have access to the server itself. Now, when this GitHub server moved to the cloud, moved to the internet, now there's a need for new processes within the organization, which of course, we are trying to solve and automate at-scale to actually off-board them, or revoke their access on the application, to each and every other different application they sign up to. So, I really appreciate the answer. I think it makes a lot of sense.

Lior Yaari:

Frank, you mentioned before, building this list of approved SaaS vendors. I know many organizations are building, moving, or sending SaaS applications to go through vendor evaluation process, or a SaaS risk assessment. So, what I'd love to ask is, what are the parameters that enterprises should look for when deciding whether an application should be an approved application or whether they should decline the users from using it?

Frank Kim:

Man, that's a good question. I think it depends on those parameters. Right? You're asking, what are the factors that you use to evaluate the security, the viability, the trust that you should have in a SaaS app. If you're a large, traditional enterprise, you're going to send that long questionnaire, and you're going to ask people to fill it out, and you get this cumbersome, ridiculous set of questions. There's typical things on there, like, "Hey, did they have their [SOC 2 00:11:30], and do they have certain third-party attestations, reviews? What's their process for testing," and all of that. I think that the main thing outside of all of those, maybe, common things that people actually look for is think about breaking it up into different buckets. What are those bigger, primary workflows that the organization is handling?

Frank Kim:

If we think about the different organizations, if you're at a traditional enterprise, a horse, if you will, in DevOps parlance, versus maybe a cloud-first company, a unicorn DevOps-wise, it's going to be a little bit different in terms of what you want to enable, and the speed at which you actually want to move. So, I think in terms of those first principles, yes, those larger enterprises are going to take a little bit more of that heavyweight approach. So, there's the third-party certification, how's the data handled, how's the data processed, what's the risk of the data that's actually there? But if you're looking to support in a more nimble environment, I think you want to look at some of the principles in terms of that API-driven, cloud-first approach.

Frank Kim:

At SANS, for example, we use Slack a lot. Slack, how it trickles out to integrate, and we use it, and set it up with other SaaS services, is one of our parts of our process engine internally, if you will. Right? A chatbot, ChatOps, and so on. So, with that, I think it's API-driven. What's the security around that? Thinking about what's that speed to delivery in terms of those metrics. I guess I'll leave it here, because I know Sounil has a lot to talk about in this area, too.

Sounil Yu:

I have a lot to complain about. So, one of the more, seemingly, straightforward ways to do a risk assessment is the permission scope that the SaaS application is asking for. So, when you, for example, SSO into a SaaS application, before it allows you in, it says, "I want access to this," whatever that might be. The challenge or the complaint here is that understanding the permission scope is wickedly hard, because there's so many different parameters that need to be examined and looked at. What is the risk of allowing someone to have read access to some repository or some data that you have associated with your IDP? What's the risk of giving them write access to that same thing? What's the risk of giving them read access to a certain Slack channel, or write access to a Slack channel?

Sounil Yu:

There's all these different permission scopes that come whenever you work with these SaaS applications. Understanding the permission scope, de-conflicting them, understanding what transit of trust relationships are created with them, it's a pretty hairy mess. I doubt most people even take much of a glance at them. If you do look at them, you'd be quite surprised. There are some SaaS providers, which I won't mention, that are very, very permissive, or promiscuous, in terms of their permission scope. In one case, I remember seeing this one where it not only asked for access to your calendar, but access to all the other calendars that you can see. Okay? So, it's not just your account. If it happens to be that your organization allows you to see everyone else's calendars by default, that means that provider can see everyone's calendars, as well.

Sounil Yu:

Is that something that you want to allow? Right? The type of exposure that you might create by ignoring the permission scope is at your own peril. Okay? Again, the number of permissions, the volume and the esoteric nature of some of these permission scope declarations, is extremely hard to parse, and extremely hard to understand, and extremely hard to understand how they relate to one another. Again, what transit of trust relationships might be created because you're giving somebody read access, and you don't understand that permission scope will tip to everything else in your environment.

Frank Kim:

Yeah. Super hard. Sounil, earlier, you mentioned SSO, single sign-on. I think I'll part argue that single sign-on, that authentication, is largely a solved problem. Right? In terms of that core-screened access, there's lots of different ways to do it. We, in security, as an industry, we've largely ignored the fine-grained access control, the authorization, the specific entitlements, for the most part, for many things, and I think this is a good example of it, because it's been too complex. How do you think about this? What has access to what? What service, maybe, is calling another service? What's calling another service? What's that downstream, trickle-down effect of all that blast radius of all this access you might have in your environment, that goes unseen? Right? Yeah. Definitely.

Sounil Yu:

I guess we have to be careful what we ask for. So, we wanted granular access controls, and we got them. Now what?

Frank Kim:

Yeah. Now you've got the equivalent of the Facebook permissions menu.

Sounil Yu:

And it's a nightmare. Right? Just think about just the extensive number of those across every SaaS application you have to deal with. Again, it's a nightmare. There's no way that, I think, we can expect security practitioners to have to try to understand or manage this on their own.

Frank Kim:

Right. Hey, they say, "Go configure Salesforce." I can barely use Salesforce.

Sounil Yu:

That's right.

Lior Yaari:

Yeah. I think if we look at the market of companies who spent two years learning the Salesforce configuration model, just to build a solution for it.

Sounil Yu:

Wow.

Lior Yaari:

It's definitely a challenge for security leaders and security teams. I want to throw another problem into the mix when you're looking at vendor risk assessments, specifically for SaaS, and that is often, the timing in which those applications get to the GOC, or to the risk team, is after the users, like 50 users, have been using it for a while. Someone discovers they're doing it, and they've asked the owners of the application to submit it through, or to process it through a vendor risk management process. Once they've already invested so much effort into using the application, and collaborating over it, is it realistically going to be declined? Is there a way to revoke or remove the application?

Sounil Yu:

Well, I was mentioning, there's actually ... One of my team members characterized it this way for me. There's problems, and there's predicaments. Problems can be solved. Predicaments have to be managed. So, what you're explaining is a predicament. We're not going to be able to solve that problem, we just have to find a way to manage it. Managing it means to know that it's happening as soon as possible so that, in the event that you actually did want to roll that back, you have a chance. You at least have a fighting chance, because you know about it sooner than ... soon enough that people haven't committed to using and having that entrenched within the organization.

Sounil Yu:

If it has been entrenched, at that point, you really are just managing the associated risk, or sending policies on, "Hey, make sure that you don't upload or send the most sensitive stuff into this environment," or to be able to gate who should have access to certain things. I could say, "Look, if you're on our marketing team, or the sales team, this is appropriate for you to use, but if you're on the engineering team, you have no business using these particular applications." Those ways to manage the predicament that we're in is what we had to do when we were dealing with post-facto situations where the team has already been using the application.

Frank Kim:

Sounil, you always have the best way to frame things, the problem and the predicament. Lior, you were asking about the GRC, and hey, operations is not the same. IT is not the same. Development is not the same. These current modern practices, in terms, need to also be applied to audit and compliance, I think. So, automation, API-driven, and so on. It's going to take some time to get there, but I think, hey, if you've got a GRC program, you want to think about, how do you capture this information automatically on a continuous basis to inform that assessment, that review, that reaction, as well, to manage that predicament? I think we're getting there, but it's slow going, I think, in a lot of organizations.

Lior Yaari:

Yeah. We really believe in the value of knowing about the use of an application from day one. So, a second after the user has started using it. This is one of the values we push for here in Grip, just because our technology enables for it. I think it's a new trend companies will go through in the next few years or so. When thinking about it, and thinking about SaaS becoming a bigger and bigger problem for companies today, I wonder if you think SaaS security is becoming a knowledge niche that requires a dedicated person to handle? Like the same shift we had with cloud security, and with identity and access management, where it started small, and now eventually, almost every company has a dedicated engineer working on this specific problem. Will we see SaaS security engineers? We've certainly started seeing those for several of our customers.

Frank Kim:

I'm just pausing for a sec because that's an interesting question. A lot of the customers and people that I talk to in the industry, when they think about cloud, they're still at the early phase, relatively early phase, of even thinking about, "Well, what do we do from our cloud infrastructure and platform security perspective? What do we do in AWS, Azure, and GCP?" While, certainly, we know that every organization has dozens, hundreds, of different SaaS services that they're using, a lot of security teams I see are really ... Their mind share is focused on other areas of the cloud. I think that in terms of the solutions that are available, we're still at that point where the market has to reach that slope of enlightenment, I guess, to use the Gartner term.

Frank Kim:

I think, with that, usually follows on, "Hey, we've got cloud security engineers, and architects, and so on, for traditional infrastructure and platform cloud." Yeah. It's very specialized. It's very niche. I think what I mentioned earlier, in terms of SaaS is an area where you need even more partnership with the business to understand what that permission model should be. Who has access? What's the data, and so on? So, I could definitely see more happening there from an overall process and a skillset perspective.

Sounil Yu:

I think the answer is going to be tied to how general purpose that SaaS application might be, versus how niche or how focused that particular SaaS application might be. So, if it's a very niche SaaS application, then I don't think you need a niche person. Rather, I would expect to actually have some technology that will satisfy my needs to secure a niche SaaS application. What I mean by that is a SaaS application that has a very specific focus and purpose. There isn't an opportunity for people to build additional applications on top of it. So, the more general purpose SaaS applications like Salesforce, like ServiceNow. You can even think of the infrastructure service, AWS and whatnot, as more general purpose.

Sounil Yu:

In those situations, I do think you need a dedicated person that can handle some of those environments, because those are ever-changing. Because of the ever-changing nature of them, I can see why it takes a startup that's trying to do Salesforce security two years to just understand it. By which time, things have changed because Salesforce has introduced new features, or AWS has introduced 20 new services. Right? So, it's an interesting reversal, if you will. If it's a general purpose SaaS application, then you need niche skills for that general purpose application. If it's a niche SaaS application, I think you can use either a general purpose person or, ideally, a technology that knows how to configure that environment quickly and easily so that you can move on and not have to worry about has it been secured properly?

Lior Yaari:

So, if I'm understanding correctly, what you're saying is that there's no need for a pair app engineer, unless the application is used widely enough within the organization, and it's ever-changing to have a dedicated person responsible for it? But I wonder, is it a good decision for an organization to appoint a SaaS security specialist, someone who's responsible with engineering challenges and the ongoing challenges of just managing SaaS in general within the company?

Sounil Yu:

Yeah. Actually, let me add one of additional piece then, as far as those niche SaaS applications. Where I would want a SaaS engineer, a SaaS security engineer, is when it comes to the integrations among those niche applications. Those integrations are where you have lots of non-deterministic outcomes that you actually do need a person to figure out, and manage, and triage, and address. So, the integrations among different SaaS applications, then is that general purpose view that requires a person, a dedicated person, to handle. Are there any security issues when I hook up [Zapier 00:26:01] with ServiceNow, with Slack? Okay? That's where it starts getting hairy because now you have all these different combinations that most technology companies, or most startups, or service providers, won't necessarily be able to anticipate.

Lior Yaari:

Yeah. Frank, do you have any comment about this?

Frank Kim:

No. I think that's pretty well covered. It makes sense from a complexity and trade-off perspective. Of course, as things get more complex, certainly, you need to specialize in it a little bit more. So, yeah. It makes sense.

Lior Yaari:

Mm-hmm (affirmative). So, an interesting topic I'd love to cover is the now-emerging concept of BYOA, bring your own application. The same ways companies moved from issuing corporate devices to BYOD, bring your own devices, there's this general thought today of allowing users to use the applications they need to use to do their job best. This is, of course, contrary to how companies have, today, a list of approved applications. I wonder, thinking about that, what do you pick, and how the choice changed across different companies, and why? How can a company decide they want to have a loose SaaS policy, allowing users to use what they want, what they need to do in order to approve such a policy, and what types of companies choose to keep the strict list of approved applications instead?

Frank Kim:

It strikes me that it really depends on the data, the importance of that data and the crown jewels. What are the crown jewels for an organization? I don't think I've seen, and I don't expect, any organization to say, "Hey, sales team, sure, you can use your own way to do customer relationship management. Forget about Salesforce." Right? There are benefits to the organization having that all centralized. On the other extreme end of the spectrum, depending on the job role, there's lots of SaaS. There's a SaaS app for everything. So, if you're using Canva to make some graphics, I could see why, "Hey, sure. If somebody wants to use that, hey, let them go ahead and use it, because it makes them more productive."

Frank Kim:

This is where I would be thinking, from a security perspective, what are the top five, top 10, most impactful and most widely-used SaaS apps that have the biggest impact? Think about those as a category in terms of those workflows, versus that long tail of just general purpose productivity apps that might be useful in one-off cases.

Lior Yaari:

I had a conversation with a CSO a few weeks ago, which was [Bradley Bosch 00:28:47], who told me, "When you hire a plumber, you expect them to bring their toolbox. Why didn't you expect the same from a data analyst or a data engineer?" I like that quote because it is true. It's true for salespeople that work together, that collaborate together. It makes sense for them to use the same platform. But for many of the dedicated professionals that we hire, they have a wide variety of applications that they can use to do the job efficiently. If we could allow it, the organization might benefit. It could move faster. It could get better outputs and better results. Sounil, I saw you thinking. I wonder what you think.

Sounil Yu:

Yeah. I was trying to think if that was the right analogy, with the plumber. Let me answer the original question, and then I'll come back to the analogy, and why it doesn't fit right for me. Anyway. I think it ultimately comes down to one's risk tolerance. The risk tolerance is also tied to how fast you want the organization to grow. So, if you have a relatively static environment, slow growth, very large enterprise, organizations that I used to work with, work for, they're going to be a lot more risk-adverse. As a result, we will move slower, and we will have time, actually, to make a decision as to whether this application is something that we want to use, or not. Things just move slower. Procurement runs slower. We have an opportunity to do a thorough review, and as a result, we can pre-approve apps ahead of time.

Sounil Yu:

Unfortunately, that just won't work for other organizations that are more risk-taking. For those risk-taking organizations, we want them ... It's a matter of business competitiveness for them to be able to find the best tools to help them do the job as quickly and efficiently as possible. Now, let's consider, going back to the plumbing example, maybe, why is that not ... Sure, they bring their own tools, but they're not going to bring the latest, newest tool that you might imagine. I think that's partly because, one, plumbing itself, or that industry, is highly regulated. You've got to have a license. You've got to have ... There's really not much innovation there. If there is to be innovation there, if there's some new widget or new gadget that someone can use to fix your plumbing problems faster, I would imagine that company, or that service, would actually be more innovative, or willing to take risks, or willing to try new things.

Sounil Yu:

Now, would I want them to try that on my house? Probably not. But if they said, "Hey, we can do this for much cheaper, and must faster, than Joe Plumber over here," okay, maybe I'm willing to take that risk because I'll get a better price and faster service, because they're using the latest app or the latest tool to fix that problem that I had. Again, like I said, I think it comes down to one's own risk tolerance. When you look at different companies, whether it's at a startup or a big, large organization, you're going to have different risk tolerance, and thus, different choices on what you pre-approve or what you allow.

Frank Kim:

When you mentioned that plumbing analogy, it made me think about, immediately, a chef. A professional chef always travels with their own knives. But how much do those knives impact other chefs or other workers in the kitchen? Not at all. It's just about making that chef more effective with the tools that they want to use. So, I think that there's that risk tolerance, but there's that productivity spectrum, as well, in terms of why should we prevent the installation of VS Code, if that's what somebody wants to use? There are organizations that I've worked at that will prevent you from installing anything. Right? But there's no impact. There's no larger impact to the organization, like with using something other than Salesforce, for example. I think from that productivity, risk spectrum is where that question really, really lies.

Lior Yaari:

One comparison I thought about over the weekend is how SaaS applications, and allowing or disallowing the use of them, is similar to how companies in the past prevented users from installing software on the laptops, back in the days before everything was in the cloud. What I thought about it is that the risk back then wasn't data moving outside of the company, it was users being able to install malware on their machine because they accidentally downloaded the wrong file. I think that with SaaS, the threat is different, because I don't think the threats we look at, or the risks we are afraid to take, other users would use a malicious SaaS application. Even though possible, it's not the main risk. The main risk is them extracting data to a location we are not aware of, one, and that could be breached by a third party. I wonder if you agree with this statement, because if that's the case, it might make sense to disallow installation of software, even though we want it, and do allow users to use applications that they need to use in order to do their job.

Sounil Yu:

Right. I'm sorry. Are you saying should we prefer SaaS applications over thick clients, or what?

Lior Yaari:

I think the risk model is different. So, the reasons we disapprove those are different from the reasons we disapprove SaaS. Maybe that should change our approach to why we could approve SaaS, because we're not afraid the users would use a malicious one.

Sounil Yu:

Sure. Going back to the risk tolerance question, if I can install a thick client that helps ensure that the data stays within my environment, then I may actually choose to do that. But the reality is, most thick clients today beacon out to, and send all the data, out anyway. So, there's almost no practical difference. I mean, if you're using Slack, the desktop client versus the web client, you're still ... It doesn't matter. Right? You're still using it. You're still sending out data. But if there's a way to contain that data, is it work the trade-off to have a thick client that may also be malware? I guess at that point, then that's where some of the vendor assessments might come in handy. I may choose not to do business with a Russian entity versus a US one, because in theory, one might be safer than the other.

Frank Kim:

Lior, are you saying that, "Hey, we're talking about what is the risk in either scenario?" If we break down risk, we know it's likelihood and impact, and we can further break down likelihood into vulnerability, what vulnerabilities, what weaknesses, mis-configurations, and so on, do we have in our environment, and the threat. What is the threat actor? What are the techniques and tactics that they're actually using? So, you're saying that if something is in the SaaS provider, well, then what is the threat? What's the technique that the attacker is going to use? Well, they've got to, maybe, compromise the cloud provider, compromise that application, or steal some credentials to get access as the user, versus on the endpoint, you're saying, "Okay, well, hey, the threat actor is still trying to get in with a different technique, but that vulnerability is different?" That's what you're getting at?

Lior Yaari:

Exactly. It is.

Sounil Yu:

Sorry. If that was the difference, if that's the dichotomy, I would strongly suggest people move to the SaaS-provided service, and whether it's their most recent [Jira 00:37:08] issue, with Confluence being compromise-able, if you had your own on-premise instance, or Exchange earlier in the year, I mean, if you're running an on-premise instance of some software that you could actually get at a SaaS service, unless you have a dedicated person that's going to be constantly attending to the security needs of Jira or Exchange, you're much better off outsourcing that to somebody else, like Microsoft and [Atlassian 00:37:42].

Frank Kim:

Exactly. That person can't do it as well, comprehensively, as effectively, and they don't have the incentive to do it as well as a Microsoft or an Atlassian.

Sounil Yu:

That's right.

Lior Yaari:

So, moving on to one of our last questions, I wonder, if looking back in hindsight, did you make any mistakes in how you designed your SaaS security program? What would you advise to the past you to do instead? Frank, maybe you can start.

Frank Kim:

Well, I guess one big mistake is that we didn't have a SaaS security program.

Lior Yaari:

That is a mistake.

Frank Kim:

We were constantly in firefighting mode when it came to SaaS applications. Things would come up. "We're using this." Now, eventually, over time, that got more mature. Certainly, the main ones, Salesforce, Slack, whatever, whatever else we were using, we got a better handle on that and helped put together some best practices, review, assessment, and so on. But that happened, to be honest, organically or by accident. We didn't think about it proactively. So, I would say the advice would be get a handle on what's the SaaS in your organization? What percent is used by what different areas? Better understand not just that long tail of visibility, but what's actually used the most, and where does that important data lie?

Lior Yaari:

Get a Grip on your SaaS, is the advice I give, as well.

Sounil Yu:

I don't know what mistakes we've made, only because if we've made a mistake, it hasn't cropped up to haunt us yet. But if there is a ... It's not really a mistake as much as it was a question of timing. I mentioned this notion of risk-adverse, risk-taking. In the life of a startup, you'll, of course, be risk taking. Right? That's the whole point of a startup to begin with. When it comes to SaaS security, having a lot of tight controls over SaaS security, it may be a hindrance to the growth of a startup. At some point, we actually changed our posture to say, as I hinted at earlier, "We're going to preapprove SaaS applications before you're allowed to log into them." It's definitely a nontrivial hurdle, but it was a decision that we made once we reached a certain number, a certain size of our organization, or a certain number of SaaS applications, where we felt like, "You know what? Okay. We need to start locking this down. We're starting to see some really weird SaaS applications that seem sketchy."

Sounil Yu:

There's something that will trigger your organization to say, "Okay. Let's start locking this down." The timing of that is really what, I would say, needs to be considered. Should it happen at the very beginning? I would argue no, because that, again, slows down the life of the startup, and that's something that's going to be really hard to swallow. But what's the right timing to switch from one that's just a free-for-all to one where it becomes more controlled? That is something that, I think, everyone will have to figure out for their own organization. We made that switch about a year into the life of the organization, and it was a painful switch, but one that we're now comfortable with. It's at a steady state. Earlier on, we would see these interesting jumps in SaaS application usage as we brought on different teams. Right?

Sounil Yu:

The sales team comes on. All these new SaaS applications. Marketing team comes on? Another bunch of SaaS applications. But over time, that starts to dwindle. When it starts to dwindle is when, I think, it might be worthwhile to say, "Okay. I think we have a good sense of what SaaS applications we use. Let's start tightening the ship down a little bit and be a bit more proactive in approving SaaS applications as they come in, because the volume is much lower," and so on, so forth. Again, that timing is something that each organization will need to think through and decide on their own.

Lior Yaari:

I can strongly relate to the example you gave about each function in the organization bringing in their own group of applications. One of the features within our platform is the ability to see a graph of how SaaS grew within the company, and every time we opened a new function, being engineering, design, marketing, you just see an immediate jump in the number of applications that we used. Those, of course, stack up on top of each other as the organization gets bigger and bigger, with different business units using their own things. So, I'd love to move to the last question, which is, if you had one tip, and a short one, for CSOs and security leaders who want to secure their SaaS applications, what would it be? Sounil, maybe you can start.

Sounil Yu:

I don't know. Get a Grip. I think it's ultimately use SSO. Try to make sure that you get everyone to use SSO. That is the one thing I would strongly advise.

Lior Yaari:

Frank?

Frank Kim:

I'll try to keep this quick. I would say, figure out how to say yes. Figure out how to say yes from a security perspective. If I think back, step back and treat ... You've got all of your different security tools. Maybe treat your security program like a portfolio of investments. Maybe you've got some small percentage in "riskier" bets, and that would be making a small investment of not a big bang deployment, but find a tool that you think will meet your need and test it out, and play with it, and see if it helps address, and help you get to saying yes.

Lior Yaari:

Yeah. So, thank you very much. I want to thank everyone who joined so far. I want to thank, again, Sounil and Frank for taking the time to speak about this important topic. My name, again, was Lior Yaari. I'm the CEO at Grip Security. We help companies discover our SaaS application, and then build access management and data governance capabilities to all of the different applications at an identified scale. If you're interested in learning more, you can go on our website, grip.security, or you can directly message me on LinkedIn. Thank you, everyone, for joining. We'll see you next time.

Frank Kim:

Thanks a lot.

Lior Yaari:

Yeah.

See More
See more
You might also like
Resources
April 16, 2021

Download our product overview

Download
Read more

for our latest updates and feature releases

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.