The SafeMashups Cloud Trust Model

The model is described in the following five steps:

  1. Create a layered model that underlies virtually every cloud service.
  2. Divide the layer into security units (SUs), and specify an XML profile for each SU.
  3. Lay out three core security assumptions about the relationship of the layers and SUs.
  4. Insert an SNMP style security agent into each SU which can report on its security profile and can also be used to establish inter-SU communications.
  5. Introduce a Cloud Trust Broker that brokers communication between SUs subject to security policies and is the single point for audit and control.

Step 1: Introduce concrete layers

Layered models, such as the OSI stack, are concrete concepts that are readily approachable, and consequently we wish to define a set of layers that are common to all clouds. While terms like IAAS, PAAS and SAAS, are useful abstractions of how a cloud service is marketed, priced and acquired, it gives us little concrete information that is relevant from a security perspective. While we are proposing one possible approach to layering, our larger point is that concrete layers are a good place to start.

The above model consists of the layers shown. It is our contention that for any cloud service it is important to answer basic questions about each of these layers (with the focus on the bottom five). For instance knowing that the application is a Java/Tomcat application running on Trusted Linux, on a version of VMware ESX on INTEL hardware and EMC storage in two physical Level 3 data centers located in the Netherlands and Germany is meaningful.

Step 2: Divide the layers into security units (SUs)

Almost all the layers shown above very naturally divide into separate security units which will inherit certain common characteristics from the layer, but could still have very different security properties. For instance, two cages in a data center, or two guest operating systems running on the same hypervisor could have very different security profiles.

Step 3: Three core assumptions about the SUs and Layers

The three central security assumptions we make are that:

  • While it can be mitigated, in general it should be assumed that Layer N can compromise Layer N+1.
  • While not always true, in general it should be assumed that Layer N cannot compromise Layer N-1.
  • It is assumed that the "chinese walls" between SUs at the same layer cannot be compromised.

The XML profiles at each SU should contain information on each of these assumptions, and the certification should talk to the validity of the assumptions.

Step 4: Insert security-agents into each SU

We introduce the concept of a security-agent at each SU, modeled roughly on the notion of SNMP agents. Analogous to SNMP agents our agents can be used to answer queries about their SU's XML profiles. They are also the SU's interface to the trust brokers that are charged with mediating communications between SUs.

Step 5: The Cloud Trust Broker

Finally, our model introduces the concept of a Cloud Trust Broker that mediates communications between SUs. It decides based on its policies and the XML profiles of the SUs whether two SUs are allowed to talk, whether an application can migrate from one SU to another, etc. The policy can be rule based or ACL based. The trust broker might be hosted by an enterprise, itself reside in a cloud, or be run by a cloud services vendor. Further, while not explored further here, the notion of inter cloud trust broker communication is a natural extension. The SafeMashups Cloud Trust Broker which we have developed is a concrete instance of this concept.