Download
complex security policies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Complex Security Policies PowerPoint Presentation
Download Presentation
Complex Security Policies

Complex Security Policies

83 Views Download Presentation
Download Presentation

Complex Security Policies

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Complex Security Policies Dave Andersen Advanced Operating Systems Georgia State University

  2. Part 1 Presentation of Material from Text Book Chapter 8.6.1

  3. Stateless vs. State-Dependent Security Policies • The Access Control List (ACL) and Capability List (CL) security models are stateless. Properties remain fixed unless explicitly changed by the server. • Complex Access Control Policies are state dependent. Authorization of access depends on subjects past history and interaction with other objects. [1998 Chow and Johnson]

  4. Information Flow Control • When information flow is built on lattices information can only flow between components of the lattice in the direction the lattice permits. • Flow properties of the lattice model include: • Transitivity: A->B and B->C implies A->C • Aggregation: A->C and B->C implies A U B ->C • Separability: A U B ->C implies A->C and B->C • Some applications require information flow which violates properties of the lattice.[1998 Chow and Johnson]

  5. Exceptions to Lattice Model [1998 Chow and Johnson]

  6. Example of a Complex Access Control Policy Computer Automated Bank Loan Application • Only clerk(S1) can prepare loan application (write permissions for object O). • One of two bank officers, the manager (S2) or accountant (S3) (but not both) must approve the application (append permissions). • Approved loan is the appended with electronic check signed by both bank manager (S2) and cashier (S4) .

  7. Graphical Representation [1998 Chow and Johnson]

  8. Security Issues • Only subjects with write permissions can alter electronic document. • Must be able to authenticate digital signatures. • Enforce a transitivity exception to write access: clerk cannot alter document once it has been approved. • Enforce sequence order of writes: application, approval, then check. • Enforce aggregation exception: either manager or accountant approves loan, not both (and therefore once approved by one it cannot be disapproved by another). • Check must be signed by both manager and cashier (separation exception). [1998 Chow and Johnson]

  9. Challenge: Simple Model for Implementing Complex Policy • First two issues (write permissions and digital signatures) are solved. • As of book publishing – solution doesn’t exist for the others. • First Possibility - Maintain Finite State Machines for each object. Unfortunately, not simple or efficient. • Second Possibility: Boolean representation of access rules. • ACEw(O) = A+ B XOR C + B AND D • Achieves simplicity and efficiency, but lacks state information for proper rule enforcement. [1998 Chow and Johnson]

  10. Storing State Information • Storing State Information on Server • File must be updated with each access. • Storing State Information on Client: • Eliminates need to update file with every access. • But, may affect clients ability to access other objects. • And, difficult to propagate state information to other clients. • Author’s Conclusion: Use Server.

  11. Part 2 Current Research

  12. Current Research • A Software Architecture for Automatic Security Policy Enforcement in Distributed Systems [2007 Hamdi, Bouhoula, Mosbah] • Authors propose: • Policy Specification Tool • Enforcement and Verification Engine • Automatically Generated Enforcement Mechanisms

  13. Policy Programming Language • PPL is used to define the policies and rules that apply to an object or group of objects and the actions that should be taken when a constraint is matched. • Uses Backus–Naur Form (BNF) Syntax

  14. Proposed System Architecture [2007 Hamdi, Bouhoula, and Mosbah]

  15. Policy Enforcement • Portability - PPL is compiled into monitors and configurations for a specific system platform. • PPL compilation allows for the detection of policy conflicts. • All security checks and state management operations occur at entry and exit of policy enforcement point.

  16. Part 3 Future Directions

  17. Automated Security Testing? Security Policies can be very complex— Can a program/system be developed to either prove or disprove (find security holes) in a set of rules or policies of a given system.

  18. References • Randy Chow and Theodore Johnson, Distributed Operating Systems & Algorithms, Addison Wesley Longman, Inc., Reading, MA, 1997. • H. Hamdi, A. Bouhoula, M. Mosbah, “A Software Architecture for Automatic Security Policy Enforcement in Distributed Systems”, SecureWare 2007, The International Conference on Emerging Security Information Systems and Technologies, October 14-20, 2007, pages 187-192.

  19. Questions?