4.4.3 Accounts within the Service Provision Chain

A number of incident scenarios are being studied by work package D4. Some incident categories can be identified by the A4Cloud detective tools and other categories would fall outside the scope of the description of work, but standard techniques and tools can be used to detect them. For instance, non-compliance with respect to data location constraints can be detected by the Data Transfer Monitoring Tool (DTMT) ^[25], but a machine infected with malware allowing a malicious external agent to have unauthorised access would not be the main focus of our tools. Once a potential data breach has been notified to the data controller (via e.g. the A-PPL Engine), evidence needs to be analysed to confirm the breach. This later step can be achieved with the help of the techniques devised in work package C-8 and the Audit Agent System (AAS), for instance, which will help to identify where failures occurred in the cloud service provisioning chain. Finally, the data subject notification can be handled as described above, possibly with the support of the Incident Response Tool, which has been developed in the context of work package D-4.

Remedial actions can be imposed by the DPAs upon data subject complaint fillings. For a detailed legal analysis of remediation and redress mechanisms, please see MS:D4.1 [33]. The search of an arrangement to remediate damages caused by a breach can be facilitated by the Remediation and Redress Tool, also under consideration in D-4.

For a more precise incident please consider the following scenario from D-4:

"Misconfiguration of services and failing to patch software quickly can lead to severe security problems such as being vulnerable to exploits and violating security requirements. Recent SSL vulnerabilities such as POODLE, BEAST and Heartbleed are prime examples for the need to patch as soon as fixes become available. However, patching may not be enough in some cases. For instance, to mitigate the Heartbleed vulnerability, certificates need to be replaced, old certificates revoked and private keys changed. Besides that, problems can arise from service misconfiguration. The recently discovered POODLE vulnerability is closely linked to obsolete protocols being allowed (which is an SSL configuration problem). Also, in cases where strong cryptography is required, specific SSL configuration is required (protocol versions, available cipher suite, cipher order, algorithms, key length, certificate status...)."

An attacker can gain access to personal data by exploiting this kind of vulnerability. In some cloud provisioning chains, it can be complex to identify whose responsibility it is to apply the necessary patches and updates to the software. This will depend on the service model and on the contractual agreements in place. The A4Cloud approach and tools help to clarify these situations: from detection until the remediation phase.

Another example from D4 of a data breach has to do with a data holders right to have access to a set of data (right to know). In such a case, individuals are granted access to specific data, but in case of a contextual change in the individuals behaviour over such access rights (such as a large number of access requests in a short period of time), this may imply a potential violation (need to know property). An example like this is common in todays security systems, which adopt intrusion detection mechanisms or perform log and error analysis to monitor malicious intruders and discover misbehaviour, which can result from e.g. the loss of credentials from the data subjects side. If an intrusion is detected, then the responsible system administrator is informed of the timestamp of the event and the details of intrusion attempt (e.g. who, what, reason for alarm, etc.). The relevant data subject will occasionally be informed, but this is subject to the responsible behaviour of the service provider, while the notification of the breach will be mainly handled in a manual way (such as by mail). As happens with the previous example, in this example the handling of the breach involves multiple notification recipients, each of whom should receive a different level of informed actions to respond to. In case of the data subject, as mentioned earlier, this actor will occasionally be notified that their credentials have been compromised, in a way that could enable hackers to enter the system with their digital identity. On the other hand, the DPA may also be informed in case of these events, since this actor has to be told the details of this breach if the damage is severe, including the affected personal data and the respective data subjects and the actions undertaken to mitigate the risks from the exposure of the breach.