Software As a Service

For many of us, Software as a Service (SaaS) is where the cloud became something new, not just someone else’s computer. It is a model in which a service provider hosts one or more applications and makes them available to users on a subscription basis, often from a cloud-hosted location (or locations). This is a paradigm shift from the older, commercial off-the-shelf (COTS) approach, where software is bought on a perpetual license, installed and run locally by the organization themselves. The only similarity of COTS with a cloud-based service is the support and maintenance contract that supplies ongoing updates, upgrades, and break/fix support for running the software.

SaaS should not be confused with software licensed on a subscription basis but hosted by the purchaser, whether within their own infrastructure or in a rented third-party infrastructure. The applications provided via SaaS are commonly, but not exclusively, accessed using web browsers, though they can also be service-based to host distributed technology, like agents on end-user assets without the need for VPN or similar technologies.

Plus many, many more (The services and organizations listed are examples and not in any way endorsed by the authors).

Nearly all enterprise-level companies use SaaS solutions, and most use more than one, with some using thousands. For example, a medium-sized company like our employer, BeyondTrust, who has fully embraced the cloud, uses hundreds of SaaS applications spread across the entire business. That sounds like a lot until you look at the McAfee 2019 Cloud Adoption and Risk Report,¹ which gives the average number of distinct cloud services used by organizations as 1,935. That’s nearly 2,000 services, on average, in use by every organization surveyed – the average IT team believed the number was closer to 30.

Selecting the right SaaS vendor to solve each business need has deep roots in cost and potential cloud attack vectors. A pretty user interface or cool, unique technology certainly shouldn’t be primary considerations. The focus should be on providing solid foundations, creating reliable and resilient implementations, and solving real business needs, underpinned by good value for money and transparent cybersecurity practices.

Some definitions and business requirements for SaaS also include the notion that the solution is multitenant, that is, a single implementation of the solution is used to provide service for many customers, while maintaining segregation between each customer for operations and their data. This is illustrated in Figure 2-1. (Note: This will be explored in more detail later in the book.)

A schematic diagram of the range of responsibilities for software as a service. The parameters are the User, Cloud Service, and Cloud Provider. Application is highlighted under Cloud Service.

Irrespective of tenancy model, licensing a SaaS application is arguably the most secure of the service provisions because the application (not necessarily the infrastructure) is entirely under the control of the SaaS provider. That said, poor password choices and misconfigured permissions can still lead to significant risks. The top attack vector for most SaaS-based solutions is a credential compromise, either at the user interface or an underlying API used for integrations or automation.

For example, APIs tend not to lock accounts when incorrect credentials or secrets are provided. Doing so would become a denial-of-service opportunity for threat actors to lock out services with multiple, deliberately incorrect, login attempts. This can be mitigated with ever-increasing delays in the response to bad credentials, offering some defense against brute-force and dictionary attacks, but such mechanisms shouldn’t be relied upon as an exclusive defensive strategy. It does provide one illustration of why privileged accounts in this space should be managed with a commercial privileged account and session management (PASM) solution that automates the creation of long, random, complex passwords to mitigate this attack vector. This will be discussed in detail later in this book. For now, rest assured that password attacks and password management will remain a fundamental part of your security model.

Platform As a Service

Platform as a Service (PaaS) takes the service provision down a technology layer below SaaS. Rather than the entire technology stack needed to deliver a software solution, PaaS delivers the platform on which the solution (typically an application) executes. This has, historically, been the provision of a managed server (or servers) where the service provider builds, provisions, and manages the operation of the server(s) using a management and sustainment model. Users of the PaaS then build or install their applications on the platform and manage only the applications themselves, taking a significant portion of the effort and complexity involved off their shoulders and onto the PaaS service provider. More recently, PaaS has expanded to include container-based platforms and other serverless environments that host applications without excessive overhead. This is slightly different than Function as a Service, covered a little later.

Unfortunately, this is one of the scenarios where responsibility for security has become a potential source of contention. While the service provider manages the platform, the security of the platform, depending on application requirements, remains (unless explicitly indicated in the service contract) with the service user. Consider the two approaches in Figures 2-2 and 2-3.

A schematic diagram of the range of responsibilities for software as a service. The parameters are the User, Cloud Service, and Cloud Provider. Application is picked, and Operating is highlighted under Cloud Service.

A schematic diagram of the range of responsibilities for software as a service. The parameters are the User, Container Service, Cloud Service, and Cloud Provider. Container and Other Customer's Container are picked, and Other Customer's Container is highlighted under Container Service.

Like SaaS solutions, PaaS is at risk from credential theft. Unlike SaaS, it is most at risk for un-remediated vulnerabilities or poor configuration management in the hosted application or the container management system. The risk for vulnerabilities in PaaS needs to be clearly defined when implementing a solution since multiple organizations and departments will ultimately share the responsibility of keeping it secure and prioritizing risk.

Having the application in the cloud and potentially directly exposed to the Internet will cause it to be subjected to continual probing and attacks. Therefore, it is vitally important that the application and container libraries, etc., are assessed for potential vulnerabilities by all stakeholders, remediated promptly, and tracked by service-level agreements (SLAs) to measure the outcome of your security posture.

Infrastructure As a Service

As we continue down the layers of services, we reach Infrastructure as a Service (IaaS). IaaS offers online services accessed via APIs that allow the service user to provision infrastructure systems, such as virtual machines, storage (block, file, object), network infrastructure (firewalls, load balancers), and even to configure VLANs (Virtual Local Area Networks) to segregate traffic among their IaaS components. This concept provides a vital lesson in how the more things change, the more they actually stay the same. The technology we are familiar with on-premise has been implemented in the cloud, and the primary control point for automation is based on APIs.

Consider how this is implemented in Figure 2-4.

A schematic diagram of the range of responsibilities for software as a service. For the user to Own Manage Maintain the application, Manage maintain the operating system, and use the virtual hardware under the cloud service.

In this service provision, the users don’t manage the cloud infrastructure itself, but they do manage all the IaaS-provisioned systems that run on top of it.

It’s important to be aware of the scope of responsibility you, as the user, have for each of the IaaS provisions you are using. If we start with what might commonly be called infrastructure, that is, network devices, you may have control over the configuration of those devices. You may be able to change the rules on a firewall or router, but you probably won’t have control over the lowest levels of the devices themselves. This makes you more of a standard user than an administrator, in terms of privileges. Similarly, with virtual machines, you will probably have control over the entire operating system running on the VM and the maintenance of it, but no access to the underlying hypervisor or the virtual hardware configuration.

As you can see, for each IaaS provision, it’s important to understand what you control and what the service provider is managing because this is the demarcation point for security responsibility. No one is going to take responsibility for the security of a system when the user can compromise that security through their legitimate access and controls. Don’t assume the service provider is doing something; verify it and ensure it is documented that way – this will save a lot of time in the long run.

Where you have full responsibility for the updating and patching of an IaaS service provision, it is important to support it just as you would any on-premises system that is directly connected to the Internet. Otherwise, threat actors will find and exploit any vulnerability that is exposed due to a lack of proper maintenance.

Function As a Service

Also known as serverless computing, Function as a Service is possibly both the most abstract of the cloud computing models and the most “cloud” of them all. The service user writes code that runs either monolithically (one large application), as microservices interacting to supply a function or application, or somewhere in between using both concepts.

The code runs as needed, rather than persisting in memory between runs, by storing results or states to a persistent storage medium, that is, a database. This allows the resources for the execution to be given dynamically. When the code is not running, there are no compute resources used, and thus, there are minimal (if any) costs associated with the runtime. The application developers aren’t concerned with the infrastructure at all, just the code, keeping the complexity of the execution environment hidden and managed.

As an example, serverless databases extend the serverless services model to applications eliminating the need to manage database server infrastructure and provide direct database access without all the overhead. This architecture is shown in Figure 2-5.

A schematic diagram of the range of responsibilities for software as a service. For the user to communicate for the assistance under cloud service can function.

As with all cloud service provisions, there are risks. The predominant risk here is the security of the data passed between functions, but it’s important to be aware of data held at rest between executions. This data is the lifeblood of the system, and any opportunity to poison that would lead to a catastrophic failure.

Typically, the usual suspects raise their heads once more with access controls (privileged by their very nature, even if not seen as such), configuration management, and vulnerability management being core among them. Even in this, the most cloud-like of cloud implementations, it’s still the same basics that we struggle with on-premises that are most likely to trip us up in this “new world.”

X As a Service

While SaaS, PaaS, and IaaS are the original trio of services offered as cloud computing, more variations of on-demand, centrally managed software services have emerged. There is now a plethora of “X As a Service” offerings that can be delivered, where X represents a technology substitution by asset or application. Many are specific instances of the more classic services, designed to address a particular market need. For convenience, you can think of them as less generic implementations of the services that have already been covered but are discussed separately because of unique implementations and/or potential security risks.

Desktop As a Service

Desktop as a Service (DaaS) provides a modern version of virtual desktop infrastructure (VDI) hosted in the cloud. While this concept has existed for decades, implemented using solutions from Citrix and Microsoft, the move to the cloud warrants further discussion on this subject. DaaS allows organizations to enable their users to have access to a virtual image of their corporate desktop, with all necessary applications and storage, from virtually anywhere and at any time. Access is often via a browser, extending the “anywhere” aspect and avoiding asset loss when hardware, like a laptop, is misplaced or stolen. DaaS is convenient and flexible, but as is common, those benefits are accompanied by risk. This is functionally illustrated in Figure 2-6.

A schematic diagram of the range of responsibilities for software as a service. For the user to use the virtual windows workstation under the cloud service.

DaaS risks include everything from inappropriate access to stolen or shared credentials, to exposing an application with potentially sensitive information directly on the Internet – all threats that must be considered in your cloud security model. This is not to say that services like this are inherently unsecure, but rather that they need to be approached eyes wide open, with a full appreciation of the potential for misuse.

Data Center As a Service

Data Center as a Service (DCaaS) offers a service where a physical data center infrastructure and actual facility, or the virtual equivalents, are provisioned for users. This is conceptually similar to data center colocation (Colo), but it bundles the entire experience, the management, and the offering to the subscribing organization as a service. This concept is a layer down from IaaS, allowing companies to use the skills of the provider and capitalize on the best practices for data center management, all while operating the data center’s services for their specific needs. The DCaaS provision can, like most cloud computing requirements, scale to the immediate needs of the user without requiring the infrastructure to be held at maximum capacity indefinitely. Functionally, this is illustrated in Figure 2-7.

A schematic diagram of the range of responsibilities for software as a service. For the user to use and manage the virtual devices under the virtual data center of the cloud service.

While the attack vectors for DCaaS may sound obtuse for this book, you need to consider the physical security controls that were implemented on-premises to protect your data center. If you consider relinquishing them to a third party and sharing them with other organizations that leverage DCaaS services, you begin to appreciate the complexity of the attack vectors that this service could be subject to, even if the entire environment is virtualized. This includes the physical access required to manage the assets and resources used to support your services.

Managed Software As a Service

Managed Software as a Service is a hosting model where an organization licenses (subscription or perpetual) a software solution, but uses an independent service provider to host and manage the software for their use cases. This offering provides a service that bridges the SaaS and PaaS provisions by providing the platform and the management without directly providing the software and actual solution. Figure 2-8 illustrates how only the software is delivered as a management component of the service.

A schematic diagram of the range of responsibilities for software as a service. For the user and the cloud provider to own, use, manage, and maintain the application.

While the hosting itself has its own security risks that should be managed by the hosting provider, the application (software) security has a shared responsibility model. The hosting provider typically manages application security patches for deployment, but the runtime of the application, which can be misconfigured or can have weak credential security, is managed by the end user. Both can open critical paths of exposure to the business and the managed software. Some service providers will undoubtedly offer services to cover the application runtime as well.

Backend As a Service

Backend as a Service delivers a mechanism for Internet (web) and mobile application developers to link their software to cloud storage and computing services through an abstraction layer interface, like an API. These services deliver capabilities, such as push notifications (sending notifications to a web browser or mobile application to alert the user to some change of state), centralized user management (registration, login, subscription processing, etc.), and activity monitoring dashboards. Figure 2-9 illustrates these services in the cloud.

A schematic diagram of the range of responsibilities for software as a service. For the user to use the application. Then the application can utilize the different Application Programming Interface under cloud service.

Attack vectors for Backend as a Service target operational runtime of data required by the back end to properly host applications. If the compromised data is shared via multiple applications, like the ability to deliver traffic or weather information, then all subscribers could potentially have incorrect, even potentially life-threatening, information.

As you may have begun to realize, there are many “As a Service” provisions and potential services on the market today. Not all of them are truly under the cloud computing “As a Service” model, and some providers are simply jumping on the messaging to differentiate with new offerings. This is where concepts like “cloud washing” (discussed later) become important in understanding cloud attack vectors. For solutions that are not cloud native, but which adhere to similar models as XaaS, you will find clear parallels to the concepts that follow in subsequent chapters.