IS 3957 Doctoral Seminar in Systems and Technology Information Assurance

1. IS 3957 Doctoral Seminar in Systems and TechnologyInformation Assurance Introduction James Joshi September 8, 2005

2. Access Control • Access control • Restrict access to system entities to authorized personnel • Security Domain • A bounded group of subjects and objects under a single security policy • Multidomain Secure Environment • Ensuring a secure interaction among participating domains

3. Current Systems • Single domain systems • Multidomain systems • Open Interconnected Heterogeneous Systems • Web applications, E-Government, Global enterprises

4. Industry (various ops) • DoDBusiness Operations Environment • Initiate a transaction • Manage a transaction • Manage reference data • Provide performance support • Control access to and protect transaction and reference data • Transmit and translate transactions and reference data DoD Business Operations Environment (Ref: JECPO) Operational View OV-1 Warfighter Operations • Introduction Movement Training Requirements Analysis Maintenance Adjudication T&E Business Protection Environment Auditing Transportation Budget Planning Training Development Construction Mgmt Receiving Program Sch, Dir, Cont Contract Admin Disposal Mgmt Procurement Personnel Admin Engineering Analysis & Approval Payment/ Disbursement Facilities Mgmt Technology Projection Funds Mgmt Inventory Flow Mgmt Oversight Maintenance Planning Health, Safety, Environment Accounting Log Planning DoD Business Operations Business Protection Environment Example

5. Discretionary Access Control (DAC) • Subjects have ownership over objects • A subject can pass access rights to other subjects at his discretion • Highly flexible and most widely used • Not appropriate for • high assurance systems, e.g., a military system • Many complex commercial security requirements • “Trojan horse” problem

6. Mandatory Access Control (MAC) • Subjects/objects have security levels forming a lattice • Flow of information is restricted. • Example: (no-readup), (no-writedown) • Well-know MAC model is the Bell-LaPadula model

7. Some Existing Models • Abstract models • HRU’s Access Control Matrix • Schematic Protection Model and variation • Mandatory • Confidentiality model - Bell-LaPadula • Integrity model • Biba, Lipner’s, Clark-Wilson • Hybrid • Chinese wall

8. Confidentiality Policy • Also known as information flow policy • Integrity is secondary objective • Eg. Military mission “date” • Bell-LaPadula Model • Formally models military requirements • Information has sensitivity levels or classification • Subjects have clearance • Subjects with clearance are allowed access • Multi-level access control or mandatory access control

9. Bell-LaPadula: Basics • Mandatory access control • Entities are assigned security levels • Subject has security clearance L(s) = ls • Object has security classification L(o) = lo • Simplest case: Security levels are arranged in a linear order li< li+1 • Example Top secret > Secret > Confidential >Unclassified

10. “No Read Up” • Information is allowed to flow up, not down • Simple security property: • s can read o if and only if • lo≤ lsand • s has read access to o • Combines mandatory (security levels) and discretionary (permission required) • Prevents subjects from reading objects at higher levels (No Read Up rule)

11. “No Write Down” • Information is allowed to flow up, not down • *property • s can write o if and only if • ls≤ lo and • s has write access to o • Combines mandatory (security levels) and discretionary (permission required) • Prevents subjects from writing to objects at lower levels (No Write Down rule)

12. Categories • Total order of classifications not flexible enough • Alice cleared for missiles; Bob cleared for warheads; Both cleared for targets • Solution: Categories • Use set of compartments (from power set of compartments) • Enforce “need to know” principle • Security levels (security level, category set) • (Top Secret, {Nuc, Eur, Asi}) • (Top Secret, {Nuc, Asi}) • Combining with clearance: • (L,C) dominates (L’,C’)  L’ ≤L and C’ C • Induces lattice of security levels

13. Lattice of categories {Nuc, Eur, Us} • Examples of levels • (Top Secret, {Nuc,Asi}) dom (Secret, {Nuc}) • (Secret, {Nuc, Eur}) dom (Confidential, {Nuc,Eur}) • (Top Secret, {Nuc}) dom (Confidential, {Eur}) • Bounds • Greatest lower, • Lowest upper • glbof {X, Nuc, Us} & {X, Eur, Us}? • lubof {X, Nuc, Us} & {X, Eur, Us}? {Nuc, Eur} {Nuc, Us} {Eur, Us} {Us} {Nuc} {Eur} {}

14. Integrity policy • Requirements different than confidentiality policies • Biba’s models • Low-Water-Mark policy • Ring policy • Strict Integrity policy • Lipner’s model • Combines Bell-LaPadula, Biba for a more practical software development and deployment process • Clark-Wilson model • Transaction integrity • Separation of duty

15. Biba’s Integrity Policy Model • Based on Bell-LaPadula • Subject, Objects • Integrity Levels with dominance relation • Higher levels • more reliable/trustworthy • More accurate • Information transfer path:Sequence of subjects, objects where • siroi • siwoi+1

16. Policies • Low-Water-Mark Policy • swo i(o) ≤i(s) prevents writing to higher level • sro  i’(s) = min(i(s), i(o)) drops subject’s level • s1xs2  i(s2) ≤i(s1) prevents executing higher level objects • Ring Policy • sro allows any subject to read any object • swo  i(o) ≤i(s) (same as above) • s1xs2  i(s2) ≤i(s1) • Biba’s Model: Strict Integrity Policy (dual of Bell-LaPadula) • sro  i(s) ≤i(o) (no read-down) • swo i(o) ≤i(s) (no write-up) • s1xs2  i(s2) ≤i(s1) • Theorem for each: • If there is an information transfer path from object o1 to object on+1, then the enforcement of the policy requires that i(on+1) ≤i(o1) for all n>1

17. Requirements of Commercial Integrity Policies (Lipner) • Users will not write their own programs, but will use existing production programs and databases. • Programmers will develop and test programs on a nonproduction system; if they need access to actual data, they will be given production data via a special process, but will use it on their development system. • A special process must be followed to install a program from the development system onto the production system. • The special process in requirement 3 must be controlled and audited. • The managers and auditors must have access to both the system state and the system logs that are generated.

18. Integrity Policy: Principles of operation • Requirements induce principles of operation: • Separation of Duty: Single person should not be allowed to carry out all steps of a critical function • Moving a program from Dev. to Prod. system • Developer and Certifier (installer) of a program • Authorizing checks and cashing it • Separation of function • Do not process production data on development system • Auditing • Emphasis on recovery and accountability • Controlled/audited process for updating code on production system

19. RBAC (NIST Standard) Permissions PA UA Users Roles Operations Objects user_sessions (one-to-many) role_sessions (many-to-many) Sessions An important difference from classical models is that Subject in other models corresponds to a Session in RBAC

20. Advantages of RBAC • Allows Efficient Security Management • Administrative roles to manage other roles • Role hierarchy allows inheritance of permissions • Principle of least privilege • Minimizes damage • Separation of Duties constraints • Prevents fraud • Grouping Objects • Permissions can be grouped according to a class of objects • Policy-neutrality • Provides generality

21. Core RBAC (relations) • Permissions = 2Operations x Objects • UA ⊆ Users x Roles • PA ⊆ Permissions x Roles • assigned_users: Roles  2Users • assigned_permissions: Roles  2Permissions • Op(p): set of operations associated with permission p • Ob(p): set of objects associated with permission p • user_sessions: Users  2Sessions • session_user: Sessions  Users • session_roles: Sessions  2Roles • session_roles(s) = {r | (session_user(s), r)  UA)} • avail_session_perms: Sessions  2Permissions

22. RBAC with General Role Hierarchy RH (role hierarchy) Permissions PA UA Users Roles Operations Objects user_sessions (one-to-many) role_sessions (many-to-many) Sessions

23. RBAC with General Role Hierarchy • authorized_users: Roles 2Users authorized_users(r) = {u | r’ ≥ r &(r’, u) UA) • authorized_permissions: Roles 2Permissions authorized_users(r) = {p | r’ ≥ r &(p, r’) PA) • RH ⊆ Roles x Roles is a partial order • called the inheritance relation • written as ≥. (r1 ≥ r2) authorized_users(r1) ⊆ authorized_users(r2) & authorized_permisssions(r2) ⊆ authorized_permisssions(r1)

24. pp px, py px, py px, py px, py px, py px, py e10 e8, e9 e6, e7 e5 e3, e4 e1, e2 po pa, pb pm, pn px, py p1, p2 Example authorized_users(Employee)? authorized_users(Administrator)? authorized_permissions(Employee)? authorized_permissions(Administrator)?

25. Constrained RBAC RH (role hierarchy) Static Separation of Duty Permissions PA UA Users Roles Operations Objects user_sessions (one-to-many) Dynamic Separation of Duty Sessions

26. Static Separation of Duty • SSD ⊆2Roles x N • In absence of hierarchy • Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n) SSD, for allt ⊆RS: |t| ≥ n ∩rtassigned_users(r)=  • In presence of hierarchy • Collection of pairs (RS, n) where RS is a role set, n ≥ 2; for all (RS, n) SSD, for allt ⊆RS: |t| ≥ n ∩rtauthorized_uers(r)= 

27. Dynamic Separation of Duty • DSD ⊆2Roles x N • Collection of pairs (RS, n) where RS is a role set, n ≥ 2; • A user cannot activate n or more roles from RS • What if both SSD and DSD contains (RS, n)? • Consider (RS, n) = ({r1, r2, r3}, 2)? • If SSD – can r1, r2 and r3 be assigned to u? • If DSD – can r1, r2 and r3 be assigned to u?

28. MAC using RBAC HR LW H Read Roles (same lattice) Write Roles (inverse lattice) M1R M2R M1W M2W M1 M2 BLP LR H L • Transformation rules • R = {L1R, L2R,…, LnR, L1W, L2W,…, LnW} • Two separate hierarchies for {L1R, L2R,…, LnR} and { L1W, L2W,…, LnW} • Each user is assigned to exactly two roles: xR and LW • Each session has exactly two roles yR and yW • Permission (o, r) is assigned to xR iff (o, w) is assigned to xW)

29. Security for Grid-based Computing SystemsIssues and Challenges

30. What is a Grid? • Enabling the coordinated use of geographically distributed resources — in the absence of central control, omniscience, strong trust relationships connect distributed heterogeneous high performance computer, computer cluster, large-scale database server and large-scale file server with high-speed interconnection network and integrate them into a transparent virtual high-performance computing environment. — Ian Foster

31. What is a Grid? • Systems & applications that integrate and manage resources and services distributed across multiple security domains • Large and dynamic pool of users and resources • Sharing is highly controlled & coordinated • Dynamic creation of services • Form virtual organizations (VO) • Collaboration is dynamic, ad-hoc • Resource providers belong to different real organizations employing different policies and mechanisms

32. What is a Grid? Domain 1 Domain 3 Virtual Organization Policy Domain 2 Domain 4 Essentially a Dynamic Multidomain Environment

33. Grid Security • Globus Toolkit (GT) includes Grid Security Infrastructure (GSI) • PKI to support identity mapping, single sign-on, delegation • GT2 • X.509 certificate, TLS, SSL protocol • Proxy certificate for delegation • Community Authorization Service • GT3 – Open Grid Services Architecture (OGSA) • Align Grid with web services technologies

34. Limitation of Classic Globus Authorization • Scalability • Each personnel or policy change requires changing policy at each participating site • Authorization is done at VO as well as in each site • Authorization information needs to be managed by individual local site • Expressivity • Native OS methods may not be expressive enough to support VO policies • Consistency • Native OS methods at different sites may not support the same kinds of policies

35. Grid Challenges • Individual hosts (resource providers) • Each domain must specify highly dynamic set of access control policies • Challenges • Highly flexible access control framework (attribute-based AC) • Multi-domain problem • Multiple policies need to be integrated • Challenges • Multidomain challenges! • Trust issues and Risk management

36. Secure interoperation • Challenges • Expressive multi-domain policy specification framework • Automation of the integration of policies • Algorithms to detect violations and compute maximal secure interoperation scalability? Policy negotiation Issues (trust) Delegation Identity/Credential mapping

37. Security Management • Tools and techniques needed to support efficient administration of Grid security • Grid can scale to Internet size • Dynamically changing resource pool • Protection objects may include • Compute cycle; storage elements • Sophisticate instruments • Data (files and database elements) • Services • High level information knowledge/concepts • Dynamic pool of users with diverse credentials • Identity/credential management • Policies and mechanisms evolve

38. Trust and Risk Management • Trust management is essential for dynamic collaboration environment • Trust-based authorization • Absolute security is not possible • Single point of failure situation • Security assurance may vary • Grid resources may be very sensitive • Trust and risk issues become very crucial • Impact severity of information leaks? • How to control propagation of risks?

39. Grid Challenges • Individual hosts (resource providers) • flexible access control framework • Multi-domain problem • Semantic heterogeneity & secure interoperability • Security management • Trust issues and Risk management

40. Local Policy Base Local Policy Base Access Control Module Local Policy Base Multidomain Security Application (e.g., workflow) Application (e.g., workflow) Lightly-coupled Access Control Module Access Control Module Trust-based Application (e.g. workflow) User’s access requests User’s authorization Access Control Module Global Policy Base Application (e.g., workflow) Application (e.g., workflow) Tightly-coupled (Federated system) Access Control Module Local Policy Base

41. Semantic heterogeneity • Different systems may use different security policies • e.g., DAC, MAC, Chinese wall, Integrity policies etc. • Variations of the same policies • e.g., BLP model and its several variations • Naming conflict on security attributes • Similar roles with different names • Similar permission sets with different role names • Structural conflict • different multilevel lattices / role hierarchies

42. Secure Interoperability • Principles of secure interoperation Principle of autonomy • If an access is permitted within an individual system, it must also be permitted under secure interoperation in a multi-domain environment. Principle of security • If an access is not permitted within an individual system, it must not be permitted under secure interoperation. • Interoperation of secure systems can create new security breaches

43. Unsecure Interoperability A X A X d c a a Y Y B C B C b b D Z D Z 2 1 2 1 F12 = {a, b, c, d} F12 = {a, b} (1) F12 = {a, b, d} Direct access (2) F12 = {c} F12 - permitted access between systems 1 and 2

44. Challenges in Secure Interoperability • How to ensure autonomy and security principles? • Determining inconsistencies/incompleteness in security rules. • Identifying security holes • Selecting optimality criteria for secure interoperability: maximizing number of domains, direct accesses

45. Assurance and Risk Propagation & Security Management • Assurance and Risk propagation • Breach in one domain can render the whole environment insecure • Cascading problem • Security Management • Centralized/Decentralized • Managing global metapolicy • Managing policy evolution

46. Approaches to Multidomain Problem • Policy-Metapolicy specification framework • Ad-hoc, Formal models: lattice merging, RBAC • Agent based approach (Policy agents) • Architectural approaches (CORBA, DCE)

47. A Multi-Domain Access Control Framework • A Multi-Phase Framework • Based on RBAC model Pre-integration Policy Comparison Policy Conformance Merging/ Restructuring Need external mediation policy to handle conflicts/incompleteness Consistent, complete and optimal specification

48. Pre-integration Phase • Requires RBAC representation of arbitrary policies. A policy mapping technique is needed for non-RBAC systems. • Uses an information base • Semantic information about domains including policies, roles and attributes • Integration/merging strategies to generate the overall configuration of the multi-domain environment.

49. Policy Comparison and Conformance • Tools & techniques for detecting • Semantic conflicts • Naming conflicts • Structural conflicts • Rule conflicts • Mediation policies are needed for resolution • Predefined meta-policies • Domain cooperation by administrators • Tradeoffs • Determine optimal/heuristic solutions secure interoperability

50. [De] Merging/Restructuring • Merging/integrating policies • Restructure domain policies according to the selected optimal criteria • Generate integrated global policy • Repeat policy conformance step • Re-evaluation and restructuring of meta-policy