Software Security II

1. Software Security II Karl Lieberherr

2. What is Security • Enforcing a policy that describes rules for accessing resources. • Policy may be explicit or implicit. Better to use explicit policy.

3. Security Goals • Authentication • Who is it that is trying to do something to the what we want to protect. • URL authentication: is yourFriendlyBank.com really a friendly bank?

4. Security Criteria • SALTZER, J. H., AND SCHROEDER, M. D. The protection of information in computer systems. Proceedings of the IEEE 63, 9 (Sept. 1975), 1278-1308.

5. Security Criteria derived from Saltzer/Schroeder • Economy of mechanism Designs which are smaller and simpler are easier to inspect and trust. • Fail-safe defaults By default, access should be denied unless it is explicitly granted. • Complete mediation Every access to every object should be checked. • Least privilege Every program should operate with the minimum set of privileges necessary to do its job. This prevents accidental mistakes becoming security problems.

6. Security Criteria derived from Saltzer/Schroeder • Least common mechanism Anything which is shared among different programs can be a path for communication and a potential security hole, so as little data as possible should be shared. (LoD) • Accountability The system should be able to accurately record ``who'' is responsible for using a particular privilege. • Psychological acceptability The system should not place an undue burden on its users.

7. Security criteria • Performance • We must consider how our designs constrain system performance. Security checks which must be performed at run-time will have performance costs. • Compatibility • We must consider the number and depth of changes necessary to integrate the security system with the existing Java virtual machine and standard libraries. Some changes may be impractical. • Remote calls • If the security system can be extended cleanly to remote method invocation, that would be a benefit for building secure, distributed systems.

8. A Logical Framework for Reasoning about Access Control • Elisa Bertino

9. Logical framework • Models • Role-based access control • Reduction to C-Datalog

10. Basic components • Subjects • User • Process: execution of a program on behalf of user • Group: partial order • Role: partial order

11. Basic components • Objects • Resources to be protected: partial order (has-a relationships) • Privileges • Access modes subjects can exercise on objects. • Partial order expressing strength between privileges

12. Basic components • Sessions • An instance of a connection of a user to a system. • Authorization rules • Exploit subjects, objects, privileges and session attributes. Positive and negative.

13. Basic components • Constraint rules • Cannot be violated by components of the system. • Static • Without taking into account the execution state • Dynamic • Taking into account the execution state

14. Formal Representation • C-Datalog • Object-oriented extension of Datalog

15. Brief introduction to C-Datalog • C-Datalog data model • Class and relation names • Class Schema • Inheritance • Object identifiers • Instances

16. Security Policies • Sigma: set of access events. • A policy is a set P subset Sigma* of finite sequences of access events. • prefix(w) = set of all prefixes of w ={u in Sigma* s.t. uv = w} • A policy is prefix closed: For all W in Sigma*: if w in P then prefix(w) subset P

17. Security Automaton • Need to implement a security automaton (SA): Sigma (access events), Q (states), q0 (initial state), delta (transition function), delta: Q x Sigma -> Q • An access event sequence is accepted if by an SA if a transition is defined for every event in the sequence.

18. Expressiveness • The class of prefix closed security policies coincides with the set of security policies accepted by a security automaton.

19. Chinese Wall Policy • Avoid conflict that may arise due to the unchecked flow of information across data sets belonging to competing parties • O: set of data objects • S: set of subjects • G: set of data sets • T: set of conflict of interest classes

20. Chinese Wall Policy • Assign group(o) in G to every object in O • Assign type(g) in G to each dataset g in G • A subject s may access a data object o only if one of the following holds: • s has already accessed another object o’: group(o) = group(o’) • Every object o’ that s has accessed: type(group(o))!=type(group(o’))

21. Chinese Wall Policy • Conflict set 1 oil companies: Oil company A (one group A1, A2, …) , Oil company B (another group B1, B2, … ) • Conflict set 2 banks: Bank UBS (one group UBS1, UBS2, … ) • (u,A1) ok; (u,A2) ok (same group); (u, UBS1) ok (different group and different type); B1 NOT OK (different group and same type)

22. Implement • AspectJ

23. Extra slides

24. Java Security at IBM Research(Larry Koved: manager) • Automating Security Analysis of Java Components and Programs • Invocation graphs

25. LoD and Security • Can execute software only if secret is known. • Secret consists of set of keys, one per class. • What is security policy? Each object only gets keys of its authenticated friends (who share the same concerns???). • What are the benefits of such a security policy? Compartmentalize?

26. LoD and security