Modern SaaS Risks - CISO Deep Dive to Gaps in SaaS Security

Jan 26, 2022

Jan 26, 2022

What are the main risks associated with SaaS applications within your organization? What parameters should organizations consider when contemplating adopting SaaS applications?

Tim Fitzgerald
CISO & SVP at Arm
Link to Linkedin
Alex Manea
CISO at Georgian
Link to Linkedin
Lior Yaari
CEO at Grip
Link to Linkedin
Modern SaaS Risks - CISO Deep Dive to Gaps in SaaS Security
This webinar will cover:

What are the main risks associated with SaaS applications within your organization? What parameters should organizations consider when contemplating adopting SaaS applications?

Join our Co-Founder & CEO Lior Yaari, Alex Manea (CISO, Georgian), and Tim Fitzgerald (CISO & SVP, Arm) to gain answers to these pressing questions and more in our latest discussion on actual modern SAAS risks and security best practices for large enterprises.

Fill out the form and watch webinar
In this webinar:

Lior Yaari:

Hello everyone and thank you for joining our webinar, modern SaaS Risks, CISO deep dive to the gaps in SaaS security. We're pleased to have today, Alex Manea, CISO at Georgian and Tim Fitzgerald, CISO at Arm, who's joining us. So Alex and Tim, thank you for joining today.

Alex Manea:

Thanks a lot for having us.

Tim Fitzgerald:

Thank you.

Lior Yaari:

Yeah. My name's Lior Yaari, I'm the CEO at Grip Security. We are a SaaS security startup and we help companies see and secure those SaaS applications. I'd love to start with a general question about SaaS challenges and today we'll dive into the variety of challenges that you're facing with your SaaS applications and how you see the world. But maybe just to start, what do you see as the main risks of SaaS being used within your organization? Alex, maybe you can start.

Alex Manea:

Sure. Yeah. I mean, I think if we take a step back and look at SaaS across different organizations, we're an investment firm and we invest in about 40 to 45 different B2B SaaS companies ourselves. Most of which obviously use SaaS apps. And the biggest risk really is just the number of SaaS apps. It's death by a 1000 cuts or death by a 1000 apps is the case may be. The reality is every single one of these SaaS apps might be fairly secure and might cause a relatively minimal amount of risk, but when you start looking at dozens or even hundreds of apps across the environment, you start getting a very different type of risk profile.

Alex Manea:

And obviously, when we talk about the risks, you look at things like data loss, like privacy breaches, but I think another key component of SaaS for us and one that maybe is not as well understood as it could be is the roles and responsibilities around securing these apps. Because in theory, with these SaaS apps, because they are SaaS, they should be secured by the vendors themselves, but it really depends from vendor to vendor.

Alex Manea:

And in some cases, the vendors really offload some of that security responsibility onto the customer. Or they'll say, "We'll give you the tools to be able to secure it, but you need to configure it yourself." And as a customer, if you don't really understand that or maybe you don't understand how configure those SaaS apps properly, you can also leave yourself open to vulnerabilities. So, there's obviously a lot of different potential types of risk with SaaS apps, but again, the biggest one I would highlight is that death by a 1000 cuts.

Lior Yaari:

I wrote it down, it's an amazing description. Death by a 1000 apps. Tim, what do you think?

Tim Fitzgerald:

Yeah, I think for us, I mean, Arm is a... We are a very engineering heavy company. A lot of what we do in terms of creating our product is extremely specialized. And fortunately for us that means the best place for us to live is in our very specialized on-prem environment. But, for anything that falls outside of that engineering environment, we have a culture that is very much... Says, "If you need a tool, go get it. You're a really smart engineer and we trust you and we trust you to do good evaluations, but if you need a tool, go get it."

Tim Fitzgerald:

We end up with an incredible amount of sprawl. I'm not sure I'd exactly call it death by a 1000 cuts because I'm not sure actually perhaps how many cuts we might have, which is actually probably the bigger problem. We have a pretty stable set of SaaS solutions that we use for a lot of corporate and back office and even just good functionality solutions that I actually feel very comfortable with, perhaps even more comfortable than my own prem environment and how well protected it is.

Tim Fitzgerald:

But the potential for sprawl and the onesie, twosie SaaS-based applications and relying on personal judgment of individuals, which is a control, but maybe not a great one, means that, we at any given time, we don't always know where all of our data is. Never mind controlling those SaaS and thinking about how to configure, which I think is a really great point that Alex put out there is there's a lot of knowledge required here to figure out how to do this properly. We spend a lot of time chasing our tail, trying to knock down the SaaS that we think are potentially risky.

Tim Fitzgerald:

We end up in a position where we have a very manual process by which we try and identify the smaller SaaS apps that people use that might cause us risk which is a very imperfect process. So, I think that the risk for us is not necessarily in our estate that we know and understand, although that risk definitely exists, it's really in the sprawl that exists that goes beyond our site line, or that that is ever-changing. Even if we have a handle on it one day, literally the next day, there's 15 more apps there that weren't there the day before.

Lior Yaari:

Yeah. I strongly agree with you both and thank you for sharing. In Grip, we view SaaS discovery as one of the main polar clients of the company. And we always do find enough surprises to be impressive because we can just assume SaaS is out. The marketing team is often complained upon, but every time I meet with my marketing team, I learn of a new app that they're using. And that's every time, every week for nine months in a row.

Lior Yaari:

So, this proliferation of applications becomes really challenging. And last Halloween, we did a campaign called zombie accounts. On casual days, we call them dormant account accounts, but those are just the users who left the company and still have access and accounts in many of the applications, mostly those that weren't known to IT and security. And it leads me to my next question, which is how do you deal with the offboarding of users from all of the different SaaS applications that they use, especially when they leave, but also when they just change overall?

Alex Manea:

Yeah. It's definitely a tough problem to solve. The way that we've implemented it internally within our environment is through single sign on. So we have a single sign on provider that we've deployed across all of our core SaaS applications. Now back to Tim's point, there's a huge long tail of other SaaS apps that are not necessarily directly integrated with our core SSO platform. For those, we have a couple of tools there.

Alex Manea:

So one is we actually use a password manager and internally, we have a policy that says that if you sign up for a SaaS app, you have to use that password manager in order to protect your passwords and generate strong passwords. And the nice thing about having that is it also gives us some visibility around what SaaS apps people are deploying. And it also gives us some control around offboarding people.

Alex Manea:

Now that is unfortunately a very manual process, but we do try our best in terms of managing that. But again, back to Tim's point, the real challenge is that long tail of folks from different teams just signing up for random SaaS apps that we might not even be fully aware of.

Tim Fitzgerald:

Yeah. I mean, my answer would be almost identical. We, I think quite successfully, use a single sign on process to control the vast majority of our SaaS applications. And it actually is a really nice user experience for our employees, right? They don't have multiple passwords to manage, everything links through. And, I know this is not the question you asked, but making our SaaS, the easiest SaaS to use is actually a big part of our strategy, right? To not give people incentive to go outside of the ecosystem that we provide.

Tim Fitzgerald:

But the big caveat there is that when we look at offboarding specifically for those services that we either don't control or are not aware of, it is a very haphazard process. We rely a lot on personal responsibility of people leaving the company. We help them along the way by helping service to them what we think they're using and ask them to take steps to make sure that they're not putting Arm at risk. And by and large, as a company, we choose to trust our employees including those that are leaving to provide appropriate do care.

Tim Fitzgerald:

And I think that actually has been fairly successful for us, but it is a fallible system for sure. And I think, when I think about my SaaS risk, I actually don't spend a lot of time thinking about my cornerstone platforms and the risk associated with those. I spend more time thinking about the sprawl that we talked about earlier.

Tim Fitzgerald:

And then, I guess tangentially to that what happens when somebody leaves and that data or those accounts are orphaned, which is often the ones that come back to bite us later on with something that looks like an innocuous data breach from a SaaS vendor and next thing we've got data there and account there that we didn't know existed. So, it is a really significant problem for us and one that I would say, while we have processes around this to make ourselves feel more comfortable, we definitely do not have a full handle on that.

Alex Manea:

And Tim, I love the point you made there just around making it as easy as possible for users to use the core platform, the SSO platform. I think that's just absolutely so critical in cybersecurity and something that I see a lot of CISOs stumble on, is they get into the mindset of my job is to lock everything down, not necessarily being a business enabler. And making the path of least resistance the most secure one, I think is ultimately what's going to lead to long term success. And I'm really glad to hear that's how you guys are approaching it at Arm.

Tim Fitzgerald:

Yeah. I mean, I like to joke that it started as a bit of a fatalistic attitude, as in we can't win this fight. There's too many SaaS out there. There's too many opportunities for people to go and get these services and we're not the type of company that would consider locking down our workstations. And we don't have to, we're not a bank, we're not covered under various regulatory statues and standards.

Tim Fitzgerald:

So, it actually is the greatest weapon we have, which is we trust you and we're going to make this as easy as possible for you to use services that gets you what you need to do the vast majority of your job. And actually, the one area where I'll say we're quite rigid is when somebody goes out and gets a SaaS that uses common functionality that exists in one of our existing platforms, we have a pretty heavy handed steer back to our cornerstone platforms. But, quite often actually people are using SaaS platforms and applications that are very niche and they serve a purpose for that person in a way, for a service that we don't offer.

Tim Fitzgerald:

So, it is both an opportunity for us to identify services we might consider offering, which I think is another aspect of this, is that you have to have your eyes wide open that says, "If people are going to go use these services, there's a reason you should go and have a look and make sure that that's not something that should be provided at a corporate level." But at the end of the day, the vast majority of our workforce, I would say probably upwards of 90% of the workload that they do, absolutely fits squarely within our cornerstone applications.

Tim Fitzgerald:

Redirecting them there, making sure that they're knowledgeable about what we have, making it a seamless experience so they don't have incentive to go somewhere else, all of these things are actually super important to control the sprawl.

Lior Yaari:

Yeah. I definitely agree. Because, for users today adopting a new application, it's just one click away. They just have a sign up form as a barrier and if they want to they can get it. They can even expense it from the corporate credit card, and just keeping them on track and having... If you try to block them, they'll just find other ways to use it.

Tim Fitzgerald:

I will say Lior we have blocked people's ability to buy software through corporate cards because we ran into some problems with that a few years ago. But that only solves half the problem, right? Half of this software is free or at least free for first use and early use. So it's corporate credit card not required. I think it's actually, those ones caused me a little bit more concern, at least when they charge it through their corporate credit card, I know it exists.

Lior Yaari:

Yeah, definitely. So, we talked about evaluating which applications could introduce the risks to the company. And I wonder, when you do a risk assessment for new application that comes in, someone wants to use an application, what are the parameters you or enterprise should look for in order to decide whether the application should be approved or not?

Alex Manea:

Short answer is all of them. I mean, and I know that sounds quirky, but it's the reality of security. It's, you have to treat your SaaS apps the same way that you treat internal security. You can't have any gaps and you have to take a very holistic approach. And I think that the challenge here is there's so many parameters to evaluate and there's so many apps to evaluate these parameters on. So it's really a scaling issue and a data issue. I mean, you need to look at the apps data security, you need to look at governance, you need to look at their identity management, their logging, their supply chain, their threat management, their endpoint management.

Alex Manea:

You really do need to take a holistic approach. I'll share the way we do it internally is we have a standard questionnaire that we use called the CSA CAIQ. It is fairly comprehensive and it is fairly holistic, but it is a little bit heavyweight, and I think that's one of the challenges. One of the other things I'll share, if I have to really focus on one or two parameters, one of the things that we have done, back to Tim's point around SSO and having that core infrastructure, is for any new SaaS apps that we deploy across the organization, they have to support SSO and they have to support MFA. That's a nonstarter for us. If they don't support MFA in 2021, they should support that. And if they don't, then we don't deploy it.

Lior Yaari:

Yeah. And that's MFA, is it natively within the application or through SSO?

Alex Manea:

It's through our SSO integration. So we have an MFA provider that we use as well through SSO, but essentially the app would have to support that.

Tim Fitzgerald:

Yeah. And actually, I don't have a ton to add to what Alex said. I mean, yes, you have to evaluate all the same parameters you would evaluate internally. And I think we're willing to accept various attestations and standards in lieu, right? And I think, we want to help many of these younger companies or newer companies achieve the level of security that they want. So we often find ourselves in a bit of an advisory or a coaching position to help bring them up to the level that they need to be at in order to have an opportunity to work with a company like Arm.

Tim Fitzgerald:

But the one thing I'll say that I always ask my team to overlay on top of the security review is a couple of considerations. One, is reputation, right? So how big are they? How long have they been around? Do they have something they can stand on that gives us confidence that they're a reputable company and that they'll stand behind what they said? And the second is we try and make an assessment of what their financial incentive is as a company. So if you're sales force, you have a massive financial incentive to keep data secure, because it's a huge part of the value proposition you provide and you can undermine all of the other services you create.

Tim Fitzgerald:

If you are a small startup and you're trying to land a big company like Arm as a client and you might be willing to say all kinds of things. And I'm not suggesting people are inherently dishonest, but you might be willing to say you have all kinds of things in place, or you'll meet all kinds of commitments and a little bit willing to roll the dice that nothing will happen during that window while you build it in the background.

Tim Fitzgerald:

And I think we are always super concerned with how much financial incentive a company has to secure data as a means of measuring how likely they are to do it well. That is an imperfect measure because we know there's plenty of companies that have financial incentive that don't do it well, but at least we want to know that they have that financial incentive. So, in some ways that disqualifies a lot of pretty young companies, relatively new companies because, if they had a major event at scale with our data, we might put them out of business with litigation. And that is not a great place to be for either company.

Tim Fitzgerald:

So I think it's making sure that they have the right security parameters in place, they need to be able to talk about it credibly, they need to be able to show some proof. It's not enough to just be able to say what policies you have in place, but all over and above all of that, we need to make sure that their business goals and the risk tolerance they might have in a company approximately matches our own.

Lior Yaari:

Yeah. Please go, Alex.

Alex Manea:

I was just going to say one last parameter I would highlight there to add to Tim's point is just around the internal use cases. I think it's really important for us as security leaders to understand that business use case and to understand what are users actually going to be doing with the app and what sort of data does the app need access to? And the way we do it internally is we have different tiers of apps depending on what the internal use case is, whether they're being deployed across the organization, whether they need access to internal confidential data, whether they need access to our finance or HR systems.

Alex Manea:

And depending on that, we'll actually have different thresholds in terms of the ways that we evaluate the app. So I think that's another key point is just understanding that business context and not evaluating it in the vacuum.

Lior Yaari:

Yeah. I want to say too that I can strongly relate to what you said from the other side as a vendor. So, we recently completed a nearly perfect penetration test and we're almost finished with our SOC two evaluation. And since doing both of those, it became much easier for us to start working with new clients for the company, because if back then we needed to fill out long forms and to go through this evaluation conversation again and again. Now that we have proof to show, that also supports all of the efforts we've invested in security, but the process itself became easier.

Lior Yaari:

And I think a lot of companies look for that when evaluating us as a vendor. What I also wonder just... And Alex said that you need to determine what is the use case for the app, because many of those applications are used by a single digit number of employees and even when storing sensitive data, I wonder if it's always worth the effort of sending him through a complex vendor assessment process to do so.

Alex Manea:

No, absolutely not. No, there's definitely situations where I mean, I'll use a specific internal example that came up recently, which is an online survey tool, or I believe it was an online quiz game tool that we could use internally for team meetings and things like that. And the team actually reached out to us and said, "Hey, do we need to do a security assessment on this?" And I said, "It's not really collecting any, any confidential internal data. This is just for team building exercises. So it's not worth the effort for us to go through that complex process."

Alex Manea:

So you definitely don't need to evaluate all the apps, but you do need to be very careful because oftentimes these apps will start off as having use cases that don't need access to internal data and next thing, this quiz game tool actually now we're doing quizzes about confidential information about our company. So you also need to be very careful about those shifting use cases.

Tim Fitzgerald:

Yeah. I mean, that is a tremendous point, Alex, because it's almost always starts with a simple use case, that makes us not pay attention. And actually we see that even with some of our bigger providers, it's not just the niche use cases. We start using it for one thing and next thing you know we've got a completely different use case and that we've massively expanded our services with that SaaS provider in a way that we don't understand.

Tim Fitzgerald:

I think that is a pretty common problem. A little bit easier to control with your cornerstone apps or the ones that you know well, but actually one that you have to pay attention to. I think what I liked about what Alex said is you quite literally cannot staff a security team large enough to evaluate all these SaaS vendors and take them through all the questionnaires. Nobody would choose to afford that, and so you have to decide which ones are worth the effort.

Tim Fitzgerald:

And I think there's a lot of judgment to be applied there and it's not always going to come to the CISO for an opinion either, so I think it's I think you have to enable your teams to be able to make good calls on when we really need to get involved or when we can just let people do what they need to do and not spend too much time on it. And there's some risk there for sure. But you got to pick your battles in this arena, I think.

Lior Yaari:

One of the main things we were thinking about recently, now that internally, within Grip we're building a risk platform. So how do we determine... We show applications that we find how we present the risk associated with this application to the organization. And one of the main thoughts is that often when doing those risk evaluations of vendors, the point in time when the application is approved is before the company knows what number of users use it? How do they use it? Because this use case could change.

Lior Yaari:

You approve, Monday for your marketing team. And a year later, the sales team decides to adopt it as bot. And now you have a completely new application with different data in it. And we think of how we can use our different perspective, continuous visibility into SaaS to change this risk over time, but I wonder if it's something you think about when doing the evaluation process itself or do you renew the evaluation process every year or month or-

Alex Manea:

Yeah. So for us, every time we renew the app we look at, do we need to do another evaluation? And in most cases, the answer is going to be, no, because the way we're using Zoom this year is no different than the way we used it last year. But to your point Lior, in situations where our internal use cases change, yes, we definitely do another thorough security review. The other thing I'll highlight as well is we're starting to see more and more third party tools around risk management, around SaaS security, things like that, starting to pop up. And those are things that we're actually starting to leverage, especially for that long tail of apps where maybe we don't want to do a formal 300 question assessment, but we just want to get a sense of the vendor's overall reputation.

Alex Manea:

We want to get a sense of what are the public facing vulnerabilities that this vendor has. We want to get a sense of what's the overall level of security of this SaaS app. I think there's a lot of great tools out there and we're definitely starting to look at leveraging those in order to scale ourselves.

Tim Fitzgerald:

Yeah. We're quite similar actually. I mean, we have an annual recertification process, especially for our medium and up vendors where we require them to not only reassert the security controls they have in place, but we require the business owners to revalidate the use case and make sure there's no mismatch. But essentially the same process on a slightly different frequency. And I think, but to be fair, I mean, there's actually quite a lot of overhead attached to that.

Tim Fitzgerald:

So it's a heavy lift from a manual process and we are starting to explore whether or not we can start to rely on some of the third party assessments of reputation and what would be the risk if we could get out of the middle of assessing individually what these companies' security postures look like and is there a credible service? I will say right now, I don't think we found a service that we feel really confident in yet that could replicate or replace what we're doing, but it's on our mind because there's a scale problem here.

Tim Fitzgerald:

And it's a scale problem that generally we're losing that fight from a scale perspective. One of the things my security team works really hard on is not to become impediment of doing business. And in some cases, this is one of the areas we are becoming an impediment because we literally can't keep pace with the number of vendors that the organization wants us to look at. So it's not that we end up rejecting a whole bunch of them or that we're super stringent and even it's that actually the volume is too high. And then at what point have we not done our due diligence and are we being irresponsible by allowing these things to happen in our environment?

Tim Fitzgerald:

So I think there's an opportunity in the market and I know that many organizations look at, but I haven't yet found the one service we can put our finger on and say, "We trust them, we'll swap out their opinion for our own," and feel comfortable that it would be okay.

Lior Yaari:

Thank you very much. I'm very interested in this discussion as you may see because we are thinking about it a lot and it's super interesting to hear your thoughts about it. I'm sure everyone listening would agree as well. I want to do a shift to another question as we near the end of the webinar. Every few months, I'm searching cloud engineer on LinkedIn and I'm seeing the number of results. And then I check for DevOps engineer, see the numbers of results. And I end with SaaS security engineer or SaaS security as a title and the numbers are growing they're not that big. But I wonder if you think that SaaS security would become a knowledge niche that would eventually require a dedicated person to handle, like cloud security or IM went through in the last 10 years.

Tim Fitzgerald:

Do you want me to have a crack and go first this time, Alex. I saw this question in advances and I was curious about it. Honestly, I don't know, actually, I don't know what the answer is here, because so much of what we do around SaaS security is fundamental security. Have we evaluated their control posture? Did we understand the risk that they present? Have we done appropriate authentication? Do we do monitoring on those services? A lot of this fits in the things we already do. And, where I could see more specialist roles starting to come in is in how we manage authentication ongoing for many services beyond single sign on.

Tim Fitzgerald:

How we start to look at how these systems interconnect, that doesn't necessarily require our network to be the linchpin. There's a lot of specialized knowledge there. But I'm not sure it adds up to a SaaS security professional designation or an individual that lives in that window. I think so much of this comes down to skills that already exist within security architects and within the identity and access management group. My hope would be that we don't have to add another specialist role actually, that we can repurpose existing skill sets to solve the problem.

Alex Manea:

Yeah. I'm with Tim on this one. I think to the extent possible, I'm a big fan of generalists when it comes to security. And I'm a big fan of people that can go across different domains and look at things holistically. Because I think if you overspecialize in a specific domain then you get into situations where you focus too much on the trees and you don't see the forest and you don't see the interconnections between things.

Alex Manea:

But to your point, Lior, I do think there are certain skill sets that are somewhat specialized. And I think those skill sets are going to continue growing. And I could see a situation a few years from now where especially in larger businesses, larger corporations, they might hire SaaS security specialists just to deal with the sheer volume of SaaS apps. It wouldn't necessarily make sense in an SMB type of context because you need those types of generalists, but in a company the size of Arm or the size of an Intel or a Microsoft, I could definitely see those types of companies having SaaS security specialists.

Tim Fitzgerald:

I will say, even a company, the size of Arm, which is a reasonably big company we have no plans to hire a SaaS specialist. This question intrigued me and so I've done some more research on this topic to figure out what a SaaS specialist might do. And I think it's possible that I roll the balls, but actually I would actually that all of my security professionals have the capacity to figure out how to handle SaaS because this is much a business process problem as it is a true security problem.

Tim Fitzgerald:

And I think, the point that Alex made is right on in that we could get somebody in who's really excellent at authentication and APIs and really thinks their way through how this SaaS integrates with the company who completely misses the point of whether or not they are secure enough themselves, whether or not they meet the business purpose, whether or not we've made the experience simple enough to use. All of these things come into play in a way that, I don't know, just doesn't seem to lend itself towards a specialist, in my opinion.

Lior Yaari:

Yeah. Cool. Interesting. Maybe getting at the end, just looking back in hindsight, did you make any mistakes in how you designed your SaaS security program or what would you advise to your past self to do?

Alex Manea:

I think one of the things that we've recently done is we've put into place more of a consistent process around deploying SaaS apps internally. And that hasn't always been the case. And I think that's often happens at a startup, where you have a new startup and everyone has full admin access to their machines and has the ability to start deploying whatever SaaS apps they want. And a lot of startups operate like that for the first few years and that's where you start getting that huge, huge, long tail of SaaS apps.

Alex Manea:

And I think if I could go back maybe four, five years, I would put into place a more rigorous process around deploying those apps to make sure that we don't have lots of SaaS apps that maybe are not completely necessary internally and making sure that we have the right security controls in place.

Tim Fitzgerald:

Yeah. I would say, I mean, somewhat jokingly, I would say almost the opposite of what Alex said, but actually with some context, because when I was in my younger career in earlier days on SaaS, we used to fight the tide is what I called it. We were constantly trying to control what people could use and be really clamped down on it. And it was just, I mean, not only was it a fight that we definitely lost, but it made my security team show up as the anti-productivity, anti-progress group.

Tim Fitzgerald:

I think actually what Alex said is correct. You need some really strong processes, but for the purpose of making this simpler and faster and enabling the business to move quicker. So they know the rules that they're working from, not having to try and guess whether or not any particular app or platform will be okay. And actually you can enable them to do a lot of the heavy lifting for your security team to help get these apps over the line if you educate and give a good playbook to work from.

Tim Fitzgerald:

So I think it's... I said somewhat jokingly, actually Alex is right on, of course you have to put some controls around this. And I think put those processes and controls as an enablement for people to get what they need as opposed to a blocker to make sure that they don't cause risk. It's a slight nuance, but I think it can be really beneficial to your security organization to be seen as partnering on this and not only being the backstop.

Alex Manea:

I think you're absolutely right, Tim. I think it goes back to the previous discussion around security as a business enabler. It's so critical for security to be seen as part of the business team and not as a show stopper or a blocker or, "We need to go to the security team and get the check mark for this app." That you can't have the business getting to that mindset because back to your previous point, Tim, if people really want to deploy a SaaS app behind your back, they will and you need to build that trust with your users.

Lior Yaari:

Yeah. I think what I understand is you need to find the balance between making sure you can understand what's being used and at least prevent things that are obviously dangerous, but let users still work with the velocity that they need. Because I know a frustration for many CISOs is just, they feel like they have to put road blocks or barriers on users, which in fact hinders innovation within the company. But there is an opportunity not to police anyone just to make sure they're doing it safely.

Lior Yaari:

So with that, I think we've reached the end of our webinar. Tim and Alex, I want to thank you again. This was wonderful. And I like how these conversations always drift to different directions that are unique each time, again and again. So thank you very much for being here.

Tim Fitzgerald:

Thank you.

Alex Manea:

Awesome.

Lior Yaari:

I really appreciate the time. To everyone who is listening, I hope you enjoyed the webinar. Again, my name's Lior Yaari, I'm the CEO of Grip Security with a SaaS security startup that sees and secures every SaaS application within the organization. And always feel free to reach out if you're interested in hearing more and see you next time.

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:

Hello everyone and thank you for joining our webinar, modern SaaS Risks, CISO deep dive to the gaps in SaaS security. We're pleased to have today, Alex Manea, CISO at Georgian and Tim Fitzgerald, CISO at Arm, who's joining us. So Alex and Tim, thank you for joining today.

Alex Manea:

Thanks a lot for having us.

Tim Fitzgerald:

Thank you.

Lior Yaari:

Yeah. My name's Lior Yaari, I'm the CEO at Grip Security. We are a SaaS security startup and we help companies see and secure those SaaS applications. I'd love to start with a general question about SaaS challenges and today we'll dive into the variety of challenges that you're facing with your SaaS applications and how you see the world. But maybe just to start, what do you see as the main risks of SaaS being used within your organization? Alex, maybe you can start.

Alex Manea:

Sure. Yeah. I mean, I think if we take a step back and look at SaaS across different organizations, we're an investment firm and we invest in about 40 to 45 different B2B SaaS companies ourselves. Most of which obviously use SaaS apps. And the biggest risk really is just the number of SaaS apps. It's death by a 1000 cuts or death by a 1000 apps is the case may be. The reality is every single one of these SaaS apps might be fairly secure and might cause a relatively minimal amount of risk, but when you start looking at dozens or even hundreds of apps across the environment, you start getting a very different type of risk profile.

Alex Manea:

And obviously, when we talk about the risks, you look at things like data loss, like privacy breaches, but I think another key component of SaaS for us and one that maybe is not as well understood as it could be is the roles and responsibilities around securing these apps. Because in theory, with these SaaS apps, because they are SaaS, they should be secured by the vendors themselves, but it really depends from vendor to vendor.

Alex Manea:

And in some cases, the vendors really offload some of that security responsibility onto the customer. Or they'll say, "We'll give you the tools to be able to secure it, but you need to configure it yourself." And as a customer, if you don't really understand that or maybe you don't understand how configure those SaaS apps properly, you can also leave yourself open to vulnerabilities. So, there's obviously a lot of different potential types of risk with SaaS apps, but again, the biggest one I would highlight is that death by a 1000 cuts.

Lior Yaari:

I wrote it down, it's an amazing description. Death by a 1000 apps. Tim, what do you think?

Tim Fitzgerald:

Yeah, I think for us, I mean, Arm is a... We are a very engineering heavy company. A lot of what we do in terms of creating our product is extremely specialized. And fortunately for us that means the best place for us to live is in our very specialized on-prem environment. But, for anything that falls outside of that engineering environment, we have a culture that is very much... Says, "If you need a tool, go get it. You're a really smart engineer and we trust you and we trust you to do good evaluations, but if you need a tool, go get it."

Tim Fitzgerald:

We end up with an incredible amount of sprawl. I'm not sure I'd exactly call it death by a 1000 cuts because I'm not sure actually perhaps how many cuts we might have, which is actually probably the bigger problem. We have a pretty stable set of SaaS solutions that we use for a lot of corporate and back office and even just good functionality solutions that I actually feel very comfortable with, perhaps even more comfortable than my own prem environment and how well protected it is.

Tim Fitzgerald:

But the potential for sprawl and the onesie, twosie SaaS-based applications and relying on personal judgment of individuals, which is a control, but maybe not a great one, means that, we at any given time, we don't always know where all of our data is. Never mind controlling those SaaS and thinking about how to configure, which I think is a really great point that Alex put out there is there's a lot of knowledge required here to figure out how to do this properly. We spend a lot of time chasing our tail, trying to knock down the SaaS that we think are potentially risky.

Tim Fitzgerald:

We end up in a position where we have a very manual process by which we try and identify the smaller SaaS apps that people use that might cause us risk which is a very imperfect process. So, I think that the risk for us is not necessarily in our estate that we know and understand, although that risk definitely exists, it's really in the sprawl that exists that goes beyond our site line, or that that is ever-changing. Even if we have a handle on it one day, literally the next day, there's 15 more apps there that weren't there the day before.

Lior Yaari:

Yeah. I strongly agree with you both and thank you for sharing. In Grip, we view SaaS discovery as one of the main polar clients of the company. And we always do find enough surprises to be impressive because we can just assume SaaS is out. The marketing team is often complained upon, but every time I meet with my marketing team, I learn of a new app that they're using. And that's every time, every week for nine months in a row.

Lior Yaari:

So, this proliferation of applications becomes really challenging. And last Halloween, we did a campaign called zombie accounts. On casual days, we call them dormant account accounts, but those are just the users who left the company and still have access and accounts in many of the applications, mostly those that weren't known to IT and security. And it leads me to my next question, which is how do you deal with the offboarding of users from all of the different SaaS applications that they use, especially when they leave, but also when they just change overall?

Alex Manea:

Yeah. It's definitely a tough problem to solve. The way that we've implemented it internally within our environment is through single sign on. So we have a single sign on provider that we've deployed across all of our core SaaS applications. Now back to Tim's point, there's a huge long tail of other SaaS apps that are not necessarily directly integrated with our core SSO platform. For those, we have a couple of tools there.

Alex Manea:

So one is we actually use a password manager and internally, we have a policy that says that if you sign up for a SaaS app, you have to use that password manager in order to protect your passwords and generate strong passwords. And the nice thing about having that is it also gives us some visibility around what SaaS apps people are deploying. And it also gives us some control around offboarding people.

Alex Manea:

Now that is unfortunately a very manual process, but we do try our best in terms of managing that. But again, back to Tim's point, the real challenge is that long tail of folks from different teams just signing up for random SaaS apps that we might not even be fully aware of.

Tim Fitzgerald:

Yeah. I mean, my answer would be almost identical. We, I think quite successfully, use a single sign on process to control the vast majority of our SaaS applications. And it actually is a really nice user experience for our employees, right? They don't have multiple passwords to manage, everything links through. And, I know this is not the question you asked, but making our SaaS, the easiest SaaS to use is actually a big part of our strategy, right? To not give people incentive to go outside of the ecosystem that we provide.

Tim Fitzgerald:

But the big caveat there is that when we look at offboarding specifically for those services that we either don't control or are not aware of, it is a very haphazard process. We rely a lot on personal responsibility of people leaving the company. We help them along the way by helping service to them what we think they're using and ask them to take steps to make sure that they're not putting Arm at risk. And by and large, as a company, we choose to trust our employees including those that are leaving to provide appropriate do care.

Tim Fitzgerald:

And I think that actually has been fairly successful for us, but it is a fallible system for sure. And I think, when I think about my SaaS risk, I actually don't spend a lot of time thinking about my cornerstone platforms and the risk associated with those. I spend more time thinking about the sprawl that we talked about earlier.

Tim Fitzgerald:

And then, I guess tangentially to that what happens when somebody leaves and that data or those accounts are orphaned, which is often the ones that come back to bite us later on with something that looks like an innocuous data breach from a SaaS vendor and next thing we've got data there and account there that we didn't know existed. So, it is a really significant problem for us and one that I would say, while we have processes around this to make ourselves feel more comfortable, we definitely do not have a full handle on that.

Alex Manea:

And Tim, I love the point you made there just around making it as easy as possible for users to use the core platform, the SSO platform. I think that's just absolutely so critical in cybersecurity and something that I see a lot of CISOs stumble on, is they get into the mindset of my job is to lock everything down, not necessarily being a business enabler. And making the path of least resistance the most secure one, I think is ultimately what's going to lead to long term success. And I'm really glad to hear that's how you guys are approaching it at Arm.

Tim Fitzgerald:

Yeah. I mean, I like to joke that it started as a bit of a fatalistic attitude, as in we can't win this fight. There's too many SaaS out there. There's too many opportunities for people to go and get these services and we're not the type of company that would consider locking down our workstations. And we don't have to, we're not a bank, we're not covered under various regulatory statues and standards.

Tim Fitzgerald:

So, it actually is the greatest weapon we have, which is we trust you and we're going to make this as easy as possible for you to use services that gets you what you need to do the vast majority of your job. And actually, the one area where I'll say we're quite rigid is when somebody goes out and gets a SaaS that uses common functionality that exists in one of our existing platforms, we have a pretty heavy handed steer back to our cornerstone platforms. But, quite often actually people are using SaaS platforms and applications that are very niche and they serve a purpose for that person in a way, for a service that we don't offer.

Tim Fitzgerald:

So, it is both an opportunity for us to identify services we might consider offering, which I think is another aspect of this, is that you have to have your eyes wide open that says, "If people are going to go use these services, there's a reason you should go and have a look and make sure that that's not something that should be provided at a corporate level." But at the end of the day, the vast majority of our workforce, I would say probably upwards of 90% of the workload that they do, absolutely fits squarely within our cornerstone applications.

Tim Fitzgerald:

Redirecting them there, making sure that they're knowledgeable about what we have, making it a seamless experience so they don't have incentive to go somewhere else, all of these things are actually super important to control the sprawl.

Lior Yaari:

Yeah. I definitely agree. Because, for users today adopting a new application, it's just one click away. They just have a sign up form as a barrier and if they want to they can get it. They can even expense it from the corporate credit card, and just keeping them on track and having... If you try to block them, they'll just find other ways to use it.

Tim Fitzgerald:

I will say Lior we have blocked people's ability to buy software through corporate cards because we ran into some problems with that a few years ago. But that only solves half the problem, right? Half of this software is free or at least free for first use and early use. So it's corporate credit card not required. I think it's actually, those ones caused me a little bit more concern, at least when they charge it through their corporate credit card, I know it exists.

Lior Yaari:

Yeah, definitely. So, we talked about evaluating which applications could introduce the risks to the company. And I wonder, when you do a risk assessment for new application that comes in, someone wants to use an application, what are the parameters you or enterprise should look for in order to decide whether the application should be approved or not?

Alex Manea:

Short answer is all of them. I mean, and I know that sounds quirky, but it's the reality of security. It's, you have to treat your SaaS apps the same way that you treat internal security. You can't have any gaps and you have to take a very holistic approach. And I think that the challenge here is there's so many parameters to evaluate and there's so many apps to evaluate these parameters on. So it's really a scaling issue and a data issue. I mean, you need to look at the apps data security, you need to look at governance, you need to look at their identity management, their logging, their supply chain, their threat management, their endpoint management.

Alex Manea:

You really do need to take a holistic approach. I'll share the way we do it internally is we have a standard questionnaire that we use called the CSA CAIQ. It is fairly comprehensive and it is fairly holistic, but it is a little bit heavyweight, and I think that's one of the challenges. One of the other things I'll share, if I have to really focus on one or two parameters, one of the things that we have done, back to Tim's point around SSO and having that core infrastructure, is for any new SaaS apps that we deploy across the organization, they have to support SSO and they have to support MFA. That's a nonstarter for us. If they don't support MFA in 2021, they should support that. And if they don't, then we don't deploy it.

Lior Yaari:

Yeah. And that's MFA, is it natively within the application or through SSO?

Alex Manea:

It's through our SSO integration. So we have an MFA provider that we use as well through SSO, but essentially the app would have to support that.

Tim Fitzgerald:

Yeah. And actually, I don't have a ton to add to what Alex said. I mean, yes, you have to evaluate all the same parameters you would evaluate internally. And I think we're willing to accept various attestations and standards in lieu, right? And I think, we want to help many of these younger companies or newer companies achieve the level of security that they want. So we often find ourselves in a bit of an advisory or a coaching position to help bring them up to the level that they need to be at in order to have an opportunity to work with a company like Arm.

Tim Fitzgerald:

But the one thing I'll say that I always ask my team to overlay on top of the security review is a couple of considerations. One, is reputation, right? So how big are they? How long have they been around? Do they have something they can stand on that gives us confidence that they're a reputable company and that they'll stand behind what they said? And the second is we try and make an assessment of what their financial incentive is as a company. So if you're sales force, you have a massive financial incentive to keep data secure, because it's a huge part of the value proposition you provide and you can undermine all of the other services you create.

Tim Fitzgerald:

If you are a small startup and you're trying to land a big company like Arm as a client and you might be willing to say all kinds of things. And I'm not suggesting people are inherently dishonest, but you might be willing to say you have all kinds of things in place, or you'll meet all kinds of commitments and a little bit willing to roll the dice that nothing will happen during that window while you build it in the background.

Tim Fitzgerald:

And I think we are always super concerned with how much financial incentive a company has to secure data as a means of measuring how likely they are to do it well. That is an imperfect measure because we know there's plenty of companies that have financial incentive that don't do it well, but at least we want to know that they have that financial incentive. So, in some ways that disqualifies a lot of pretty young companies, relatively new companies because, if they had a major event at scale with our data, we might put them out of business with litigation. And that is not a great place to be for either company.

Tim Fitzgerald:

So I think it's making sure that they have the right security parameters in place, they need to be able to talk about it credibly, they need to be able to show some proof. It's not enough to just be able to say what policies you have in place, but all over and above all of that, we need to make sure that their business goals and the risk tolerance they might have in a company approximately matches our own.

Lior Yaari:

Yeah. Please go, Alex.

Alex Manea:

I was just going to say one last parameter I would highlight there to add to Tim's point is just around the internal use cases. I think it's really important for us as security leaders to understand that business use case and to understand what are users actually going to be doing with the app and what sort of data does the app need access to? And the way we do it internally is we have different tiers of apps depending on what the internal use case is, whether they're being deployed across the organization, whether they need access to internal confidential data, whether they need access to our finance or HR systems.

Alex Manea:

And depending on that, we'll actually have different thresholds in terms of the ways that we evaluate the app. So I think that's another key point is just understanding that business context and not evaluating it in the vacuum.

Lior Yaari:

Yeah. I want to say too that I can strongly relate to what you said from the other side as a vendor. So, we recently completed a nearly perfect penetration test and we're almost finished with our SOC two evaluation. And since doing both of those, it became much easier for us to start working with new clients for the company, because if back then we needed to fill out long forms and to go through this evaluation conversation again and again. Now that we have proof to show, that also supports all of the efforts we've invested in security, but the process itself became easier.

Lior Yaari:

And I think a lot of companies look for that when evaluating us as a vendor. What I also wonder just... And Alex said that you need to determine what is the use case for the app, because many of those applications are used by a single digit number of employees and even when storing sensitive data, I wonder if it's always worth the effort of sending him through a complex vendor assessment process to do so.

Alex Manea:

No, absolutely not. No, there's definitely situations where I mean, I'll use a specific internal example that came up recently, which is an online survey tool, or I believe it was an online quiz game tool that we could use internally for team meetings and things like that. And the team actually reached out to us and said, "Hey, do we need to do a security assessment on this?" And I said, "It's not really collecting any, any confidential internal data. This is just for team building exercises. So it's not worth the effort for us to go through that complex process."

Alex Manea:

So you definitely don't need to evaluate all the apps, but you do need to be very careful because oftentimes these apps will start off as having use cases that don't need access to internal data and next thing, this quiz game tool actually now we're doing quizzes about confidential information about our company. So you also need to be very careful about those shifting use cases.

Tim Fitzgerald:

Yeah. I mean, that is a tremendous point, Alex, because it's almost always starts with a simple use case, that makes us not pay attention. And actually we see that even with some of our bigger providers, it's not just the niche use cases. We start using it for one thing and next thing you know we've got a completely different use case and that we've massively expanded our services with that SaaS provider in a way that we don't understand.

Tim Fitzgerald:

I think that is a pretty common problem. A little bit easier to control with your cornerstone apps or the ones that you know well, but actually one that you have to pay attention to. I think what I liked about what Alex said is you quite literally cannot staff a security team large enough to evaluate all these SaaS vendors and take them through all the questionnaires. Nobody would choose to afford that, and so you have to decide which ones are worth the effort.

Tim Fitzgerald:

And I think there's a lot of judgment to be applied there and it's not always going to come to the CISO for an opinion either, so I think it's I think you have to enable your teams to be able to make good calls on when we really need to get involved or when we can just let people do what they need to do and not spend too much time on it. And there's some risk there for sure. But you got to pick your battles in this arena, I think.

Lior Yaari:

One of the main things we were thinking about recently, now that internally, within Grip we're building a risk platform. So how do we determine... We show applications that we find how we present the risk associated with this application to the organization. And one of the main thoughts is that often when doing those risk evaluations of vendors, the point in time when the application is approved is before the company knows what number of users use it? How do they use it? Because this use case could change.

Lior Yaari:

You approve, Monday for your marketing team. And a year later, the sales team decides to adopt it as bot. And now you have a completely new application with different data in it. And we think of how we can use our different perspective, continuous visibility into SaaS to change this risk over time, but I wonder if it's something you think about when doing the evaluation process itself or do you renew the evaluation process every year or month or-

Alex Manea:

Yeah. So for us, every time we renew the app we look at, do we need to do another evaluation? And in most cases, the answer is going to be, no, because the way we're using Zoom this year is no different than the way we used it last year. But to your point Lior, in situations where our internal use cases change, yes, we definitely do another thorough security review. The other thing I'll highlight as well is we're starting to see more and more third party tools around risk management, around SaaS security, things like that, starting to pop up. And those are things that we're actually starting to leverage, especially for that long tail of apps where maybe we don't want to do a formal 300 question assessment, but we just want to get a sense of the vendor's overall reputation.

Alex Manea:

We want to get a sense of what are the public facing vulnerabilities that this vendor has. We want to get a sense of what's the overall level of security of this SaaS app. I think there's a lot of great tools out there and we're definitely starting to look at leveraging those in order to scale ourselves.

Tim Fitzgerald:

Yeah. We're quite similar actually. I mean, we have an annual recertification process, especially for our medium and up vendors where we require them to not only reassert the security controls they have in place, but we require the business owners to revalidate the use case and make sure there's no mismatch. But essentially the same process on a slightly different frequency. And I think, but to be fair, I mean, there's actually quite a lot of overhead attached to that.

Tim Fitzgerald:

So it's a heavy lift from a manual process and we are starting to explore whether or not we can start to rely on some of the third party assessments of reputation and what would be the risk if we could get out of the middle of assessing individually what these companies' security postures look like and is there a credible service? I will say right now, I don't think we found a service that we feel really confident in yet that could replicate or replace what we're doing, but it's on our mind because there's a scale problem here.

Tim Fitzgerald:

And it's a scale problem that generally we're losing that fight from a scale perspective. One of the things my security team works really hard on is not to become impediment of doing business. And in some cases, this is one of the areas we are becoming an impediment because we literally can't keep pace with the number of vendors that the organization wants us to look at. So it's not that we end up rejecting a whole bunch of them or that we're super stringent and even it's that actually the volume is too high. And then at what point have we not done our due diligence and are we being irresponsible by allowing these things to happen in our environment?

Tim Fitzgerald:

So I think there's an opportunity in the market and I know that many organizations look at, but I haven't yet found the one service we can put our finger on and say, "We trust them, we'll swap out their opinion for our own," and feel comfortable that it would be okay.

Lior Yaari:

Thank you very much. I'm very interested in this discussion as you may see because we are thinking about it a lot and it's super interesting to hear your thoughts about it. I'm sure everyone listening would agree as well. I want to do a shift to another question as we near the end of the webinar. Every few months, I'm searching cloud engineer on LinkedIn and I'm seeing the number of results. And then I check for DevOps engineer, see the numbers of results. And I end with SaaS security engineer or SaaS security as a title and the numbers are growing they're not that big. But I wonder if you think that SaaS security would become a knowledge niche that would eventually require a dedicated person to handle, like cloud security or IM went through in the last 10 years.

Tim Fitzgerald:

Do you want me to have a crack and go first this time, Alex. I saw this question in advances and I was curious about it. Honestly, I don't know, actually, I don't know what the answer is here, because so much of what we do around SaaS security is fundamental security. Have we evaluated their control posture? Did we understand the risk that they present? Have we done appropriate authentication? Do we do monitoring on those services? A lot of this fits in the things we already do. And, where I could see more specialist roles starting to come in is in how we manage authentication ongoing for many services beyond single sign on.

Tim Fitzgerald:

How we start to look at how these systems interconnect, that doesn't necessarily require our network to be the linchpin. There's a lot of specialized knowledge there. But I'm not sure it adds up to a SaaS security professional designation or an individual that lives in that window. I think so much of this comes down to skills that already exist within security architects and within the identity and access management group. My hope would be that we don't have to add another specialist role actually, that we can repurpose existing skill sets to solve the problem.

Alex Manea:

Yeah. I'm with Tim on this one. I think to the extent possible, I'm a big fan of generalists when it comes to security. And I'm a big fan of people that can go across different domains and look at things holistically. Because I think if you overspecialize in a specific domain then you get into situations where you focus too much on the trees and you don't see the forest and you don't see the interconnections between things.

Alex Manea:

But to your point, Lior, I do think there are certain skill sets that are somewhat specialized. And I think those skill sets are going to continue growing. And I could see a situation a few years from now where especially in larger businesses, larger corporations, they might hire SaaS security specialists just to deal with the sheer volume of SaaS apps. It wouldn't necessarily make sense in an SMB type of context because you need those types of generalists, but in a company the size of Arm or the size of an Intel or a Microsoft, I could definitely see those types of companies having SaaS security specialists.

Tim Fitzgerald:

I will say, even a company, the size of Arm, which is a reasonably big company we have no plans to hire a SaaS specialist. This question intrigued me and so I've done some more research on this topic to figure out what a SaaS specialist might do. And I think it's possible that I roll the balls, but actually I would actually that all of my security professionals have the capacity to figure out how to handle SaaS because this is much a business process problem as it is a true security problem.

Tim Fitzgerald:

And I think, the point that Alex made is right on in that we could get somebody in who's really excellent at authentication and APIs and really thinks their way through how this SaaS integrates with the company who completely misses the point of whether or not they are secure enough themselves, whether or not they meet the business purpose, whether or not we've made the experience simple enough to use. All of these things come into play in a way that, I don't know, just doesn't seem to lend itself towards a specialist, in my opinion.

Lior Yaari:

Yeah. Cool. Interesting. Maybe getting at the end, just looking back in hindsight, did you make any mistakes in how you designed your SaaS security program or what would you advise to your past self to do?

Alex Manea:

I think one of the things that we've recently done is we've put into place more of a consistent process around deploying SaaS apps internally. And that hasn't always been the case. And I think that's often happens at a startup, where you have a new startup and everyone has full admin access to their machines and has the ability to start deploying whatever SaaS apps they want. And a lot of startups operate like that for the first few years and that's where you start getting that huge, huge, long tail of SaaS apps.

Alex Manea:

And I think if I could go back maybe four, five years, I would put into place a more rigorous process around deploying those apps to make sure that we don't have lots of SaaS apps that maybe are not completely necessary internally and making sure that we have the right security controls in place.

Tim Fitzgerald:

Yeah. I would say, I mean, somewhat jokingly, I would say almost the opposite of what Alex said, but actually with some context, because when I was in my younger career in earlier days on SaaS, we used to fight the tide is what I called it. We were constantly trying to control what people could use and be really clamped down on it. And it was just, I mean, not only was it a fight that we definitely lost, but it made my security team show up as the anti-productivity, anti-progress group.

Tim Fitzgerald:

I think actually what Alex said is correct. You need some really strong processes, but for the purpose of making this simpler and faster and enabling the business to move quicker. So they know the rules that they're working from, not having to try and guess whether or not any particular app or platform will be okay. And actually you can enable them to do a lot of the heavy lifting for your security team to help get these apps over the line if you educate and give a good playbook to work from.

Tim Fitzgerald:

So I think it's... I said somewhat jokingly, actually Alex is right on, of course you have to put some controls around this. And I think put those processes and controls as an enablement for people to get what they need as opposed to a blocker to make sure that they don't cause risk. It's a slight nuance, but I think it can be really beneficial to your security organization to be seen as partnering on this and not only being the backstop.

Alex Manea:

I think you're absolutely right, Tim. I think it goes back to the previous discussion around security as a business enabler. It's so critical for security to be seen as part of the business team and not as a show stopper or a blocker or, "We need to go to the security team and get the check mark for this app." That you can't have the business getting to that mindset because back to your previous point, Tim, if people really want to deploy a SaaS app behind your back, they will and you need to build that trust with your users.

Lior Yaari:

Yeah. I think what I understand is you need to find the balance between making sure you can understand what's being used and at least prevent things that are obviously dangerous, but let users still work with the velocity that they need. Because I know a frustration for many CISOs is just, they feel like they have to put road blocks or barriers on users, which in fact hinders innovation within the company. But there is an opportunity not to police anyone just to make sure they're doing it safely.

Lior Yaari:

So with that, I think we've reached the end of our webinar. Tim and Alex, I want to thank you again. This was wonderful. And I like how these conversations always drift to different directions that are unique each time, again and again. So thank you very much for being here.

Tim Fitzgerald:

Thank you.

Alex Manea:

Awesome.

Lior Yaari:

I really appreciate the time. To everyone who is listening, I hope you enjoyed the webinar. Again, my name's Lior Yaari, I'm the CEO of Grip Security with a SaaS security startup that sees and secures every SaaS application within the organization. And always feel free to reach out if you're interested in hearing more and see you next time.

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.