1 / 19

Complex Security Policies

Complex Security Policies. Dave Andersen Advanced Operating Systems Georgia State University. Part 1. Presentation of Material from Text Book Chapter 8.6.1. Stateless vs. State-Dependent Security Policies.

dixon
Download Presentation

Complex Security Policies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related