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

2. IFIP11.3-2003 2 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.

3. IFIP11.3-2003 3 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.

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

5. IFIP11.3-2003 5 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.

6. IFIP11.3-2003 6 FlexFlow System Architecture

7. IFIP11.3-2003 7 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

8. IFIP11.3-2003 8 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 2 0 1 2

9. IFIP11.3-2003 9 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.

10. IFIP11.3-2003 10 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 ].

11. IFIP11.3-2003 11 An Example Flow Tree

12. IFIP11.3-2003 12 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 ).

13. IFIP11.3-2003 13 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.

14. IFIP11.3-2003 14 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.

15. IFIP11.3-2003 15 An Example Assumption. –Using nodes x n as object and environment x e as subject, the owner of the object. Base relations specification rules.

16. IFIP11.3-2003 16 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.

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

18. IFIP11.3-2003 18 Express Denning’s Lattice Model

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

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

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

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

23. IFIP11.3-2003 23 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.