Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Security II Karl Lieberherr. What is Security Enforcing a policy that describes rules for accessing resources. Policy may be explicit or implicit.

Similar presentations


Presentation on theme: "Software Security II Karl Lieberherr. What is Security Enforcing a policy that describes rules for accessing resources. Policy may be explicit or implicit."— Presentation transcript:

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

27


Download ppt "Software Security II Karl Lieberherr. What is Security Enforcing a policy that describes rules for accessing resources. Policy may be explicit or implicit."

Similar presentations


Ads by Google