Protection & Security

1. Protection & Security Greg Bilodeau CS 5204 October 13, 2009

2. Protection from: • Malicious users • Modifying data • Accessing confidential data • Misuse of resources • Collaborative efforts • Controlling access to data • Allowing the right users the right privileges CS 5204 – Fall, 2009

3. How to secure a system • Authenticate • Authorize • Audit changes, prepare for recovery • Close the system to un-trusted users • Isolation • Exclusion (firewalls) • Restrict un-trusted users to sandbox • File security system • Best approach is combination of tactics CS 5204 – Fall, 2009

4. Principles of Security Assign only the rights needed (least privilege) Partition rights by duty or role (separation of duties) Enforce rights in simplest manner (economy of mechanism) Acceptable to user community (acceptability) Universal enforcement of policies (complete mediation) “Security through obscurity” not required (open design) CS 5204 – Fall, 2009

5. Goals for Security Only modified by authorized entities Only accessed by authorized entities (confidentiality) Cannot disclaim ownership (non-repudiation) Source can be verified (authenticity) Accessible to authorized entities CS 5204 – Fall, 2009

6. Goals for Collaborative Systems Applied and enforced at distributed platform level Generic and useful for variety of tasks Be scalable to large numbers of potential shared operations Protect data at various levels of granularity Transparent access for authorized, strong exclusion for unauthorized that doesn’t hamper collaboration Allow high-level access rights Dynamic, specify and change policies at run time Not hamper performance CS 5204 – Fall, 2009

7. Access Matrix O5 O6 O1 O2 O3 Sx = Subject Ox = object O = Owner R = read access W = write access *X = copy bit set O4 W S1 *O R W R *R W S2 R W R S3 CS 5204 – Fall, 2009 Abstract reference model to associate subjects with objects (and other subjects), used by security monitor querying reference monitor

8. Access Matrix • May change over time • Users added or removed • Files created or deleted • Commands manipulate the matrix • First test if conditions for command are true, ex: check if subject attempting to give write access to another subject for an object has *W access right • If it does, update the entry for the target subject with the new access right CS 5204 – Fall, 2009

9. Implementing the access matrix • Matrix can be implemented in various ways • Subject perspective • Subjects • Roles • Teams • Object perspective • Objects • Domains • System perspective • Tasks • Clearance • Context • Lock and key • Memory mapping CS 5204 – Fall, 2009

10. Capability Lists O4 O5 O6 O1 O2 O3 S1 {*O,O1} {R,O2} {W,O3} {R,O4} {W,O6} S2 {R,O1} {W,O3} {*R,O5} {W,O6} {R,O5} S3 CS 5204 – Fall, 2009

11. Capability Lists Defined as a list of {permission, object} pairs Gives entire access rights profile of each subject Easier to store in memory than entire matrix Subject incapable of starting action without permission CS 5204 – Fall, 2009

12. Access-control Lists O1 O2 O3 O4 O5 O6 S1 {*O,S1} {R,S1} {W,S1} {W,S1} {R,S1} S2 {R,S2} {W,S2} {W,S2} {*R,S2} S3 {R,S3} CS 5204 – Fall, 2009

13. Access-control Lists CS 5204 – Fall, 2009 Defined as a list of {permission, subject} pairs Gives entire access rights profile of each object Easier to store in memory than entire matrix

14. Capability List and Access-control List • Difficult to dynamically change access rights: • Capability list: difficult to determine how many and which subjects have rights for a given object • Access-control list: difficult to tell all accesses a subject has across objects • Do not account for contextual information • Context: environmental variables, dynamism and unpredictability • Context can define access when in a given role CS 5204 – Fall, 2009

15. Role-Based Access Control (RBAC) Assigning access rights to roles R1 {*O,O1} {R,O2} {W,O3} S1 R3,R1 R2 {R,O5} S2 R2 R3 {R,O6} S3 R2 Assigning roles to subjects CS 5204 – Fall, 2009

16. Role-Based Access Control (RBAC) Roles created for various combinations of {object, rights} pairs, subject assigned one or more roles Assignment of rights to roles and roles to subjects can be done at different times Allows updating of multiple subject’s access rights automatically through inheritance Allows cardinality and conflict of interest rules to be enforced However, cannot allow specific subject access to specific object CS 5204 – Fall, 2009

17. Domain-Based Access Control O1 O2 O3 O4 O5 O6 S1 {*O,S1} {R,S1} {W,S1} {W,S1} {R,S1} S2 {R,S2} {W,S2} {W,S2} {*R,S2} {R,S3} S3 O2 O6 O4 O3 {R,S1} {W,S1} {W,S2} CS 5204 – Fall, 2009

18. Domain-Based Access Control Similar to Role-Based Authenticates user when he enters the domain CS 5204 – Fall, 2009

19. Task-Based Access Control (TBAC) Protection States A2 {*O,O1} {R,O2} {W,O3} A1 Activate A1 Tasks {R,O5} Deactivate A2 A3 {R,O6} A3 CS 5204 – Fall, 2009

20. Task-Based Access Control (TBAC) Task-based access control (TBAC) changes subject’s rights as it moves through stages of a given task Steps associated with protection state, with specific rights Each step has disjoint protection state Limited in context to activities, tasks and workflow progress CS 5204 – Fall, 2009

21. Team-Based Access Control (TMAC) CS 5204 – Fall, 2009

22. Team-Based Access Control (TMAC) Assigns permissions based on team designations Both user and object contexts (similar in concept to a combination of RBAC and Domain) Can be modified depending on environment context, i.e. what other subjects/teams are present Allows fine-grained control over individual users and objects Context-Based TMAC (C-TMAC) Incorporates context as an entity in the architecture CS 5204 – Fall, 2009

23. Spatial Access Control S1 {Reg1} *W Access Graph S2 {Reg2, Reg3} R Region 1 Region 2 Region 3 Boundary “Collaborative Environment” CS 5204 – Fall, 2009

24. Spatial Access Control • Boundaries create regions • Access graph gives credentials • Governs movement within and between regions • Specifies access rights within each region • No support for fine-grained control • Insecure region creation possible CS 5204 – Fall, 2009

25. Context-Aware Access Control (Context-AW) Assigning access rights to environment roles E1 {*O,O1} {R,O2} {W,O3} S1 E3,E1 S1 E3 S2 E2 S2 E2 E2 {R,O5} S3 E2 S3 E2 E3 {R,O6} Assigning roles to subjects based on context Extends RBAC with environment roles Capture environment state Roles activated based on environment conditions at time of request CS 5204 – Fall, 2009

26. Comparison of access control methods CS 5204 – Fall, 2009

27. Bell­LaPadula Model classification clearance level n w i level i r,w objects r subject level 1 *-property CS 5204 – Operating Systems

28. Lock-and-Key Access Control Subjects associated with set of keys for objects S1 O1,K1 O2,K1 O1 K1,R K2,W S2 O1,K2 O2 K1,R K2,W S3 O2,K1 Each object associated with a {key, rights} pair CS 5204 – Fall, 2009

29. Lock-and-Key Access Control Like capability list Key values are meaningless to the subject Key values have no inherent rights CS 5204 – Fall, 2009

30. Memory Protection Hardware based on mapping Memory not in range of map protected Each subject/domain has own address space CS 5204 – Fall, 2009

31. Conclusion • Propagation of rights between users • Simple in subject and system* perspectives • Difficult for data perspective • Discovery of rights to a resource • Simple in object perspective • Difficult in subject and system* perspectives • Revocation • Simple in object and system* perspectives • Difficult in subject perspective • Reclamation • Simple in object and system* perspective • Difficult in subject perspective CS 5204 – Fall, 2009

32. Questions ? CS 5204 – Fall, 2009