Results in Workflow Resiliency: Complexity, New Formulation, and ASP Encoding

09/26/2018
by   Philip W. L. Fong, et al.
University of Calgary
0

First proposed by Wang and Li in 2007, workflow resiliency is a policy analysis for ensuring that, even when an adversarial environment removes a subset of workers from service, a workflow can still be instantiated to satisfy all the security constraints. Wang and Li proposed three notions of workflow resiliency: static, decremental, and dynamic resiliency. While decremental and dynamic resiliency are both PSPACE-complete, Wang and Li did not provide a matching lower and upper bound for the complexity of static resiliency. The present work begins with proving that static resiliency is Π_2^p-complete, thereby bridging a long-standing complexity gap in the literature. In addition, a fourth notion of workflow resiliency, one-shot resiliency, is proposed and shown to remain in the third level of the polynomial hierarchy. This shows that sophisticated notions of workflow resiliency need not be PSPACE-complete. Lastly, we demonstrate how to reduce static and one-shot resiliency to Answer Set Programming (ASP), a modern constraint-solving technology that can be used for solving reasoning tasks in the lower levels of the polynomial hierarchy. In summary, this work demonstrates the value of focusing on notions of workflow resiliency that reside in the lower levels of the polynomial hierarchy.

READ FULL TEXT VIEW PDF

Authors

page 1

page 2

page 3

page 4

09/07/2021

Aspartix-V21

In this solver description we present ASPARTIX-V, in its 2021 edition, w...
04/14/2011

Backdoors to Tractable Answer-Set Programming

Answer Set Programming (ASP) is an increasingly popular framework for de...
08/15/2020

How to build your own ASP-based system?!

Answer Set Programming (ASP) has become a popular and quite sophisticate...
08/09/2021

Harnessing Incremental Answer Set Solving for Reasoning in Assumption-Based Argumentation

Assumption-based argumentation (ABA) is a central structured argumentati...
12/05/2019

Solving Advanced Argumentation Problems with Answer Set Programming

Powerful formalisms for abstract argumentation have been proposed, among...
03/03/2018

Path Puzzles: Discrete Tomography with a Path Constraint is Hard

We prove that path puzzles with complete row and column information--or ...
05/07/2021

Solving the Workflow Satisfiability Problem using General Purpose Solvers

The workflow satisfiability problem (WSP) is a well-studied problem in a...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Confidentiality, integrity, and availability are three essential goals of security. This paper is about availability considerations in workflow authorization models.

A workflow is an application-level abstraction of a business process. Access control in a workflow application is captured in a workflow authorization model (Thomas and Sandhu, 1998; Atluri and Huang, 1996; Bertino et al., 1999; Tan et al., 2004; Crampton, 2005), the main idea of which is to realize the Principle of Least Privilege (Saltzer and Schroeder, 1975) through permission abstraction (Baldwin, 1990). Instead of granting permissions directly to users, permissions are granted to the steps of a workflow. When a user is assigned to perform a step in the workflow, the permissions are then made available to the user. Two additional access control features are typically found in a workflow authorization model. First, qualification requirements can be imposed on each workflow step. An example is to require that the “Prepare Budget” step be carried out by an “Account Clerk,” while the “Account Review” step be carried out by an “Account Manager” (example taken from (Wang and Li, 2010)). This is typically framed in terms of roles in an underlying Role-Based Access Control (RBAC) model. Second, further security constraints may be imposed across steps to prevent abuse. A classical example would be separation-of-duty constraints: e.g., the “Create Payment” step and the “Approve Payment” step must be carried out by two distinct users (example taken from (Crampton et al., 2013)). Recent works in workflow authorization models have considered arbitrary binary constraints, thereby introducing into workflow authorization models an element of Relationship-Based Access Control (ReBAC) (Wang and Li, 2007, 2010; Khan and Fong, 2012).

As permissions are now encapsulated in workflow steps, we want to make sure that the workflow can actually be executed, or else the situation amounts to a denial of service. In other words, one must ensure that it is possible to assign users to workflow steps, so that all qualification requirements and security constraints are satisfied. This notion of availability has been known in the literature as the workflow satisfiability problem (WSP) (Bertino et al., 1999; Crampton, 2005; Wang and Li, 2010; Crampton et al., 2013). WSP can be used as a policy analysis to help the workflow developer debug her formulation, so that the latter is not overly constrained.

A major landmark in the study of the WSP has been the work of Wang and Li (Wang and Li, 2007, 2010), who first introduced into the literature the application of Fixed Parameter Tractable (FPT) algorithms (Fellows, 2013) to solve WSP. Subsequently, major breakthroughs in the design of FPT algorithms for WSP have been invented by the research group at Royal Holloway University of London, including kernelization algorithms (Crampton et al., 2012, 2013; Crampton and Gutin, 2013), exploitation of problem symmetry in pattern-based algorithms (Cohen et al., 2014, 2016), and novel problem formulations (Crampton et al., 2015, [n. d.]),

A second major contribution of Wang and Li’s work is the introduction of an advanced notion of availability that is stronger than workflow satisfiability. That notion is workflow resiliency (Wang and Li, 2007, 2010), the subject of this paper. The idea is to anticipate catastrophes that may remove users from service. One would like to ensure that, even if the adversarial environment has taken away a certain number of users, the workflow is still satisfiable by the remaining personnel. More specifically, Wang and Li proposed three different notions of workflow resiliency, namely, static, decremental, and dynamic resiliency. While decremental and dynamic resiliency have been shown to be -complete, Wang and Li did not provide a matching upper and lower bound for the complexity of static resiliency: static resiliency is in and is -hard. Whether static resiliency is -complete has remained an open problem since the notion was first conceived a decade ago. Bridging this complexity gap is the first motivation of this work.

The last few years have witnessed a renewed interest in the study of workflow resiliency (Mace et al., 2014, 2015a, 2015b; Crampton et al., 2017a). Two lines of research have been representative. The first is the work of Mace et al. (Mace et al., 2014, 2015a, 2015b), who argue that it is more important to assess to what (quantitative) degree of resiliency a workflow enjoys, rather than to test if the workflow is resilient or not (binary). The goal is to offer guidance to the workflow developer in terms of refining the formulation of the business process.

While Mace et al.’s approach is valuable, it is the position of this paper that deep insights of the workflow can be gained by evaluating the workflow against multiple and incomparable notions of workflow resiliency: e.g., statically resilient for a budget of and decrementally resilient for a budget of , where . In fact, each notion of workflow resiliency captures a family of attack scenarios. Confirming that a workflow is resilient in terms of several incomparable notions of resiliency offers deep insight into the formulation of the workflow. We therefore need a good number of notions of workflow resiliency, rather than just a few. More than that, we need notions of workflow resiliency that are not computationally prohibitive to test. Unfortunately, a pessimistic reader of Wang and Li may come to the (unwarranted) conclusion that static resiliency is an exception rather than a rule, and that most notions of workflow resiliency are -complete. This pessimism is understandable as the notions of workflow resiliency proposed by Wang and Li are formulated in terms of strategic games. If resiliency is fundamentally a -complete phenomenon, then hoping for an efficient solution may be unrealistic. A second motivation of this work is to demonstrate that there are indeed useful notions of workflow resiliency that are not as prohibitive as decremental and dynamic resiliency.

A second line of recent work in workflow resiliency is that of Crampton et al. (Crampton et al., 2017a), who devised a first FPT algorithm for deciding dynamic resiliency. The parameter they used was , where is the number of steps in the workflow, and is the number of users that the adversary can remove. While is universally accepted to be a small parameter in the literature (Wang and Li, 2010; Crampton et al., 2013), is not. For example, if is a fixed fraction of the number of users (e.g., 5% of the user population), it already grows much faster than is acceptable for an FPT algorithm. It is the position of this paper that parameterizing the problem using is not fruitful (see §8, however, for an example of adversary models in which such a parameterization could make sense). In this light, non-FPT approaches are still valuable when is not a small parameter. The formulation of algorithmic solutions for workflow resiliency without assuming a small is the third motivation of this work.

This paper has three contributions:

  1. In §3, static resiliency is proven to be -complete, thereby bridging the long-standing complexity gap in the work of Wang and Li (Wang and Li, 2007, 2010). This result also provides the intellectual justification for the third contribution below.

  2. In §4, we dispel the pessimistic interpretation of Wang and Li’s work by formulating a new notion of workflow resiliency, one-shot resiliency, which is more sophisticated than static resiliency, and nevertheless remains in the third level of the polynomial hierarchy (-complete). This means that useful notions of workflow resiliency can be formulated without flirting with -completeness.

  3. We advocate the use of Answer Set Programming (ASP) (Gebser et al., 2013; Gelfond and Lifschitz, 1988), a modern constraint-solving technology, for deciding static and one-shot resiliency. ASP has been shown to be particularly fitted for reasoning problems in the lower levels of the polynomial hierarchy (Eiter and Gottlob, 1995; Eiter et al., 2007; Sakama and Rienstra, 2017; Brewka et al., 2017). In §6, we demonstrate the feasibility of this approach by presenting ASP encodings of static and one-shot resiliency. These reductions employ an encoding technique known as the model saturation technique (Eiter and Gottlob, 1995; Eiter et al., 2007). This solution approach does not require the parameter to be small.

2. Background: Workflow Satisfiability and Resiliency

This section provides a brief introduction to workflow satisfiability and resiliency, in order to prepare the reader to understand the rest of this paper. All the materials presented in this section have already appeared in previous work (particularly (Wang and Li, 2007, 2010)).

2.1. Workflow Satisfiability

A workflow is the abstract representation of a business process.

Definition 2.1 ().

A workflow is a partial ordering of steps. For steps , we write whenever but .

Steps are tasks to be executed by users, and the partial ordering expresses the causal dependencies among steps. If two steps are ordered by , then they must be executed in that order; otherwise, they can interleave in any arbitrary manner.

When a workflow is executed, users are assigned to the steps, sometimes in an incremental manner.

Definition 2.2 ().

Given a workflow and a set of users, a partial plan is a function such that (a) , and (b) is causally closed: that is, for , if and , then . A partial plan is also called a plan when .

Security constraints, such as seperation of duty, may be imposed on a workflow in order to prevent abuse.

Definition 2.3 (in the style of (Cohen et al., 2014, 2016)).

A workflow authorization policy is a 5-tuple , where the components are defined as follows:

  • is a workflow.

  • is a set of users.

  • is the step authorization policy, which lists for each step those users who are qualified to carry out the step.

  • is a set of constraints. Each constraint has the form . The set specifies the steps constrained by the constraint. The component is a set of partial plans, each with as its domain. The set specifies the combinations of assignments that are permitted by the constraint.

The following definition specifies when a (partial) plan satisfies the requirements imposed by a workflow authorization policy.

Definition 2.4 ().

Suppose is a partial plan for the workflow authorization policy . We say that is valid if and only if the following conditions hold:

  • For every step , .

  • For every constraint , if , then there exists such that for every , .

A plan is valid if and only if it is valid as a partial plan.

The following are some examples of constraints. Following (Wang and Li, 2007, 2010), we focus mostly on entailment constraints, including the generalization by (Crampton et al., 2012, 2013). Our ASP encodings of §6 can easily handle the cardinality constraints of (Crampton et al., 2012, 2013) as well.

Example 2.5 ().

Suppose is a set of steps, and is a set of users.

  • Suppose and are non-empty subsets of , and is a binary relation. We write to denote the entailment constraint for which , and .

  • Crampton et al.classify entailment constraints in to various types (Crampton et al., 2012, 2013). A type-1 entailment constraint is one in which both step sets are singleton sets. We overload notation and write to denote . A type-2 entailment constraint is one in which exactly one of the two step sets is a singleton set. A type-3 entailment constraint is one in which neither of the step sets is a singleton set.

  • The separation-of-duty constraint is the type-1 entailment constraint . Similarly, the binding-of-duty constraint is defined to be .

When one formulates a workflow authorization policy, one must ensure that the constraints are not overly restrictive to the point that no valid plan exists.

Definition 2.6 ().

A workflow authorization policy is satisfiable if and only if at least one valid plan exists. is the language of workflow authorization policies that are satisfiable.

Theorem 2.7 ((Wang and Li, 2007, 2010)).

is -complete.

Even though is theoretically intractable, previous work has demonstrated that it can be decided with moderate efficiency by apply modern solving technologies (Wang and Li, 2010), and with even greater efficiency by Fixed-Parameter Tractable algorithms (Wang and Li, 2010; Crampton et al., 2013; Cohen et al., 2014, 2016).

2.2. Workflow Resiliency

For mission critical business processes, a degree of availability higher than workflow satisfiability is often desired. The basic idea is to anticipate catastrophic events, which may render some users unavailable for duty. The goal is to ensure that there is enough redundancy in human resources so that the workflow can execute to completion even when accidents occur.

The first notion of workflow resiliency models a workflow that runs for a very short period of time (e.g., in minutes). Some users become unavailable prior to workflow execution. Due to the short duration of the workflow, no further users are removed from service.

Definition 2.8 (Static Resiliency (Wang and Li, 2007, 2010)).

A workflow authorization policy is statically resilient for an integer budget if and only if, for every subset of that has size or less, there is a valid plan that does not assign the users in .

Workflow resiliency is typically described in terms of two-person games: Player 1 attempts to construct a valid plan, while Player 2, who models the adversarial environment, counters Player 1 by removing users from service. Static resiliency can thus be modelled by a two-person game that is played in one round: Player 2 first removes up to users, and then Player 1 constructs a valid plan with the remaining users. A workflow authorization policy is statically resilient when Player 1 can win no matter how Player 2 plays.

The next notion of workflow resiliency models the situation in which the workflow runs for a moderately long time (e.g., within a day). During the execution of the workflow, more and more users become unavailable.

Definition 2.9 (Decremental Resiliency (Wang and Li, 2007, 2010)).

A workflow authorization policy is decrementally resilient for integer budget if and only if Player 1 can win the decremental resiliency game no matter how Player 2 plays.

The decremental resiliency game is a two-player game that proceeds in rounds. At any time, the configuration of the game is a pair , where , and is a partial plan. In the initial configuration, both and are .

Each round begins by Player 2 choosing some users from to be added to , so long as . (A legitimate special case is when no user is chosen. Also, users added to remain there until the end of the game.) Next, Player 1 extends by assigning a user from to a not-yet-assigned step.

Player 2 wins right away if becomes empty, or if becomes invalid. Player 1 wins if is eventually turned into a valid plan (i.e., every step is assigned a user).

The third notion of workflow resiliency models situations in which the workflow runs for an extended period of time (e.g., in days). Once an accident occurs to remove some users from service, they return to work before the next accident has a chance to occur.

Definition 2.10 (Dynamic resiliency (Wang and Li, 2007, 2010)).

A workflow authorization policy is dynamically resilient for integer budget if and only if Player 1 can win the dynamic resiliency game no matter how Player 2 plays.

The dynamic resiliency game is a two-player game that proceeds in rounds. At any time, the configuration of the game is a partial plan . Initially, is .

Each round begins by Player 2 choosing a subset of such that . Next, Player 1 extends by assigning a member of to a not-yet-assigned step.

Player 2 wins right away if , or if becomes invalid. Player 1 wins if is eventually turned into a valid plan.

We write for the language of pairs for which is statically resilient for a budget . Similarly, we write and for the respective language of decremental and dynamic resiliency.

The three notions of resiliency are totally ordered in terms of how demanding they are.

Theorem 2.11 ((Wang and Li, 2007, 2010)).

.

Note the proper set inclusion in the statement above. While is the least demanding notion of resiliency among the three, its computational complexity is also the least intimidating.

Theorem 2.12 ((Wang and Li, 2007, 2010)).

and are -complete. is in , and is -hard.

Note that the upper and lower bound for do not match. Since the publication of Wang and Li’s works a decade ago, whether is -complete has remained an open problem. The starting point of the present work is to provide an affirmative answer to this problem.

3. Static Resiliency Revisited

The first main contribution of this work is the following result:

Theorem 3.1 ().

is -hard.

In addition to providing a matching lower bound for Wang and Li’s upper bound (Theorem 2.12), this result has practical implications for the choice of solution strategy for . -completeness implies that it is unlikely one can employ -solving technologies to solve . One is now driven to employ constraint-solving technologies that are designed for problems in the second level of the polynomial hierarchy. As we shall see in §5, one such technology is Answer-Set Programming.

Proof.

We sketch a polynomial-time Karp reduction from the -complete problem, Dynamic Hamiltonian Circuit () (Ko and Lin, 1995; Schaefer and Umans, 2002), to .

Problem::

(Ko and Lin, 1995)

Instance::

A simple graph111An undirected graph is simple if it contains neither loops nor multi-edges. , and an edge set .

Question::

Is it the case that for every with , has a Hamilton cycle?

Remark::

The graph is defined to be .

The proposed reduction takes as input an instance of , which consists of a graph and a set . The reduction returns an instance of consisting of a budget and a workflow authorization policy :

  1. is a set of steps, where :

    These steps model a Hamiltonian cycle: each step in models a vertex in the Hamiltonian cycle, and each step in corresponds to an edge in the Hamiltonian cycle.

  2. The partial order is simply the equality relation (). In other words, steps can be executed in any order.

  3. is the set of users defined as follows:

    (1) for
    (2) for
    (3) for

    Intuitively, the users represent vertices and edges in graph . A plan, which assigns users to steps, effectively identifies vertices and edges that participate in the Hamiltonian cycle. All vertices and those edges not in have copies (see (1) and (2)). That means the adversary cannot make these vertices and edges unavailable by removing users. There are, however, only one copy of those edges in (see (3)). The adversary can prevent these edges from participating in the Hamiltonian cycle.

  4. The step authorization policy ensures that users representing vertices are assigned to steps representing vertices, and the same for edges.

  5. The constraint set is made up of two types of constraint. Intuitively, the constraints in ensure that each valid plan identifies a circuit of size , while the constraints in ensure that the identified circuit is Hamiltonian.

    1. is a set of type-1 entailment constraints induced by the binary relation . For every edge connecting vertices , define a binary relation :

      In other words, relates a user representing to a user representing one of the two vertices connected by . Now, is defined as follows:

      We also write to represent the converse222The converse of is the relation . of . In short, relates a user representing a vertex to a user representing an edge that has that vertex as one of its two ends. Now, define :

      The overall effect of the constraints in is that a valid plan identifies a circuit in the graph.

    2. contains type-1 entailment constraints that are specified using the binary relation :

      Intuitively, two users are related by whenever they represent two distinct vertices. can now be defined as follows:

      Effectively, ensures that any circuit identified by a valid plan passes through pairwise distinct vertices: i.e., the circuit is a Hamiltonian cycle.

It is obvious that the reduction can be computed in time polynomial to the size of the instance. Observe also the following:

  1. There is a one-to-one correspondence between a valid plan of and a Hamiltonian cycle in .

  2. For every choice of with , there is a corresponding set of no more than users from that the adversary can remove.

  3. When the adversary removes users from , no more than of them belong . These latter users correspond to a choice of with .

Consequently, the input instance belongs to if and only if the output instance belongs to . ∎

The reduction above employs only type-1 entailment constraints, meaning that type-1 entailment is all that is required to drive the complexity of to the second level of the polynomial hierarchy.

4. One-shot Resiliency

An impression that one may get from reading (Wang and Li, 2007, 2010) is that, with static resiliency as an exception, other notions of workflow resiliency (such as decremental and dynamic resiliency) are largely -complete because of their game-based definition. The goal of this section is to dispel this false impression. We do so by proposing a notion of workflow resiliency that is more sophisticated than static resiliency, and yet remains in the lower levels of the polynomial hierarchy.

4.1. Problem Definition

One-shot resiliency is a generalization of static resiliency and a specialization of decremental resiliency. Rather than removing users at the beginning of the game, as in static resiliency, the adversary of one-shot resiliency may wait till a more opportune time, and then remove users in the middle of the game. Yet, unlike decremental resiliency, in which the adversary may “strike” multiple times, the adversary in one-shot resiliency may only strike at most once.

Definition 4.1 (One-shot Resiliency).

A workflow authorization policy is one-shot resilient for integer budget if and only if Player 1 can win the one-shot resiliency game no matter how Player 2 plays.

The one-shot resiliency game is a two-player game that proceeds in rounds. At any time, the configuration of the game is a pair , where , and is a partial plan. Initially, and are both .

Each round begins by Player 2 opting to either pass or strike, with the restriction that Player 2 must pass in all future rounds after it has struck in a round. If Player 2 chooses to strike, then it further selects no more than users from to be placed in . No action is required of Player 2 if it passes. Next, Player 1 extends by assigning a member of to a not-yet-assigned step, so that remains causally closed.

Player 2 wins right away if , or if becomes invalid. Player 1 wins if is eventually extended to a valid plan.

One-shot resiliency models situations in which the workflow runs for a moderate length of time (as in decremental resiliency), but a catastrophe is a truly rare event. The latter either does not occur, or else it occurs only once. The effect of the catastrophe is irreversible during the execution of the workflow, as in the cases of static and decremental resiliency (i.e., removed users do not return to the game).

We write to denote the language containing pairs so that is one-shot resilient for budget .

Theorem 4.2 ().

.

The proof of this theorem is left as an exercise for the reader.

Even though it is defined in terms of a strategic game, one-shot resiliency remains in the third level of the polynomial hierarchy.

Theorem 4.3 ().

is -complete.

A proof of this result will be given in §4.2 and §4.3. This result provides the intellectual justification for deciding one-shot resiliency through a reduction to first-order Answer-Set Programming with bounded predicate arities (§6)

4.2. Membership in

Input: a workflow authorization plan .
Input: an integer budget .
Output: a boolean value indicating if is one-shot resilient for budget .
Remarks: This algorithm is equipped with an oracle.
1 Guess a functional sequence ;
2 if  is not a valid plan then return false;
3 ;
4 for  from to  do
5       if  then return false;
6       ;
7      
8return true;
Algorithm 1 A non-deterministic algorithm for deciding .

We begin the proof of -completeness by arguing that is in . This argument turns out to be anything but trivial, and it sheds light on the problem structure of : there is a short encoding of a winning strategy for Player 1. This insight will be used in our ASP encoding of in §6.

Suppose is a workflow authorization policy

. We construct a decision tree

that captures the “moves” of Player 1. A sequence is functional if and only if no step appears more than once in . Every functional sequence represents a function that maps steps to users. When is a valid partial plan, we call a play of Player 1. Each play represents a legitimate sequence of “moves” that Player 1 can make (without losing). The decision tree is constructed as follows: (a) tree nodes are plays; (b) a play is the parent of another play whenever (i.e., is obtained from by assigning a user to an additional step). In , the empty sequence is the root of the tree, and a play is a descendent of another play whenever is a prefix of . A play is called a terminus whenever is a valid plan (i.e., every step is assigned). is satisfiable if and only if has at least one terminus.

Suppose is the budget for Player 2. A strike of Player 2 is a pair of the form , where is a play, , , and . The play is the trigger of the strike. Intuitively, a strike is a rule that tells Player 2 to remove the users in immediately after Player 1 has made the moves in . A strike invalidates a terminus when (a) is a descendent of in , and (b) no user from is assigned by after the moves in . A strike is successful if and only if it invalidates every terminus that is a descendent of its trigger. A set of successful strikes is a strategy for Player 2 if the strikes are pairwise independent: two strikes are independent whenever they have distinct triggers that are not descendents of each other. The requirement of independence ensures that Player 2 strikes at most once during a game play. A strategy of Player 2 is a winning strategy if and only if every terminus of is invalidated by a strike in . A strategy subsumes another strategy if and only if (a) every terminus that invalidates is also invalidated by , and (a) invalidates at least one terminus that does not invalidate. A strategy is maximal if and only if there it is not subsumed by any other strategy.

Suppose is one-shot resilient for budget . Consider a maximal strategy for Player 2. Since cannot be a winning strategy, there is at least one terminus that is not invalidated by any strike in . Here is the crux of the present argument: No strike can invalidate , or else we can construct another strategy that subsumes , thereby contradicting the maximality of . The play can be seen as a succinct representation of a winning strategy for Player 1.

Lemma 4.4 ().

if and only if there is a sequence of assignments such that (a) is a valid plan, and (b) for every play that is a prefix of (i.e., is an ancestor of in ), no strike with trigger can be successful.

The idea of Lemma 4.4 can be translated into a non-deterministic algorithm for deciding , as depicted in Algorithm 1. The algorithm begins by guessing a play that corresponds to a valid plan , and then check that no prefix of can trigger a successful strike. An insight is that this latter check can be achieved by invoking an oracle against the “remaining workflow” after the assignments in are committed. This notion of the “remaining workflow” is formalized in the following definition, which defines the notation used in line 1.

Definition 4.5 ().

Suppose is a workflow authorization policy, and is a valid partial plan for . Then is the workflow authorization plan such that:

and is defined as follows:

where the notation is defined below:

Intuitively, selects those partial plans in that are consistent with the assignment of to , and then eliminates the pair from those selected partial plans.

Since is -complete, Algorithm 1 depends on an oracle. In addition, Algorithm 1 runs in non-deterministic polynomial time. Therefore, belongs to .

4.3. -hardness

To demonstrate that is hard for , we present a polynomial-time Karp reduction from SUCCINCT--RADIUS to . The problem SUCCINCT--RADIUS is known to be -complete for every (Hemaspaandra et al., 2010; Schaefer and Umans, 2002).

The radius of a directed graph is the smallest such that there exists a vertex such that every vertex is reachable from by some directed path of length no greater than . (We consider reachable from itself by a directed path of length zero.) Deciding if has a radius no greater than is not hard if is represented as, say, an access control matrix or adjacency lists. What causes the problem to become intractable is when is specified using a succinct representation. In such a representation, the adjacency matrix of is specified through a boolean circuit. Suppose has a size of for some

, then vertices can be identified by bit vectors of length

. The adjacency matrix of can now be represented by a boolean circuit that takes two size- bit vectors and as input, and returns a one-bit value to indicate if there is a directed edge from vertex to vertex . Formulated in this way, deciding if the radius of is bounded by is -complete.

Problem::

SUCCINCT--RADIUS (Hemaspaandra et al., 2010)

Instance::

A boolean circuit that succinctly represents a directed graph

Question::

Is the radius of no greater than ?

Given , one can construct a boolean circuit , which takes size- bit vectors as input, and returns if and only if vertex is reachable from vertex by a directed path of length no more than , and that directed path visits intermediate vertices , , etc in that order.

The circuit tests if and are identical bit vectors. The circuit is defined as follows:

Note that has a size that is times the size of .

One can now check if has a radius no greater than by checking the following:

(4)

Our goal is now to encode (4) using an instance.

Our reduction takes as input an instance of SUCCINCT--RADIUS consisting of a boolean circuit , where has vertices, and constructs an instance of consisting of a budget and a workflow authorization policy :

  1. The steps in are “placeholders” for boolean values representing the input and output bits of , as well as the intermediate values computed by the gates in .

    • .

    • and contain one step for each bit of and .

    • contains one step for each bit in , , for a total of steps.

    • contains one step each gate in . Intuitively, these steps represent the output bits of the gates.

    • contains exactly one step representing the output bit of .

  2. orders the steps in first, then , followed by , and then , and lastly .

  3. Users represent the two boolean values (true and false). A plan can thus be interpreted as an assignment of boolean values to the the input, output, and gates of the boolean circuit . Although there are only two boolean values, there are multiple copies for each.

    There are two variants of boolean values, the -variant (), and the -variant (). “True” is represented by - and -users, and “false” is represented by - and -users. Each boolean value of the -variant has copies (i.e., more than the budget ). There are, however, only copies of each boolean value of the -variant

  4. The step authorization policy describes what type of boolean values can be assigned to each step.

    Essentially, boolean values of the /-variant can be assigned to steps representing , , and the circuit gates. The output of the entire boolean circuit is forced to be true, as only -values can be assigned. Only boolean values of the /-variant can be assigned to steps representing .

  5. contains three types of constraint.:

    1. Constraints in encode the computation performed by the gates in . For example, suppose step corresponds to an AND gate, which in turn takes its two input bits from the output of the gates represented by steps . Then we formulate a constraint , so that contains all partial plans such that is a user representing “true” if and only if both and are users represent “true.” Similar constraints can be formulated for OR gates and NOT gates.

    2. contains exactly one type-1 entailment constraint , where represents the gate that computes the overall output of , and is a binary relation such that whenever and both represent the same boolean value. Since can only be assigned -users, this constraint forces to output “true.”

    3. contains a type-1 entailment constraints for every pair of steps . The binary relation is defined in such a way that if and only if . These constraints forces a linearization of the / truth values when they are assigned to .

The encoding of the boolean circuit is straightforward to understand. We explain here how the quantification structure (--) of formula (4) is captured by the reduction. There are copies of each boolean value of the /-variant, but the budget of Player 2 is only . No matter which users are removed by Player 2, Player 1 can freely assign any boolean values of the /-variant to the steps representing the bit vectors and . That is not the case for . If Player 2 strikes before the steps in are assigned, and it also removes users of the /-variant, then there are only such / values left to be assigned to the steps in . In addition, the constraints in requires that the remaining /-users are assigned to the in “sorted order” of their indices. This means that the remaining boolean values of the /-variant are now linearized into a bit vector when they are assigned to . In this way, Player 2 can dictate the value of . To maximize its control, Player 2 will (a) strike before any of the -steps are assigned, (b) strike after all the -steps are assigned so as to maximize its knowledge of , and (c) remove only users from (since removing users of the /-variant has no effect on the decisions of Player 1). The overall effect is that Player 1 will first pick , then Player 2 picks , and after that Player 1 picks the ’s. This captures exactly the quantification structure of the formula in (4).

Now that we know and are respectively complete problems in the second and third level of the polynomial hierarchy, we propose in the following a solution approach for these two problems.

5. Background: Answer-Set Programming

Answer-Set Programming (ASP) is a declarative programming paradigm (Gebser et al., 2013). It is essentially Datalog with disjunction and default negation, defined over a stable model semantics. Over the last decades, ASP implementations have become increasingly competitive in efficiency. A notable example of a mature ASP implementation is the Potassco project (Potassco, [n. d.]), which is the ASP solver used in this work. Due to such progress in ASP implementation technologies, reasoning tasks at the lower levels of the polynomial hierarchy have now been regularly encoded in ASP (e.g., (Brewka et al., 2017; Sakama and Rienstra, 2017)). To these computational problems, ASP plays a role analogous to what is for the -complete problems.

We offer here a brief introduction to the stable model semantics of propositional ASP. This prepares the reader to understand how the model saturation technique (Eiter and Gottlob, 1995) works in the encodings of §6.

We begin with the abstract syntax of propositional ASP. An ASP program is a finite set of rules. A rule has the following form:

Here, the ’s and ’s are atoms (i.e., propositional symbols), and at most one of or can be zero. The head of , written , is the set , and the body of is . We write for , and for . A rule with is a fact (in which case we omit the “”). A rule with is an integrity constraint. Intuitively, a rule asserts that one of the head atom holds if the body, read as a conjunction of literals, holds. A fact asserts a (disjunctive) condition unconditionally. An integrity constraint asserts that the body does not hold.

Unlike Prolog, whose semantics is defined procedurally, ASP is purely declarative. The semantics of ASP is defined in terms of stable models (Gelfond and Lifschitz, 1988). An interpretation of program is a set of atoms. is a model of if and only if, for every , when and . Not every model is stable though. To arrive at the definition of a stable model, we need to define the reduct of relative to :

An interpretation is a stable model of if and only if is a -minimal model of . In other words, an cannot be a stable model of if has a model that is a proper subset of . This requirement of minimality is crucial for understanding how the model saturation technique (Eiter and Gottlob, 1995) works in the ASP encodings of §6.

The definition of stable models can be extended to first-order programs through the use of Hebrand interpretations (Eiter et al., 2007). The minimality requirement for the models of the reduct carries to the first-order case.

Checking the existence of stable models in the presence of disjunction and default negation is -complete for propositional ASP (Eiter and Gottlob, 1995), and -complete for first-order ASP with bounded predicate arities (Eiter et al., 2007). The complexity results presented in §3 and §4 grant us the rational justification for employing ASP technologies to solve and .

6. ASP Encoding of and

ASP is a natural constraint solving technology for tackling problems in the lower levels of the polynomial hierarchy. Solving and using ASP does not require us to assume that is a small parameter (an assumption made in (Crampton et al., 2017a)). This section demonstrates the feasibility of this solution approach by presenting ASP encodings of and instances.

The presentation below uses the concrete syntax of logic programs supported by the Potassco collection of ASP solving tools

(Potassco, [n. d.]). We do so to ensure realism: our encoding is literally executable. This, however, does not affect the generality of our encoding, as every Potassco-specific syntax employed by our encoding can be reduced to pure ASP (Gebser et al., 2013, Chapter 2).

In this section, only separation-of-duty constraints are encoded. The encoding can be extended readily to accommodate binding-of-duty, cardinality, and entailment constraints (Crampton et al., 2012, 2013). The focus here is not so much on the encoding of various constraint types in ASP, but on using ASP to express the quantification structure of and .

6.1. Encoding Static Resiliency

Fact
step(). for each
ignored before(, ). whenever
user(). for each
auth(, ). for each
ignored sod(, ). for each
Figure 1. Instance-specific facts used in the ASP encoding of and . The predicate before/2 is ignored in the encoding, while sod/2 is ignored in the encoding.
1 % Generate Player 2’s strike
2 { removed(U) : user(U) } .
3 % Generate Player 1’s assignment
4 avail(S, U) :- auth(S, U), not removed(U).
5 assign(S, U) : avail(S, U) :- step(S).
6 % Test separation-of-duty constraints
7 violation :-
8 sod(S1, S2), assign(S1, U), assign(S2, U).
9 % Model saturation
10 assign(S, U) :- violation, avail(S, U).
11 % Reject unsaturated models
12 :- not violation.
Figure 2. Rules common to all instances in the ASP encoding of .

We present an ASP encoding for the complement of . Given a workflow authorization policy and a budget , the pair belongs to the complement of if and only if there exists a subset of no more than users such that every plan that does not assign users from will fail to satisfy . In other words, if our ASP encoding is unsatisfiable (has no stable model), then is statically resilient for budget . Conversely, if our ASP encoding is satisfiable (has at least one stable model), then every stable model encodes a subset of users that can be removed by the adversarial environment to render unsatisfiable.

Our ASP encoding is uniform (Gebser et al., 2013, Chapter 3) in the sense that every instance of can be reduced to a logic program that can be “factorized” into two parts, a part containing rules that are common to all instances of , and an instance-specific part , such that .

Suppose we have been given an instance consisting of a workflow authorization policy and a budget . The instance-specific part of the ASP encoding consists of the facts in Fig. 1, which describe the components , , , , and of . The rules common to all instances of are listed in Fig. 2.

The rules on lines 2, 2, and 2 in Fig. 2 are responsible for generating interpretations that serve as candidates for stable models.

Line 2 is a choice rule that models the choice of Player 2. Specifically, it generates up to ground atoms of the remove/2 predicate in a model candidate. These facts represent the set of users removed by Player 2.

Line 2 specifies when a user is available for assignment to a step , given the choice of by Player 2. Line 2 is a shorthand that asserts, for each step , the following disjunction: assign(, ) assign(, ). where , …, are the users identified by predicate avail/2 to be available for assignment to .

The cumulating effect of the model generation rules (lines 2, 2, and 2) is that an interpretation will be generated as a model candidate for each user set of size or less, and for each plan that both complies with the step authorization policy and assigns only users from . Each model candidate contains, on top of the instance-specific facts in Fig. 1, the following ground atoms:

  • removed() for each

  • avail(, ) whenever is available for assignment to

  • assign(, ) whenever

There are now two cases:

Case 1::

is valid. Neither lines 22 nor line 2 will be “triggered.” But line 2 will reject .

Case 2::

is not valid. Then lines 22 will detect this case, and introduce the proposition violation into the interpretation under consideration. Moreover, the interpretation will then be saturated by line 2: all possible ground atoms of predicate assign/2 will be added to the interpretation. In short, model candidate will be “converted” to a superset , which contains, on top of the ground atoms in , the following ground atoms:

  • violation

  • assign(, ) for every available for assignment to

Suppose . For every choice of , there exists at least one valid plan that does not assign users from . Note that the model candidate will not be saturated, and thus it will be rejected by line 2. Not only that, the saturated model is not a minimal model for , because its proper subset is also a model for . Consequently, no stable model exists for the program .

Conversely, suppose . Then there is a such that every plan that does not assign users from is invalid. This means that Case 1 above never holds for this choice of . This also means that every model candidate is converted into a saturated model . As none of the interpretations is a model for , is the minimal model for . The program has at least one stable model.

We have thus demonstrated that it is feasible to use ASP for encoding . The key is to use an advanced ASP programming technique known as model saturation (Eiter and Gottlob, 1995) to encode the quantification structure (i.e., -) of ’s complement. We now examine an extension of this technique for encoding .

6.2. Encoding One-shot Resiliency

1: % Generate a plan as part of Player 1’s strategy
2: 1 { assign(S, U) : auth(S, U) } 1 :- step(S).
3: % Generate a total ordering of steps as part of
4: % Player 1’s strategy
5: order(X, Y); order(Y, X) :-
6: step(X), step(Y), X != Y.
7: order(X, Y) :- before(X, Y).
8: order(X, Z) :- order(X, Y), order(Y, Z).
9: % Generate strike point of Player 2
10: post(S); pre(S) :- step(S).
11: post(S2) :- post(S1), order(S1, S2).
12: % Generate strike set of Player 2
13: removed(U); preserved(U) :- user(U).
14: % Available assignments for Player 1
15: avail(S, U) :- pre(S), assign(S, U).
16: avail(S, U) :- post(S), auth(S, U), preserved(U).
17: % Detect satisfiability
18: sat :-
19: avail(1, U1), avail(2, U2), , avail(9, U9),
20: U2 != U7, U3 != U4, , U8 != U9.
21: % Player 2 loses if it removes more than users
22: sat :- +1 { removed(U) : user(U) }.
23: % Model saturation
24: pre(S) :- sat, step(S).
25: post(S) :- sat, step(S).
26: removed(U) :- sat, user(U).
27: preserved(U) :- sat, user(U).
28: avail(S, U) :- sat, auth(S, U).
29: % Reject unsaturated models
30: :- not sat.
Figure 3. ASP encoding of . Note that the rule on lines 33 are instance specific. This encoding also assumes the instance-specific facts in Fig. 1.

The crux in designing an ASP encoding of lies in capturing the quantification structure of (i.e., --). To this end, we employ the advanced adaption of model saturation as found in the proof of Lemma 6 and Lemma 7 in (Eiter et al., 2007).

Unlike the encoding in §6.1, the ASP encoding of presented here is not uniform. It cannot be factorized into an instance-specific set of facts and a set of of rules that are common to all instances. More specifically, is encoded using the instance-specific facts in Fig. 1 and the rules in Fig. 3. Note that lines 33 of Fig. 3 are only examples. Each instance will have a different formulation of those lines, depending on what constraints are in .

Our ASP encoding of basically follows the idea of Lemma 4.4, and thus Fig. 3 could be seen as an ASP variant of Algorithm 1:

  1. The logic program “guesses” a functional sequence that encodes the strategy of Player 1.

  2. Then model saturation is employed for capturing the universal quantification of Player 2’s strikes.

  3. Lastly, testing whether a prefix of can be extended to a terminus is performed without model generation rules.

Generating Player 1’s strategy.

The first part of Player 1’s strategy is a plan, which is represented by the predicate assign/2. Using a choice rule, line 3 generates, for each step , exactly one fact of the form assign(, ) if user is authorized to execute step .

The second part of Player 1’s strategy is a total ordering of steps. This is represented by the predicate order/2, which is generated by lines 33. More specifically, lines 33 generate, for every pair of distinct steps and , either order(, ) or order(, ). Line 3 ensures that the generated ordering honors the ordering constraints of the workflow, and line 3 ensures transitivity.

Generating Player 2’s strike.

The strike of Player 2 is generated by lines 33. There are two parts to the strike. The first part is a subset of users to be removed. Line 3 is a shorthand that asserts, for each user , the disjunction below: removed() preserved(). The alert reader will notice that no constraint on the size of is placed here. As we shall see, the size is controlled by having Player 2 loses the game if it picks more than users in (see line 3).

The second part of Player 2’s strike is the choice of a round to launch the strike. This choice is generated by lines 33. More specifically, every step is labelled as either “pre-strike” or “post-strike” by line 3. A pre-strike step is one that is ordered before the launch point according to the total ordering chosen by Player 1 above; otherwise, the step is post-strike. Line 3 ensures that post-strike steps are never ordered before pre-strike steps.

Testing if a prefix of Player 1’s strategy can be extended to a terminus.

Lines 33 check whether, after the strike chosen by Player 2, the assignments made prior to the strike by Player 1 can be extended to a valid plan. This section can be further divided into two subsections: (a) lines 33, and (b) lines 33.

Lines 33 determine which user is available for assignment to which step after the strike. For pre-strike steps, the assignment is fixed according to Player 1’s strategy (line 3). For post-strike steps, authorized users who have not been removed by the strike are available (line 3).

Then comes lines 33, which mark the interpretation by the marker proposition sat whenever the workflow authorization policy is found to be satisfiable (given Player 1’s strategy and Player 2’s strike). This is the part of the encoding that has been inspired by the proof of Lemma 7 in (Eiter et al., 2007). The main feature of this section is that satisfiability is checked without model generation rules (e.g., choice rules and disjunctive rules). Instead, a single rule is used. This rule, however, is instance specific: a different rule of this form will have to be formulated for each instance. The rule considers all possible user assignments to the steps (line 3), and then checks the SOD constraints inline (line 3). By encoding the nested existential quantification without model generation rules, we can reuse the model saturation technique to encode the outer existential-universal quantifications.

Other mechanics.

Line 3 ensures that Player 2 plays according to the budget. If Player 2 removes more than users, then Player 1 wins: i.e., the workflow authorization policy is considered satisfied.

If the workflow authorization policy is satisfiable (i.e., the proposition sat is part of the model), then lines 33 will saturate the model by producing all possible ground atoms that can ever be asserted as a result of Player 2’s choice. Finally, line 3 rejects unsaturated models. Using an argument analogous to the one in §6.1, one can demonstrate that a stable model exists if and only if Player 1 has a winning strategy.

7. Related Work

The notion of resiliency was introduced into the study of access control by Li et al., originally in the context of RBAC rather than in workflow authorization models (Li et al., 2006, 2009). Significant recent advances have been achieved in employing parameterized complexity analysis to facilitate the design of efficient algorithms for the Resiliency Checking Problem (RCP) (Crampton et al., 2016). In particular, the efficient FPT algorithms designed for WSP is employed as subroutines for solving RCP. There is also interest in formulating “resiliency”-variants of combinatorial problems in general (Crampton et al., 2017b). A form of resiliency checking problem has also been defined for Relationship-Based Access Control (ReBAC), in the context of policy negotiation performed among co-owners of the a resource (Mehregan and Fong, 2016). ReBAC resiliency checking was shown to be complete for . That result, however, is significantly different from Theorem 3.1 of the present paper. First, ReBAC resiliency is about an adversary who can remove relationship edges in an underlying social graph, whereas the adversary of workflow resiliency removes users. Second, the hardness proof of (Mehregan and Fong, 2016) involves a reduction from the Graph Consistency problem, and is therefore fundamentally different from the one presented in this paper. In general, the nature of RCP is different from workflow resiliency, as the latter contains an element of dynamism, allowing the adversarial environment to remove users as the workflow is executing.

The idea of workflow resiliency was first introduced by Wang and Li (Wang and Li, 2007, 2010). The present paper bridges the complexity gap of static resiliency that existed since the first conception of the idea a decade ago.

Two notable lines of recent research explore new directions in the study of workflow resiliency. Mace et al. (Mace et al., 2014, 2015a, 2015b)

pointed out that simply knowing whether a workflow is resilient or not is not sufficient. The real interest of the workflow developer is to receive feedback from the policy analysis in order to repair the workflow. They proposed a quantitative model of resiliency in response to this need. The idea is to build a probabilistic adversary model, and then formulate a Markov Decision Process to capture how users are removed over time. While the insight of their perspective is acknowledged, it is the position of this paper that multiple notions of resiliency are needed in order to provide insights into the workflow engineering process. The proposal of one-shot resiliency is partly motivated by this consideration.

A second recent work on workflow resiliency is the FPT algorithm of Crampton et al. for deciding dynamic resiliency (Crampton et al., 2017a). Unfortunately, the parameter they used involves the budget of the adversary, which is not universally considered small. It is therefore necessary to consider solution approaches that do not assume a small . The proposal of ASP as a solution approaches for static and one-shot resiliency in the present work is a response to this challenge.

Kahn and Fong proposed workflow feasibility as a dual notion of workflow resiliency (Khan and Fong, 2012). The idea is based whether the current protection state can be repaired to make the workflow satisfiable. Feasibility checking is also defined for ReBAC (Mehregan and Fong, 2016), and shown to be complete for .

8. Conclusion and Future Work

We proved that static resiliency is complete for , thereby solving a problem that has been open for more than a decade since Wang and Li first proposed the notion of workflow resiliency (Wang and Li, 2007, 2010).

We have also demonstrated that useful notions of workflow resiliency need not be -hard. The fact that we can define a notion of workflow resiliency (one-shot resiliency) that remains in the lower levels of the polynomial hierarchy () implies that the lower complexity of static resiliency is not an exception.

The completeness of