Thanks, everyone for joining today. We're super excited to be here with you and to talk about Demystifying 3rd Party Risk: Discovery and Why It Matters. This is actually our first webinar in a three part series on third party risk. So if you're here today, we hope to see you at the other two sessions as well. The next session will be on February 22.
Before we get going, I'll quickly introduce myself and SafeBase. So I’m Macy and I'm the director of Strategy and Operations here at SafeBase. For those of you who aren't familiar with SafeBase, we are a Smart Trust Center for b2b companies to share their security posture and automate access to sensitive documents. Everyone here today is eligible for two months free of SafeBase. So if you're interested in learning more, please reach out to us. I will put our emails up at the end here as we have the Q&A. So please don't hesitate there.
Today, we have two awesome guests. We have Drew and Kevin. So for Drew, we'll start with his intro. Drew is an information technology executive with two decades of experience in InfoSec, technical operations, and information systems. He's served as a CISO, CIO, and head of information security for multiple technology companies, including Druva, Google, NetSuite, Shutterfly, and others. Drew is also an angel investor, independent board member, and advisor for over a dozen companies solving interesting security, privacy, and technology challenges. Thank you Drew for joining us today. We're really excited to be here with you.
Last but not least, we have Kevin, he's SafeBase’s Director of Information Security. Prior to SafeBase, Kevin helped start the security programs at Jet.com And SeatGeek, and also works with various startups on their information security policies.
With that, thank you, for those of you that just joined us, we are excited to have you here, we will be able to answer questions as we go. So if you have questions, please post them in the chat and the Q&A or feel free to direct message me and I'll make sure to ask them throughout. And now we can go ahead and get started here. So we'll get started. Drew, question for you. I would love to understand why third party risk has become such a problem?
Well, first, I want to say good morning, good afternoon, good evening to everybody that's joined or is joining.
I think third party risk is a problem because as everybody knows, we have choices, we have options. In the SaaS and service provider world, today, things are so easy. Companies pop up, you know. In a heartbeat, they can build and maintain their services. And when you think about risk management you can deal with it in one of multiple ways. And anybody that's dealing with risk management knows that you can mitigate it, you can eliminate it, you can transfer it, where you can solve it. But with third party risk, sometimes you often don't know about it. And I think sometimes people don't realize how challenging this can be to address.
One of the things that I noticed, and some of the companies I've worked at in the past is anywhere between 25 to 50% of these third parties are unknown to the security team. Because someone has seen a service and says, oh, that'd be very helpful for this or that or they approached finance because finance has to pay to invoice or they approached legal to deal with the contract, or marketing because of some other reason, and it doesn't get to the security team. And because SaaS is so easy, and so browser based today there's no reason why security would necessarily know.
And I think all add on so on top of that, think about 20 years ago, before SaaS became a thing. Anytime you wanted to use a new tool, you would have to install software on your computer. And naturally what would happen is you try to install it, and Windows would say, please enter an administrator password right now. It's kind of the old school way of doing application security, meaning just don't let people install things.
But these days, what are you really installing? Maybe Zoom, Chrome, these are pre approved, maybe Spotify, but all these other SaaS services, especially the ones that have SSO enabled, you can just click login with Google. You don't even have to make a password. So it makes it very seamless. And also, other things that make this much more of a problem is a lot of these newer technology companies, they don't do what banks and hospitals do. They don't decrypt traffic anymore. A lot of people view it as somewhat of a invasion of privacy. And also, like firewall, URL blacklisting is kind of dying out. A lot of companies back in the day, they would block Facebook. But now all these companies need Facebook as part of their business. And so in a lot of ways, the internet at these companies is much more open then it used to be.
And so for someone who worked at a company that had none of these restrictions, what’s to stop them from saying, Oh, I'm going to sign up for this, it’s a free trial, great. I don't even need involve finance, let me just try it out. So that's what we've seen. And other things to note about why it's so easy is a lot of these startups, they use things like React, it makes it very easy to set up a website very quickly. And security isn't necessarily something they don’t care about but it’s just not on the highest priority level.
And so you're starting to see, for the first time ever, all these big companies ask smaller startups, can you get a SOC 2 audit. So for those of you who aren't familiar SOC 2 audits are these security focused audits where you hire a third party firm to look at your internal processes and procedures to make sure that you fit a certain standard. And this is because the problem has gotten so ridiculous, where everyone is signing up for SaaS services. I'm sure the average Fortune 500 easily has three to four thousand services, but probably more. I know that when I was at Walmart, we had about 200 security tools, just security. And so you can imagine if you're tacking on marketing, and all these other things that it explodes, right?
I mean, Kevin, as you mentioned, security is often an afterthought at these companies. When a company starting up, and I've talked to founders, I've talked to product managers about this, you know, they realize that they have to build features to be able to attract customers. So security is something they think about later. And you're right. I mean, you know, that 25 to 50%, that's unknown. Companies I've been at in the past we knew about 200 to 250 vendors, and then I would deploy something like Lumos Identity, which goes out and searches for these auth tokens and searches for these welcome emails and things like that. And I would find out that there's 100, 150 applications that we don't even know about. And for some of these you approach the business owner, you approach the person that has a license for it, and they're like, oh, I forgot I signed up for that six months ago, and I'm not using that anymore. But you realize we're still paying for it, they still have our data, they still have access. I mean, so many things make that such a challenging issue.
Yeah, that's, that's really interesting. Thanks for that, both of you. I would love to hop to the next topic. And we did get a question in on that one, which we can answer at the end. But Drew, from your experience, in addition to security risks, what are some IT, legal, and financial risks that folks may not be aware of when they sign up for new services on their own? You just sort of touched on the finance side, but anything else?
I mean, from a legal standpoint, one of the things you have to think about is, where does privacy sit in your organization? You know, I've had organizations where I've been responsible and accountable for privacy, but I've had other organizations where legal has been accountable and responsible for privacy. And frankly, I think that's where privacy should be, because it is a legal risk.
And I mean, you think about, you know, geopolitical boundaries, and, you know, things like GDPR and CCPA. And, you know, there's a plethora of other privacy and security legislation is being considered now. This is just the beginning. And while some of these things like GDPR seem to be focused on the larger companies out there, the Googles and the Microsofts and Facebooks of the world, that's not going to stay that way as these programs are mature. As those companies get better, then those regulators are going to start looking at smaller companies.
And when you think about a bigger company like Facebook, or Google or something like that, while these fines are enormous and costly, these companies can survive. This is because it’s still not a significant number in their overall revenue projection. But for a smaller company, a $20 million fine could be the difference between going bankrupt and surviving. These things become really important to figure out.
And at the end of the day, and I think Kevin mentioned this a little bit, while there aren’t too many applications that are installed today, when you have all of these things in your browser, though, you are affecting the stability of your system, which means it becomes an IT problem. And then, of course, finance has to pay for these things ultimately. They need to know where these things get charged to, and things like that. Everybody knows that you can just email AP at a company. And if the company is not in a good place, it will just pay the invoice not knowing any better. And all of those can be detrimental to the business itself.
Yeah, and so one tricky thing that SaaS kind of made into a big problem is, you'll notice that a lot of these SaaS sites, they'll have different pricing plans. So you'll have the freemium, then you'll have like a business/Pro, then you have a team license after that. And so it's very easy for someone on there by themselves to sign up for that paid solo plan. And then someone else in a different group or department works with IT to set up an enterprise plan, which has a ton of extra features. Now you're paying the company twice, and the person who has a single license might not even realize, and they might not even realize that they actually should have access to the enterprise features. And so you're kind of losing out on features there too.
And so, other things to add on to that related to legal. So one thing that trips up a lot of startups is when they sign these DPAs, or data processing addendums, there's usually a clause with the larger companies that say, if you intend to add a new sub processor that will process our data, you must inform us within X amount of days before you deploy it. And the reason this is starting to happen is because a lot of these smaller companies, or even bigger companies, aren't handling privacy properly. And so all these big enterprises, they have an obligation to protect their customer data. And so if their vendors are signing up with other vendors, and aren't telling them it creates like another creates like a third party, rogue IT kind of issue, right?
Yeah. And some of that comes from GDPR. I mean, GDPR stipulates some of that stuff, where, if you're changing your data processors, you need to let your data subjects know. And I mean, Kevin, you and I have talked about this, some of these early startups, they gain more access to data than they generally need, or they gain more privileges to what they generally need. And I've had conversations with entrepreneurs and product managers about this, companies I've invested in, and what they tell me is, hey, I may need that in the future. And I don't want to have to go back and ask that company for this, because that's a difficult conversation.
But what that means is, then you as a user of that service, or your company, as a customer of that service provider, they now have access to data that they necessarily shouldn't have. I remember a situation and I've seen this more than once, where when a security review is being done for an application, and I was handed an IAM policy, an identity and access management policy that was open, open, open. I mean, it was basically all resources, all access. And when I asked the vendor, they said, well, this just makes it so that it works. And I said, well, that's just not going to fly with me and my team. You know, I need to see the policy that is very specific to what access you may need. And and I've had vendors push back and say, well, that may break things in the future and I said, well, then it'll break things down in the future. Let's solve those problems in the future, I want to make sure that what access you have is what you need. Because I don't want to handle this in this way because ultimately things get forgotten.
Things get overlooked, and Kevin, you and I talked about this sometimes. People stop using applications and that data is still out there. And I can't believe that I've heard this more than once. But when I've asked companies for security information to try and figure out there security posture, I've had more than one company tell me what we're in Amazon, AWS, they have security, right? And it just, confounds me to think that people are not focused on security.
And that's, that's one of the reasons why at my last company when I met Al, the CEO of SafeBase it was one of the things I said, I just get it, this, this needs to happen. Because as a service provider, as a vendor, you know, I want to be able to provide that information out to my customers, so that my team isn't turning around every time they get a request for a security policy. I want to be able to provide them a self service way that they can download that and at the same time, give me a chance to be able to communicate updates to customers when things happen. And that's, I think that's paramount.
Drew that really great point. And thanks for the SafeBase plug, but we do really help our customers communicate. And, you know, with recent Log4j vulnerability, we did see a lot of our customers provide updates for that and things of that nature. So thanks for sharing that. I would love to switch a little bit in terms of topics. So you, of course, have a lot of operations experience. So can you talk through how mature organizations typically inform various stakeholders, when new vendors are onboarding, what are the typical tasks that each team is responsible for?
I mean, that's, that's pretty interesting. I can think several of the companies that I've assisted in the past that have not had any programming at all. It is haphazard, at best. Somebody learns about something, and they may or may not tell someone else. And that's one of the things that I do almost immediately. The system that I've been using for the last few years that I think works, the best is a tier system, where I decide on vendors based on risk, based on data access, need to be in what tier level and that will decide who needs to be involved. And then I use something like, and we talked briefly about this last time, we talked, Macy, Zip to manage that process.
Because what I what I find very valuable and what I find very hard in organizations is the accountability. I want to be able to visualize, when I say, look, this needs to go through a privacy review, this needs to go through legal, needs to go security, it needs to sign off on this. I want to be able to see those steps and see who's assigned the work. Now, you can do that with things like JIRA, and other things where if you build the custom workflows, but I think that's the key is you've got to be able to make sure that you have everybody in alignment and held accountable for their responsibilities to the process.
Yeah, and, you know, regarding alignment, it's really good for all the teams involved to be on the same page, because naturally, someone will first go to IT and say, can you enable SAML for this thing, and the IT person, if they're following policy should be saying, has Legal gone through this, has Finance approved, etc. And vice versa, right? If someone says, here's an invoice for the service, Finance should respond, have you talked to IT yet?
Maybe this isn't even compatible, right? Because a good example is SAML, right? Everyone knows that. Okta is super popular for logging into services. If IT has a policy that all external SaaS services have to use Okta for authentication, and if you're signing up for SaaS services that don't support it, which is fairly common at the startup level, IT is just going to straight up say no, and then you'll have wasted 30 days trialing the service out, only to be told this is actually not going to work. So it's that's why all the stakeholders need to be involved.
And Kevin, you and I talked about this. There’s I don't know if the participants know about this, but there's a site out there called sso.tax. And these are companies out there that charge extra money for that SSO enablement, which I mean, as Kevin and I were talking about this offline, it boggles our minds, I mean, to charge just for security features. Now, don't get me wrong. I think that companies can bundle SSO with a suite of enterprise features and charge for that. There's nothing wrong with that. I mean building something does take money. But to say that setting up just SSO requires a fee, is ridiculous, in my mind. I think if you bundle it with a set of enterprise features, then that makes perfect sense to me. And I think that's fair, you know, we have to be fair between service providers and customers. I think that's one of the things that you can do.
And I think the other thing that, Kevin, I felt, I've seen a companies, like you alluded to, not waiting to go talk to IT. But I've also seen people that really want to use a service, and they want to get to be able to use a service as quickly as possible. So they're going to find, or try and take advantage of the path of least resistance. And that may mean that they just go to Legal or they just go into Finance and say, hey, I'm using this new service. Because they don't want to go through the security review. They don't want to go through IT telling them no. And that just leads to enormous problems down the road.
Yeah, and that's actually the perfect pivot. We have six minutes left. And one of the questions we got from the audience is about that Drew. So why don't we pivot to some some audience questions? And Kevin, you can chime in with what you're gonna say then as well. So the first question we got was on that vendor onboarding process. People oftentimes don't really like following them, because they don't understand why we have to go through all these steps in order to start using someone new. Do you have any techniques to encourage users to follow it? Or follow the processes without seeming like, you know, you’re the bad guy and saying no all the time?
Yeah, I look, I I'm a believer that security has to work for the business. And I think some of my peers and some of the people in security, as you alluded to tend to be purveyors of No. And I think that gives them a bad rap. I think much like sales teams, much like Customer Success teams, we have to realize that we have an obligation to our customers. So we have to make sure that it is clear what steps need to be followed, and that there are efficient and effective steps so that it can be done quickly. I like to show when I when I improve systems like this, I like to show that to the individuals. Like hey, when we onboarded a vendor a year ago, that would’ve taken you a month. And now it only takes you two days, and here’s who's accountable and here’s who hasn't done their responsibility. And again, you hold these people accountable on the team, on IT, on Security, to do their job. And if they're not doing their job, then you stop them and you say, look, if you can't do this job, then you're letting our customer down.
Yeah, and another thing that I've found to be helpful in terms of helping with the relationship is taking a different approach when doing the vendor review process. So a lot of times security teams will think, no, I don't want another vendor in my system. And I really think we should start thinking about it as I would like to help this person that's asking for this tool, and hopefully the tools meet their standards. And if you start to think and take that approach, you could still follow the review process. But in terms of the language, when you communicate to your team members, it shouldn't be it has to go this review process. You should really be saying things like we'd love to help you onboard the service but we just to make sure we're in a good place so we do need to do a review.
And one other thing that a lot of companies fail to do is you've probably seen a ton of other SaaS services like competitors of that service. If you find something that really isn't up to par, offer an alternative, right? And one of the best things a CISO told me is instead of saying no, learn to say no, but. For example, let's say you’re reviewing a new payment processor company that’s a startup and you're not comfortable with their security. You could say, well, maybe we shouldn't use this but I'm familiar with Stripe. I'm familiar with Braintree. Those are industry recognized solutions that could solve the problem. How about we talk about them? And I think if we start thinking about in that way, people will be much less afraid of talking security when dealing with vendors.
And, you know, Kevin, that that's exactly the point. I think that every team, be it IT, be it security, be it Legal, be it Finance, has to realize that we have customers, whether internal or external. And we can only be successful if we have that collaboration and cooperation. If if people feel like it's a difficult process, you need to elicit feedback. You need to ask people to tell you, hey, how did it go, give me a score of one to ten. It doesn't have to be this enormous questionnaire. How did the process go? And if you're not getting a high NPS out of that, go back to that person and say, what made their problem, that situation, challenging for you, so that we can improve it? People will respect you for that. And they'll be more willing to go through a process when they know that they're, they're being heard.
Awesome. Awesome. Thank you. So we only have about 30 seconds left here. So if people have more questions, we're happy to hang back for a couple of minutes and answer them. And I have put my email and Kevin's email up on the screen for you all. So if you want to contact us or you know, get in touch with Drew, feel free to shoot Kevin and I an email. Really, thank you so much for joining today. This was a really great discussion. Drew, thanks for all of your time. Be on the lookout for our next webinar. For this series, we'll be discussing strategies and techniques to help reduce rogue SaaS registrations. Of course, if you're interested in SafeBase, please do reach out everyone who attended today will get two months free. So really excited to hear from some of you and we'll we'll be in touch. I look forward to seeing you at the next webinar. Thanks, everyone.