Jump to Navigation

 

5.2.4 Collection and Management of Evidence

The provision of evidence is an essential element of an accountable system, enabling demonstration, verification and the construction of the account, while motivating and guiding a range of other functions and procedures important for accountability. Evidence contributes to the detective controls inherent to accountable systems. In particular, it supports the account by providing arguments to show whether policies, norms and regulations are satisfied at any stage of the service delivery. Therefore, the A4Cloud project proposes an account-oriented definition of accountability evidence: a collection of data, metadata, and routine information and formal operations performed on data and metadata, which provide attributable and verifiable account of the fulfilment of relevant obligations with respect to the service and that can be used to convince a third party of the veracious (or not) functioning of an observable system [47].

As shown in Figure 25, the project determines three verification levels where accountability evidence should be provided in order to verify the correct operations of the system:

  • Organisational policies: At this layer, evidence supports the correct definition of policies for the context.
  • Mechanisms and procedures: This involves the provision of evidence that appropriate mechanisms and controls are deployed in accordance with the obligations defined at the policy layer.
  • Operational practices: The evidence from this level should reflect that operations (what is actually happening) satisfy the requirements expressed in the policies (what is supposed to be happening). This may need continuous monitoring, recording and analysis of the activities in the service delivery.

Figure 25: Accountability evidence.

In line with the above levels, the project identifies the following five major types of evidence relevant for accountability:

  • Data processing practices: evidence of operational practices such as replication, storage, deletion, copy, access, optimisation, consent, security, segregation, proofs of retrievability, etc.
  • Data collection practices: evidence on data collection practices such as policy compliance, privacy issues, security breaches, etc.
  • Notification: evidence that notifications were sent to the interested stakeholders in case of privacy issues (unauthorised access, etc.), policy violations, security breaches (data leakage, data lost, corrupted or tampered, etc.) and services or policy modifications, as well as service practices and users rights;
  • Remediation: evidence related to remediation to customers in case of security breaches, privacy issues and policy violations.
  • Organisational practices: evidence of requirements related to employees' training, system certifications, privacy policies, etc.

The provision of evidence is a complex process that entails: identification, association and collection of information that will constitute evidence from various sources; processing and use of cryptographic techniques to ensure integrity; secure storage; and presentation for the various different stakeholders, auditors and regulators. Specifically, the process must be designed in such a way as to:

  • Give account of events and occurrences within the services of cloud providers in a non-invasive manner to the customers’ privacy and without exposure of sensitive material from the inside of organisations;
  • Ensure information is collected securely in a tamper-evident process, which however may allow verification checks from different services, tools and trusted third parties (e.g. auditors);
  • Avoid excessive data collection, minimising privacy issues and ensuring scalability of evidence storage with time, even with growing user bases and multi-tenancy scenarios.

To address this challenge the A4Cloud project has designed a Framework of Evidence (FoE) consisting of a set of mechanisms for extracting evidence in typical scenarios encountered in cloud services and managing their full lifecycle [47]. The FoE provides automated support to all the phases of the evidence lifecycle: monitoring, collection, storage, verification and presentation. The FoE considers four main types of sources:

  • Internal data as logs, metadata SIEM outputs, etc., collected from monitored operations and services;
  • Data from end-users or from a cloud service to another, or internal data as customers’ or employees’ lists, training certificates, seals, etc.;
  • Documentation of the service’s practices, contracts and organisational policies that relate to accountability and for which implied obligations can be expressed (manually or by other A4Cloud tools like AccLab or COAT – discussed later in the document) in machine-readable policies;
  • Cryptographic proofs that are generated upon request at a particular point of time.

Using the FoE, the collected and processed evidence are assembled and stored as records. These records contain elements supporting a claim such as the actions that the evidence records, a timestamp, the identity of the authenticated agent that performed the recorded action and a reference to the policy that the action may or may not comply with. Among the supporting elements included in the records, audit logs and cryptographic proofs are of particular interest in the proposed Framework of Evidence. Audit logs provide documentary evidence of a sequence of events, actions and changes observed in the accountable service. They support the occurrence (or not) of an operation and demonstrate compliance or non-compliance with the policies. Audit logs must be protected against adversarial tampering or deletion to provide a non-disputable record of events. Logs also enforce the correct system behaviour since the latter is held accountable for the events, changes and actions that are logged in the audit logs. Cryptographic proofs provide an instantaneous assurance of correct (or not) behaviour of the accountable system, verifiable at any point of time. They are intended to convince any entity verifying them that the system provides the appropriate safeguards when processing and storing data. As an example of such proofs, in the project we focus on a particular cryptographic proof of storage called proofs of retrievability. They ensure with high probability that the accountable system stores the outsourced data as expected in policies, contracts and regulations and that this data is retrievable at any point of time.

Evidence contributes to account definition, attribution of responsibilities and policy violation reports.

Therefore, to support accountability across the provisioning chain, services providing the following high-level functions need to be provided for evidence provision:

  • Support for the extraction of evidence targets (i.e. what to monitor, when, etc.) from policies, ensuring compliance and full coverage (i.e. no obligations described in policies are left unmonitored);
  • Support for collection of logs from different sources and parts of the infrastructure;
  • Support for full lifecycle of evident management (i.e. mechanisms to extract, assemble, secure, store evidence, etc.), ensuring privacy, integrity, verifiability;
  • Support for enforcing access rights with regard to evidence;
  • Support for context-specific presentation of evidence to different parties possessing different access-rights and privileges.

Evidence also supports elements for the provision of the account. The C-2 conceptual framework [1] defines three types of accounts that can be provided. We outline here some examples of evidence that can be provided to support these three different types of accounts:

  • Proactive account: This kind of account may report the quality and security levels of the services provided by the cloud. Evidence in this case may consist of certification of the compliance of the offered data processing and storage services with regulations and contracts. The certificates should designate the party that provides the service, the issuer of the certificate, the validity period of the certificate, the level of security guaranteed by the certified service, etc.
  • Additionally, proactive accounts can be supported by consistency checking reports that act as evidence of contractual obligations agreed between the cloud provider and its customer.
  • Account of compliance: Evidence should be collected to provide an account of a legitimate event to demonstrate that the cloud provider complies with regulations and contracts. Logs are the most relevant sources of evidence to prove policy compliance. However, the integrity of logs may not be always easy to verify. Hence, there may also be additional cryptographic proofs for some cases such as proofs on data storage: for example, Proofs of retrievability, such as the one presented in [47], are cryptographic proofs that verify whether or not a data storage service actually stores the outsourced data. Collected on a periodic basis, these proofs of retrievability enable an auditor to check the correct storage of the data, meaning that the service stores the data as expected by regulation and contracts. Therefore, the proofs of retrievability can support this kind of account.
  • Account of security breach: In case of the occurrence of an incident, evidence should demonstrate that the fault actually occurred, identify the actors and the environmental settings that lead to the incident, assign time and date to the event, and have a reference to the particular policy rule(s) that the reported event infringes. Logs can be an example of such inculpatory evidence to provide an account in case of an incident and to attribute the responsibility of that incident to a particular actor in the cloud. Indeed, logs report the actions performed by a particular entity and record the identity of that entity and the timestamp corresponding to the reported event.

The RA does not prescribe a specific method for providing an account, recognising that in many cases the form and contents of the account as well as the context of its provision are specific to the particular circumstances of the actors involved. For example, a particular account may consist of highly structured and annotated information allowing it to be transmitted electronically in an automated fashion, or may be an e-mail containing textual information that is not organised in a specific way.

However, given that the construction and provision of the account requires the provision of evidence, the RA notes that in order to support accountability across the provisioning chain via the construction and provision of the account, actors need to implement the services supporting evidence provision outlined above, as well as implement services supporting context-specific presentation of the account to different parties possessing different access-rights and privileges, in cases where the account can be processed automatically by computers.