Declaring a truce on SaaS security
Break out of the prisoner's dilemma.
All other things being equal, Software-as-a-Service (SaaS) is more secure than a customer-managed version of the same software. That’s because:
Fixing vulnerabilities in a product you develop and test is always going to be faster than providing a patch to an external party who has to then apply, test, and deploy it.
There is simply no way for an external organization to apply a patch faster than the software provider itself due to the transaction costs involved (making the patch available, documenting the changes, answering questions, etc.).
Because days, hours, and even minutes matter when it comes to remediating known vulnerabilities, these transactions costs are extremely expensive from a security perspective.
Due to the same transaction costs, even if an organization cannot fix a vulnerability in its software immediately, it can apply compensating controls (changing a firewall rule, etc.) faster to its own environment than can an external party running the same product.
Finally, for the most part, an organization that builds something is going to have a far better idea of how to monitor it than some outsider. Anomaly detection and threat hunting is going to be easier if you are observing something you built rather than something someone else developed.
According to Gartner (although it’s not completely clear how they arrived at this statistic), through 2025, 99% of cloud security failures will be due to customer - rather than vendor - mistakes. This means the vast majority of such failures will be due to security misconfigurations rather than software vulnerabilities.
While some have noted these misconfigurations often result from design flaws in the cloud-based products themselves, I haven’t seen any evidence that they have more design flaws than customer-managed ones. So you are going to need to tackle this problem irrespective of deployment model.
And none of the above even reflects the fact that SaaS is generally a far preferable method from a business perspective both for the buyer to consume and the vendor to provide. A SaaS model offloads onerous information technology (IT) tasks to a specialist (the vendor) and allows the customer to focus on where it has a competitive advantage (i.e. whatever its main line of business is).
There certainly are use cases that require customer-managed software, such in air-gapped networks or situations that require specific data residency. But these are few and far between.
The prisoner’s dilemma of SaaS security
Unfortunately, many security teams behave as if the above were not the case. They tend to apply far more scrutiny to SaaS than they do to products their organization manages itself. I am not sure exactly why, but think it is the result of some odd combination of them being:
Concerned about job security if ever more IT-related tasks are outsourced. While logical from the individual level, from the organizational perspective this is not a valid concern (although one needs to account for it when designing a strategy). It is more in the realm of internal politics than security, so I won’t address it in detail.
More suspicious of things that are harder to observe directly. Whether or not it is a real phenomenon (open to debate), some people implicitly or explicitly believe in the Hawthorne effect, which suggests that others modify their behavior when they know they are under observation. More importantly, knowing about a security problem is a prerequisite to doing something about it, so wanting to know as much about a vendor’s product and its operations is logical.
This dynamic creates an odd and counterproductive game theoretical situation where:
Customer security teams make it harder for their organization to consume SaaS.
Due to fears about customer overreaction (often unwarranted), vendor teams are not as transparent as they could be about security issues and considerations, exacerbating the problem.
Vendors are hesitant to transition fully to SaaS due to customer security concerns.
For organization that offer both SaaS and customer-managed versions, this has the even worse effect of diverting resources away from SaaS security toward maintaining the “legacy” product, perversely, in the name of security.
SaaS nonetheless remains the superior model for both organizations.
This situation is reminiscent of the classic prisoner’s dilemma where two criminals arrested by the police would benefit most if they collaborated with each other but have strong incentives to defect due to the uncertainty of the other party’s behavior.
Calling a truce
The good news is that, unlike the prisoners, vendors and customers can communicate. So there is a way out of this conundrum, which I describe as a “truce.” While obviously there is more to it, I suggest the following good-faith measures to help catalyze such a move.
What customers should do
Analyze the downsides of hosting products themselves and weigh these against the benefits to increased knowledge of the software and its operation. Include technical demands on the vendor to maintain both SaaS and non-SaaS models as part of this calculus.
Focus on appropriate technical due diligence, like penetration testing and external network scans, over security theatre like questionnaires.
Implement logical but not expansive vulnerability disclosure requirements in contracts.
What vendors should do
Maximize transparency through detailed shared security models documenting exactly what responsibilities are those of the vendor and what are those of the customer.
Proactively disclose vulnerabilities and security incidents to the maximum extent possible, only withholding information if it could allow for malicious attack.
Embrace participation in vendor bug bounty arrangements (e.g. Dropbox’s program).
Provide SaaS software bills of material (SaaSBOM) for customer inspection.
Offer data residency guarantees that contractually and transparently provide data location information in accessible formats (such as a SaaSBOM).
For both customers and vendors, SaaS is usually the more secure deployment method.
Despite this, many organizations behave as if the opposite were true. There is an understandable hesitance on the part of organizations to rely on technologies they can not directly observe or control. Unfortunately, in the big picture, this hesitance is to their detriment.
By small, cooperative steps, both parties can arrive at a better equilibrium.
Worried about making the right deployment choices?
As imperfect as things are now, there are still decisions to make.
Especially with the explosion of AI tools of all different varieties and architectures, companies are finding it harder and harder to make the right calls when it comes to:
Cybersecurity
Compliance
Privacy
Need help?