Did You Know You Have a SaaS Problem?

<Note: transcript is automatically created and may contain typos>

[00:00:00] ANNOUNCER: This is the Cloud Security Today Podcast, where leaders learn how to get cloud security done. Now your host, Matt Chiodi.

[00:00:16] MC: People, process and technology. Oh, man. Those first two are so hard, the people and the process side. On today's podcast, we go deep into the topic of SaaS security. That's right. Think about the Salesforces, Dropbox, Office 365. That's what we dig in today. Get ready, grab a notepad and get ready to take notes and enjoy this discussion with Brendan O'Connor, the CEO of AppOmni.

[INTERVIEW]

[00:00:45] MC: Thanks for joining us today. Super excited to have you on our next edition of Cloud Security Today. If there's one topic that I get asked, probably the most about, it is SaaS security. How do I secure SaaS applications? How do I make sure that I have visibility, what controls over and over? These are the questions I get. Today, I'm really excited because on the podcast, we have Brendan O'Connor, who's the CEO of AppOmni joining us today. Brendan, thanks for coming on today.

[00:01:14] BO: Glad to be here. Thanks for having me, man.

[00:01:16] MC: Awesome. Awesome. I’ll tell you, first of all, let's just start off the beginning. Tell us what problem does AppOmni help address? What do you guys do?

[00:01:26] BO: Thanks for the question. I don't like to make these things so much of a sales pitch. I'll keep it pretty short. SaaS security management and SaaS applications is one of the biggest blind spots in the enterprise today, if not the biggest. SaaS may have started as a simple web app 10 years ago. Today, major SaaS platforms have evolved almost into their own operating systems. We're looking at a situation, where especially with remote work and what we've seen over the past year, companies have significantly expanded their SaaS investment and footprint and the SaaS applications themselves have really grown in complexity. Most companies haven't updated their security controls to support SaaS, or invested in new technology to manage this problem. That's where AppOmni comes in.

[00:02:10] MC: Awesome. That's pretty cool. All right, so before we dive a little bit more into maybe the technical side of it, and the how-to side, one of the other common questions that I get, either from people who are early on in their career, or maybe they are further along in their career and they're looking to make a pivot into cybersecurity, is how do I get into cybersecurity? Tell us just a little bit around, what does your journey look like?

[00:02:35] BO: I would sum up my journey as bite off more than you can chew and grow a bigger mouth. That's worked for me for 20 years. I started 20 years ago in embedded systems. I wasn't even really in security at the time. Security wasn't a job, or a function that you could apply for. I started doing IT engineering right out of college, first job out of college, at a communications company and they made embedded systems. This is around the time of Ethernet and LAN being everywhere.

We had security cameras, we had door and badge access control systems. HVAC systems, like the air-conditioner, nurse call systems in hospitals, all of these little electronic devices that were plugged in and wired into the building. Today, we'd call them IoT devices. 20 years ago, it was embedded systems, or facility-based electronics. That's how I got started. I got started in IT, because I found a vulnerability that the door access control system we had had a six character uppercase alpha password, that I was able to brute force. It was the same password for every controller that controlled all of the doors on the land.

I was able to from my computer, get into the system and tell all the doors to open, the exterior doors to open at the same time from my computer. The CIO saw me do that, grabbed me by the shoulder and walked me over to the dev and engineering team and had me sit down with them. It's like, work with these guys to fix it. That's how I got into security is playing a prank, but I was curious on how those systems worked. That was my start.

Then I moved into banking, I was in banking when online banking started to become a thing and spent the early part of web 1.0, building and securing enterprise banking platforms. Then in 2007, I joined a small company called Salesforce. It's the beginning of the cloud journey. I was there for about 10 years, and it became a very large company. I found myself doing cloud and SaaS full-time as a security professional starting with 2007. I've been in it for a while.

[00:04:33] MC: I noticed one thing you said there was what led you down the path into security, it sounds like it was really curiosity. I'm just curious. From your perspective, how much does curiosity play into just growth overall in a career? For you, how does that change? Today, you're a CEO. Most people look at that and they're like, “Wow, you're at the peak.” How much of a role does even curiosity play today in your role as a CEO at a cybersecurity startup?

[00:05:05] BO: It's always important. I found, it gives me a couple things. Number one, is a pull is always more powerful than a push. Someone forcing you to do something is not as effective as there's something inside you that's pulling you towards it. When you are intrinsically motivated, I feel like you find the best in yourself. You bring your best thinking and your best energy to a problem. I love solving hard problems. I love solving puzzles. Enterprise security at scale is a hard problem. It's a puzzle. There is not a one-size-fits-all solution.

You can't just take a single approach and say, this applies to every industry, every company of every size, every technology platform. That's one of the things, that curiosity, that desire to understand the problem and come up with a solution is definitely one of the things that's kept me motivated. Whether it's as a CISO, application security engineer, a pen tester, or as a CEO today, I love talking to customers about what their challenges are and how we can work together to fix them. I think, it's the same job. It's scoped a little bit differently, but I'm still solving hard security problems alongside my customers.

[00:06:10] MC: That's great. I love hearing that. I love asking people about just how they got to where they are, because I think oftentimes, I think back to much earlier on in my career, I just thought, is there just one thing I need to do to make this jump? Of course, looking back on and after over 20 plus years now, I've realized that it's the small series of steps and decisions that you make along the way. That curiosity, always just being willing to learn and read and it's just been such a huge part of it for me.

I'll ask you one other thing before we jump in back to the SaaS pieces. What do you read? What are one or two things maybe that you read on a consistent basis? Do you love reading books? Are you a Kindle person, e-reader? What does that look like? How do you learn best?

[00:06:54] BO: I have a Kindle. It's near full. I've been a Kindle user for a long time. There's something about the paperback, or a hardcover book. I still appreciate a book. The truth is, it's just way more convenient to carry a Kindle. I've got shelves full of books in my house, as well as a few different versions of Kindle that we've used over the years.

I try and stay up on industry news. I read a lot of Slack channels. I read a lot of industry publications. I learned to be fluent in business, read the Wall Street Journal, or some business news. Understand things beyond the security aspect. Understand what types of other things are happening that are impacting customers beyond just the security lens. The security lens is very important, but also understand what's happening in the market and what other things may be impacting that business to those customers.

I'm a junkie for books, whether it's new fiction, or if it's the classics. I have a special place in my heart for the classics. I was an ancient history major and I love the classics. One of my favorite books is Marcus Aurelius’ Meditations.

[00:07:54] MC: Okay. I have not read that myself, but it's actually – it's on my to-read list. Full disclosure.

[00:08:00] BO: Awesome. Yeah. I try and always read. I try and always learn. I was trying to listen. I try and always maintain humility, that there's some very smart people that probably know a lot about a particular domain that I don't. Getting access to those people and listening to them, being able to ask them questions is just fantastic. Always learning. Always listening.

[00:08:20] MC: I love that. With that frame, skipping back, I think to how all this learning applies to SaaS security. Typically, when I'm working with clients globally, literally hundreds of them, one of the most common questions that I've got, I'd say over the last two years, has to do with CASB, so Cloud Access Security Brokers. For most of the questions, when they come to me, people almost always see SaaS security being – you talked about SaaS security and then you talk about Cloud Access Security Broker. My question for you is, does a CASB solve all SaaS security issues? Then where does it fall short? Again, I know you try not to make it a sales pitch, and that's totally fine. What is the solution like an AppOmni bring to the table that a CASB is missing? I'd love to hear your thoughts on that.

[00:09:11] BO: I'm not a big fan of CASB, having led security teams at leading cloud providers, with Salesforce and ServiceNow. I feel like I have a pretty unique perspective on the problem, both from the cloud provider, as well as being a cloud customer. If you have a CASB and you're getting value from your CASB, that's great. If it's a security control that it's helping you in your program, that's fantastic. It certainly doesn't solve all of the problems. I don't think it solves even the highest impact problems. My view of CASB is it solves common problems, like shadow IT, network-based DLP.

It is fundamentally a network-based architecture that's an extension of the perimeter. At a time when everyone's talking about zero trust and the perimeter is dissolving, why is it when we think about SaaS applications our solution is, well, let's build a slightly higher bigger perimeter. It's not effective. It's not working. If you have a CASB agent on your endpoint and you're going through the secure edge, or the proxy, or the tunnel, or whatever you want to call it from a network perspective, you're routing that traffic where the CASB can see and inspect and interact with it.

You're probably a low-risk user and that you're an authorized employee on company equipment. That CASB does not apply to the public Internet. If you're an attacker, you're going to go directly at that cloud provider, you're going to look for misconfiguration, you're going to interrogate their APIs, you're going to look at what portals, or endpoints, or sites have been exposed from those SaaS platforms and what's out there. Because the CASB isn't in front of my network, it's in front of the customer's network. The attacker is not going to opt in to going through the CASB. They're going to go directly to the cloud.

Your lowest risk population, your internal users where you control their endpoint and you control their traffic, you have robust security controls. The rest of the world, the rest of the Internet, what controls do you have on what they can see and do with your data? Well, the controls need to be around the cloud tenant. The controls need to be around the data and those APIs and those applications that are running inside that cloud environment. Trying to address it at the network is really only addressing it for your part of the equation.

It's like, if I build a secure highway, or secure tunnel between my driveway in the mall, well, great. I've secured all traffic that egresses my driveway. That doesn't prevent my neighbor from just driving to the mall. In fact, it doesn't prevent me from going to other stores in the mall once I get there. You're not wrapping the control around the cloud provider’s network and they won't let you. You can't pick up your own security controls and install them into their data centers.

It's a control that is in your perimeter that you control and operate, and you're trying to force your users to go through it. Oftentimes, you can do that. What you can't do is force attackers and third parties, or cloud native applications to go through it. That's where the gap is. It does some things very well; shadow IT, network-based DLP. People get a lot of value from that. If you're trying to prevent the attacker from downloading your data from a publicly exposed API, or misconfiguration, the CASB is not going to see it. Can I tell you a quick story?

[00:12:14] MC: Sure. I love stories.

[00:12:15] BO: Okay. We did a bake-off with a CASB provider, where the CASB provider was interested in our technology. This is a CASB provider on the Gartner MQ too. This is not some startup. This is a big company. I'm not going to mention it. They wanted us to run our product through their technology. We looked at one of their SaaS tenants, and we connected live with them on the Zoom across the Internet and we were not passing traffic through their CASB, which they had in front of this cloud application, this cloud tenant.

We found hundreds of thousands of documents and sensitive data records that were accidentally exposed via API live during our live risk assessment. They're watching us access this data from the public Internet, from outside the CASB, not on their internal network. Their CASB is reporting that there's no activity. It's not seeing it, because we're intentionally bypassing it. We're going directly to the cloud provider. We found production credentials. We found third party apps we could access externally. It's the controls around the data in the tenant. It's not a network problem. It's an application problem and it's a data problem.

[00:13:22] MC: I love that. I love that story. That’s powerful. Thinking about that, from a people and process perspective, if we go back to your experience when you were at Salesforce, and I don't want to skip over that. I think, for people who don't know you, you ran security for Salesforce, which I did have to do the research on this. Back in 2017, when you left, it had revenue, Salesforce around 10 and a half billion. Today, they're somewhere north of 17 billion. Behemoth.

What should organizations be focused on from a how to manage SaaS security at scale perspective? Not what to do, but how do they actually do it? Are there frameworks out there that organizations can be following as they look at trying to secure their N number of SaaS tenants that they have out there? How do you view that? How would you recommend people approach that, or think about it?

[00:14:11] BO: There's definitely frameworks. I want to give a little bit of credit to ServiceNow. I was in Salesforce for 10 years. When I left Salesforce, to join ServiceNow as CTO, I had the great experience of working with that amazing company and amazing team there too. I think, I have the unique experience of having led security teams at the top two SaaS providers, Salesforce and ServiceNow. I got to see both the internal, what we were doing as a cloud provider, but also, I was a cloud customer. These were both cloud-first companies.

Not only did they use their own cloud products, but they used other SaaS products. I really had the challenge of securing SaaS at scale enterprise-wide, at a time where most companies were still taking their first steps into the cloud. Part of it is just the nature of the companies I worked for in my role. I got to this problem very, very early on. They're both fantastic companies and I think that the cloud is inherently a better security model.

There's certain things that they do and SaaS providers do in the shared responsibility model that's very much better than what their customers could do themselves. They harden their perimeters, they patch, they have great vulnerability management and OS hardening and infrastructure hardening programs. They do this stuff at scale and they hire some of the best security talent in the world to manage and secure these production environments.

There's a ton that you get for free by going with SaaS. A lot of common things that you'd have to worry about in your own environment, or infrastructure environments, you get just solved for you by the SaaS provider, because they abstract so much that away. One of the challenges that I saw was upfront, security teams would look at a SaaS provider like any other vendor. They would do a traditional vendor risk assessment. They would say, do you have a SOC2? Do you encrypt our data? Talk to us about your data handling processes. You background check your employees that have access to data.” Typical stuff that you would ask any vendor.

That's not a bad thing to do, but that's a terrible place to end the process. The real risk is once users are using the application, once that application is loaded up and configured and running custom code and connected into your business processes and you've loaded all your data into it, a car is at its safest when it's parked on the dealer lot. We have to drive the car to actually start putting risk into the equation. No one would ever secure their endpoints by saying, “Well, we asked Microsoft if they had a SOC2 and they background check their employees, and they passed vendor risk management, so I guess we don't need to worry about endpoint security.” It's a ridiculous statement. No one would ever call them that.

When it comes to SaaS, it's like, “Well, we asked the cloud provider, do they have a SOC2? Do they background check their employees? Everything looks good. I guess, we don't have anything to do.” I've also seen that a big challenge is when it comes to who owns SaaS security, it's a big game of not it. Everyone hopes it's someone else's job, but there isn't one person that's like, “Yes, we specifically own that.”

If you think about it, it's mission critical applications. Sometimes the most important, or most used apps in the entire business, Microsoft 365, Slack, GitHub, Salesforce, ServiceNow, Workday, Atlassian. We live in these applications. Were in Zoom right now, everyone is using Zoom, or teams, or some video conference. SaaS is how we get work done. The data that's in these applications is some of our most sensitive. It’s data about our customers, our internal systems and operations, our employees, our payroll, very sensitive data. How is that not security's job to govern access? How does that not have a very clear, defined owner in process?

I think assigning an owner and having them in charge of like, we need to understand what SaaS applications we're using, what the important ones are, and what is our minimum bar from a security perspective? What control should be in place? Do we actually apply those controls consistently? Because what we find is because it's no one's job, you have good people with good intentions that make some pretty big mistakes, because they're not security experts. Meanwhile, the security team, they're not even looking. They may not even have access to some of these major SaaS applications. If they did, they're not quite sure what they're looking at, because they're not experts.

[00:18:17] MC: Yeah. That's a good one. I can just see this now being in a consulting call with one of my clients and them asking me, “Well, where should governance sit for SaaS applications?” Let's say, I'm a client, or I'm a customer of yours and someone asked you that question. Especially, I see this confusion a lot, especially the larger the company. If we're talking about a multi-national. Like you said, a lot of times, the SaaS applications, they may be owned by somebody in a business unit. They may not even be visible to IT or to security. There's that visibility problem, which we talked about falls under, I think, probably the CASB space, that can help you discover what are the SaaS apps that are actually in use in my organization.

I guess, the question then is, is, where do you think that fits best? Is it within an IT security, like a governance type role? Have you seen organizations that do this well, centralize that? What have you seen work well? What do you recommend?

[00:19:18] BO: When I run my programs, to me, this was application security. It's app sec. This is security as code. It's config as code. API security is app sec. Looking at role-based access control, you could argue, is authorization an app sec problem more of a traditional infosec problem. Having a clear owner and in my programs application security-owned SaaS applications and the data that's behind them.

I've also seen people have sec ops look at it. I've seen it be a distributed function. What has worked best for me and what I've seen customers really adopt and scale is, you can't look at every single change. I mean, you can't. There's so much change that's going on in these applications. These applications update themselves multiple times a year. That just comes with your subscription. It's not a bug. It's a feature. They're always adding more. The levers, knobs and switches are increasing in number and complexity, even if you do nothing, but you're not doing nothing.

You've got whole IT teams that have dozens of admins that live inside these applications and manage them and configure them, write code on them, integrate them with business processes and automation. These apps are great to integrate with. They can run almost any conceivable business process. Like I said, they're becoming closer to operating systems in the cloud than a single simple web app.

You can't watch what every individual is doing. You got to put guardrails in place. What are the things that always need to be in place? What are the things that users should never ever be doing? Can you programmatically put those in place, whether it's checking config, whether it's scanning config before you commit it to production, or it's just giving guidance and a checklist to the admins as security even wait in. Instead, these are the specific things that we expect you to do.

Our policy wants two-factor authentication everywhere. We need to have this encryption at rest feature on. These native security buttons or levers, knobs and switches that the cloud provider comes out of the box with, these must stay on. We see in almost 50% of cases in certain applications, people have disabled cross-site scripting protection. Disabled access SaaS in prod. It's on by default with most SaaS applications, or the SaaS apps that we've seen. Why does it get disabled? There's an article on Stack Overflow that recommends turning it off as a troubleshooting step for admins. You have an IT admin that doesn't know what XSS stands for and just trying to solve a problem. You've got a security team that knows exactly what XSS is, and what it does or why it's important. They don't even know that's a button they should be looking for.

It's a disconnect. You need to be able to understand what are those baseline level of controls and ensure that they're always in place. To me, that's baselining. That's guard rails. It's not rocket science, it's process.

[00:21:59] MC: I love that. Securing IS and pass platforms has always been a pain. Prisma Cloud by Palo Alto Networks is the industry's most comprehensive cloud native security platform with the industry's broadest security and compliance coverage throughout the development lifecycle and across hybrid and multi-cloud environments. The Prisma cloud platform offers an integrated approach that enables security operations and DevOps teams to collaborate effectively and accelerate secure cloud native application development. To find out more, go to paloaltonetworks.com/prisma.

One of the things that I've seen on the infrastructure and pass side of the house from a cloud perspective is just the proliferation of infrastructure as code. Terraform. Terraform has been growing like crazy. It's multi-cloud. Obviously, AWS, I think was one of the first ones to do it with cloud formation templates. Is there anything like that in the SaaS world? Is that something that's still years out? Is that even possible to do something like that? I know it can be called infrastructure, but –

[00:23:10] BO: First of all, I love Terraform. I love HashiCorp. Very proud. Also, fantastic product. We definitely see the exact same challenge, that this is config as code. Doing this manually is not the way to do it. This is a job for automation. This is a terrible job for a human to do this manually and it's repetitive. Put it into code and we’ve built our product to do along that philosophy with SaaS, is put the guardrails in place, make it programmatic, don't have a user inspecting every change, or just staring at glass trying to understand what users are doing.

Have a system that puts those guardrails in place, where people can define their intention. This is what I want to occur. Let the machine, let the code actually build that technical configuration. Because trying to manage these complex systems manually, it's like trying to manage your windows fleet with regedit. You could do it that way, but that's a terrible job. There's nothing really that any endpoint management solution can do that you couldn’t manually script through regedit and connect it individual computers and do it. Who would do that? There's a whole market around endpoint management for specifically that reason. It's error prone, it's manual, it's time consuming, it doesn't scale.

SaaS is the same way. Infrastructure as a service is the same way. These are old problems that are just coming up in a new flavor. Sometimes we can lift and shift the old technology and make it work in the cloud. Sometimes, we got to rethink the same value prop, but for a different architecture. My argument would be that SaaS is fundamentally different architecture than hosting things on-premise. You need to rethink, what is the value that you get from your security tools? How can you get that value today in an automated fashion in these new systems that supports that new architecture?

[00:24:57] MC: I love that. That's a great point. It's a great point. One of the things that I've blogged about in the past is the difference between effectiveness and efficiency. I know most of our listeners, they're using probably dozens of SaaS offerings, and they are struggling with measuring cloud security in general. I was going to ask like, metrics, things like that. I guess from your perspective, what are some ways companies can better measure and understand those two areas when it comes to SaaS security? Effectiveness. How effective am I being with my controls?

Then efficiency, obviously talking to how well am I actually doing those things? Are there metrics that you typically recommend organizations track when it comes to SaaS security? What should they be looking at? If you can share maybe, what are – are there similar metrics that you can share that you guys looked at, at either when you were at Salesforce or when you were at ServiceNow?

[00:25:57] BO: Yeah, that's a great question. I think that's a walk answer. I think most people are still learning to crawl when it comes to SaaS. To have metrics that you can track over time, you need to have that base level of telemetry. I think that most organizations today lack that base level of telemetry. What are the total number of security controls available in a given SaaS platform? Of those security controls? Are they on or off for us? I don't think most people can answer that comprehensively.

I mean, that's very, very basic. Think about it. SaaS, it's not just one environment. You can have dev environments, QA environments, staging environments. You can have multiple deployments for different GOs, or different business units. It's not like, just because you use Microsoft 365, or Salesforce, or GitHub that it's one single entity. You have many different repos, or channels, or environments out there.

What are your environments? What are the most important ones? What are the ones the business spends the most money on? What are the ones that the most users use? What are the ones that have the most sensitive data? Because these systems are on the public Internet. If it's not housing critical data, you should triage that towards the bottom of the list. If it's data about your customers, or your financials, or your employees, or all of your internal documents, that should be at the top of your list.

Understand what are the systems, who owns it and what is the current state of your security controls? Most people aren't there today. That's got to be step one, understanding that. From there, you need to measure and understand, okay, of the security controls that we have applied, are they being applied consistently and comprehensively across all our environments? No, it doesn't make any sense to put a 10-foot tall fence around two sides of your yard. You haven't prevented anyone from coming in if it's only partial coverage. It's probably more secure to have a two-foot tall fence around all four sides, at least then you can keep rabbits and small dogs out of your yard, rather than a huge fence that only covers one or two sides of the yard.

Do you have the right baseline level controls? Things like two-factor authentication, proper logging, encryption at rest? The basics of security, are they being applied consistent? Can you be excellent at doing the ordinary when it comes to security management and configuration? From there, then it's build a process. How is this scalable? How can we stop finding problems in production and start preventing them from getting into production in the first place? Sometimes we need tow trucks, because sometimes we crash our car. Crashing your car is a failure condition. We shouldn’t invest in better, faster, quicker tow trucks. We should be investing in guardrails to keep cars from driving off the cliff in the first place, so we don't need the tow truck.

Netflix has been a proponent of this for more of over a decade. They call it the paved road. If you give people a nice, easy paved road for them to follow, most people will follow it, because they just want to get their job done. Good people with good intentions make mistakes. When you don't give them guidance, they can make some pretty big security mistakes. When it comes to the cloud, you can shoot yourself in the foot with a cannon. You can have a huge blast radius and cause a lot of damage with some very basic mistakes.

Viewing every manual setting doesn't scale. Viewing every single change individually doesn't scale. That would completely shut the business down. How do you put guardrails in place that make sure that any changes to security relevant settings, new connections, exposing API's externally, third-party apps, things that have really high security impact that you're able to know when they occur, or be able to scan, or approve or catch those things in test or dev before it gets promoted into production?

[00:29:39] MC: Where do you think the market is just in – maybe, when I say market, I really mean the industry in terms of cybersecurity. Do you see customers in general? Are they asking the right question around this? Because as I mentioned before, I rarely ever get questions around the actual configuration of the SaaS platform. It's always again, CASB. CASB solves all my problems. Again, they're just focusing on I think, basically, the access portion of it, one part of the access portion.

Where do you think the organization, the industry is rather, in terms of just the maturity? Do you feel like, are you starting to hear that question more and more like, one of the things that caught, I think, the world's attention back in December was what happened with the SolarWinds hack. Has that changed? Have you found that people are starting to ask more questions, even about the SaaS platform itself? I mean, I agree with you.  I remember when I ran cloud security at Cognizant, I put together something specific around how we were vetting SaaS vendors.

We did look for SOC2s and ISO 27,000, all those things, but that doesn't address the configuration, like you said, of the of the SaaS platform itself. I guess, just question just generally speaking, has SolarWinds, which continues to just unfold, the output of that, has that changed? Has that caused people to ask different questions around even SaaS security?

[00:31:00] BO: It has. I mean, we've had several customers, I mean, since the holidays, approached us post-breach, where they didn't think they have an issue and they were told they had an issue. Suddenly, they're scrambling. As a longtime security professional, I've been in that case. No one likes to be on the post breach response team. I mean, it's a special pressure and pain. My heart goes out to anyone who's experiencing that, where you've got to make the best of a bad situation and figure out what happened. I hate to see that happen, but I love to be part of the solution and helping customers when that happens.

The truth is, it's happening and sometimes we hear about it. A lot of times that we don't, where they keep it pretty quiet. That aside on what our reporting is and should be on how often these breaches are occurring, customers are waking up to it. They know that with remote work, they can't rely on the perimeter. A lot of the thinking around SaaS was an on-premise thinking applied to a cloud problem. Because to your point, you thought about connectivity and isolation.

Well, we're just going to put a wall, or a proxy in front of the SaaS application. That makes it internal. We triage and trust our internal applications more than we do our external ones, because they're behind protection. They're behind those walls of the perimeter, our defense in depth. Well, I'm telling you, SaaS is not now and has never been behind your perimeter. Even if you think it is, that the cloud doesn't work the way that you think it does.

You need to look at how this third-party connectivity is actually working. When you grant an OAuth token, even if you have an identity provider with strong authentication, zero trust, they call it two or three factors, certificates, temporary one-time password, username and password, we have the strongest identity provider in the world. Well, guess what? That's the authentication that gets you a wristband to get into Disneyland. Once you're in Disneyland, you just show the wristband on all the rides. They don’t all check your ID, or maybe for an over 21 audience. It's like getting beer at a bar. You get checked at the door, then you have the stamp or the wristband and that's what gets you around. Every individual resource within that location doesn't re-ask for your full credentials.

Well, once you get a session ID and you're connected to a SaaS application, let's say I want to integrate something. I want to integrate a third-party app to sync my sales leads, or something to help me collect logs and dedupe duplicates that I have in my log stream, benign good use case. Well, once I grant an OAuth token to that third-party provider, it doesn't talk to my IDP. It doesn't go inside my network. I have a valid session. I've got the wristband. I make a copy of that wristband and I hand it to a third-party that is somewhere else on the Internet, running in Azure, AWS, GCP, their own data center, not on my network, not connected to my systems.

When that app connects to my cloud application, guess what? It shows the wristband. It doesn't go connect into my network and read zero trust authenticate to my identity provider. My IDP doesn't even see the activity. All the activity is happening inside the cloud provider. We do an assessment, where we will do a quick scan and show you how many third-party applications have live API integrations into your environment. On average, the security team is aware of less than half of them.

Think about it. Less than half of the apps that today are connected to your production environments and have some level of privilege to your data and the security team doesn't even know what they are. They could be making copies of your data. They could be syncing your data. You could be violating industry regulations, or compliance requirements without even knowing it. Because one individual user who had good intentions, was not trying to attack you, connected to a unsanctioned application, they copied your customer list.

Security is looking at the network. Guess what? There's no network activity on your network. It's not coming from your network. Staring at the ground is not going to tell you what's happening up in the cloud. You need to actually look at the cloud system. We also find, typically, third-party applications are vastly over provisioned. There isn’t an environment I've looked at that I haven't seen at least one or two apps. Oftentimes more, but at least one or two that have the equivalent of domain admin.

You've given a third-party vendor domain admin over your production environment. The fact that it's an API and not a UI, doesn't actually impact what it's able to do. The fact that it's programmatic access and persistent access, yeah, they don't get a browser like a user. What we saw with SolarWinds is, if that company gets compromised, they already have these bridges into all of these customers environments. The attacker doesn't need to establish access. They can just walk across the bridges that already exist. It doesn't look like an anomaly, unless you're looking really, really closely. There isn't an authentication of that. Your identity provider isn't part of this equation. They're already authorized. They already have the wristband.

[00:35:47] MC: Is that what we've been talking about there with the OAuth token, is that something that is a misconfiguration that you see, usually on behalf of the customer? I mean, is that something that – Is there a setting, they can change, so that that doesn't happen? How do you defend against that type of scenario? I guess, that's the real question.

[00:36:05] BO: Yeah. Most cloud providers do have some pretty strict controls that you can put in place, where you can have third-party tools that automate that workflow. AppOmni being one of them, but not the only. There's tools that will help you do that, or you can do it manually with the cloud provider. Then also, part of it is that's how OAuth works. Think about your phone. When you're using an app on your phone, you may have to authenticate with your full credentials, or using your identity provider at work once. After that, that app has a token. Usually, you can use local auth, like your fingerprint, or your face ID. That authentication, it doesn't re-prompt you for your username and password, or you don't need to reconnect your phone to the VPN.

Or think about IoT devices how they work. They're coming from carrier networks, and they're talking directly to the cloud. They're not VPN’ing into your network and egressing through your CASB, or talking to your IDP. They get this token. OAuth is a longer lib session ID. It’s being used for that purpose. I think that most security teams haven't really dug in, because OAuth can be complicated and it doesn't have one flow. There's actually a few different flows. The cloud providers don't always make it easy for you to see what all of those tokens that have been granted are. Who granted the token? When did they give it? How often has it been used? When was it last used?

Sometimes that date is there, but it's not in one place. You have to do some digging to go around and fetch it. I think it all comes back to that failed premise of it's not accessible. People think they have a wall around the cloud, and that these types of things aren't possible, or they're much more difficult than they truly are, so they don't think it's a big problem.

[00:37:39] MC: I love that. I love this conversation, just because I think it is it's so practical. I think, again, it's an area that many organizations are just starting to wake up to, in light of what happened with SolarWinds. Even as they rethink about how do we reevaluate how we do vendor risk management. I mean, this is a huge part of that, because that type of connectivity, right into this place where you have this massive amount of sensitive data, that would have never happened in an on-premise world without IT or security being completely involved.

Now, all of a sudden, you have all this data that's so sensitive, that's living in the SaaS apps. This isn't a new problem. SaaS is new. It just came out in the last three years. It's been around for many years. I love that. If you're someone listening to this podcast, and you're thinking, “Oh, my goodness. I had no idea that this risk actually existed.” What would you say would be maybe, what are some things that they could do right away to try to maybe get a handle on this? What would you recommend? What steps should they take?

[00:38:39] BO: It's a great question. It was something you said around like, that would never happen on-premise. That is actually a very important point. Security has been gatekeepers. As the people that own the firewall, the people that own the perimeter, security has often been a role of gatekeepers. You got to ask the gatekeeper, if you want to get in or out of that gate. That allowed security teams to express a certain amount of governance, because they held all the keys.

With SaaS, not only the security not hold all the keys anymore. They don't even know where all the doors are. Someone else has the door. Someone else has the keys. This has been democratized. SaaS applications and the SaaS companies, they've been very successful doing it, but they sell directly to the line of business. They sell directly to who their users are. In a lot of cases, they can bypass IT and security. That's why security doesn't have the keys like they used to.

To more directly answer your question of what can security teams do now, you got to look at what your major SaaS applications are, what are the app stores, or the functionality they have that allow you to connect and run native code within that runtime and what are their capabilities to take external code, so code running in another cloud service, or somewhere else to connect via API, web service API. There's two different classes of third party-apps. One is that run natively inside the runtime. Others, they run somewhere else, but connect and sync data, or read and write to the cloud. Those are the two major categories.

One of those is going to be the API connections. All of those are going to have usernames and passwords provisioned, API keys, OAuth tokens. There's going to be some credential that has been issued from the system to that, and you can catch them there. The ones that are getting installed inside your runtime, those are probably in a different area of the application. You have to look around and see what third-party code, or add-on code have we put in, what privilege level does it run? This is where it gets important. To whom have we exposed it?

We'll see cases where an admin level package, totally great software, not malware in any way, shape, or form, valid business purpose is installed on that SaaS environment’s runtime. It's running locally inside the cloud environment. Then gets provisioned to everyone, which includes external users. If you have external users that have pinhole access, or you've built a portal, or a site, or you've tried to grant limited external access, you may have accidentally exposed admin functionality running as root, or running as sysadmin to low-privileged, or untrusted users.

No one intended to do that, but because no one was looking at how the system was configured, who had access to what, what privilege level did these apps run as and to whom have we provisioned them inside the cloud environment, not on the desktop, you find out that, “Oh, great. I have 3,000 users that can all copy all of my data and decrypt it, because they have access to call this admin API.”

The other thing is, these applications are often SaaS themselves, which means they change. Even if you do nothing, the cloud provider is releasing more updates all the time. An application that maybe did one or two things when you first installed it and approved it in your third-party risk program two years ago, well guess what, that vendor has probably released a whole lot of updates. Your IT admins, or your business users may have enabled new functionality, or may have just been pushed to them by the vendor.

That application can now do 10 things, or 20 things, or have new external entry points. SaaS security is not a point in time problem. It is continuous. It's like, you don't look at the car and just test it when it's parked on the dealer lot. That's probably the safest it'll ever be. The risk is in the driver when it's on the road.

[00:42:19] MC: I love that. This has been a great conversation, Brendan. I really appreciate your time and just learning, just even though I've been in cloud security for well over a decade, you've brought up a lot of items that I probably haven't even thought about. I know that I'm going to have a lot of listeners here that are probably have a lot of questions. If they want to follow up with you, if they want to learn a little bit more about AppOmni, how should they connect with you? What should they do?

[00:42:42] BO: Always love connecting with people. Always love talking security. I am very much a security geek and love talking to other security people. Appomni.com. A-P-P-O-M-N-I. App like application, Omni like all. Appmoni.com is the way to reach us. Or you can catch me on LinkedIn, or Slack, or email me, or I can't wait to start getting to some security conferences, hopefully, by the end of this year, or next year when we're all vaccinated. Always love talking security with people.

[00:43:07] MC: Great. Well, thanks for coming today, Brendan. Enjoyed the conversation.

[00:43:10] BO: Hey, thanks so much for having me.

[OUTRO]

[00:43:12] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com. 

[END]