BUSINESSES’ USE of software-as-a-service applications is shadow IT on steroids. Take the case of the chief information security officer of an insurance company who enlisted security expert Jayson Ferron to help with an operating system migration. Ferron, CISO/CEO of Interactive Security Training, asked the client CISO, “Do you use the cloud? And he said, ‘Absolutely not; we’re an insurance company, we don’t trust the cloud.’ Come to find out, there were 50,000 users using Salesforce.com that the CISO didn’t know about because the business was expensing it.”
Indeed, it’s so easy to sign up for a SaaS application that “your employees now have the power of SaaS in their hands,” agrees Jerald Dawkins, CTO of Cerberus Sentinel, an MSSP headquartered in Scottsdale, Ariz. And if it’s a free service, they don’t even need to get permission from accounting, he adds. The problem? “They’re pushing corporate data to this free service on a vendor that you don’t know about, a service that you don’t know about.”
Jayson Ferron
According to research from security vendor Axonius focused on SaaS usage, 74% of businesses have more than half of their applications in the cloud, and 66% are spending more on SaaS applications now than a year ago. However, most organizations said SaaS security lagged in urgency and priority. Of those surveyed, 60% ranked SaaS security fourth or lower on their list of current security priorities, pointing to limited time and resources (28%), pressure to focus on other issues from the C-Suite (23%), and staffing shortages (15%).
Securing SaaS applications is “a different beast” for MSPs accustomed to securing networks and endpoints, says Lawrence Cruciana, president of Corporate Information Technologies, an MSP in Charlotte, N.C. According to a recent ChannelPro reader survey, roughly half (48%) of respondents believe that securing SaaS applications is more difficult than securing the network and endpoints. Moreover, in the Axonius research, 66% of organizations agreed that the increase in SaaS applications has resulted in more complexity and increased security risk in their organizations.
“The inherent nature of those platforms [is] they’re always on, always connected, always [in an] exposed state,” Cruciana explains. While SaaS brings great business value, he says, it also brings “equally great areas of exposure. In many instances, the MSP isn’t always in control of the introduction of new features or new products or new configuration items, or even the default configuration.”
A Shift in Focus
Andras Cser, vice president and principal analyst at Forrester, points to four main challenges with SaaS security:
- Constant change in SaaS platforms’ capabilities and consequently security policy setup
- Varying, complex definitions of zero trust/least privilege across SaaS platforms
- The breadth of SaaS offerings
- Ties to data that mix SaaS security with data protection
While the fundamentals of the MSP’s job remain the same—working with the right vendor, securing the data, configuring the platform, and managing and supporting the customer’s environment—SaaS security is a shift in focus, Dawkins says. “It changes the conversation from being one that’s very technical, and talking about hardware and perimeter security, and [turns] it to being one of risk management.” That encompasses vendor management to ensure they have the proper cybersecurity controls to protect your customer’s data.
In addition, each SaaS application has its own release and update cadence, maintenance cycles, and notification mechanisms, Cruciana says. “That by itself is one of the core differences … you’re not in control. Generally, those platforms move at the pace of the SaaS providers’ release schedule, and I’ve yet to find any of them that are in sync with a customer’s rate of change and change adoption.”
Whose Responsibility Is It, Anyway?
Cruciana urges MSPs to define and document the roles and responsibilities in their organization, such as “who’s responsible for the technical administration of the product, who’s responsible for the security configuration of the product, who’s responsible to keep up with all of those new features?”
Knowing what the SaaS vendor is responsible for matters too. Securing SaaS applications is a shared responsibility among the SaaS provider, the MSP, and the customer, explains Dawkins. “There’s a new emerging trend with SaaS providers and cloud providers, and Microsoft is a great example. Microsoft has what they call a shared responsibility matrix.”
Jerald Dawkins
The matrix outlines what the SaaS or cloud provider is responsible for, which is primarily uptime and security of the host infrastructure, and what the customer is responsible for, such as information and data integrity, identity and access, and platform and resource configuration. “I think what’s eye opening to me and to MSPs alike is the number of items that are in the shared column and that aren’t Microsoft’s responsibility,” Dawkins says.
As a result, he adds, MSPs need to review each provider’s responsibility matrix and manage that for their clients. They must also articulate the division of responsibilities between them and the client, noting “what you’re taking on and what you honestly can’t take on just because the client ultimately has to be responsible for their data.”
Spelling this out clearly is important, because not every client understands it yet. “Surely if they’re buying that cloud product through the MSP, that customer absolutely expects the MSP has their back and is doing everything in their power to secure the organization,” Cruciana says.
That means taking the time to learn all the nuances of the SaaS app, especially the security controls, he stresses. “I think the major players, Microsoft, Salesforce, AWS to a point, Google, those big players, they’ve done such an incredible job of making education available. I think that’s one of the inherent values of their product.” However, he notes, “I think the uptake of that information varies considerably between organizations. [MSPs] have to take the initiative on their own to learn the product, to ask the questions, to really reach out and engage that SaaS provider.”
Many MSPs, Cruciana says, may think they’re protected because they’re paying for the security tools the provider offers, but the burden is on the MSP to configure the tools. For example, Dawkins points out, “Microsoft and all these SaaS providers give you the ability to have role-based access control … but at the end of the day you’re the one that has to implement those controls.” They’re typically not turned on by default, he explains.
In addition, Ferron encourages MSPs to talk with the SaaS vendor and explore their website to really understand the security risks. “What’s the service level agreements that are available for them? What kind of additional controls can they add to protect their data? How do they back up the data, and can you verify that it’s backed up? Who has access to the data? Can they encrypt the data using their keys on the vendor side?”
MSPs and their customers need to understand what’s being stored in SaaS solutions as well, Ferron continues. “Do you have a data leak protection policy where you’re looking at what data is leaving your organization and where it’s going?”
Another key issue for MSPs to consider, especially if they have global clients, is data locality, which makes a big difference from a compliance perspective, especially in regulated technology spaces. “So, there’s cloud providers, but where physically are they in the world? And where is this data?” asks Dawkins, who encourages all MSPs to familiarize themselves with the National Institute of Standards and Technology’s Guidelines on Security and Privacy in Public Cloud Computing (NIST SP 800-144).
“That’s one thing that I would definitely pull up and review and have a good understanding of,” he says.
Best Practices
How to move or get rid of data, versus its location, is something Cruciana likes to think through from the very beginning. “I’m understanding at the point of deployment what is the approved process, both internally in the SaaS and with the customer, and then correspondingly, what the documented process is with the SaaS provider to dispose of or remove data from the SaaS platform.”
Lawrence Cruciana
Understanding the provider’s data retention requirements and if those differ from any regulatory requirements the customer may have is also important, as is determining and documenting who is responsible for onboarding a new user or a change in roles or access levels and decommissioning a user.
“Very often that’s the MSP’s responsibility, but to the customer, and I think this is especially true in the SMB space, they just kind of presume that you [the MSP] know that Jenny in accounting got married and has a new last name or that Bob over in finance is no longer with the company,” Cruciana notes.
In general, he adds, applying the principle of least privilege is advisable. “Justify everyone’s access,” he says.
For his part, Ferron recommends having users connect to the business’s VPN and a federated ID management system with their credentials to access the third-party SaaS application. “The user doesn’t get a credential to that third-party source. We manage the process, the authentication, between the user and the third-party source.”
Decommissioning Users
Dawkins adds that identity access management, multifactor authentication, and single sign on “are all critical to ensure that you’re commissioning and decommissioning your user base appropriately.” Removing a SaaS user is not like the old days of Active Directory when you could disable a user from the entire network, he says. Now you may be decommissioning somebody from Microsoft 365, but did you decommission them from Salesforce too?
And what became of their data? “User offboarding involves saving and transitioning data to a manager for safekeeping,” says Cser. “Offboarding a user is mainly deactivating the user in the authentication data source. When offboarding a SaaS app, organizations should remove it from the federated identity framework’s Relying Parties and ‘sanitize’ (backup then remove data from) the decommissioned SaaS app.”
That’s why the process for decommissioning a user from a third-party app should be documented, Ferron says. When disabling the entire company or moving from one SaaS app to another, the question becomes how do you get your data out? That’s a critical topic to discuss with each of your cloud vendors. “I typically like to have that conversation up front,” Ferron says.
The Toolbox
There are a variety of tools available to help manage SaaS security. According to Cser, organizations are starting to look at SaaS security posture management (SSPM) tools like AppOmni and BetterCloud, for example, along with cloud access security brokers (CASB), DLP, email security, and mobility management solutions.
According to a recent ChannelPro reader survey, the top solution respondents are using is identity and access management (60%), followed by vulnerability monitoring and testing (48%), continuous discovery, monitoring, and decommissioning (35%), and CASB (14%).
There are free tools as well, Cruciana says, which can be found in the major providers’ security portals. “For Office 365, as an example, Microsoft has PowerShell-based tools that will allow you to reach into your environments and compare these security configurations against known exploited attack vectors.”
Microsoft also has CASB tools, according to Dawkins, but there’s a caveat. “You have to implement them and enable them and engage them, and that’s part of that configuration side,” he says. “That’s part of that shared responsibility, the work that MSPs need to do.”
No matter what tools they use, Cruciana says, MSPs need to follow a security framework, what he calls a North Star. “If you don’t have a configuration guidance, a security baseline, I think all those tools are pretty well useless.”
Work to Do
The fine art of securing SaaS apps is currently a work in progress. “I think there are a limited number of individuals who have started to recognize the issue and we’re starting to work towards it, but for the most part, I think [channel pros are] still in the elementary concepts of securing infrastructure, securing endpoints, securing data on-prem and not thinking about the rest of the picture, especially when you start adding third-party solutions,” Ferron says.
Cruciana agrees. “As a channel, I think we have a lot of education still to do, and frankly, we have to be able to do it ourselves.” That starts with implementing detection controls and then auditing “what’s happening on the endpoints so that we can see those things, control those things, and really begin to increase the level of enforcement, so that information flows only through authorized channels.”
No doubt this is a complex space, sums up Dawkins. “While there were some things that were greatly eased because of SaaS, it greatly exacerbated some other challenges and problems.” It’s a situation that calls to mind one his favorite sayings: “The more you know, the more you realize you don’t know.”
