Shared Responsibilities for Security in the Cloud, Part 1

By Alexander Anoufriev, CISO, ThousandEyes

Introduction: Security Responsibilities in the Cloud Era

When businesses owned their applications and all underlying infrastructure, they also owned their security. Now this is changing with a shift in ownership and operational responsibilities over many applications as they are moving to the Cloud. In the cloud era, security is not owned solely by the cloud service provider (CSP) or consumer. Cloud security is a shared responsibility.

To illustrate this model of shared responsibility I will be using:

• ThousandEyes SaaS Platform as an example of a cloud application which is owned and operated by ThousandEyes
• Cloud Security Alliance (CSA) Trusted Cloud Initiative (TCI) reference architecture

We’ll need to understand the high level architecture of this specific solution. The ThousandEyes solution consists of three major components (see Figure 1):

1. SaaS Platform, which is installed and operated in the ThousandEyes data center
2. Enterprise Agent, which is installed in the customer’s network
3. Cloud Agent, which is installed in hosting providers’ networks and managed by ThousandEyes

We monitor the performance of networks and applications inside of an enterprise, on the internet and in the cloud. As a part of our service, we process and store the following data elements:

• User accounts (name, email)
• Hashes of passwords (only if local authentication is in place; in Web SSO with SAML scenario this is not applicable)
• Definitions of network performance tests
• Results of the tests (measurements)
• Alerts
• Reports
• Support tickets

Responsibilities by TCI Domain

Governance, Risk and Compliance

Figure 2 illustrates responsibility for the governance, risk and compliance (GRC) domain of TCI architecture. This domain is responsible for the identification and implementation of the appropriate organizational structures, processes, and controls to maintain effective information security governance, risk management and compliance. Both parties, the service provider (ThousandEyes in this example) and the consumer, are independently responsible for all of the listed processes.

Responsibility for specific processes will differ between provider and consumer, for example: the service provider manages compliance with its internal policies, control standards and procedures, while it designs, develops, deploys and operates the service. The customers manage compliance while they use the service.

Privilege Management Infrastructure

Privilege Management Infrastructure ensures that users have the access and privileges required to execute their duties and responsibilities with Identity and Access Management (IAM) functions. Figure 3 illustrates shared responsibilities in IAM.

In our example, the identity management process extends from a service provider to a service consumer while other related processes and services exist independently in both entities. With the ThousandEyes SaaS Platform, customers are able to take advantage of their own web single sign on (SSO) technologies. In this case, they become responsible for authentication, authorization, and privilege management. Alternatively, they can use ThousandEyes-supplied identity information.

Threat and Vulnerability Management

This domain provides core IT security service and processes. Figure 4 demonstrates how responsibilities are allocated between the service provider and consumer.

Here we can see that some of the security processes/services are fully shifted to the service provider. All infrastructure-related compliance testing, vulnerability management and penetration testing are operated by the service provider, while threat management exists on both sides and often covers different threats. Due to this, they are two different processes.

(Part 2 of this post will run tomorrow.)