Security Policies

1. Security Policies

2. Reading • For this class: • Information Security Policy - A Development Guide for Large and Small Companies, http://www.sans.org/reading_room/whitepapers/policyissues/information-security-policy-development-guide-large-small-companies_1331 • S. De Capitani di Vimercati, P. Samarati, S. Jajodia: Policies, Models, and Languages for Access Control, http://seclab.dti.unimi.it/Papers/2005-DNIS.pdf • Look at the Information Security Program - USC, http://uts.sc.edu/itsecurity/program/index.shtml Information Warfare - Farkas

3. Why Do We Need Security Policies? Basic Purpose of Policy Policy and Legislative Compliance Policies as Catalysts for Change Policies Must be Workable Information Warfare - Farkas

4. Purpose Protect people and information Set the rules for expected behaviour by users, system administrators, management, and security personnel Authorize security personnel to monitor, probe, and investigate Define and authorize the consequences of violation1 Define the company consensus baseline stance on security Help minimize risk Help track compliance with regulations and legislation Information Warfare - Farkas

5. Legislative Compliance Showing what the company’s stance Common legislations: HIPAA (Health Insurance Accountability and Portability Act), GLB (Gramm-Leach-Bliley Act) and Sarbanes Oxley, Family Educational Rights and Privacy Act (FERPA) Mapping policy statements to legislative requirements Information Warfare - Farkas

6. Catalysts for Change Drive forward new company initiatives Move towards better security and general practices Must be read and known by everyone Information Warfare - Farkas

7. Must be Workable Security policy is useful, useable, realistic Fits the company’s existing policy Involve and get buy-in from major players Information Warfare - Farkas

8. Who Will Use the Policy? • Audience groups • Management • Technical staff • End users • Audience and policy content • Include relevant information only • Multiple ways of using the policy Information Warfare - Farkas

9. Policy Type Policy Hierarchy Governing Policy (single document) Technical Policies (multiple documents) Job Aids / Guidelines (support to apply technical policies) Information Warfare - Farkas

10. Policy Development Development Process Maturity Top-Down Versus Bottom-Up Current Practice Versus Preferred Future Consider All Threat Types Policy Development Life Cycle Information Warfare - Farkas

11. Governing Policy • Cover information security concepts at a high level • Define, describe, explain • Mainly for managers and end users • Aligned with existing and future organizational requirements • Supported by the technical policies Information Warfare - Farkas

12. Technical Policies Used by technical custodians carrying out technical responsibilities More detailed than the governing policy System and issue specific Describe what must be done NOT how to do it Address: what, who, when, where to secure Information Warfare - Farkas

13. Job Aid/Guidelines Procedural, step-by-step directions Addresses: How? Support particular technical policies Not required for all policies Information Warfare - Farkas

14. Prioritizing Policy Topics • Legally obliged to protect • Critical decision-making by your organization or your customers • Supports organizational goals Information Warfare - Farkas

15. Governing Policy Outline Appendix 1 http://www.sans.org/reading-room/whitepapers/policyissues/information-security-policy-development-guide-large-small-companies-1331?show=information-security-policy-development-guide-large-small-companies-1331&cat=policyissues Information Warfare - Farkas

16. Technical Policy Outline Appendix 2 http://www.sans.org/reading-room/whitepapers/policyissues/information-security-policy-development-guide-large-small-companies-1331?show=information-security-policy-development-guide-large-small-companies-1331&cat=policyissues Information Warfare - Farkas

17. Policy Development Team • Primary Involvement • Information Security Team • Technical Writer(s) • Secondary Involvement • Technical Personnel • Legal Counsel • Human Resources • Audit and Compliance • User Groups Information Warfare - Farkas

18. Security Policy Research Information Warfare - Farkas

19. Policy, Model, Mechanism • Policy: High-level rules (governing policy) • Model: formal representation – proof of properties (governing policy) • Mechanism: low-level specifications (technical policy) Separation of policy from the implementation! Information Warfare - Farkas

20. System Architecture and Policy • Simple monolithic system • Distributed homogeneous system under centralized control • Distributed autonomous systems homogeneous domain • Distributed heterogeneous system Complexity Of Policy Information Warfare - Farkas

21. Traditional Access Control • Protection objects: system resources for which protection is desirable • Memory, file, directory, hardware resource, software resources, etc. • Subjects: active entities requesting accesses to resources • User, owner, program, etc. • Access mode: type of access • Read, write, execute Information Warfare - Farkas

22. Access Control Models • See CSCE 522 for details • Been around for a while: • Discretionary Access Control • Mandatory Access Control • Role-Based Access Control • Relatively new: • Usage-Based Access Control • Capabilities-Based Access Control Information Warfare - Farkas

23. Closed vs. Open Systems Closed system Open System (minimum privilege) (maximum privilege) Access req. Access req. Allowed accesses Disallowed accesses Exists Rule? Exists Rule? yes no no yes Access permitted Access denied Access permitted Access denied Information Warfare - Farkas

24. Negative Authorization • Traditional systems: Mutual exclusion • New systems: combined use of positive and negative authorizations • Support exceptions • Problems: How to deal with • Incompleteness – Default policy • Inconsistencies – Conflict resolution Information Warfare - Farkas

25. Negative Authorization What is the effect of adding new access control rules to the policy? • Positive authorizations only • Negative and positive authorizations Information Warfare - Farkas

26. What is the effect of adding new access control rules to the policy? • Positive authorizations only • (John, +read, 727-materials) , (John, +write, 727-exams) • Add: (John, +write, 727-final) • Negative and positive authorizations • (John, +read, 727-materials) , (John, +write, 727-exams) • Add: (John, -write, 727-midterm) Information Warfare - Farkas

27. Conflict Resolution • Denial takes precedence • Most specific takes precedence • Most specific along a path takes precedence • Priority-based • Positional • Grantor and Time-dependent • Single strategy vs. combination of strategies • Any new suggestions??? Information Warfare - Farkas

28. Policy Specification Language • Express policy concepts • Required properties of policy languages: • Support access control, delegation, and obligation • Provide structuring constructs to handle large systems • Support composite policies • Must be able to analyze policies for conflicts and inconsistencies • Extensible • Comprehensible and easy to use Information Warfare - Farkas

29. What are the trade offs between the authorization language requirements? Information Warfare - Farkas

30. Policy Specification Language Approaches • Logic-based approach • Adv: Precise and expressive • Disadv: not intuitive, difficulty and complexity of implementation • e.g., Jojodia et al., A logical language for expressing authorizations, 1997 • Graphical approach • Adv: supports visual understanding • Disadv: Scope is limited • E.g., Hoagland et al., Security Policy Specification using a Graphical Approach, 1998 • Event-Based language • Adv: clear semantics and architecture • Disadv: limited scope • E.g.,Lobo et al., A Policy Description Language, 1999 • Object-Oriented, declarative language • Adv: clear semantics, expressiveness, easy to use • Disadv: support of domain specific semantics • E.g., Damianou et al., The Ponder Policy Specification Language, 2000 Information Warfare - Farkas

31. Provisions and Obligations • Yes/no response to every request is just not enough • Provisions: Conditions to be satisfied before permission is considered • Obligations: Conditions to be fulfilled as a consequence of accesses Author: D. Wijesekera Information Warfare - Farkas

32. Delegation Policies • Supports temporary transfer of access rights • Must be tightly controlled by security policy • Always associated with authorization policy • Not intended for security administrators • Constraints! • New area: delegation of obligations Information Warfare - Farkas

33. Policy Development • Policy maker: • Start with high-level policies • Refine high-level policies to low-level policy specification • determine resources required to satisfy the policy • translate high-level policies into enforceable versions • support analysis that verifies that lower level policies actually meet the needs of higher level ones. Information Warfare - Farkas

34. Policy Refinement “If there exists a set of policies Prs: P1, P2 .. Pn, such that the enforcement of a combination of these policies results in a system behaving in an identical manner to a system that is enforcing some base policy Pb, it can be said that Prs is a refinement of Pb. The set of policies Prs: P1, P2 .. Pn is called the refined policy set.” (Bandra) Information Warfare - Farkas Modified from slides of A. K Bandara

35. Policy Refinement Properties • A policy refinement is complete iff: • Correct: there is a subset of the refined policy set such that a conjunction of the subset is also a refinement of the base policy • Consistent: there are no conflicts between any of the policies in the refined policy set • Minimal: if removing any policy from the refined policy set causes the refinement to be incorrect Information Warfare - Farkas Modified from slides of A. K Bandara

36. Policies for Integrated, Heterogeneous Systems • Providing Security and Interoperation of Heterogeneous Systems” by S. Dawson, S. Qian, and P. Samarati; in Distributed and Parallel Databases, vol. 8, no 1, January 2000 (http://homes.dsi.unimi.it/~samarati) • Demand for information sharing • Heterogeneous systems • Local access control • Need interoperation Information Warfare - Farkas

37. Automated Policy Translation Architecture Security Policy 1 Security Policy 2 Security Policy n Automated Translation Modules ACL ATM BLP ATM Other ATM Unified Security Policy in ASL Information Warfare - Farkas

38. Federated Databases • Set of autonomous and (possibly) heterogeneous databases participating together • Loosely coupled • Tightly coupled • Logical data storage • Federated schema, data model, and federated users • Access control • Full authorization autonomy • Medium authorization autonomy • Low authorization autonomy Information Warfare - Farkas

39. Mediation-based Databases • Mediator provides controlled accesses to local databases (resources) • No need for federated schema and multi-database language Information Warfare - Farkas

40. Need • Transparent access • Autonomy • Security Information Warfare - Farkas

41. Mediation-based Interoperation • Architecture • Security policy specifications • Application and source security lattices • Correctness of specifications: consistency, non-ambiguity, non-redundancy • Access control • Mediator: accesses on virtual relation – limiting the number of applicable rules • Local sources: on local data (labeled) and translated application user label Information Warfare - Farkas

42. Next Class Insider’s threat Information Warfare - Farkas