The industry is hurtling towards the SaaSification of everything, but what does this mean for customers and vendors alike? This in-depth post explores the complex landscape of SaaS, highlighting both its promises and costs, especially in areas like security and autonomy. Through real examples and historical security failures, we suggest a more critical approach to embracing the SaaS model.
There is an industry trend toward the SaaSification of everything. Everywhere you look, customers are exchanging agency over their information and systems in the pursuit of going faster, with the hope of investing less time and energy. In many cases, this trend is leaving customers with no choice but to turn to SaaS for best of breed software.
This is a Faustian bargain, with security giving way to convenience.
These objectives need not be mutually exclusive, particularly as businesses embrace zero trust principles to secure themselves against today’s threat landscape. To understand the forces acting on customers and vendors alike, let’s consider the benefits and costs of the SaaS bargain.
For customers in search of solutions to pressing business problems, software delivered over the Internet promises to shorten time to value. In this model, no customer infrastructure is required, other than an email address and credit card number. For organizations tight on time and resources, or who in some cases have no capacity to deploy or maintain infrastructure, exchanging their information and access to their systems for the promise of going faster with less effort is difficult to pass up. This is particularly true where vendors promise to handle customer information with care, bolstered with certifications and audits, making infrastructure and security someone else’s problem.
For vendors looking to grow quickly at the least cost, centralizing products into a SaaS delivery model addresses operational and technical issues. Operationally, the incremental cost of adding customers is typically low. By collecting multiple customers' data into a single system, vendors may achieve attractive economies of scale. On the technical side, vendors operating a singular system under their control gain the ability to ensure a consistent data model. Without having to distribute data structures across customer infrastructure, architecture and implementation is straightforward. Related to this, vendors operating one implementation of their software have less to maintain, without the challenge of distributing changes to customers and ensuring their timely application. Most often, SaaS vendors deploy changes to their applications with little to no customer involvement. Customers may receive advance notice for new releases in terms of UI or feature changes, but seldom control schedules. It’s the vendor’s show, and other than the sole power to eventually discontinue service, customers are along for the ride.
The benefits of the SaaS bargain garner most of the attention, but there are real and pointed costs which are more often glossed over. Significant among these costs are compromises in the closely coupled areas of autonomy and security.
Autonomy is an organization’s absolute control over its information assets, encompassing the ability to access, manipulate, and dispose of that information free from external restrictions. Autonomy is challenged when customer information and processes are placed in systems controlled by vendors, resulting in technical and practical limitations to free movement and migration of information, commonly known as vendor lock-in. Depending on the degree of lock-in, organizations looking for new service providers may face enormous difficulty in retrieving their information, or may not be able to do so at all, before being forced into renewal or needing to maintain a system in perpetuity. In the consumer space, data protection regulations are working to reduce lock-in and recognize the data sovereignty of the individual. This has pushed large providers to create data export systems in usable forms, to create meaningful data choices, and to make exercising those choices tangible. This type of data-sovereignty-by-default is less prevalent for business actors, and is left instead to the domain of negotiated terms, placing the onus on the customer (caveat emptor).
System availability is also the subject of negotiation. Customers are expected to be sophisticated in their consumption choices and obtain service level agreements with contract remedies for failures. These damages are intended to incentivize vendor investments in availability and to offset customer losses from failures after the fact, but the practical consequences of outages remain. In April 2022, several hundred customers faced these practical consequences when Atlassian suffered a two week outage of their cloud products. Pursuing the SaaS bargain, Atlassian has been pushing customers to their cloud-managed products, eliminating the most accessible tier of their customer-managed solutions. During the outage, over 700 businesses that were solely reliant on Atlassian’s cloud came to a full stop, with significant open questions as to time to restoration and data integrity issues for the duration of the incident. Outages occur in every system, but when we design systems such that customers have no autonomy over their own information, we create scenarios where business critical processes and information can become inaccessible at a moment's notice, with no hope for customer-driven restoration. Service level commitments and contractual promises fall in the face of practical availability, and no business should operate with this potential for failure.
A particularly troubling ramification of the SaaS bargain is the question of customer data privacy. When customers entrust their information to vendor systems, vendors obtain access to that customer information. Again, contractual obligations and security certifications are intended to limit and contain this access; but, by the time we reach for these protections, the damage is done. In order to serve their customers, vendor employees must work with customer information. The often disjointed nature of organizations, with teams pursuing evolving and occasionally conflicting goals, coupled with inevitable turnover, results in shifting personal and business perceptions about what vendors may do with customer information. Unless strong, independently validated technical means are deployed to secure customer information held by third parties – such as models where customers manage their own encryption keys – it is foolish to believe that vendors are not reviewing customer data for every advantage that information may afford the business in its own growth ambitions. If vendors have access to customer data for business purposes, so do individual employees attempting to further those purposes, and so do outside parties who obtain access to vendor systems, either as the result of legal process or as a consequence of security failures.
Speaking of security failures, when the information of many organizations is consolidated into centralized systems, those systems become the brightest targets for those seeking that information. Rather than needing to target organizations directly, and circumventing whatever security defenses those organizations have at an individual level, attackers who successfully compromise SaaS vendors can reap the information of hundreds or thousands of customers in a single act. This happens regularly, and we are likely to hear more about such incidents in the near future. The belief is that vendors carrying the burden of operating systems on behalf of customers are more capable of protecting those systems than customers are. However, this model nearly always transitions the entire responsibility and observability of security to the vendor, leaving customers with no ability whatsoever to expand their defenses or directly influence their own incident response.
Perhaps the most significant example of this came in 2011 when RSA, the company responsible for the gray SecurID keyfobs used for two factor authentication by everyone from banks to governments, was hacked. In trusting a single organization with the secret material for these keyfobs, the successful hack cascaded across industries, exposing some of the most sensitive information in existence at the time.
And we seem to not have learned our lessons:
Very much like the RSA hack of 2011, centralizing the critical information and systems of thousands to millions of customers into the hands of a few vendors makes those vendors high value targets with devastating consequences for customers relying upon them when failures inevitably occur.
The weight organizations should place on the cost side of the SaaS bargain will vary in proportion to the nature and sensitivity of their workloads. There are workloads where the model of bringing customer data to vendor systems makes the most sense, such as services which by their nature require large, distributed, and ongoing capital investments. Examples of this include content distribution networks and infrastructure as a service.
But as products reach further into organizations, such as those underpinning the embrace of zero trust access solutions, we must closely examine the suitability of the SaaS model and the wisdom of trusting vendors who encourage zero trust practices, but require customers to trust them in order to achieve it.
In a zero trust based system, access to enterprise resources is denied by default, and permitted only when each user, device, and service is authenticated and authorized to communicate. Zero trust approaches dispose of the perimeter security and access model, instead conditioning data flows on principles of least privilege and micro-segmentation. The systems which implement zero trust access are exceptionally sensitive, serving as the primary means by which network flows and information access is achieved. As such, customers must carefully evaluate how they implement zero trust solutions, paying particular attention to architecture choices and the cost side of the SaaS bargain.
More simply: customers must question who and what they are trusting with their most crucial systems.
We started Bowtie with the firm belief that secure network access is the first and most important element of any organization’s technical operations, and that yesterday’s networks are failing us. The answer to these legacy problems is the full embrace of zero trust principles in every aspect of business operations, starting with secure access. Given the foundational aspects of network access, we set out to build Bowtie with all the benefits of the SaaS bargain, but without its costs.
Bowtie deploys into existing customer environments, whether they be in public clouds, private clouds, data centers, or physical facilities, with no more complexity than competing vendor-operated access solutions, and without the centralization risk. Leveraging the principles of Local-first Software, Bowtie utilizes an advanced data layer in our distributed control plane which looks and feels like a centrally managed SaaS solution, but operates entirely under customer control, with no elements of our solution reaching back into Bowtie systems or depending on our availability to function correctly. With software packaging focused on effortless updates, Bowtie offers customers the benefits of a SaaS-managed experience.
But Bowtie goes further than ease of setup and ease of maintenance: Bowtie’s Local-first strategy enables outcomes that can’t be achieved when depending on vendor availability, or when sending all of your data to a vendor’s network. By deploying locally, Bowtie runs as close to users and resources as possible. With no vendor-run network to connect to first, we shorten network paths and help our customers go as fast as possible. Also, because we have no possibility of receiving customer data flows, either at the data plane or at the control plane (in the form of customer access tokens or encryption keys), customer privacy is never at risk. We simply cannot view any customer data, because we never collect or process it. And we cannot let ourselves into your network, because we have no access to it. In the zero trust access space, this should be the rule, not the exception.
As you start your zero trust journey, or if you’ve already started but are uncomfortable with trusting vendors to run your network, chose both security and convenience: try Bowtie today.
William is co-founder and CEO of Bowtie. Prior to founding Bowtie, William spent his career leading IT, Security, and Law at organizations such as Planet and NASA.
Subscribe to our newsletter to get the latest news, features, and updates from us.
.png)
