Assigning Responsibility for Failed Obligations

Abstract

Traditional security policies largely focus on access control. Though essential, access control is only one aspect of security. In particular, the correct behavior and reliable operation of a system depends not only on what users are permitted to do, but oftentimes on what users are required to do. Such obligatory actions are integral to the security procedures of many enterprises. Unlike access control, obligations assigned to individual users are often unenforceable, that is, the system cannot ensure that each obligation will be fulfilled. Accurately determining who was at fault when obligations are not met is essential for responding appropriately, be it in terms of modified trust relationships or other recourse. In this paper, based on a formal metamodel of obligations, we propose an approach for fault assessment through active online tracking of responsibilities and dependencies between obligations. We identify and formalize two key properties for the correct assessment of fault, and design responsibility assignment and fault assessment algorithms for a concrete yet general access control and obligation system.

Delegation of Obligations and Responsibility

“…On the first hand, if a and c share a source forbidding an agent to harm another in the way c did, then a liability can be derived from that, and the corresponding sanction will be considered independently from x. It can also be the case that c broke one of its own norms and is sanctionned for that [10], but that its liability is not towards b. On the other hand, if c has not violated any norm applying to it, then it is not faulty in any way and has neither to be sanctionned nor to provide a reparation.…”

“…By default, any delegation that is not allowed is forbidden, and deny has priority over allow. The overall rule for deriving an obligation delegation from a delegation attempt is described by (10).…”

“…delObAttempt(A, P, B, C, X, FRoption, Loption), O(B, P, C, X), allow(B, A, P, C, X, FRoption, Loption, ), ¬deny(B, A, P, C, X, FRoption, Loption, ) delOb(A, P, B, C, X, FRoption, Loption) (10) Obligation chains We have seen that an obligation can be delegated with or without delegating (or sharing) liability towards the original obligator. In order to decide whether an agent is liable towards another for a given obligation, one must know whether there is a chain of obligations (including both the initial one and the delegated ones) between them, and whether liability has been shared or forwarded at each step.…”

“…Yet, agents can violate their obligations due to various causes that can be related to agents themselves (e.g. lack of time or competence), or to other agents who have performed (or not) actions such that they have blocked out the fulfillment of the obligation, or finally to system faults, such as a system dysfunctioning or insufficient authorization/resource [10]. For these reasons, it is necessary to have means to clearly identify the responsibility of agents that are involved in the obligation violation, especially when obligations are delegated to one or more other agents.…”

Beyond accountability

“…Many application domains, including healthcare information systems, require the inclusion of obligations as part of their access control policies [3,7,13]. An obligation is an action that needs to be performed by a user before or after accessing a resource 1 .…”