A Trustworthy Usage Control Enforcement Framework

Introduction

Usage control requirements stipulate the handling of data after access is granted and, as such, generalize access control requirements. Typical requirements include “notify when message leaves system”, “don't delete for five years”, “delete data within thirty days”, and also actions one and two on a specific item must not be performed by the same individual”. The handling of data is reflected by system-level events at different levels of abstraction including the operating system (events: system calls), enterprise service buses (ESB; events: messages), windowing systems (X11; events: network packets), and so on. From this perspective, usage control policies hence stipulate allowed and disallowed sequences of events. These policies can be both detective and preventive in nature. Detective policies stipulate what is allowed and what is not allowed. The respective enforcement strategy is optimistic: if the policy is violated, not too much harm will happen, and the violation can be punished, compensated, or sometimes even undone. Preventive policies, in contrast, prevent violations from happening.

In this paper, which is an extended version of one of our previous publications (Neisse, Pretschner, & Di Giacomo, 2011), we present a usage control policy enforcement framework that was developed as part of an EU-funded research project MASTER (MASTER, 2012). In the context of this project, our framework was used to demonstrate two application scenarios in a hospital and an insurance company. Requirements in these scenarios include Chinese Wall, Separation of Duty (SoD), and privacy protection through identity anonymization. Chinese Wall policies are required in an insurance company to prevent consultants working for competing companies from having access to sensitive information. SoD and privacy protection are required in the hospital scenario to anonymize patient data and to minimize the risk of fraud by preventing doctors from prescribing and dispensing medicine without involving a nurse or another doctor. Because of space restrictions, we concentrate on a SoD example in this paper.

The more general setting is as follows. Business processes are formalized as sequences of events. Control objectives (“more than one person should be involved in a drug prescription and dispensation to prevent fraud”) are defined in specification-level policies. Specification-level policies define control objectives, but they do not specify how the objectives can be achieved. This can, in general, be done in different ways: by blocking (e.g., forbid dispensation if the user that prescribed is the same trying to dispense medicine) or by executing additional actions (send a notification to an auditor requesting confirmation that the dispensation is not a fraud). The concrete choice is stipulated in so-called implementation-level policies. The usage control enforcement framework that we describe in this paper has a focus on implementation-level policies.

Our framework can be used for specification and enforcement of implementation-level policies at different levels of abstraction. To illustrate this flexibility we show an implementation that instantiates our framework at the operating system and ESB levels. In this implementation, prescription and dispensation are services running in an ESB. The motivation is that SoD policies enforced at the ESB level can be circumvented by a malicious user by directly modifying the files that contain the prescription and dispensation records. Moreover, in principle, it is simple to circumvent policy enforcement components from our framework, e.g., by killing the respective processes. As a consequence, we need to make sure that this cannot happen, or at least detect if it has happened. Since root users – the extreme case of potentially malicious insiders – usually can do everything they desire, we include in our framework components that use trusted computing technology to create tamper-proof integrity measurement logs. In the case of an audit, root users will then have to justify why specific changes to the system have been applied. For space reasons we do not provide here the security and performance evaluation of the integrity measurement components and refer to a previously published paper that describes this technology (Neisse, Holling, & Pretschner, 2011):