NCSC Security Principles

The UK National Cyber Security Centre has published a number of questions concerning SaaS security as a guide to what to ask SaaS providers.
Details can be found here: https://www.ncsc.gov.uk/guidance/saas-security-principles

In line with our transparency policy we publish below our responses and details on the security features that we implement. If you need further information please contact us.

SaaS Security Principle 1
Data-in-transit protection between clients and service

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

Description
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.

Response
Yes, we currently use the TLS 1.2 protocol.

SaaS Security Principle 2
Industry good practice external certificate configuration

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

Description
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.

Response
Yes.

SaaS Security Principle 3
Data-in-transit protection between microservices

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

Description
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.
Response
Yes

SaaS Security Principle 4
Industry good practice internal certificate configuration

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

Description
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.

Response
Yes.

SaaS Security Principle 5
API authentication and protection

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

Description
All externally exposed API queries which return protected information should require successful authentication before they can be called.
Response

SaaS Security Principle 6
Privilege separation

Question
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?

Description
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.

Response
Yes

SaaS Security Principle 7
Multi-factor authentication

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

Description
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.

Response
–

SaaS Security Principle 8
Logging and event collection

Question
Does the SaaS provider collect logs of events?

Description
Types of log may include security logs and resource logs.

The SaaS product generates all relevant security-critical logs.

Response
–

SaaS Security Principle 9
Availability of logs

Question
Does the SaaS provider make logs available to the client?

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

Response
–

SaaS Security Principle 10
Clear incident response to patching and security issues
Question

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?

Description
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.

Response
Yes, depending on the security threat, complexity of testing and deploying any software updates or patches, patches are often applied within a few hours; our policy for critical security patches is that they are applied within 30 days of their publication.

SaaS Security Principle 11
Clear and transparent details on a product’s security features

Question
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?)

Description
The SaaS provider makes available clear and transparent details on the security features that they implement, and how best to configure them.

Response
Yes.

Last updated: 23 Oct 2018