CHAPTER 11: SECURITY AND SOFTWARE AS A SERVICE

In this chapter, I describe how the security services defined within the SRM, shown in Figure 7, may be delivered by consumers implementing a service using a SaaS Cloud.

There are countless SaaS services available covering a wide range of capabilities, including:

•Billing

•Customer relationship management (CRM)

•Collaboration

•Content management

•Document management

•Enterprise resource planning (ERP)

•Environmental health and safety

•Financials

•Health and wellness

•Human resources

•IT service management (ITSM)

•Personal productivity

•Project management

•Sales

•Security

•Social networks

Examples of SaaS providers include:

•Salesforce.com (www.salesforce.com)

•Sage (www.sageone.com)

•Intuit (www.intuit.com)

•Netsuite (www.netsuite.com/portal/home.shtml)

•SuccessFactors (www.successfactors.com)

•Oracle (www.oracle.com/applications/)

•Office365 (www.office.com/)

•Google Apps (https://gsuite.google.com/)

•GitHub (https://github.com/)

•Zoom (https://zoom.us/zoomrooms?zcid=2438)

•Slack (https://slack.com/intl/en-gb/)

•Huddle (www.huddle.com)

•Confluence (www.atlassian.com/software/confluence)

•Box (www.box.com)

•Dropbox (www.dropbox.com/teams)

•Qualys (www.qualys.com)

•MIMECast (www.mimecast.com)

•Okta (www.okta.com/)

•AlertLogic (www.alertlogic.com/solutions/product-overview-and-pricing/)

•Demisto (www.demisto.com/)

•Veracode (www.veracode.com/)

The selection of SaaS CSPs given above highlights the real diversity that is present in the SaaS ecosystem. It also highlights the impossibility of providing detailed security guidance that is applicable to all categories of SaaS service provision. The security requirements for a financial reporting system or a HR system are clearly different to those for a system designed to promote collaboration or a service providing security testing. The guidance presented in this chapter will necessarily be generic and aimed at helping organisations secure their use of services whereby they entrust their data (and relying business processes) to SaaS vendors.

Secure development

In a SaaS environment, the primary responsibility for the delivery of a secure application rests with the provider. SaaS providers should be strongly incentivised to provide a secure service; given the competitive nature of the SaaS landscape, a series of security mishaps would not be conducive to a long-term future.

One of the drivers for adopting the SaaS model is to rid yourself of the problem of software development (and, perhaps, integration) and the overhead of supporting the developed software on an expensive infrastructure. However, the more complex the SaaS application the more work is required to tailor it to meet your particular needs. Examples of the work involved can include 'skinning' the application with your own logos and visual style guidelines, configuration of the users and their access rights, transformation of any data to be uploaded to the SaaS provider and integration of the SaaS provider into your wider environment (e.g. implementation of single sign-on).

The decision to adopt a SaaS model does not mean that you can immediately reassign your hands-on technical staff to other roles. You will need to retain some skilled resource to configure and then manage the technical or mundane administrative aspects of your chosen SaaS solution.

From a secure development perspective then, whilst there will be little in the way of content, you will still require a limited set of coding standards (e.g. configuration guidelines) together with the capability to code review and unit test any preparatory work (e.g. upload scripts) prior to their usage. However, the vast bulk of the delivery responsibility for such services in relation to the application itself rests with the CSP.

Integrity

With a SaaS approach, you are buying into the integrity of the SaaS application and the underlying datastores. The only aspects of integrity that a consumer can influence relate to the integrity of the data provided to the CSP and the integrity of the organisation-specific configuration within the SaaS application. Consumers should also ensure that they maintain the integrity of their on-premises datastores by content checking any information sourced from their SaaS provider prior to it being incorporated into a trusted datastore.

From a non-repudiation perspective, SaaS consumers are limited to the audit functionality and non-repudiation capabilities offered by their SaaS provider. User activities on a SaaS application can only be captured by the provider, unless such activities are proxied between the consumer and the SaaS provider. Fortunately, such proxies do exist and they can provide significantly more capability than simple logging of traffic between the on-premises environment and a SaaS provider. This capability, commonly referred to as a Cloud Access Security Broker (CASB), will be explored further in the section on integration later in this chapter.

The final service within the integrity service grouping is the snapshot service. In the IaaS and PaaS discussions the snapshot service provides a known-good baseline of data, application or configuration information. In the SaaS environment, the snapshot service could be implemented through exports of data at specific points and then securely storing such data on-premises (or with an alternative Cloud provider), e.g. through hashing and/or signing of the data export. SaaS providers may also offer their own equivalent snapshot capability, although consumers would need to be comfortable with the verification of such snapshots (e.g. signed hashing) and where such snapshots would be stored.

Integration

The integration set of services comprise CASB, API and CWPP. CWPP (Cloud workload protection platform) products were discussed in chapter 9. CWPP is placed within the integration services because it provides consuming organisations with the capability to place security controls around their workloads that are either portable or consistent or both. CWPP is not relevant in the SaaS context.

The API service relates to the need to provide programmatic access to Cloud services; this capability is as applicable to SaaS as it is to other Cloud models. In the SaaS context, the API could be used for user management, audit event configuration and retrieval, and service control.

The API service is intimately related to the final service in this grouping: the Cloud Access Security Broker (CASB) service. The CASB service provides a mechanism to supplement the security controls offered by Cloud providers, predominantly in the SaaS arena but not solely. For example, access to Cloud management APIs across all types of Cloud providers can be controlled by a broker.

The CASB name refers to a class of real-world products and services that can be used to deliver the conceptual service within the SRM. Examples of CASB products include:

•Netskope (www.netskope.com/)

•McAfee MVISION (formerly Skyhigh Networks) (www.mcafee.com/enterprise/engb/products/mvision-Cloud.html)

•BitGlass (www.bitglass.com/)

•Microsoft Cloud App Security (www.microsoft.com/en-us/enterprise-mobility-security/Cloud-app-security)

CASBs tend to provide similar functionality across the different products; this functionality is described below.

Discovery and risk assessment

The CASB identifies the Cloud services in use, alongside a view of the risk of using such services. CASB vendors maintain in-house catalogues of Cloud services – tens of thousands these days – with risk ratings scored using criteria such as ‘hosting location’ and ‘certifications achieved’. Identification of the Cloud services in use will usually be achieved through analysis of web proxy and firewall logs or through running web traffic via the CASB for a period of time sufficient to identify normal usage.

Cloud access control

The CASB controls which Cloud services can be accessed by end users (authorised services) and which will have access to them blocked (non-sanctioned services). As always with security, a whitelisting approach is preferred to a blacklisting approach, though this comes with increased management overheads. CASBs can also control the actions that users can take within Cloud services through either the proxying of the connection or the configuration of the service via the APIs that the services expose.

Data loss prevention

CASBs can be used to prevent sensitive information leaking to Cloud services. CASBs work much as any other DLP solution, i.e. through pattern matching and/or heuristics. Some CASB products offer agents that can be installed on end user devices to prevent information leakage at source, i.e. on the device and prior to traversal of the CASB itself. Some CASBs will take a retroactive approach to DLP by scanning documents uploaded to Cloud services and removing them when they are found to contain controlled content.

Data tokenisation and/or encryption

CASBs can be used to tokenise or encrypt information being uploaded to Cloud services. Some SaaS providers offer downloadable pseudo-CASBs to enable this functionality, e.g. the ServiceNow Edge Proxy.²³¹

Security assessment

CASBs often offer the capability to perform a security assessment of the Cloud services that they secure, e.g. through a check against relevant CIS benchmarks.²³²

Cloud monitoring

A CASB provides another source of logging and monitoring information to supplement that available from Cloud services. If all Cloud access is passed via the CASB, the CASB can provide a single point of visibility for user activity across an organisation's Cloud environment.

CASBs can be deployed either on-premises or in the Cloud, with the latter becoming a more common approach. However, if deployed on-premises, these products can offer extremely valuable functionality for the integrity of data and for compliance with data residency requirements. Consumers can use these products to encrypt or tokenise their sensitive data to ensure that it remains on-premises. If an organisation does not have strong regulatory compliance requirements to ensure that data remains on-premises at all times, then the Cloud-based model tends to be more appropriate for most organisations– for the same reasons that often make the Cloud model trump on-premises alternatives.

There are three main deployment approaches for using CASBs, illustrated in Figures 37-39. These figures depict the CASB as being hosted in the Cloud, but bear in mind that it could also be hosted on-premises.

Figure 38 illustrates the model you may be most familiar with: a CASB implemented in-line between the Cloud users and the Cloud services.

Figure 38: CASB in-line deployment option

In the in-line model, all user traffic is routed via the CASB. This is the only deployment model that allows organisations to actively block access to non-sanctioned Cloud services. This model allows proactive control of user activity and pre-emptive DLP, i.e. controlled content can be blocked prior to being stored within Cloud services.

Figure 39 illustrates the other common CASB deployment pattern: API only.

Figure 39: CASB API deployment option

With the API model, the CASB sits to the side of both users and the Cloud services that they access. The CASB is provided with credentials to the protected Cloud services and uses this access to control user activity via the APIs exposed by the various Cloud providers. In this model, the Cloud consumer is best able to control user activities within the Cloud services that the CASB product understands, i.e. there will be little value in this deployment approach if the CASB product has no ability to call the required APIs. In general, connectors can be configured as required, but this entails coding, testing and maintenance overheads. It is important to note that DLP operations are carried out retroactively in this model. For example, should a document containing controlled content be uploaded to One Drive, Dropbox, Box or a similar service, this upload will not be blocked in real time; however, the CASB will use its access to scan the uploaded content and will automatically remove it – as a result, there will be a polling window whereby controlled content will be hosted and available within the Cloud service. This may not be acceptable to some organisations.

The reverse proxy model is the final deployment model that I will discuss here (see Figure 40, below).

Figure 40: CASB proxy deployment option

In this model, the CASB is implemented to support a specific Cloud service by supplementing its access controls. This may be necessary if the SaaS service seems to lack adequate controls in areas like authentication, authorisation and security monitoring. In the reverse proxy model, as in the in-line model, the CASB is able to prevent the upload of controlled information into the protected Cloud service.

CASBs are typically considered within the SaaS context (which is why they are discussed in this chapter); however, they can also be used to control access to the major IaaS suppliers – the main CASB vendors understand the management APIs well enough to act as an additional source of access management capability. Note that these deployment models are not necessarily exclusive, i.e. it is perfectly reasonable, and indeed advisable, to deploy both the in-line and API models to control activities both within the Cloud service and in transit to the Cloud.

I mentioned encryption and tokenisation earlier in this section, and this subject is worthy of further discussion. Figure 41 illustrates how such technologies work.

Figure 41: Encryption and tokenisation

On the left, we have our SaaS CSP and on the right, our consumer on-premises environment. In this scenario, the consumer is keen to take full advantage of the functionality and flexibility offered by their CSP, but they also have requirements that necessitate keeping their sensitive data on-premises. The solution illustrated in Figure 40 allows the consumer to meet both requirements, with certain restrictions relating to the difficulties of completing search and sorting operations on encrypted data. Users within the consuming organisation accessing their Cloud services are unaware of the device sat in-between themselves and the SaaS provider. This device (e.g. a CASB or other product) intercepts the sensitive data before it leaves the on-premises environment and replaces the sensitive data items with either encrypted or tokenised values. This treated data is then transmitted to the CSP and stored within the Cloud. Subsequently, when the user needs to access the SaaS application, the application processes the treated data that it holds and returns it to the end user. Before the response reaches the end user, the device replaces the treated data with the real data. End users can, therefore, take advantage of many of the SaaS application’s capabilities whilst retaining complete control of their sensitive data.

The use of equality-preserving and/or order-preserving encryption algorithms can enable support for some logical operations and functionality on encrypted fields within the SaaS application; however, this comes with the security cost of encrypted fields always producing the same ciphertext for the plain text (as opposed to usual field-level encryption which would see different ciphertext being produced for each encryption operation). Equality-preserving encryption supports comparison operations, such as filtering, matching, and grouping. Order-preserving encryption algorithms support sorting and size comparison (less than/greater than) operations in addition to the capabilities enabled by equality-preserving algorithms.

Tokenisation is different to encryption: it replaces sensitive data with random values rather than relying upon encryption. When using tokenisation, a mapping between the real values and tokenised values must be retained on-premises so that the real values can be reinserted for presentation to end users.

Implementing products like CASBs or other tokenisation/encryption solutions has some downsides. For example:

•If their purpose is to keep data on-premises, the devices must be implemented on-premises. Implementing new physical hardware may not be compatible with the aims of moving to Cloud-based delivery.

•Hardware and software does not maintain itself: the products will require configuration and maintenance, e.g. patching, sanctioned application whitelisting, SaaS application level access control, et cetera.

•These devices can now act as a choke point and ‘bump in the wire’ for your SaaS access. Ensure that you can still meet required response times.

•It may be necessary to install a high availability or resilient pair, possibly at more than one location if the Cloud-based deployment option is not deemed adequate.

•Tokenisation or encryption will result in a degraded user experience within the SaaS applications: application capabilities that require access to clear text data will not function as expected with encrypted or tokenised data.

The above issues all point to a significant financial investment (in kit, hosting, CASB licensing and management) which may outweigh the financial benefit from moving to a pay-as-you-go model. In particular, consumers should ensure that they factor all relevant issues into their cost/benefit analysis with regard to adopting SaaS.

Availability

In a SaaS environment, the options for business continuity (BC) and disaster recovery (DR) are limited. If an organisation has fully bought into the SaaS philosophy and has little in the way of on-premises equipment, data or technical IT expertise then they will struggle to continue their business processes should their SaaS fail. Furthermore, if a SaaS (or the CSP) fails catastrophically, consumers may also struggle to retrieve their data from the CSP. On the positive side, one of the selling points of the SaaS approach is the relative speed to operation compared to an on-premises implementation. So, if there is a long-term outage a consumer could simply switch providers, assuming that the consumer has access to the underlying business data. Obviously, such a supplier switchover would not be a trivial undertaking and the feasibility of such an approach varies with the complexity of the service involved. It is also not just a technical issue, any switchover would also require users within the consuming organisation to be retrained to operate the new service and potentially implement changes to established business processes. So, whilst it may be a relatively trivial exercise to move from one vulnerability assessment as a service provider to another (e.g. from Qualys to SureCloud), it would be a much more painful exercise to switch your personal productivity suite from Google Apps to Office 365.

There are six concrete steps that a would-be SaaS consumer should take to ensure that appropriate business continuity and disaster recovery mechanisms are in place:

1.Ensure that you know the availability requirements of the business processes relying on the proposed SaaS application.

2.Investigate whether your proposed SaaS CSP can meet the identified availability requirements before signing up through examination of published availability statistics.

3.Examine the recompense on offer from the CSP should they fail to meet their published SLAs: service credits may not be much comfort when you are losing thousands of pounds an hour in lost business.

4.Consider the impact on your business processes should the SaaS provider undergo outages of minutes, hours, days or weeks. At which point (if any) is the outage unsustainable?

5.Consider storing a replicated copy of your business data either on-site or at a separate CSP to ensure that your data is always available, even if your SaaS application is not.

6.Plan for the worst-case scenario. Know what you will do if the SaaS is unavailable to the point of the associated losses being unsustainable. Options may include:

•Falling back to a legacy on-premises system;

•Falling back to manual processes (making use of the copy of your business data);

•Switching to an alternative SaaS solution; and

•Having insurance.

The above steps are not intended to offer a comprehensive approach to business continuity; there are enough standards available, e.g. BS 25999/ISO 22301 that provide detailed advice in this area. My aim is rather to suggest some questions that should be in the back of your mind as you plan a SaaS implementation. You should also consider the comparative cost of implementing similar levels of business continuity and disaster recovery using physical, on-premises, systems. Whilst the levels of BC/DR available in the SaaS world may be limited, the SaaS approach may still represent a more feasible or cost-effective solution, particularly where an organisation does not possess geographically distributed redundant data centres or who have a poor track record of delivering available services.

As the Cloud model has matured, the number of organisations delivering complex business processes through a combination of many atomic Cloud services, sometimes integrated and managed via a service broker, has increased. For example, implementation of separate sales, CRM, storage, and authentication SaaS services to deliver a single overall business process. This approach offers great flexibility as you can switch in and out different CSPs as new 'best of breed' suppliers emerge – at least in theory. In practice, life is made more difficult through the lack of common standards in the area of portability and interoperability.

From an availability perspective, you can find the availability of your overall business process being less than you may imagine. Always remember that the availability of your overall business process is dependent upon the availability of each atomic service, i.e. failure at one element may take down the entire business process. A combination of four services offering 99.5% availability will only deliver a combined availability of 98% which may not meet your needs. Of course, similar concerns affect systems hosted on-premises where a failure of a critical server, database, switch, et cetera could also adversely affect the availability of a service. Always remember to step back and consider the overall requirements for your business processes and the impacts of those requirements not being fulfilled, regardless of your proposed delivery approach.

Cryptography

The delivery of the services within the cryptography grouping is firmly the responsibility of the SaaS CSP in most instances. Only the SaaS CSP can define the encryption requirements needed to access their service, albeit that such access is usually protected via TLS. Furthermore, it is the responsibility of the CSP to properly implement any encryption (and associated key management) of customer data should that be an element of their service. Given that the key management functions and the encryption implementation are both in the realm of the CSP, such a capability should not be viewed as offering protection from a threat actor within the CSP.²³³ The only choice available to the consumer in a vanilla SaaS implementation may be whether or not to enable encryption on their communications and data. However, remember that SaaS consumers can still choose to encrypt data on-premises and only send encrypted (or tokenised) data into the Cloud should they decide to implement products such as a CASB.

Access management

Unlike with the IaaS and PaaS chapters (chapters 9 and 10), I am not going to explore the individual access management facilities available within a variety of different SaaS providers. I will instead provide some generic guidance as to how you can maintain control of your users and data when using SaaS providers.

Figure 42: SaaS access management

Figure 42 shows the delivery responsibility split when you, as a SaaS consumer, adopt a standard implementation of a SaaS service. The CSP is responsible for how they authenticate your users to their service. The CSP is responsible for how they authorise access to your data and their functionality (on your data) within their application. The CSP provides the enforcement functionality (filter) to enforce their access controls. All that is left for you to do as a consumer is to:

•Register your users;

•Assign their access rights;

•Set an access management policy around users’ access rights (if such a capability exists); and

•Decide whether or not to adopt federated identity management (if it is supported by the CSP).

Even those areas where the consumer still has some influence will be implemented using CSP-provided services, i.e. they remain a joint delivery responsibility.

For some consumers, this shifting of access management responsibilities may well count as one of the benefits of adopting a SaaS model. For others, it represents their worst nightmare of what can possibly go wrong with the Cloud model. As a SaaS consumer you need to decide which camp you fall within; there is no generic right or wrong answer. Your answer should be the result of a consideration of the data concerned, the application concerned and the users concerned. The higher the risk associated with unauthorised access to your data, the more likely it is that you will not be content to delegate so much of the access management functionality to the CSP. So what can you do if you are not content to rely solely upon your CSP? Once again, we have the option of implementing a CASB to control access, particularly in conjunction with a Cloud-based identity provider, e.g. Okta or Duo Security (now owned by Cisco).

At this point, consumers may also want to consider the adoption of a ‘zero trust’ approach towards access control – this will be discussed further below, but see the validate section of chapter 9 for more.

Other than maintaining a level of control over the delivery of access management services, an equally important result of adopting a single sign-on and control approach is user convenience. Consider a situation where a normal enterprise user must access applications hosted across their on-premises environment and across multiple SaaS providers. From a user experience perspective it is undoubtedly preferable to only authenticate once and then be presented with access to all of your authorised applications rather than be constantly prompted to enter your credentials.

From an organisational perspective, supplementing this authentication with zero trust considerations, such as device health and behavioural anomaly detection, provides extra comfort. It should be noted that some CSPs do offer some of the characteristics associated with zero trust approaches out of the box, so not all consumers will need to add in new components, e.g. users of Office 365 can benefit from Azure AD Conditional Access.²³⁴ Conditional Access allows authentication decisions to be supplemented with access control decisions based on a user's network location, the device they are using or the client application making the connection. Consumers should always inform themselves about native capability so they can make informed choices regarding user authentication and authorisation.

Now, one danger of adopting an approach in which you enforce control via some form of gateway, such as a CASB or an associated authentication provider, is that you must ensure that your users actually traverse that gateway. Easy enough when all of your users are based on-premises, but more often than not there will be a requirement to support mobile users, including users based on the Internet. In this scenario, you could choose to force your users to connect via your chosen gateway, e.g. by requiring your remote users to connect to your on-premises network before hopping back to the Internet to access the SaaS services. This is not a recommended approach: users are increasingly Internet-native, and zero trust approaches allow organisations to move away from this kind of old-world approach of VPNing into a corporate network prior to reaching out again to SaaS services. Alternative approaches include the installation of agents on end user devices (a functionality offered by some CASBs), or configuring the SaaS application to always redirect users to the gateway for authentication.

So, to summarise:

•Help your users (and yourself) by implementing single sign-on.

•Make use of appropriate federation technologies based on the levels of risk, e.g. OpenID Connect, OAuthv2, SAML, et cetera.

•Select an appropriate mechanism to act as a ‘front door’ to your SaaS services, e.g. Okta, Duo Beyond, Azure AD, Cloud App Security, et cetera.

Where you do not implement federated identity management, consider:

•Your authentication requirements (e.g. two-factor authentication). Ascertain whether they can be supported by your CSP.

•Your provisioning requirements. Ascertain whether it is sufficiently straightforward to create users, distribute their credentials, and remove or deactivate them when necessary.

•Your authorisation requirements. Ascertain whether the levels of control within the application are sufficiently granular. Make sure that it is sufficiently simple to maintain user privileges.

•Your data privacy requirements. Ensure you are legally entitled to populate SaaS-hosted user directories with the personal details of your employees (if relevant).

Another question that consumers should consider relates to the choice of Cloud deployment model. Some SaaS applications can be made available via a public or a community Cloud model, particularly where vendors are targeting government or other closed community clients (e.g. defence organisations); a number of SaaS CSPs are already offering community Cloud services aimed at delivering to government clients. Remember that Cloud does not always mean ‘public Cloud’.

Security governance

The primary delivery responsibilities for the SRM security governance services for a SaaS application are shown in Figure 43.

Figure 43: SaaS security governance

The risk management responsibilities for the application are now the primary delivery responsibility of the SaaS provider; it is their application and consumers have no control over how the application level risks are managed. However, consumers must still remember to consider their risk management responsibilities with regard to their data and their business processes that rely upon the SaaS application.

There are still some services within the security governance grouping that are a joint delivery responsibility, for example, the disseminate and enforce services and the personnel security services. With regard to the disseminate service, security policies and procedures must be disseminated to staff within both the CSP and the consumer. Similarly, both the CSP and the consumer must enforce those policies and procedures. In a SaaS environment, the CSP is primarily responsible for delivery of a base set of security policies regarding how their service may be used. The consumer must provide their own set of policies and procedures for their own users, but the primary delivery responsibility for security policy regarding the SaaS application itself sits with the CSP.

The personnel security service grouping remains a joint delivery responsibility with SaaS as it is with all Cloud models. Employees should be appropriately vetted and managed whether they are employed by the CSP or the consumer; both sets of staff may pose a risk to the confidentiality, integrity and availability of the service.

Security operations

The primary delivery responsibilities for the SRM security operations services are shown in Figure 44.

Figure 44: SaaS security operations

Always remember that the actual assignment of responsibilities for the SRM services will vary depending upon the actual application and CSP concerned. The assignments in this book are based on an abstract application that could be hosted on-premises, on an IaaS, or PaaS or SaaS Cloud rather than being based on a single real-world SaaS application. That said, you can see from Figure 44 that the monitoring duties are split between the CSP and the consumer. Whilst the log service is undoubtedly the delivery responsibility of the CSP, the analysis service is a joint delivery responsibility. After all, the consumer must analyse the relevant audit log information that the CSP is collecting.

The event management service is primarily the responsibility of the CSP; many of the events that are identified will be within the realm of the CSP such as problems with the underlying infrastructure or issues with the application itself. Consumers will mainly be interested in events specifically affecting their users, data or service. A service being described as the primary delivery responsibility of a CSP does not necessarily mean that there is no delivery responsibility for the consumer. This view of the SRM is primarily intended to help organisations understand where the bulk of the effort takes place and to identify where interfaces need to be established between the CSP and consumer.

Consumers that implement CASBs or other Cloud security gateways may well have a different split in responsibilities with regard to security monitoring services. Such devices (or services) increase the level of control and visibility that consumers retain of their users' interactions with Cloud services.

In terms of the administration services within the SRM, these services are, with the exception of deploy, completely within the remit of the CSP. The CSP is responsible for the management of their service (e.g. security patching), provision of mechanisms to manage their service and the subsequent decommissioning and disposal of their equipment upon failure or end of life. The one service within this grouping that is a joint delivery responsibility is the deploy service. Even in a SaaS environment, consumers must still undertake a set of activities to deploy the application to their users, e.g. provision of connectivity, access devices, user credentials, upload of business data and user training. It is these kinds of deployment activities that make change management a joint delivery responsibility.

SaaS CSPs often tout their rolling programme of tightly managed application upgrades as a major advantage of the SaaS service model. SaaS consumers do not need to worry about keeping up to date with service patches or costly upgrades to the latest versions of their business applications – this is all part of the service in SaaS. However, such changes can impact upon the business processes of the SaaS consumer. Consumers should monitor CSP roadmaps to ensure that they are aware of upcoming functionality to ensure that:

1.They take full advantage of new business opportunities that new functionalities may offer; and

2.They do not suffer a sudden unexpected drop in availability should a capability that their business users currently rely upon become deprecated in a scheduled update.

Problem management is similarly a joint delivery responsibility; problems may arise from a misconfiguration of the application by the consumer, as well as from issues with the application or service itself. Communication channels must be available for each side to notify the other of potential issues with the service.

Vulnerability management is firmly in the domain of the CSP in the SaaS environment, indeed there would be little point in consumers performing security testing as they would have no ability to fix any identified issues. Consumers should instead ensure that their CSPs have a thorough vulnerability management process in place including regular penetration testing by qualified organisations.

The incident management services are a joint delivery responsibility; both consumers and CSPs must be able to respond to a security incident and, in some cases, respond jointly. As in other areas where responsibility is joint (or where the CSP is primarily responsible) there must be a well-publicised communications facility available to, firstly, notify the other party of an incident and then to enable both parties to manage the incident through to closure. SaaS consumers should be aware of the potential difficulties of obtaining evidence that is admissible in court from SaaS CSPs. However, as many organisations often choose to manage such incidents in-house rather than involving law enforcement in order to manage potentially adverse publicity, this may not be a major stumbling block.

The asset management services are primarily the responsibility of the CSP as they are responsible for the physical assets and software licenses providing their service. The consumer remains responsible for managing the licenses that may be associated with their usage of the SaaS application.

Conclusion

The SaaS service model is likely the most widely adopted of the Cloud service models and is also the most diverse in terms of the services on offer. The SaaS CSPs are responsible for delivery of a secure application and there is little that a consumer can do to actively influence the security of the SaaS service. From an application perspective, consumers are often limited to controlling the data that they choose to upload to the CSP, configuring the access rights of their users and monitoring the usage of the SaaS application. Consumers must also consider the security of the mechanisms that they use to connect their users and their data to the SaaS application, particularly as such communications tend to involve the Internet as the bearer.

²³¹ https://docs.servicenow.com/bundle/london-servicenow-platform/page/administer/edge-encryption/concept/c_EdgeEncryptionOverview.html.

²³² www.cisecurity.org/benchmark/amazon_web_services/.

²³³ Although some SaaS providers do allow a form of Bring Your Own Key, e.g. Salesforce Shield www.salesforce.com/uk/products/platform/products/shield/.

²³⁴ https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/.