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

IFIP 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 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 Issues with Existing Proposals Security labels or access control lists limits for applications. Application/model specificity. No prohibitions. Cannot combine policies across levels.

IFIP What FlexFlow 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 FlexFlow System Architecture

IFIP Flow Trees FlexFlow 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. o 5 o 4 o 3 o 2 o 1

IFIP Flow Trees (Cont.) 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 1 o 2 o 5 o 3 o

IFIP 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 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 sub- trees 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 An Example Flow Tree

IFIP FlexFlow 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. playRole(x s,x r ), isMember((x n,x e ),X L ).

IFIP Special Predicates safeFlow(x n, x e, X L, action). –Represents grantable/deniable one-step flow. –x n, x e = destination node,destination env. –X L = a finite list of source (node,env) pairs. – = flow permission/prohibition. – x action = name of the one-step flow, e.g. copy, assign.

IFIP Predicates of the Framework safeFlow*(x flowH, x flowEnv, x action ). –Permitted/prohibited flow tree. –x flowH = A flow tree represented as a list. –x flowEnv = flow tree environment. finalSafeFlow(x flowH, x flowEnv, x action ). –With the same arguments as safeFlow*, –Representing decision made by FlexFlow.

IFIP An Example Assumption. –Using nodes x n as object and environment x e as subject, the owner of the object. Base relations specification rules.

IFIP Example Continued One-step flow specification rules Flow tree construction rules From rules (1)—(6) and (7), safeFlow*([(file1,Alice),(file2,Bob)],[ ],+copy) is derivable. From rules (1)—(6) and (9), safeFlow*([(file1,Alice),(file2,Bob)],[ ],-copy) is derivable.

IFIP Example Continued Conflict resolution rules. From rule (10) we can get. Flow [(file1,Alice),(file2,Bob)] should be authorized. Decision rules.

IFIP Express Denning’s Lattice Model

IFIP Express Decentralized Label Model Mayer&Liskov

IFIP Flexible Flow Control of Ferrari et al.

IFIP Express Flexible Flow Control Model Ferrari et al.

IFIP Express Flexible Flow Control of Ferrari et al.

IFIP 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.