Flex Flow A Flexible Flow Policy Specification Framework

Flex. Flow: A Flexible Flow Policy Specification Framework Shipping Chen, Duminda Wijesekera and Sushil Jajodia Center for Secure Information Systems George Mason University

Introduction • Information flow control policies specify under what conditions information may be exchanged. • Policies vary on: – System levels at which information transfers, – Types and units of information transfer, – Single/multiple destinations. • Objective to model commonalities among policies that govern information flow between abstract entities. IFIP 11. 3 -2003 2

Previous Work • Denning’s lattice model for secure flows. – Flow control based on the security classes of objects. • Ferrari et al. ’s model for object-oriented systems. – Flow control based on ACL’s of objects. • Myers+Liskov’s language based flow control. – Flow control based on decentralized labels of program variables. • Bertino et al. ’s work on RBAC for work flow systems. • Various type theory based systems. IFIP 11. 3 -2003 3

Issues with Existing Proposals • Security labels or access control lists limits for applications. • Application/model specificity. • No prohibitions. • Cannot combine policies across levels. IFIP 11. 3 -2003 4

What Flex. Flow Adds • Provide a logic programming based flow control policies specification language. • Allow permissions and prohibitions. • Does not depend on a specific meta-policy. • Not confined to an application domain. • Can model policies in other frameworks. • Therefore, can mix policies at different system levels. IFIP 11. 3 -2003 5

Flex. Flow System Architecture IFIP 11. 3 -2003 6

Flow Trees • Flex. Flow has trees referred to as flow trees build up from nodes and branches. • Nodes represent information sources and sinks. • Branches represent pathways taken by information flowing between nodes. • Information flows from the leaves of a tree via intermediate nodes to its root. IFIP 11. 3 -2003 • o 5 • o 3 • o 4 • o 2 • o 1 7

Flow Trees (Cont. ) • o 1 • A flow tree can have flow sub-trees. • Depth one flow trees make up the basic units, called one-step flow trees. • Can build larger trees by recursively merging one -step flow trees. • o 2 • 0 • o 5 • o 3 • 1 • 2 • o 2 IFIP 11. 3 -2003 8

Two Environments • Local Data: node environments have data related to a node. – E. g. ACL of an object, execution role of a task. • Global Data: Tree environments have data related to a whole tree. – E. g. execution time of a flow tree, execution process. • Environments are user definable. – Type and number of variables not specified. IFIP 11. 3 -2003 9

List Representation of Flow Tree • A flow tree is represented as a list. • The head of the list = the root (node, node environment) pair. • The tail of the list includes the leave (node, node environment) pairs or subtrees encoded as sub-lists. – E. g. [o 5, o 4, [o 3, o 2, o 1]] represents a tree which rooted at o 5 and has leave node o 4 and sub-tree [o 3, o 2, o 1]. IFIP 11. 3 -2003 10

An Example Flow Tree IFIP 11. 3 -2003 11

Flex. Flow Syntax • Terms: – Terms made up from constants and variables for nodes, environments and actions. – Constants and variables over lists of (node, env) pairs. • Predicates. – Application specific predicates. • E. g. play. Role(xs, xr), is. Member((xn, xe), XL). IFIP 11. 3 -2003 12

Special Predicates • safe. Flow(xn, xe, XL, <sign>action). – Represents grantable/deniable one-step flow. – xn, xe= destination node, destination env. – XL= a finite list of source (node, env) pairs. – <sign>= flow permission/prohibition. – xaction= name of the one-step flow, e. g. copy, assign. IFIP 11. 3 -2003 13

Predicates of the Framework • safe. Flow*(xflow. H, xflow. Env, <sign>xaction). – Permitted/prohibited flow tree. – xflow. H = A flow tree represented as a list. – xflow. Env = flow tree environment. • final. Safe. Flow(xflow. H, xflow. Env , <sign>xaction). – With the same arguments as safe. Flow*, – Representing decision made by Flex. Flow. IFIP 11. 3 -2003 14

An Example • Assumption. – Using nodes xn as object and environment xe as subject, the owner of the object. • Base relations specification rules. IFIP 11. 3 -2003 15

Example Continued • One-step flow specification rules • Flow tree construction rules From rules (1)—(6) and (7), safe. Flow*([(file 1, Alice), (file 2, Bob)], [ ], +copy) is derivable. From rules (1)—(6) and (9), safe. Flow*([(file 1, Alice), (file 2, Bob)], [ ], -copy) is derivable. IFIP 11. 3 -2003 16

Example Continued • Conflict resolution rules. From rule (10) we can get. Flow [(file 1, Alice), (file 2, Bob)] should be authorized. • Decision rules. IFIP 11. 3 -2003 17

Express Denning’s Lattice Model IFIP 11. 3 -2003 18

Express Decentralized Label Model Mayer&Liskov IFIP 11. 3 -2003 19

Flexible Flow Control of Ferrari et al. IFIP 11. 3 -2003 20

Express Flexible Flow Control Model Ferrari et al. IFIP 11. 3 -2003 21

Express Flexible Flow Control of Ferrari et al. IFIP 11. 3 -2003 22

Ongoing Work • Add constraints specification+resolution capability. – Integrity constraints are an essential part of flow control specification. – E. g. Chinese Wall Model. – Static vs. Dynamic constraints. • Construct Materializations. IFIP 11. 3 -2003 23