I was asked by a colleague to put together some notes on the importance of protecting SaaS solutions ala traditional backups. Me, being the long winded person I am, ended up putting together this piece. As I took a closer look at SaaS the more I realized the availability and security of your data is entirely at the whim of your service provider. That raises some interesting questions, such as what happens to your business if the data is unretrievable? Who’s legally responsible when data is exposed? Even if you’re not legally responsible, who will your users direct their ire at? I suppose it’s something I always knew. Join me as I muddle through, trying to determine whether the simplicity of SaaS is worth some of the tradeoffs. Spoiler alert, I can’t answer that for you.
What is SaaS?
I’ve performed a cardinal sin by using an acronym several times without explaining what it is. Software-as-a-Service, SaaS. Instead of running software how you would normally… provisioning an environment, downloading it, installing it, managing it, etc., SaaS is just getting direct software access from the provider.
There’s also IaaS, Infrastructure-as-a-Service, and PaaS, Platform-as-a-Service, which are similar concepts but have different areas of responsibility. Check out this handy chart…
As you move from traditional on-premises deployed software, up to SaaS, the management responsibilities that go into running said software move further unto the provider’s realm.
Email is one of the most common SaaS use cases for enterprises and individuals alike. In the early days folks used to spin up their own email servers, but as it grew in popularity and importance it became a free feature offered like ISPs like AOL and Yahoo. I recall my local ISP promoting the number of mailboxes you got per package. Enterprise organizations continued to run on-premises Exchange for a long while before Office 365 came in, took the traditional infrastructure, and put it into a business-friendly consumable SaaS package. Gone was the need to deploy load balancers, mail servers, patch them on the regular, back them up, etc. (will touch on backup later).
SaaS has grown to be one of, if not, the largest methods of software consumption. In addition to all things mail, ERP/ERM solutions have shifted to SaaS such Microsoft Dynamics 365, SalesForce, Jira, and Ellucian. If you use any Oracle software, there’s a good chance they have a SaaS solution for it and that’s the way Oracle wants you to consume. It goes on and on… most modern payroll systems, project management, and quite a few security solutions.
Why SaaS?
I briefly mentioned this earlier but two of the key reasons for a SaaS implementation are the shift in operational responsibility and licensing flexibility.
Licensing isn’t a key component of this discussion but is worth mentioning. Having a SaaS solution allows solution providers to charge on a by-individual basis the most efficient way possible. Per-seat licensing has been around forever, but now those licenses can easily be tracked by active user account. No need to spend money on buffer seats, or have to worry about someone coming in and doing an audit. You can also scale those licenses to feature different tool sets on the fly without having to wait for a customer’s traditional license lifecycle to come back around. Just gotta watch because scaling down licenses often come with hidden fees or conditions.
The biggest benefit to SaaS is the ease of consumption. You no longer need to worry about maintaining a data center, provisioning servers, deploying operating systems, building network infrastructure, buying a bunch of storage capacity, validating that all those work together, patching for security updates etc etc etc. It’s as close to plug-and-play as things get.
All of that is now on someone else’s shoulders. Your users just log into a web or local client (ala Outlook) and consume services directly. Administrators are relegated to more mundane elements like making sure the service feature functionality is enabled.
Shared Responsibility
Something you may have heard in the cloud provider space is also prevalent when it comes to SaaS providers: The shared Responsibility Model. Essentially what this is saying is that the SaaS provider is responsible for some components of the solution stack, and the customer others.
Who is responsible for what will vary depending on the solution. Not only are the SaaS providers deploying and maintaining the software on a day-to-day basis, but they’re typically responsible for securing the solution and maintaining system availability.
Security responsibilities typically run the gambit from event logging, to encryption, to patching, and even physical access to the facilities where these systems operate. End point access, such as MFA, will vary. Some providers charge extra for basic security like SSO for MFA (see The SSO Wall of Shame). MFA is a hard requirement for security, the recent exposures from Snowflake speak to that.
Another area where I see variations surround data backup. For example with Atlassian (the folks behind Jira and Confluence) that responsibility falls on the organization, providing tools to do so. For Ellucian (the folks behind Banner, the ERP system powering nearly every higher education organization I’ve worked with) that’s something that falls under their responsibility per their Shared Responsibility Matrix, but takes on more complexity when you read some of the details…
Ellucian will conduct regular backup of Client Data. Backups will adhere to Ellucian’s internal backup controls. Ellucian will not be responsible for the accuracy of Client Data but will only be responsible for appropriately backing up the Client Data contained in the Cloud Software. Client may request copies of database backups for archival purposes. Upon such request, Ellucian will make a copy of the database available to Client for secure download monthly. Each database backup made available in this manner will replace the previously available file. It will be the Client’s responsibility to retrieve those files in a timely manner. via Ellucian Cloud Software Standards
Office 365 is yet another interesting use case. As far as I can tell Microsoft has no official shared responsibility details for O365 specifically (you could infer responsibilities from the Azure documentation, but not having anything specific to O365 is just an opening for a lawyer to start a sentence with “But actually”). Instead every backup provider will tell you that it’s up to the customer to backup the data to prevent data loss. In this case Microsoft provides API access to make the process super smooth.
As someone who’s been in the backup space for many years now, not having a complete understanding of how your SaaS data is protected and restored is a red flag. The fact that you don’t need to backup the underlying servers does not remove your obligation to your company’s data.
Uptime responsibilities tend to vary greatly. Speaking of Microsoft, they provide a public list of SLAs for their various products and provide service credits for outages (for example, Microsoft Teams, anything less than 95% uptime gets you a 100% service credit). SalesForce does not make any public claims and SLA guarantees seem to be on a per-contract basis.
Shit, Meet Fan
Now we’re at the point where I get to play Devil’s Advocate to the benefits of SaaS. What happens when some part of this fails?
Traditional outages are pretty straight forward. If you have service credits, at least you can take solace in getting some funds back. But how does that compare to the cost of loss business productivity? I can’t help but think of the one-in-a-million type events which happen as well, such as when Google Cloud accidentally deleted a customer’s account all together.
The real can of worms is a cyber security failure. As I write this CDK Global – a provider of software services thousands of car dealerships use to schedule services, track inventory, and invoicing – remains down after a reported ransomware attack. I’m not familiar with CDK, and all the current scuttlebutt is negative, but I haven’t seen any info on how they do shared responsibilities or SLAs.
While dealerships are back to using pen and paper for transactions, let’s assume it’s worse than your typical attack. What happens if the backups don’t exist or are also encrypted? What happens if the data is exfiltrated and client information is sold off?
These are a whole bunch of hypotheticals here but I think they need to be discussed and understood within your organization. Thing is, the same applies when you run your own environment, you just have a third party in the room.
Even more hypotheticals
While poking at this I also started to wonder about what sort of security and compliance documentation/certifications SaaS providers have. Top providers like Salesforce have a ton of public information from SOC reports, to NIST attestments, and even third-party vulnerability/penetration assessments. Comparatively I don’t see any publicly posted certifications from the aforementioned CDK Global.
Another hot topic is if/how those SaaS providers might be using your data. Most of the big providers outright say they won’t sell your data. But now that AI/ML is so popular, what about using it to train models? Adobe recently had a publicity crisis after some very vague language made it into their T&Cs about using customer’s data to improve Adobe’s machine learning services and software. They have since clarified but the damage done, fears and existing sentiment stoked. Fact is, there’s money to be made from data, and it wouldn’t take much for a SaaS provider to risk alienating their install base for a quick cash grab.
I also heard some chat about SaaS solutions being a bigger target. There’s some merit to that. If you’re a leading provider with sensitive data you’ve got a bigger target on your back than an individual organization who might be consuming those services. Who’s got more of an incentive to pay a ransom than an organization with thousands of customers? There’s an upside to this however. In theory your SaaS provider should be better prepared to run and maintain an environment, protecting it, than said smaller organization might be. Would you rather pay for and maintain SOC/NIST/etc compliance, or offload that as well?
Third-party risk management; if a company is relying more and more on outside parties in order to conduct business or to protect their business, the 3rd party partner becomes an increasingly significant element of the Threat Model. “Security Scorecard” and “Bitsight” are one way companies assess the risk of 3rd party partnerships. – Alec Karry
Your Homework
After all this rambling, what’s the key takeaway? Like any other technology solution you need to review the pros/cons of every SaaS application. It might not be your application, but it’s still an application that has your data. I personally use various SaaS services, but I also use local services where more appropriate. Use cases will vary, and a provider’s services will vary as well, so here’s a quick summary on what to research before making a decision…
- Thoroughly understand any shared responsibilities
- Read their security and compliance information
- Do they have appropriate security validations and auditing?
- Read their SLA/your contract
- Are there service credits? How do they work?
- Do they make separate distinctions between planned and unexpected outages?
- How would a SLA violation impact your business? Can you provide a better SLA using internal resources?
- How is the data being protected (consistency/backups/replication/etc)?
- Does their data retention meet your compliance requirements?
- Do you need any additional tools or policies to backup data?
- What does a restoration workflow look like?
- Do they nickel and dime you for security features?
- I have more respect when they at least pretend the TruCoat is free of cost.
Hopefully that information can help you make an assessment as to whether a SaaS solution will meet your needs.
Additional Resources
Publication History
- June 26, 2024 – Initial Publication
- June 27, 2024 – Minor proofreading