Guidance

SaaS security principles

Created:  11 Jun 2018
Updated:  11 Jun 2018
Cloud nuts
A brief description of the criteria developed by the NCSC to evaluate the security of various 'Software as a Service' (SaaS) offerings.

The table below lists each SaaS security principle, along with a brief description of its purpose, and the question the NCSC used to quiz the organisation on its support for this principle.

The final column (Sample output) shows the kind of conclusions you may come to after scrutinising the service's website (or questioning their support staff).

 

SaaS Security
Principle

Question 

Description

Sample
output

Data-in-transit protection between clients and service

Does the SaaS provider protect external data in transit using TLS?

Data should be protected as it transits between the client and the SaaS product.

Transport Layer Security (TLS) is a protocol which provides privacy between communicating applications and their users, or between communicating services. When a server and client communicate, well-configured TLS ensures that no third party can eavesdrop or tamper with any message.

At the time of writing, TLS 1.2 is the current version, and this includes security improvements over version 1.0. The predecessor to the TLS protocol was the Secure Sockets Layer (SSL) protocol, all versions of which are now regarded as insecure.

Yes 
Industry good practice external certificate configuration

Does the SaaS provider protect external data in transit using correctly configured certificates?

Certificates used within the external TLS connection should follow good practice.

The NCSC recommend a set of preferred TLS profiles which SaaS providers are encouraged to adopt.

Unknown
Data-in-transit protection between microservices

Does the SaaS provider protect internal data in transit between services using encryption?

Data should be protected as it transits between a SaaS provider's microservices.

Since microservices can be hosted in different areas of a cloud service, data should be as protected between microservices as it is between client and service.

Yes
Industry good practice internal certificate configuration

Does the SaaS provider protect internal data in transit between services using correctly configured certificates?

Certificates used within the internal TLS connection should follow good practice.

The NCSC recommend a set of preferred TLS profiles which SaaS providers are encouraged to adopt.

Unknown
API authentication and protection

If APIs are available, does the SaaS provider protect both internal and external APIs through an authentication method?

All externally exposed API queries which return protected information should require successful authentication before they can be called. Yes (version dependent)
Privilege separation

If there is a concept of privilege levels in the service, does the SaaS provider have the ability for low privilege users to be created?

The SaaS product should implement levels of privilege, and have authorisation mechanisms in place to enforce the separation of privileges between different types of account. Yes
Multi-factor authentication

If there is a concept of privilege levels, does the SaaS provider at least make 2FA/multi-factor authentication available on high privileged accounts?

The SaaS product should implement a method of requiring multi factor authentication to the service. Enabling multi factor authentication helps lower the impact of credential theft. Yes
Logging and event collection

Does the SaaS provider collect logs of events?

Types of log may include security logs and resource logs.

The SaaS product generates all relevant security-critical logs. Yes
Availability of logs

Does the SaaS provider make logs available to the client?

The SaaS product makes available security-critical events to your audit and monitoring service. Partial

Clear incident response to patching and security issues

Does the SaaS provider have a clear incident response and patching system in place to remedy any publicly reported issues in their service, or libraries that the service makes use of?

The provider’s previous track record on this is a good metric to see how they’ll cope with any new issues.

The SaaS provider has a clearly defined policy for patching internal systems as well as dealing with security issues. Yes
Clear and transparent details on a product's security features Does the SaaS provider give clear and transparent details on their product and the implemented security features (i.e. how easy has it been to answer the above questions?) The SaaS provider makes available clear and transparent details on the security features that they implement, and how best to configure them. Partial: the vendor has provided some answers to the above principles in a security white paper. However, not all principles were covered.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No