Information systems might access, manage and record sensitive data about citizens. In addition, the pervasiveness of these systems is dramatically increasing and increasing thanks to the mobile and the IoT revolutions. However, several unintended data breaches are reported every week, and this might compromise the privacy, safety, and security of citizens. For all these reasons, the European Parliament approved in April 2016 the EU General Data Protection Regulation (GDPR). The main goal of such regulation is to protect the privacy of citizens with regard to the processing of their personal data. It enforces a Privacy by Design and by Default approach, where personal data is processed only when needed by the functionalities of the information system. On the other hand, static analysis aims at proving at compile time various properties on information systems. This discipline has been widely applied during the last decades to identify potential software leaks of sensitive data. In this scenario, this paper discusses what role static analysis could play in a GDPR perspective. In particular, we introduce GDPR and static analysis, and we then propose how existing taint analyses and backward slicing algorithms might be combined to produce reports useful for GDPR compliance. We identify four main actors in the GDPR compliance process (namely, data protection o cers, chief information security o cers, project managers, and developers), and we propose a speci c level of reporting for each of them.
On April, 27th 2016 the European Parliament adopted the \General Data Protection
Regulation" (GDRP). This regulation will become enforceable on May, 28th 2018, and its goal is
to lay down \rules relating to the protection of natural persons with regard to the processing
of personal data and rules relating to the free movement of personal data" [
Roughly speaking, GDPR allows an information system to access, and manage sensitive
data that is needed to perform the functionalities of the system following the Privacy by Design
[
During the last decades, static program analysis has been widely applied to various properties. From a GDPR perspective, privacy analyses aimed at detecting possible leakages of sensitive data are particularly promising, since they allow to detect potential leaks at compile time before the system is deployed. Therefore, they might help to prevent unintended data breaches because of software vulnerabilities and leaks.
In this scenario, the main contribution of this paper is to discuss how static analysis might be applied for GDPR compliance. In particular, we discuss (i) how such tools can be applied as a privacy enhancing technology (PET) in the Privacy by Design (PbD) approach, (ii) what types of di erent static analyses for privacy exist, and (iii) what information might be tracked by these tools and how this might be reported to the various actors (namely, data protection o cers, chief information security o cers, project managers, and developers) in the GDPR compliance.
The paper is structured as follows. The rest of this Section will introduce a minimal running example. Sec. 2 presents privacy enhancing technologies, privacy by design and the GDPR. Sec. 3 discusses static analysis avors and its use for privacy analysis. Sec. 4 advocates and formalizes its role for GDPR compliance. Sec. 5 concludes. 1.1
This section provides background about privacy regulations and technologies and the GDPR. 2.1
The concept of Privacy Enhancing Technologies (PET) has been around for decades [
While PETs intervene at the end of the chain of data manipulation (e.g., anonymization before
communicating or storing the data), \the Privacy by Design approach is characterized by
proactive rather than reactive measures. It anticipates and prevents privacy invasive events before
they happen. PbD does not wait for privacy risks to materialize, nor does it o er remedies for
resolving privacy infractions once they have occurred { it aims to prevent them from occurring.
In short, Privacy by Design comes before-the-fact, not after" [
The GDPR will come into enforcement on May 28th, 2018. It enforces PbD as a legal obligation
for entities that control and/or process privacy data. Its Article 25 (data protection by design
and by default) recites: taking into account the state of the art, the cost of implementation and
the nature, scope, context and purposes of processing as well as the risks of varying likelihood
and severity for rights and freedoms of natural persons posed by the processing, the controller
shall, both at the time of the determination of the means for processing and at the time of the
processing itself, implement appropriate technical and organizational measures, such as
pseudonymization, which are designed to implement data-protection principles, such as
data minimization, in an e ective manner and to integrate the necessary safeguards into the
processing in order to meet the requirements of this Regulation and protect the rights of data
subjects. Article 25 further arguments that the controller shall implement appropriate technical
and organizational measures for ensuring that, by default, only personal data which are
necessary for each speci c purpose of the processing are processed. That obligation
applies to the amount of personal data collected, the extent of their processing, the period of their
storage and their accessibility. In particular, such measures shall ensure that by default personal
data are not made accessible without the individual's intervention to an inde nite number of
natural persons. PETs and PbD will become mainstream, to ful ll the legal obligations imposed
by GDPR (in particular, Principle 1 of PbD). Institutions, such as ENISA, already provide
community standards on the evaluation of PETs [
Certi cations and guidelines often impose, discuss or suggest the use of static analysis [
Wikipedia1 de nes it as the analysis of computer software that is performed without actually executing programs. This includes for instance manual software audit, but this article restricts its scope to automatic software static analysis, to focus on a technical discussion. 3.2
A static analyzer issues alarms at program points where an actual bug might occur at runtime,
such as a NullPointerException, or the code might be ine cient, because for instance of an
unused variable, or a security vulnerability might be exploited, such as an SQL injection, or
private data might be leaked, by sending for instance the user identi er to a website, as in
Fig. 1. Alarms might be (i) true alarms (such as signaling an information leak at line 14 in
Fig. 1); (ii) false alarms, that are not actually problems (such as reporting a warning at line
2); (iii) true negatives (no alarms at non-problematic program points, such as not reporting
a warning at line 2); or (iv) false negatives (missed true problems, such as not reporting an
information leak at line 12). Fig. 2 depicts these concepts: the left side contains the problematic
program points; the right side the non-problematic ones; the upper part is what is reported
by the analysis, while the lower part is what is not reported. Ideally, a static analyzer should
feature true alarms and true negatives only. This, however, is not computable in general [
A warning should embed contextual information about its meaning. For instance, a warning might explain where a null value was assigned to a variable that gets dereferenced. A privacy violation warning might report the source program point where sensitive data was disclosed and the data ow from the source to the sink. This lets the developer determine if the warning is a real issue: if the source is not deemed relevant or if the ow is sanitized in the middle, the developer might decide to ignore the warning. Privacy warnings might also report the API call that discloses the information (such as URLConnection.connect()) or might specify the exact kind of sensitive data that is disclosed (such as the longitude and the latitude of the user). For instance, a static analyzer might be able to see that the method calls at lines 5, 9, and 10 in Fig. 1 lead to a leak of con dential information, while that at line 2 does not. In addition, it might report that line 5 discloses the IMEI of the telephone, line 9 the location projected on the latitude, and line 10 the longitude.
A sound static analyzer considers all possible executions of a program and consequently does not miss any true alarm while still featuring some false alarm. If it does not issue any alarm about a property, then the program always satis es that property. That is, sound analyzers have no false negatives. In Fig. 1, it would report that there is an information leak at line 14 when send is called from lines 5, 9 and 10; it might also report a false information leak alarm when send is called from line 2, if it does not track context-sensitive information.
Full soundness is still an open problem for real programming languages such as Java and
Android, that feature complex execution behaviors. It is often compromised because of the
application lifecycle (components of mobile apps use complicated event-based execution models,
triggered by external actors); re ection (applications can use data as code and consequently
perform arbitrary dynamic executions); multithreading (arbitrary interleavings are too many for
the analysis); native code (machine language translated from any other programming language
can be linked, that the analyzer does not understand); dynamic class-loading (code is loaded
at runtime, unknown at analysis time). For instance, an analyzer unsound wrt. the Android
application lifecycle could miss that the operating system calls onLocationChanged in Fig. 1;
the analyzer could consequently miss the leak of the user location. To the best of our knowledge,
current analyzers are all unsound wrt. native code (which is platform-dependent), while some
support some of the rst four features, at di erent degrees [
Privacy leaks detection in software has been widely studied. It reduces to detection of
information ows from a source of con dential information (e.g., getDeviceIdentifier) to a sink (e.g.,
operations on Internet connections). From this perspective, it is similar to detecting injections
and XSS vulnerabilities, but sources and sinks are not xed but rather user-provided. Early
information ow analyses [
These analyses are the most appealing for GDPR, since they automatically identify leaks and scale (in terms of e ciency and precision) up to the size of industrial applications. However, they provide limited feedback: since a source-sensitive ow analysis would be too expensive, they only track and discover that some sensitive data could be leaked, without further detail; moreover, they only report the program point where data is leaked, not the complete ow. 4
A few years ago, ENISA already underlined [
One can identify four main actors in this lifecycle, who apply static analysis for GDPR compliance. The Data Protection O ce (DPO) uses a static analyzer to inspect if the whole system respects the privacy constraints identi ed during design. He needs a very high level view of what sensitive data is leaked (such as the user identi er or location) and to whom. At this level, no technical detail such as precise program points and chain of called methods is needed. The Chief Information Security O cer (CISO) needs a similar view of the system, but with detail about which software components leak which data, in order to identify the project manager who is responsible of leaks unexpected at design time. The Project Manager (PM) needs precise detail for each component about the program points that generated the leak (exact sources, sinks and ow of sensitive data inside the program). This lets the Software Developer (DEV) inspect the code where an alarm is issued. The developer is interested in the exact ow of sensitive data.
Higher levels require information that can be abstracted from lower levels. In particular, the precise ows of sensitive data at DEV level, belonging to the same subcomponent, can be abstracted (removing the exact program points accessing and leaking sensitive data) and aggregated into a unique report at PM level. As a further approximation, many program points can be abstracted into few sources of sensitive data (since the same information can be accessed at di erent program points and in di erent ways), leading to a higher and more readable representation at CISO level. Finally, information can be aggregated to represent privacy leaks of the whole system at DPO level.
Therefore, we start by considering how the exact ow of sensitive data can be reconstructed from the results of a taint analysis and then present how this ows can be abstracted into the information needed at di erent levels. 4.1
Let us start by considering how one can obtain the information necessary at DEV level, by using static analysis. As discussed in Sec. 3, taint analysis can be instantiated to report the program points that could leak sensitive information. To achieve this, taint analysis typically tracks, for each program statement, the local variables and heap locations that might be tainted, that is, could contain sensitive information. It is too expensive to track precisely the source of sensitive data during the analysis, but one can reconstruct full data ows backwards, starting from the sinks.
Namely, for each statement, one can apply backward slicing [
Let St and W be the set of all program statements and warnings, respectively. Each warning refers exactly to one program statement (formally, getStatement : W ! St). We assume that each program p 2 P (where P is the set of all programs) is composed by a set of methods (formally, P = }(Me) where Me is the set of all methods), and each method is represented as a control ow graph (CFG) whose nodes are statements (Me = CFG (St) where CFG (St) represents a control ow graph of statements). On this CFG, taint analysis, given a program, infers a set of warnings, and an entry and exit state for each program statement. Formally, taint : P ! (}(W) ) where is the set of states of the taint analysis reporting the local variables that are tainted, and = St ! represents the results (that is, entry and exit states) obtained by the taint analysis on each statement of the program.
We can then reconstruct the ow of sensitive data by computing a backward slice [
Running Example: Consider the running example we introduced in Section 1.1. We assume that the location (received by the listener onLocationChanged at line 8) and the user IMEI (read by calling TelephonyManager.getDeviceId at line 4) are considered as sources of sensitive data, while sending information (through a call to URL.openConnection().connect() at line 14) is a sink. On this program, the taint analysis produces one warning at line 14 reporting that some sensitive data might be leaked. We then apply backward slicing to this program point and we obtain three distinct slices: (i) a slice from line 4 to 5 and then 14 (formalized by s1 = 4 ! 5 ! 14) representing the leakage of the identi er, (ii) s2 = 9 ! 14 (leakage of latitude), and (iii) s3 = 10 ! 14 (leakage of longitude). Note that the backward slicing is in position to discard the ow coming from the call to send at line 2 (that is, the slice 2 ! 14) by checking that this method call does not pass tainted (i.e., sensitive) data through the parameters. 4.2
We now discuss four di erent levels of reporting targeting the four main actors we identi ed (namely, data protection o cers, chief information security o cers, project managers, and developers). Starting from the information inferred by static analysis through taint analysis and backward slicing (as formalized in Section 4.1), we present these reports as further abstractions starting from the one that contains the most detailed information (that is, the report for developers).
DEV The developer needs to know full details about ows of sensitive data, to determine if the ow was real and which sensitive data is involved. The slices computed by the backward slicing algorithm contains the information needed at DEV level since, for each ow of sensitive data to a sink, it reports complete detail of the ow. Hence, one can formalize the DEV report as follows:
DEV : P ! }(S) DEV (p) = Sw2W1 backwardSlice(w; ) where taint (p) = (W1; ) Running Example: The DEV report contains the full details of the three slices introduced in Section 4.1. In this way, the developer can inspect the complete ow of sensitive. PM The project manager is interested in knowing what subcomponents generated the ows of sensitive data and complete detail of the sources and sinks, at source code level. His goal is to identify the developers that implemented such piece of code. One can abstract DEV into PM by (i) aggregating all leaks whose source is in the same component; and (ii) abstracting the ows into pairs composed by a source and a sink. Assume that a function component : St ! C speci es which component a statement belongs to, and functions source : S ! }(Source) and sink : S ! Sink return the possible sources and the sink of a given slice (where Source St and Sink St), respectively. One can project DEV (that is, a set of slices) into PM as follows: PM : }(S) ! (C ! }(Source Sink))
PM (S1) = [c 7! Ss2S1;source2source(s)f(source; sink) : sink = sink (s) ^ component (source)g] Running Example: Let us assume that the running example in Figure 1 is made by two components: st concerns the start of the application (method onStart), while loc deals with location updates (method onLocationChanged). Therefore, the PM report will related (i) component st to the singleton f(4; 14)g (representing the leakage of user identi er), and (ii) component loc to the set f(9; 14); (10; 14)g (representing the leakage of latitude and longitude, respectively).
High level managers such as the Chief Information Security O cer would be interested in knowing which subcomponent of the system accessed and leaked which sensitive data. Hence, as a further abstraction, one can aggregate sources and sinks by projecting them into their types. Assume that functions sourceType : Source ! SourceTypes and sinkType : Sink ! SinkTypes translate sources and sinks to their type, respectively, are provided. The projection of PM into CISO is de ned as follow:
CISO : (C ! }(Source Sink)) ! C ! }(SourceTypes SinkTypes)
CISO (p) = [c 7! S(source;sink)2p(c)(source(source); sink (sink)) : c 2 dom(p)] Running Example: Let us assume that longitude and latitude are both abstracted to the same source type called Location (since they both represent very precise geographical information), while the user identi er is represented by the source type IMEI. Instead, the sinks that transmit data over Internet are represented by Internet. Therefore, the CISO report applied to our running example of Figure 1 will relate component st to f(IMEI; Internet)g, and component loc to f(Location; Internet)g. This report abstracts away the implementation details about the method calls accessing and leaking the sensitive data, as well as the ow of such data inside the program. However, it can be understood by actors in the software lifecycle that are not involved in the technical implementation details.
DPO The data protection o cer needs a high-level and legal view of how the whole software system deals with sensitive data. Hence, one can project away the information about components from CISO and produce the DPO information. Formally,
DPO : (C ! }(SourceTypes DPO (t) = S(sourceType;sinkType)2dom(t)(sourceType; sinkType)
SinkTypes)) ! }(SourceTypes
SinkTypes) Running Example: This last level of abstraction merges together the two components tracked by the CISO into the same set, producing f(IMEI; Internet); (Location; Internet)g. Through this information one might check if the information inferred by the static analysis matches what was expected by the system design. 4.3
Let us summarize the main components needed to develop the four GDPR reports DEV, PM, CISO and DPO). First of all, one needs a set of sources Source and sinks Sink. For injection analysis these sets are usually xed (for instance, reading servlet inputs are sources and SQL methods are sinks for SQL-injection), for GDPR we expect that these sets will be speci c to the software system under analysis, since di erent software rely on APIs providing sensitive data in various ways. In addition, one needs the abstraction of software sources and sinks (such as getDeviceId and connect in Fig.~reflst:runningexample) to types of sensitive data (device identi er) and data leaks (leakage to <site>). These components are formalized by functions sourceType and sinkType. In any case, the GDPR requires to identify how sensitive data is accessed (that is, the set of sources together with their abstraction) and leaked (sinks). Finally, one needs to know how the software system is split into components (function component ), a common information available on all structured software systems. 5
This paper discussed how static analysis can be applied for GDPR compliance. In particular, it introduced some aspects of the EU General Data Protection Regulation, and existing applications of static analysis to privacy properties. It then identi ed four main actors (developers, project managers, chief information security o cers, and data protection o cers) that could be involved at various stages of GDPR compliance, and formalized how combining existing static analyses and information can lead to useful reports for GDPR compliance. The nal vision is that static analyzers can be applied to help GPDR compliance re-using existing static analyses (and in particular, taint analysis and backward slicing) and information (about source and sinks, and software components).
These ideas are currently being implemented into the Julia static analyzer [