Addressing SaaS Security Holistically
When someone approaches me and says they “want to secure the cloud”, I immediately ask, “Which problem are you trying to solve: securing access to the cloud or securing apps/data in the cloud?”. This distinction is critical because how you approach addressing these two areas is wildly different.
Securing Access to the Cloud
Since I know most want to talk about technology, I’ll start here. From a market perspective, this has historically been covered by the Cloud Access Security Broker (CASB) vendors. If you are looking for a drastic market change, this is one. While CASB vendors (and marketers) had this cornered for the past 5+ years, over the last 18 months, a new technology emerged known as the Secure Access Service Edge (or SASE, a cringe-worthy acronym). SASE combines much of what CASBs do along with SD-WAN, Firewall as a Service, Secure Web Gateway, VPN, and a few other remote access buzzwords. This is very much a convergence technology. While the term itself is new, the idea of taking a slew of disparate yet adjacent security technologies into a single platform is not. Watch this market as it is rapidly emerging.
The most common pitch for selling SASE looks like this:
And as you can see, being able to centrally enforce secure access to the cloud from a single set of policies is more efficient. But while SASE can help with securing access to your SaaS cloud, it doesn’t do anything at all to address apps and data already in the cloud.
Securing Apps/Data In the Cloud
Everyone should be familiar with the shared responsibility model at this point so let’s just touch on it very briefly. Suffice it to say, when you put data into any cloud platform, you share security responsibility with the provider. How much depends upon if it’s IaaS/PaaS vs. SaaS and whatever else you might have been able to work into the contract with the provider. [The larger the provider, the less likely you will be able to add any additional terms unless you commit to a top-tier amount of cloud spend with the provider and/or are a sovereign government.]
Microsoft created this handy chart:
Credit: Microsoft
I love this chart because it makes abundantly clear the amount of investment and time each consumption model will require. To make this numeric (and perhaps overly simplistic), notice how there are ten areas of responsibility. Across the models, it breaks down like this:
On-prem - 10 out of 10
IaaS - 7 out of 10
PaaS - 4.5 out of 10
SaaS - 3.5 out of 10
Admittedly, each of the ten areas may not require equal time and investment, but you get the point: plan accordingly and realize what you are walking into depending upon the cloud consumption model. No matter which you choose, they will all require strategic planning across the people, process, technology, and data spectrum. But how do you secure SaaS, you ask, since you can’t install anything or run agents?
How to get it done
SaaS security has long been an area incorrectly addressed only through vendor risk management (VRM) programs. The problem is that while VRM is an important part of choosing the SaaS provider, as you add data and users into these platforms there is still a massive amount of security ground to cover. Most security teams stop after conducting the initial risk assessment and configuring SSO. At which point the day-to-day operations are usually left to IT or a business unit administrator. This is a critical mistake and a breach waiting to happen.
People
Getting situational awareness of your organizational use of SaaS apps is a critical first step. Most organizations will have three categories of SaaS apps: sanctioned (paid for by IT or a BU and reviewed by security), tolerated (perhaps paid for by IT or a business unit, security is aware but has not done a risk assessment), and unsanctioned (ShadowIT, no IT or security involvement). No matter which category your SaaS apps fall into, if they have sensitive corporate information, they need to be reviewed by humans for the risk impact to the business. This means that depending upon the scale of your SaaS usage, you may need to have dedicated cloud headcount for both VRM as well as the ongoing care and feeding of the platforms.
Process
Dedicated headcount is great but resources will need a documented process to follow. Critical processes/workflows include: how SaaS risk is to be assessed, standardized metrics to track through the lifecycle of the application, and defined ownership of the entire shared responsibility model within the enterprise. Having this framework and defined ownership will simplify what is currently a hot potato in most organizations: who owns SaaS security. Go ahead, ask around your company. Who actually owns SaaS security? Is it the BU, security, IT, a mix of all the above? Focus here before moving to the next step.
Technology
Security teams are limited to provider APIs when it comes to monitoring and configuring SaaS platforms. This means that security teams need to recognize that the risk management tools already in their arsenal likely do not apply to SaaS platforms. NGFWs, CASBs, VPNs, CSPMs (at least what’s currently available at the time of writing), etc., provide little to no protection for the data and thousands of possible configurations that exist in each SaaS platform. This is why in the last 18-24 months a new market emerged known as SaaS Security Posture Management (SSPM). Some of the startups in this field include Obsidian, Siriux, and AppOmni. Their aim is to help secure the configuration of popular SaaS platforms such as Microsoft 365, SalesForce, and Box, to name a few. SaaS security issues run the gamut from failure to enable MFA to overly permissive sharing for external users. SSPM vendors use cloud provider APIs to discover, protect and monitor the configuration of SaaS platforms. If you understand what current CSPM platforms do for IaaS/PaaS security, think of this applied to SaaS and you have the current generation of SSPM platforms. This market is still very early, watch it closely.
On this months podcast
This month I featured Brendan O'Connor, the CEO of AppOmni. When it comes to SaaS security, I’m not sure there is anyone more well versed given that he ran security for both ServiceNow and Salesforce. If you want to go another five levels deeper into SaaS security than what I covered above, make sure to listen to this month’s podcast! And oh, PS: no vendor FUD either. I actually tried to get Brendan to talk more about what AppOmni does for SaaS security but he dodged my question in true professional style. Make sure to roast him on Twitter (and no, he isn’t personally on Twitter either so you’ll be roasting the company).
Until next month,
Matthew Chiodi
Author, Cloud Security Today
Visit our sponsor, Prisma Cloud, to learn more about their cloud native security platform for IaaS/PaaS as well as securing DevOps.




