5.2.3 Monitoring and Environment State Collection

The ability to collect evidence of the events and actions that take place inside a cloud environment is absolutely reliant on the ability to observe and monitor the state of all systems that operate in this environment. Clearly, this requires that all systems are instrumented and monitored so that information about their state and inner workings is extracted and made available for analysis at various levels of granularity. Because most cloud services are implementation-specific and involve customisations, we do not propose a specific architecture for environment state information collection services. Nonetheless, we assume that capabilities to monitor the state of the cloud environment are in place.

Using the Cloud Trust Protocol (CTP)

The Cloud Trust Protocol (CTP) is a project currently being developed by CSA (a partner in A4Cloud). It aims to create a RESTful Application Programming Interface (API) that will allow cloud customers to query cloud providers about the security/privacy/compliance level of their service in near real-time. In the next paragraph, we analyse the potential use of this new tool for the purpose of providing the account.

It should be highlighted that CTP does not define a monitoring architecture or framework but only defines an API to present the result of the monitoring in a standardised way.

In CTP the level of security of a cloud service is expressed through the measurement of “security attributes”, which apply to “cloud resources”. More precisely, CTP has adopted the following data model:

• A cloud service is divided into a set of resources (e.g. a VM, an API call, a database)
• Each resource has a set of attributes (e.g. “uptime”, “confidentiality at rest”, “incident response performance”)
• Each attribute has a set of measurements, where a measurement is a process that enables to quantify or qualify an attribute, according to a specific metric (e.g. “percentage of failed requests per hour”).
• Each measurement produces a value called “measurement result” (e.g. “99.98637 % / hour”)
• Each measurement can also be associated with an objective, which represents what is typically described in a SLA by describing a constraint on the measurement result (e.g. “result > 99.95 % / month”)

This data model enables cloud customers to get precise information about the security level of a service, and compare these levels with the security objectives that have been defined by the provider (provided of course that the provider is willing to provide a valuable set of attributes and measurements). In addition to these elements, the CTP API also proposes:

• Triggers: these are conditions (like objectives) that will generate an alert, sent to the customer.
• Logs: logs that are stored by the provider, for each trigger event.

With the high-level presentation of CTP we can examine how closely it can be related to the notion of the account. First, we can observe that:

• By construction, CTP triggers provide a mechanism to be notified of events, whether these events are “legitimate” or “incidents” depends solely on the choice of the trigger conditions formulated by the customer. CTP triggers and logs therefore provide a vehicle for ‘a report or description of an event’, which defines the notion of the account (see 4.1).
• CTP “objectives”, which describe obligation of the organisations, are closely linked to the notion of “proactive report”.
• The account is expected to answer a certain number of question: notably who, what, where and when. By construction, the CTP data model:
  • Provides clear identification of “who” (via service-units).
  • Describes partially “what” through measurement results, but does not identify “root cause”
  • Describes “where” in the sense of identifying the “resources” to which attributes apply. Moreover “location” can be an attribute of a resource in itself.
  • Describes when through timestamps.
• The CTP standards envision explicitly the possibility to add a digital signature to measurement results, though this feature is not standardised at the time of writing.

However, we can also argue that CTP is not designed to present all the features that are expected of an “account” in the sense defined in A4Cloud:

• CTP does report “evidence” in the strict sense but only “results”. Logs in CTP only allow deduction of the fact that a result failed to match a condition but they do not provide support for the results themselves.
• CTP does not describe actions taken to deal with an incident, but only describe that the incident occurred.

One last aspect to consider is that CTP targets mainly security/privacy attributes that can be minored in an automated way. This does not cover all elements that an organisation should monitor as part of an accountable process.

In summary, the CTP API can be used by organisations as a tool to provide an “account” of technical and measurable attributes related to security, privacy and compliance in general. However, the CTP API does not provide a mechanism to support the presentation of evidence in relation with incidents but only a mechanism to report that a specific incident occurred.