Log Design for Accountability

Abstract

International audienceThe position put forward in this paper is that accountability is a requirement to be taken into account from the initial design phase of a system because of its strong impact on log architecture implementation. As an illustration, the logs we consider here record actions by data controllers handling personally identifiable information to deliver services to data subjects. The structures of those logs seldom take into account requirements for accountability, preventing effective dispute resolution. We address the question of what information should be included in logs to make their a posteriori compliance analysis meaningful. Real-world scenarios are used to show that decisions about log architectures are nontrivial and should be made from the design stage on. Three categories of situations for which straightforward solutions are problematic are presented. Our discussion shows how log content choices and accountability definitions mutually affect each other and incites service providers to rethink up to what extent they can be held responsible. These different aspects are synthesized into key guidelines to avoid common pitfalls in accountable log design. This analysis is based on case studies performed on our implementation of the PPL policy language

Constructing Independently Verifiable Privacy-Compliant Type Systems for Message Passing between Black-Box Components

“…Le Métayer et al [3,2,7,6] have described several languages for describing architectures and deciding privacy-related properties over them. Barth et al [4] also give a formal definition of architectures, and show how to decide properties defined in temporal logic.…”

Log Analysis for Data Protection Accountability

“…Actually, one of the arguments against the use of accountability of practice is that the logs required to implement it could in fact represent an additional source of risks for personal data. As illustrated in our work [4], designing the contents of the logs is therefore far from obvious: intuitive solutions typically include too much data or omit information necessary for effective compliance. -A clear definition of the accountability process has to be provided, showing how accounts are built and analyzed.…”

“…The format of the logs is a key design choice for an accountability architecture. As discussed in [4], this choice is far from obvious. In our framework, it is guided by two factors: the privacy policies which have to be verified and the aforementioned data minimization principle.…”

“…The formal framework presented in this paper contributes to the three types of accountability introduced in §1: it can be used to provide precise definitions of privacy policies and to build log analysers to check the compliance of a log with respect to the privacy policies of the data collected by the DC. Actual log files can be parsed and converted by log abstraction to traces that can be mechanically checked as in [4]. In addition, it suggests a number of manual checks and procedural measures required to complement the log analysis and make it fully effective.…”

Towards a Multidisciplinary Framework to Include Privacy in the Design of Video Surveillance Systems

“…Available means to achieve this accountability of practice include privacy policy languages such as EPAL [7] or PPL [20], which allow the precise specification of (technical) data handling policies. These standardised policies can then be used to analyze system operation traces (audit logs) through a posteriori technical compliance control [8,11].…”