Usage control (UC) is concerned with what happens to data after access has been granted, and is usually defined on the grounds of events that, somehow, are related to data. Data may assume different representations within the system, possibly at several levels of abstraction. This research aims at extending a generic event-driven UC model and its language [1] by the explicit distinction between data and representations of data. The resulting system will be able to enforce policies for single representations (e.g., delete f1.txt after thirty days) as well as for all representations of the same data at once (e.g., if f2.txt is a copy of f1.txt, also f2.txt will be deleted). To this end, different data-flow tracking approaches will be investigated. The result will be implemented, instantiated and evaluated in terms of security, precision and performance.
The ever-growing sharing of digital content in the last decades demands better
technologies to control what may happen to data after access to it has been
granted. Usage Control (UC) [
With this work, I want to investigate a different aspect of the problem: the
data dimension. To enforce a requirement such as “don’t copy this picture” one
must consider that this picture may exist in multiple representations within
the system, potentially residing at different levels of abstraction, like network
packets, Java objects, window pixmaps, data base records, or files. Some UC
requirements, usually related to confidentiality properties, address all the
representations of the same data at once (“this picture cannot leave the local
system”, no matter which copy), whereas other requirements, usually related to
integrity properties, refer to one (or some) specific representation(s) (“content
of file /etc/passwd cannot be modified”, but a copy of it could). The general
research question addressed by this work is “How can usage control requirements
be expressed and enforced on different representations of data within a system,
at and across different layers of abstractions?”. I plan to answer it in three steps:
1) Extending a generic UC model [
2) Define a generic model for tracking flows of data across different instances of the model defined in step 1, possibly at different layers of abstraction (crosslayer data-flow tracking). This will support integration of enforcement mechanisms at different layers to achieve system-wide usage control.
3) Refine the results of steps 1 and 2, in terms of precision e.g. considering DFT approaches that accounts for structural or quantitative aspects of data. This is motivated by preliminary results showing that the overapproximation introduced by basic taint-propagation becomes quickly prohibitive. In summary, The goal of this research is to define, formalize, implement and evaluate a usage control model which supports data flow tracking at and across different layers of abstraction.
The remaining of this paper is organized as follows: in §2 I compare my work to existing solutions; in §3 I describe a use case of my system; in §4 and §5 I discuss the different steps of my research plan and some preliminary results. 2
The subject of my research is the combination of data flow monitoring with usage control, a policy language, and a prototype enforcement infrastructure.
A number of policy languages, like [
In terms of general-purpose usage control models, I see similarities with
the models underlying XACML [
Concerning data flow tracking, my approach restricts the standard notion
of information flow analysis, which also caters to implicit flows and aims at
non-interference assessments [
This scenario relies on instantiations of the model for a mail application (Mozilla Thunderbird, TB) and its underlying OS (MS Windows). Imagine Alice wants to send some sensitive content (text and pictures) to Bob via mail, while setting some restrictions on its usage such as “The content of this mail cannot be printed, forwarded nor saved on removable devices and it must be deleted within 30 days”.
When Bob opens the mail, he tries to print it, but the action is forbidden; similarly, the “Forward” button is disabled. Bob then creates a new message and drag&drops some content from Alice’s mail to it. This action is allowed, but in order to prevent violations of the “no-forward” policy, the new mail is also not allowed to be sent. This is enforced thanks to the data-flow tracking component, which recognizes the two mails as representations of the same data. (Step 1)
Afterwards, Bob tries to save the attached picture to his USB stick. The policy that forbids it cannot be enforced by TB, because file management is an OS duty. Hence, after Bob chooses where the file should be saved (but before the actual saving), the monitor for TB notifies the OS monitor about the policy. Only then TB starts to save, but, as required, the OS denies it. (Step 2)
Bob then saves the picture to a local folder. When he browses it with the file explorer, the icon of the picture file is replaced by its thumbnail preview, which is automatically generated by Windows and stored in a hidden file (Thumb.db) in the same directory. After 30 days, all the copies of the picture, identified by the data-flow tracking system, are deleted. Thumb.db, however, containing only a small amount of data of the original picture (plus the thumbnail of many other files), is not considered as a copy and thus it is not deleted. (Step 3)
Note that, under different assumptions on the environment, usage control can be used against deliberate attackers (like Bob) or to mitigate unintended disclosures (e.g. Alice preventing herself from disclosing sensitive data by accident). 4
Step 1: Usage Control & Data Flow Tracking In the example above, Alice formalizes her requirements in a language that supports UC constraints specification, like “delete within 30 days”, while, at the same time, addressing abstract data (the content of a mail) in lieu of specific representations of it (a mail, a file, a window, etc.). She may also want to express data-dissemination restrictions, like “this data should never leave the local system”, regardless of which sequence of events leads to the disclosure. The definition of such language and the respective system model are the goals of this part of my research, which addresses the question “How can we express and enforce data-centric UC requirements?”
To answer it, I will augment a policy language [
Thus, the second step of my thesis will be the definition of a UC model that relates representations of data at different levels, like f and w. The problem is far more complex than “just connecting” data representations at different levels. A relation between events must also be defined, because the execution of an action (like “save as” in Thunderbird) may result in several events at another level (e.g. “open”,“write” and “close” system calls at the OS level). This introduces additional problems, e.g synchronization and race-condition issues.
The fundamental question addressed at this step is How can we relate data representations and events at different levels of abstraction? I plan to tackle it with a bottom-up strategy: firstly, I will connect two specific existing implementations (for Thunderbird and Windows), looking for a common shared knowledge-base on top of which the cross-level relationship can be defined. Then, I will extend this model by adding, one-by-one, other layer-specific instantiations of the model of step 1. Existing implementations offer the advantage of knowing a-priori when and where data flows from one level to another.
Finally, I will try to leverage the result to generalize the model for arbitrary number and type of levels. The expected outcome is a framework for dynamically connecting arbitrary instantiations of the model; new monitors and enforcement mechanisms can be added at any time and share usage information with existing components, working together for a single system-wide enforcement. Step 3: Data Flow Tracking Refinement Preliminary results (§5) show that the overapproximation induced by the taint-based data-flow tracking introduces enough false positives to compromise the overall functionality of the system. That is why, as third step, I will refine my data-flow tracking precision. The fundamental questions addressed here are: “How can we measure the exact amount of data flowing within the system? How should such value be interpreted? ”
To answer this question I plan to a) augment the taint-based analysis of step 1 with quantitative aspects and b) consider the structure of data representations. In terms of a), the benefit of measuring the amount of data stored in each representation is twofold: on one hand it allows specification of quantitative policies such as “if a file contains more than 5% of sensitive data, then delete it upon logout” ; on the other hand, it can be used as a possible declassification criterion.
Note that usually quantitative measurements are used to determine how
many bits of information flow from inputs to outputs in a program [
In terms of b), I want to refine the taint-propagation by considering the structure that data exhibit when stored by particular events in special types of containers (e.g. a ZIP archive file). In this case, the taint-propagation in case of a split-event (e.g. decompress), will introduce a lot of useless overapproximation. Evaluation and Limitations At the end of each step, I will evaluate the results in terms of security, precision and, when possible, performance. According to preliminary results, the overhead of the monitoring infrastructure is above two orders of magnitude. Given the expected complexity of the outcome, my goal is to achieve, at the end, a usable system. Hence, fine-grained tuning and extreme performance optimizations will be analyzed, but their implementation is out of scope. Similarly, policy management and policy deployment, as well as details on distributed aspects of usage control and guarantees (enforcement mechanisms are up and running, not tampered with, etc.) will not be part of this research. 5
Preliminary results have been published in [
Acknowledgments This work was done as part of the DFG’s Priority Program SPP 1496 “Reliably Secure Software Systems,” ref. numbers PR-1266/1-2.