1. CSE333 URBSOO-1 User Role Based Security for Object-Oriented Systems/Applications M.-Y. Hu, S. Demurjian, T.C. Ting Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 {steve, ting@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. CSE333 URBSOO-2 Overview of Presentation  Object-Oriented Design Model Concepts  Review: Approaches/Concepts of Security  Motivation of URBS for OO  User Role Based Security for Discretionary Access Control  Concepts and Issues  URBS Example for SDEs  Security Issues for OO Paradigm  URBS Approaches - OO and C++  Advanced Security Code Generation  Software Architectures for URBS  Reflections and Comments

3. CSE333 URBSOO-3 An Object-Oriented Design Model  Assumptions of OO Design Model  Vocabulary:  What are Object Types?  Attributes?  Methods?  Public Interface vs. Hidden Implementation  Concept of a Profile  Inheritance and its Variants

4. CSE333 URBSOO-4 OTs, Attributes, and Methods

5. CSE333 URBSOO-5 Encapsulation and Hiding

6. CSE333 URBSOO-6 Profiles to Track Design Data  Profiles Contain Detailed Requirements on the Semantic Contex(n)t for All Constructs of Application  Force SWEs to Supply Detailed Design Info. As Application is Designed  All Profiles Share Following:  [Defn. 6:] A base profile (BP) contains: a name for the feature or construct and a prose description for its purpose within application.  We'll Focus on Non-Security Constructs  We'll Provide Examples via earlier Prototype (ADAM) and Health Care Application (HCA)

7. CSE333 URBSOO-7 Attribute Profile

8. CSE333 URBSOO-8 Method Profile

9. CSE333 URBSOO-9 Object Type Profile

10. CSE333 URBSOO-10 Object Type Profile

11. CSE333 URBSOO-11 Inheritance Variants  Distinguish Between Type and Instance Level  Employ a Hierarchy to Define Choices:  T-LEVEL: Variants that Dictate the Information and Behavior that is Inherited by Subtype from Supertype  I-LEVEL: Variants that Relate to If and How a Subtype is Instantiated ISA / +-----+ +---------+ / T-LEVEL I-LEVEL / / | +---+ / +----+ | / / | FULL PRIV1 PRIV2 RESTR CONSTRUCTOR / | +--+ | / | ABSTR LEAF(DB) REGULAR(PL)

12. CSE333 URBSOO-12 Four T-LEVEL Combinations  What Can be Inherited?  Who Can See What When?

13. CSE333 URBSOO-13 What Dictates Correct Variant? What Dictates Correct Variant?  The OT's Role in Application:  FULL for Unlimited Cooperative Design  PRIV1 for Cooperative Design, No Priv. Data  PRIV2 Limits Access to PPI methods  RESTR Requires Intervention of URBS  The Responsibility SWEs w.r.t. Application  A Time Factor which Mandates Different Interpretations in a Application's Lifetime:  Initially ISA - FULL  Design Partitioned Among Multiple SWEs - PRIV1, PRIV2, and RESTR May be Chosen  User Role(s) of SWEs from URDH are Utilized!  Trying to Integrate Security Concepts into Design

14. CSE333 URBSOO-14 C++ Equivalents for Variants  To Understand Different Variants, Let's Consider C++ Analogs for Design Model Constructs  Provides a General Indication of Impact of Different Inheritance Combinations on Code Generation

15. CSE333 URBSOO-15 Impact on Code Generation SUPPOSE: OT1 = (D1, M1), with M1=(HM1,PM1) | OT2 = (D2, M2), with M2=(HM2,PM2) FULL: OT2 = (OTName2, {D1,D2, {M1, M2) C++ : class OT1 { protected: D1, HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2; Notice: OT2 inherits all Data and Methods Only PM1, PM2 have Potential to be Public!

16. CSE333 URBSOO-16 Impact on Code Generation PRIV1: OT2 = (OTName2, {D2, {M1, M2) C++ : class OT1 { private : D1; protected: HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2; PRIV2: OT2 = (OTName2, {D2, {PM1, M2) C++ : class OT1 { private : D1, HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2;

17. CSE333 URBSOO-17 Three I-LEVEL Combinations  ABSTR: Short for Abstract Class  Instantiation of a Subtype is Neither Desirable Nor Possible  LEAF: Database Version  Creation (Deletion) of Instances at the Leaves  REGULAR: Programming Version  Creation/Deletion at Any Hierarchy Node  Implications on University Example? Person / Student Employee / UnderGrad Graduate Faculty

18. CSE333 URBSOO-18 Impact on Code Generation  No Changes to Previous Slides on What Gets Inherited  ABSTR: At Least One Pure Abstract Method  LEAF: Instantiate at Leaf Nodes  REGULAR: Generate Public Constructors  What Happens With Mixed Inheritance Variants?  Which Ones Make Sense?  Which Ones Cause Conflicts? GENERATE protected constructors in C++! PERSON - constructor is protected | EMPLOYEE - constructor is protected | FACULTY - constructor is public

19. CSE333 URBSOO-19 C++: (REGULAR, FULL) Inheritance

20. CSE333 URBSOO-20 C++: (LEAF, RESTR1) Inheritance class Record : public Object { // ATTRIBUTES: private: int RecNo; // A unique record number protected: // System defined CONSTRUCTOR & DESTRUCTOR: Prescription(); virtual ~Prescription(); // **** System defined protected methods. protected: void SetRecNo(float toSet); // **** System defined public methods. public: void PrintRecNo(); float GetRecNo(); void printallattrs(); ;

21. CSE333 URBSOO-21 Glossary of Protection and Security Terms  Access Control List  List of Principals (User, Process, …) Authorized to have Access to Some Object  Authenticate  Verify Identity of Principal Making Request  Authorize  Grant Principal Access to Information  Capability  Unforgeable Ticket as Proof of Authorization of Presenter to Access Named Object  Capability List  List of Protected Objects which Likewise List Authorized Principles

22. CSE333 URBSOO-22 Glossary of Protection and Security Terms  Certify  Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism  Confinement  Restricting What a Process Can Do to with Authorized Objects  Domain  Objects Currently Accessed by Principal  (De)Encryption  De(Encoding) of Data According to Transformation Key for Transmission/Storage  Grant  Authorize Access to Objects by Principals

23. CSE333 URBSOO-23 Glossary of Protection and Security Terms  Password  Encrypted Character String to Authenticate Identity of Individual  Permission  Form of Allowed Access to Object (R, W, RW)  Principal  Entity (Person/Process/etc.) to Which Authorizations are Granted  Privacy  Ability to Decide Whether, When, and to Whom Information is Released  Propagation  Principal Passing on Authorization to Object to Another Principal

24. CSE333 URBSOO-24 Glossary of Protection and Security Terms  Protected Object  Known Object whose Internal Structure is Inaccessible Except by Protection System  Protection & Security  Mechanisms and Techniques to Control Access to Information by Executing Programs  Revoke  Remove Previously Authorized Access from Principals  Ticket-Oriented  Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.

25. CSE333 URBSOO-25 Review Fundamental Security Issues  Software Engineers Can Write Complex Programs Limited by Intellectual Capabilities  OS Designer Must Create Protection Scheme that Can’t be Bypassed by Current and Future Software  Users and Processes Initiators  Users have Dedicated and Shared Resources  Resources Shared by User Groups vs. Resources Globally Shared  Users Spawn Processes that Access Resources  Processes May be Local or Remote (on Another Machine Connected via Network)  Protection System of OS Must Support Above According to Organization’s Admin. Policy

26. CSE333 URBSOO-26 Review Policy & Mechanism  Security Policy Defines Rules for Authorizing Access to Computer and Resources  Who are Users? What are Resources? What Resources are Available to Each User? Etc…  Protection Mechanisms Authenticate  Access to Resources  Insure File and Memory Protection  A Security Policy is an Organizations Strategy to Authorize Access to the Computer’s Resources  Managers have Access to Personnel Files  OS Processes have Access to the Page Table  Security Transcends OS as a Separate Research and Realization for All Types of Systems/Applications

27. CSE333 URBSOO-27 Review Authentication  User/Process Authentication  Is this User/Process Who It Claims to Be?  Passwords  More Sophisticated Mechanisms  Authentication in Networks  Is this Computer Who It Claims to Be?  File Downloading and Transferring  Obtaining Network Services  What is the Java Promise?  What Does Java Guarantee re. Applets?  What Can Application Do that Applet Can’t?

28. CSE333 URBSOO-28 Review Authorization  Ability of Principals to Use Machines, Objects, Resources, etc.  Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc.  Authorization Mechanism Enforces Policy at Runtime  External Authorization  User Attempts to Access Computer  Authenticate Identify and Verify Authorizations  Internal Authorization  Can Process Access a Specific Resource?

29. CSE333 URBSOO-29 Review User Authentication  Combination of User ID and Password Universal for Access to Computers  However, Cannot Prevent …  Guessing of Passwords  Stolen and Decrypted Passwords  Masquerading of Intended User  Is User Who they are Supposed to be?  What Extra Information Can User be Asked to Supply?  What About Life Critical Situations (DCP)?  Past Invasion of Engineering Computing  yppasswd File Stolen/Decrypted  S. Demurjian’s Sun Workstation Corrupted

30. CSE333 URBSOO-30 Review Network Authentication  Computers Must Interact with One Another  Classic Example, Transmitting E-Mail Msgs.  Does Transferring Computer have Right to Store a File on Another Computer?  Viruses: Passive Penetrating Entity  Software Module Hidden in Another Module  When Container Executed, Virus Can Penetrate and Wreak Havoc  Worms: Active Penetrating Entity  Actively Seeks to Invade Machine  Morris’s Worm Penetrated via Unix Finger  Passed String that Executed Allocated Memory  Destroyed Runtime Stack/Allowed Worm Execute

31. CSE333 URBSOO-31 Review What are Available Security Approaches?  Mandatory Access Control (MAC)  Bell/Lapadula Security Model  Security Levels for Data Items  Access Based on Clearance of User  Discretionary Access Control (DAC)  Richer Set of Access Modes  Focused on Application Needs/Requirements  User-Role Based Security (URBS)  Variant of DAC  Responsibilities of Users Guiding Factor  Facilitate User Interactions while Simultaneously Protecting Sensitive Data

32. CSE333 URBSOO-32 Security in Software Applications Focusing on DAC and URBS  Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/URBS for OO  Efforts in  Automatically Generatable and Reusable Enforcement Mechanisms  MAC/DAC/URBS Security within Distributed Setting  Premise:  Customizable Public Interface of Class  Access to Public Interface is Variable and Based on User Needs and Responsibilities  Only Give Exactly What’s Needed and No More

33. CSE333 URBSOO-33 Motivation User-Role Based Security for OO  Public Interface is Union of All Privileges for All Potential Users No Explicit way to Prohibit Access  Customizable Public Interface of Class  Access to Public Interface is Variable and Based on User Needs and Responsibilities  Only Give Exactly What’s Needed and No More public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc… For MDs and Nurses For MDs Only For Admitting

34. CSE333 URBSOO-34 Focusing on DAC and URBS   We’ve Explored DAC/URBS for OO Systems and Applications   Potential Public Methods on All Classes   Role-Based Approach:  User Role Determines which Potential Public Methods are Available  Automatically Generate Mechanism to Enforce the Security Policy at Runtime  Allow Software Tools to Look-and-Feel Different Dynamically Based on Role   Approaches have Stressed Exploiting OO/PL Capabilities (Inheritance, Exceptions, Generics) While Limiting SW Engineers Knowledge

35. CSE333 URBSOO-35 What are Key Security Concepts? What are Key Security Concepts?  Assurance  Are the Security Privileges for Each User Adequate to Support their Activities?  Do the Security Privileges for Each User Meet but Not Exceed their Capabilities?  Consistency  Are the Defined Security Privileges for Each User Internally Consistent?  Least-Privilege Principle: Just Enough Access  Are the Defined Security Privileges for Related Users Globally Consistent?  Mutual-Exclusion: Read for Some-Write for Others

36. CSE333 URBSOO-36 URBS for OO Systems/Applications  User Role Based Security for Discretionary Access Control  OO Design Model Enhancements  URs, UTs, and UCs  User-Role Definition Hierarchy  Node Profiles for Privileges  URBS Example for SDEs  Security Issues for OO Paradigm  URBS Approaches - OO, ADAM, and C++  Advanced Security Code Generation  Software Architectures and URBS

37. CSE333 URBSOO-37 What is User-Role Based Security(URBS)?  Most OO Programming and Database Languages have a Single Public Interface that is Shared by All Users of OT/Class  Consequently, Public Interface Often Union of all Possible Methods Required by All Likely Users  Discretionary Access Control:  Occurs at Type-Level  Different Portions of Public Interface Available to Different Users at Different Times Depending on User-Roles  Promote Potential Public Interface

38. CSE333 URBSOO-38 Motivating Security for OO Paradigm  OO Paradigm Provides Minimal Support via Public Interface and Private Implementation  Public Interface Represents UNION of all Possible Privileges Needed by All Potential Users  A Method in the Public Interface for One Specific User Available to ALL Users  Can Access to Public Interface be Customized?  Can Individuals have Particular Access to Specific Subsets of Public Interface?  Can Access be Based on (Potentially) Dynamic User Roles?  Can Code be Automatically Generated to Implement an Enforcement Mechanism?  Role of OO Paradigm in Support a Generic, Evolvable, Reusable Enforcement Mechanism?

39. CSE333 URBSOO-39 Why is URBS Needed?  Many Situations When OT Library Designer (SWE) Could Utilize More Fine-Grained Control to Access of Public Interface  Tradeoff Between Developers and End-Users  SWEs Have Different Roles Based on Their Responsibilities Related to Cooperative Design on an Application  SWEs Should Only See Those Portions of the Application That They Need to See or That They Will Be Responsible for Implementing  End-users Must Be Limited in Their Interactions and Access Depending on Their Roles

40. CSE333 URBSOO-40 Why is URBS Needed?  For Example:  In SDEs, the public interface for Modules has methods that read (for SWEs and Managers) and modify instances (only for SWEs)  In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller)  In HCA, different health care professionals (e.g., Nurses vs. Physicians vs. Administrators, etc.) require select access to sensitive patient data

41. CSE333 URBSOO-41 What is URBS Approach?  Collects User Role, User Type, and User Class into User-Role Definition Hierarchies for Application  To Establish Privileges: Assign Different Methods of PIs to Different UCs, UTs, and URs  Defined Security Must be Enforced:  For SWEs - by Supporting Environment  For End-Users - by Application and Its Tools  URBS Approach Intentionally Obscures Information and Its Access  Consistent with OO Principles on Hiding  Force SWEs to Focus on Abstract Concepts  Incorporate URBS into OO in a Manner Consistent with OO Principles and Philosophy

42. CSE333 URBSOO-42 FYI: The ADAM Environment +---------------------------------------------+ | ADAM OO GUI Code Generation | | +----------------+ +---------------+ | | | OO Design and |-------| Ada83, Ada95 | | | | URBS Definition| | C++, Ontos C++| | | +----------------+ | Latex Documen.| | | | | Eiffel, IDL | | | | | ---------| | | +-------------+ | JAVA |Mod-3 | | | | Server | +---------------+ | | | Abstraction | <--- Supports Design | | +-------------+ Persistence | | / | | | Unix Ontos Other DBS... | | File OODBS | | System | | ADAM/UNIX, IV3.1, X, SparcStation | | ADAM/PC, Windows95, Borland C++ | | ADAM/NT, WindowsNT, Java | +---------------------------------------------+

43. CSE333 URBSOO-43 OO Design Model Enhancements  Extend OO Design Model to Support URBS  Extensions are Consistent with Model and OO Paradigm  Focus on:  User-Role Definition Hierarchy  Identifying Relevant Profiles  Detailing Privilege Acquisition Process  Changes to Existing Profiles  Automatic Analyses for Information Consistency

44. CSE333 URBSOO-44 The Health Care Application - OTs

45. CSE333 URBSOO-45 The Health Care Application - OTs

46. CSE333 URBSOO-46 The Health Care Application - OTs

47. CSE333 URBSOO-47 The Health Care Application - RTs

48. CSE333 URBSOO-48 The User Role Definition Hierarchy  Characterize Individual/Group Application Access via Hierarchy in Three Abstraction Levels :  User-Roles (URs) for Fine-Grained Activities  grade-recorder (changes and corrections)  transcript-issuer (fill transcript request)  User-Types (UTs) for Similarities that are Shared Among Set of URs  registrar-staff is common responsibilities (access student records) among URs  User-Classes (UCs) for Commonalities Across UTs  non-academic-staff (UTs: purchasing-staff, campus-police, maintenance-staff, etc.)  academic-staff (UTs: dept-staff, registrar-staff, presidents-office, etc.)

49. CSE333 URBSOO-49 User Role Definition Hierarchy for HCA Users UC:Medical_Staff UT:Nurse UT:Physcian UR:Manager UR:Staff_RN UR:Education UR:Discharge_Plng UR:PrivateUR:Attending UC:Support_Staff Etc. UT:Technician UR:Director UR:LabUR:Pharmacy UR:Radiology

50. CSE333 URBSOO-50 User Role Definition Hierarchy for HTSS Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police... dept-staff registrar-staff... / \...... / \ grade-recording transcript-issuing

51. CSE333 URBSOO-51 Privilege Definition Process  Assignment  Assign Methods to Various Nodes of URDH  Methods that are Assigned are Positive Privileges  Indicate they can be Invoked by User (via a Software Application/Client)  Prohibition  Indicate the Methods which Can’t be Called  These represent the Negative Privileges  Attempt to Invoke by User (via a Software Application/Client) Results in Exception  Why are Prohibited Methods Necessary?

52. CSE333 URBSOO-52 Privilege Acquisition Process  Assignment  Assigned to UR for Its Use Only  Assigned to UT and Passed to Its URs  Assigned to UC and Passed to Its UTs  Employ OO Concepts: Inheritance w.r.t. Privileges  Specialization (UT to URs)  Generalization (URs to UT, UTs to UC)  Notes:  A UR Under 2 UTs May Have Diff. Meaning  URs Cannot be Further Specialized  Granularity of UR: Designer Definable!  Vitals, SetIV, etc., in HCA  OrderItem, TakeInventory, etc., in HTSS

53. CSE333 URBSOO-53 Node Profiles and Privileges Node Profiles and Privileges  Profiles Contain Detailed Requirements on the Semantic Contex(n)t for Security Related Aspects of Application

54. CSE333 URBSOO-54 Node Descriptions Examples from HCA

55. CSE333 URBSOO-55 Role Security Requirements Examples from HCA

56. CSE333 URBSOO-56 Assignment of Methods Positive Privileges for Nodes  Explicit Access to PPI Methods of OTs  Staff_RN Assigned:  Get_Symptom of Visit and Get_Medication of Prescription  Get_Patient_Name of Record and Get_Test of Medical_R  Set_Symptom (record symptoms on patients)  Set_Test_Code (record test to be conducted)  Set_Patient_Name and Insert_Med_History  Discharge_Plng and Education Assigned:  Similar Get Methods  Limited Write: Insert_Med_History

57. CSE333 URBSOO-57 Implied Methodology for Assignment  Privileges Associated with URs  Shared Privileges for URs Under Same UT Can be Moved to UT  Shared Privileges for UTs Under Same UC Can be Moved to UC  However, Methods Assigned to:  UC Available to Its UTs/URs  UT Available to Its URs  Observe that:  Commonalities Push Up Tree  Differences Flow Down Tree

58. CSE333 URBSOO-58 Two Important Concepts  Methods Call Other Methods  “8” Methods Assigned to Staff_RN  Direct Methods/Explicitly Assigned  “n” Indirect Methods Assigned to Staff_RN  “8” Methods Assigned Call Other Methods  In Turn, Other Methods Call Still Other Methods  Hence, Chaining Effect of Implied (Actual) Calls  Methods on URDH Mirror Inheritance Concepts  Methods on UC Available to all of its UR  Methods on UR Specific to that Role

59. CSE333 URBSOO-59 Prohibited Methods Non-Allowed Actions/Negative Privileges  Important To Give Explicitly, Since:  Methods Call Other Methods (MP)  Assigned Methods Map to Larger Set Due to Calls and Inheritance  Staff_RN Prohibited:  Set_Treatment of Visit  Set_Medication of Prescription  Get_All methods from Medical_R  Prohibition w.r.t. Hierarchy:  On a UR Implies on Its UT/UC  On a UT(UC) Implies on Its URs(UTs)

60. CSE333 URBSOO-60 Consistency Criteria Relationships Between URDH Nodes Consistency Criteria Relationships Between URDH Nodes  Equivalence - URDH Nodes Must Have Same Capabilities per Assigned/Prohibited Methods  Physical  Respiratory  Respiratory  Occupational  Education  Discharge_Plng  Subsumption - Ordering Among URDH Nodes w.r.t. Capabilities  Staff_RN Discharge_Plng  Manager Staff_RN  Transitive Closure Applies

61. CSE333 URBSOO-61 A Complete Node Profile

62. CSE333 URBSOO-62 The Software Development Environment (SDE) Example

63. CSE333 URBSOO-63 The SDE URDH UC:SE UC:Manager

64. CSE333 URBSOO-64 Notation: Extending PPI Concepts

65. CSE333 URBSOO-65 The SDE URDH with Assigned Methods “Lousy” Assignment UC:SE {LPI1, M2.3, M3.3} UC:Manager(LPI1) {LPI4} {LPI2} {LPI4} {LPI3, M2.1, M2.2} {M2.4,2.5 M3.4,3.5} {M2.4,2.5 M3.4,3.5} {M2.4, M4.1} Notes: 1-SDECommon, 2-Project, 3-System, 4-Module

66. CSE333 URBSOO-66 Overview: Assigned Methods  UC SE: LPI1, M2.3, M3.3  All Methods from SDECommon  Retr_System (M2.3) from Project  Retr_Module (M3.3) from System  All UTs of SE Share Methods  UT SE-Regular: LPI4  Full Access to all Module Methods  Shared by All URs of SE-Regular  UR Report_Bugs: M4.1 Restricted Access

67. CSE333 URBSOO-67 Detailed Scope and Rational How are Flaws Identified/Corrected?

68. CSE333 URBSOO-68 Revising Privileges via URDH  Too Much: M-Division UT  LPI1 (SDECommon) from MANAGER  Add_User and Del_User  Remove LPI1 from MANAGER  Replace with M1.1, M1.4, M1.5, M2.4  Not Enough: SE-Maintain/Document} UR  M4.* Methods Not Accessible  Not Present on UT or UC  Assign Subset of LPI4  M4.1, M4.2, and M4.11

69. CSE333 URBSOO-69 Revising Privileges via URDH  Too Much: SE-Regular/Document UR  All Module Methods via LPI4  Includes Modification Methods  Move LPI4 Down Hierarchy  Assign Subset of LPI4

70. CSE333 URBSOO-70 Revising Privileges via OTs  Which URs Access an OT?  Shouldn't Have: {\tt SDECommon} OT  MANAGER/M-Division/Report has Access  Realization that Role is Not Needed - Remove  SE-Regular has Access to Add_User} and Del_User  Move LPI4 Down Hierarchy to Specific Roles  Should Have: Module OT  SE-Maintain/Document} Not On List  Correct Oversight as Previously Discussed  Note: Complementary Nature of Analyses w.r.t. URDH vs. OTs

71. CSE333 URBSOO-71 The SDE URDH with Assigned Methods Revised “Better” Assignment UC:SE{M1.5,M2.3,M3.3,M4.11} UC:Manager{M1.1,M1.4, M1.5,M2.4} {LPI4} {M2.1, {LPI4 M2.2, w/o M3.1, M4.1 M3.2, M4.2} LPI4} {M1.1, M2.4, M3.4, M4.1} Notes: 1-SDECommon, 2-Project, 3-System, 4-Module {M1.4,1.6 M2.4,2.5 M3.4,3.5 M4.1,4.2} {M1.4,1.6 M2.4,2.5 M3.4,3.5 M4.1,4.2} {M4.1}{GPI2}{M2.5}

72. CSE333 URBSOO-72 Last Thoughts on SDE Example  What Actions have Occurred?  Differences Trickle Downward  Commonalities Move Upward  Too Many/Few Privileges  Possible URDH Changes:  Method Assignments  Add a New Role/Delete an Existing Role  Split a Role into Two or More Roles  Possible Application Changes:  Add/Delete OTs  Modify Private Data Items  Change Inheritance  Add/Modify/Delete Methods

73. CSE333 URBSOO-73 Security Issues for OO Paradigm  MAC/DAC/URBS - Existing Security Approaches  Must Security for OO Systems Embody an Existing Approach?  Is there a `Better' or `New' Choice to Consider?  Are there Characteristics/Features of OO Paradigm, Systems, and Applications that Should Dictate Approach?  Focus on Impact/Influence of:  Encapsulation, Hiding, and Inheritance  OO Application Characteristics  Polymorphism, Dispatching, Overloading  Object-Oriented Paradigm Claim

74. CSE333 URBSOO-74 Encapsulation, Hiding, and Inheritance  Object Types (OTs)/Classes Involve:  Encapsulated: Data and Methods  Public Interface to Access OT  Hidden Implementation Fosters Representation Independence  Encapsulation: Reduces Allowable Actions via the Public Interface  Hiding: Masks Sensitive Details in Implementation  Inheritance: Controlled Sharing Among OTs Transfers Privileges from Ancestor(s) to Descendant(s)  All Three Embody Security Concepts!

75. CSE333 URBSOO-75 What's in an OO Application? What's in an OO Application?  Application Characteristics:  High Volumes of Persistent Data  Varied/Disparate Data  Multiple Individuals/Unique Needs  Distributed: Agencies/Individuals/Systems  Public Interface of OT Provides:  Methods, Parameters, Return Type  One Interface for All Users  Can't Control/Limit Access to Public Methods  Need: Selective/Customizable Control of Public Interface Based on an Individual's Role

76. CSE333 URBSOO-76 What's in an OO Application? What's in an OO Application?  OT/Class Libraries Contain:  Hundreds (or More) OTs  Instances/OT Range from Very Few (10s or Less) to Very Many (1000s or More)  Instances Can Change Types  Instances/OT Can Change Radically Over Time  Conflicts with MAC:  Relational Data, Few OTs (10s), Many Instances (1000s)  Control at Instance and Attribute Value Levels

77. CSE333 URBSOO-77 Polymorphism, Dispatching, Overloading All Three Embody Security Concepts!  Polymorphism:  Type-Independent Software Promotes Reuse  Realized via Generics or Parameterized Types  Can Polymorphism be Used in a Role Independent Security Library for Authentication and Enforcement?  Dispatching:  Run-Time Method Invocation Based on Type  Strong Ties to Inheritance, Reuse, and Extensibility  Can Dispatching Support Execution of Security Code by Invoking Different Methods Based on User Roles?  Overloading:  Methods with Same Name and Different Signatures  Ada, C++, SML, etc., Support User-Defined Overloading  Overloading Supports Polymorphism and Dispatching

78. CSE333 URBSOO-78 Object-Oriented Paradigm Claims Object-Oriented Paradigm Claims  Accepted Claims:  Stresses Modularity  Promotes Software Reuse  Facilitates Software Evolution  Difficult-to-Prove Claims:  Controls Data Consistency  Increases Productivity  For OO Security, Reuse and Evolution are Critical!  Both Strongly Linked to Definition and Maintenance of OT/Class Libraries

79. CSE333 URBSOO-79 Security Issues and Approaches  Security Defn./Enforcement Consistent with OO Precepts and Principles  Support for Wide-Variety of User-Roles  User Roles - Extensibility/Evolution Critical  Target Emerging Systems:  Focused on OO Systems Supporting C++/Java  Programming, SW Engineering, Databases, Security  URBS within Joint Object-Oriented Framework  Framework Facilitates Development of Application Code Against Persistent Class Library (and its Underlying DB)  Role-Based Enforcement Mechanism is Part of Executable Image After Compilation  During Runtime, Role of Logged In Individual Utilized to Enforce Security

80. CSE333 URBSOO-80 Related Work -- All Examine Generated Code to Realize Security  Aspects/Richardson and Schwarz - Emerging  Aspects Extend OO Data Models with Roles  New Operations/Data Possible for New Roles  Our Work has Classes as Superset of Operations and Data that are Available to Roles  Object-Level Control/Richardson, et al.  Capabilities and ACLs Let Owners of Objects Control Who can Invoke Methods on Instances  Instance Level without Obvious Means to Include User Roles  Subject-Oriented Programming/Harrison & Ossher  Classes can have Different Subjective Views  Very Similar to Our Work

81. CSE333 URBSOO-81 Core Level URBS Approaches  General Solution Issues  Present Set of Goals for Security:  Extensibility and Flexibility  Hiding & Encapsulation  Reusability  Goals Relevant for both Application and URBS Enforcement Mechanism  Approaches Include:  Brute-Force  User-Role Subclass - Application Perspective  URDH Class Library - User Roles Perspective

82. CSE333 URBSOO-82 General Solution Issues  OO Security Designed/Implemented via Libraries Geared to Reuse, Extension, and Evolution  Applications Customize Libraries:  Generic Libraries Acquire Domain Specifics  Libraries Provide Security Definition/Authentication  Dynamic Policies: Enforced/Changed Based on Roles  Software Tool/Client Application Acquires Security and Behaves Differently Based on User Roles  URBS Enforcement Mechanisms (EM):  URDH and Assigned/Prohibited Methods  Brute Force: Method Level Code Changes  User-Role Subclassing: Inheritance to Deny Access  URDH CLass Library: Inheritance with Both URDH and Application  Utilize C++ (Java Versions Later)

83. CSE333 URBSOO-83 Goals for URBS Enforcement Mechanism Goals for URBS Enforcement Mechanism  Extensibility: Application Perspective:  New Classes, Methods, Roles, etc.  Automatic Adjustment by URBS EM?  Extensibility: URBS EM Perspective:  New Security Policies/Approaches  Can you go from MAC to DAC?  Flexibility: Application Perspective:  Changes to Roles, Methods, Classes, etc.  How does URBS EM Adapt?  Flexibility: URBS EM Perspective:  Change to Security Restrictions/Policy  Reimplementation of URBS EM?

84. CSE333 URBSOO-84 Goals for URBS Enforcement Mechanism Goals for URBS Enforcement Mechanism  Hiding & Encapsulation: Application Perspective:  Invisible to Users and Components  Minimize Impact on Actual Software  Hiding & Encapsulation: URBS EM Perspective:  Representation Independence a Must  Exploit OO Paradigm/Principles  Reusability: Application Perspective:  Reuse of Classes, Methods, Roles  Does URBS EM Always Need Regeneration?  Reusability: URBS EM Perspective:  Is URBS EM Application Specific?  Is there a Generic URBS EM?

85. CSE333 URBSOO-85 Goals for URBS Enforcement Mechanism Goals for URBS Enforcement Mechanism  Software Engineering Related  Software Itself  How Pervasive are the Security Additions?  Easy to Change/Modify as Privileges Change?  Adheres to Existing OOPL Capabilities  Software Engineer  How Much Does the Software Engineer Need to Know about Security?  What can be Hidden from Software Engineering?  Can we Prevent Software Engineer from Getting at Restricted Software?  For Example, Putting in Trap Door

86. CSE333 URBSOO-86 Quantifying URBS Approaches  Brute-Force (BFA)  Focus on Code Level Changes  Include “Conditionals” for Each UR Allowed to Access a Method in Each Methods Code  User-Role Subclass (URSA)  Specify “Subclasses” for Each User Role that Correspond to Each Application Class/OT  Override Prohibited Methods to Return Nulls  URDH Class Library (UCLA)  Employ a Separate Class Library that Mirrors the URDH and Contains Privileges  Requires Casting to Insure Correct Behavior

87. CSE333 URBSOO-87 Brute Force Approach  Consider HCA Prescription Class:  UR: Staff_RN Assigned Following Methods class Prescription { Public: Set_Prescription_No(....); Get_Prescription_No(....); Set_Pharmacist_Name(....); Get_Pharmacist_Name(....); Set_Medication(....); Get_Medication(....); Protected: char* patient_name, address,..... } Get_Prescription_No(....); Get_Pharmacist_Name(....); Get_Medication(....);

88. CSE333 URBSOO-88 Brute Force Approach  Method Implementation:  Comments on BFA:  Code for IFs Easily Generated  Any Changes Have Significant Impact  Encapsulation is Poor - Spread Across OTs  No Identifiable Enforcement Mechanism char* Prescription::Get_Prescription_No (....) { /* Check if a valid user is accessing the method */ if (User.User_Role == Staff_RN) || (User.User_Role == Physician) || (etc.) { //.... method code for the access..... } else return (NULL);

89. CSE333 URBSOO-89 User-Role Subclassing Approach  Consider HCA Prescription Class  Associated Privileges: class Prescription { public: virtual Get_Prescription_No(....); virtual Set_Prescription_No(....); virtual Get_Pharmacist_Name(....); virtual Set_Pharmacist_Name(....); virtual Get_Medication(....); virtual Set_Medication(....); private: char* prescription_no, pharmacist_name,... } UR: Attending_MD PM: Set_Pharmacist_Name AMs: All of the Rest UR: Staff_RN AMs: Get_Pharmacist_Name Get_Prescription_No Get_Medication PMs: Set_Prescription_No Set_Pharmacist_Name Set_Medication

90. CSE333 URBSOO-90 User-Role Subclassing Approach  Generate User-Role Subclasses: class Staff_RN_Prescription: public Prescription{ public: virtual void Set_Prescription_No(...) {return;}; virtual void Set_Pharmacist_Name(...) {return;}; virtual void Set_Medication(...) {return;}; }; class Attending_MD_Prescription: public Prescription{ public: virtual void Set_Pharmacist_Name(...) {return;}; };

91. CSE333 URBSOO-91 User-Role Subclassing Approach  Behavior at Runtime: Consider the Call  Type of ptr Determines Which Method is called:  If Staff_RN User Role, the Method  is Called Which Returns Nothing (Overridden) ptr->Set_Prescription_No(); virtual void Set_Prescription_No(...) {return;};

92. CSE333 URBSOO-92 User-Role Subclassing Approach main() { char user_name[20], user_role[20]; Prescription* P; Staff_RN_Prescription* SP; int Number; char* Medication; cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Simulates a URDH and Authorization List Current_User=new User(user_name, user_role); P = new Prescription("Jessica", "3-9-95", 100, "Kitty", "Cold");

93. CSE333 URBSOO-93 User-Role Subclassing Approach // This is a portion of application code if (strcmp(user_role, "Staff_RN")==0) { // Create a Instance to Hold “Staff_RM” SP = new Staff_RN_Prescription("", "", 0, "", ""); // Copy from the Parent Prescription Object SP->copy_object(P); //copy attributes from parent // Attempt to Invoke a Method as Staff_RN SP->Set_Prescription_No(200); // Set No to 200 //Get the Result of Invocation Number=SP->Get_Prescription_No(); // Staff_RN Doesn’t have Privileges - output 100 cout << "Number==" << Number << "\n"; P->copy_object(SP); //copy attributes from child delete SP; }

94. CSE333 URBSOO-94 User-Role Subclassing Approach Application Code Still UR Specific  Comments on URSA:  Extensible via New User-Role Subclasses  Hindered by Switch/Recompilation  Encapsulation of Security at Method Level  Enforcement Mechanism Still Vague void Fill_Patient_Prescription(..., Prescription* p_rec) { // Determine the role of the user currently switch (User.User_Role()) { case Staff_RN: ((Staff_RN_Prescription *) p_rec)->Set_Prescription_No(...); break; case Attending_MD: ((Attending_MD_Prescription *) p_rec)->Set_Prescription_No(...); break; }

95. CSE333 URBSOO-95 URDH Class Library Approach  Objectives  Utilize Structure of URDH to Record Privileges  Track all of Methods Assigned to User Roles, User Types, and User Classes  Result  Class Hierarchy Corresponding to URDH  Contains all Permissions  Turn Off Permissions at Root Node  Turn On Permissions to Correspond to Assigned Methods  Invocation only if Method “Turned On”

96. CSE333 URBSOO-96 URDH Class Library Approach Partial Class Hierarchy for URDH Root UsersUC:Medical Staff UT:Nurse UR:Staff RNUR:ManagerUR:Education Turn Off All “Check” Methods at Root Node Turn On Check Methods To Correspond to Assigned Methods Call “Check” Method Prior to Invoking Actual Method

97. CSE333 URBSOO-97 URDH Class Library Approach URDH Classes  Consider Following URDH Subset:  and its Corresponding Class Library: UR: Staff_RN Assigned methods: Get_Prescription_No() (to Staff_RN) Get_Pharmacist_Name() (to Staff_RN) Get_Medication() (to Nurse) class Root: all methods return False; class Users: public Root class Medical_Staff: public Root class Nurse: public Users, public Medical_Staff { int Check_Prescription_Get_Medication(){return True;} }; class Staff_RN: public Nurse { int Check_Prescription_Get_Prescription_No(){return True;} int Check_Prescription_Get_Pharmacist_Name(){return True;} };

98. CSE333 URBSOO-98 URDH Class Library Approach Impact on Application Classes  Introduce “Object” Class to Track Current User and Tie into URDH Class Hierarchy  Note User Part of Prescription Constructor class Object { protected: Root* current_user;... } class Item: public Object{... } class Prescription: public Item { public : Prescription(Root* u, char* Name,...); int Get_Prescription_No();... };

99. CSE333 URBSOO-99 URDH Class Library Approach Impact on Application Classes  Focus on Actual Method Implementations  Wrap Check Method Call Around Method Body  Note Other Gets and Sets are Similar int Prescription::Get_Prescription_No() { if(current_user-> Check_Prescription_Get_Prescription_No()) return(Prescription_No); else return(NULL); } void Prescription::Set_Prescription_No(int No) { if(current_user-> Check_Prescription_Set_Prescription_No()) {Prescription_No=No;} }

100. CSE333 URBSOO-100 URDH Class Library Approach main() { Prescription* P; char user_name[64]; char user_role[64]; int Number; Root* current_user; cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Create and Simulate a New User if (strcmp(user_role, "Staff_RN") == 0) { current_user = new Staff_RN(user_name); } else current_user = new Root(user_name);

101. CSE333 URBSOO-101  Key Issues:  Create User to Coincide with Entry in URDH Class Hierarchy and Set Current User  Change Each Method Code to Invoke Check Method Prior to Actual Invocation (Body) URDH Class Library Approach P = new Prescription(current_user,"Jim", "3-9-95", 1, "Ron", "Flu"); // FOLLOWING Set HAS NO EFFECT IF A STAFF_RN // IS ATTEMPTING TO MAKE THE CHANGE P->Set_Prescription_No(100); Number=P->Get_Prescription_No(); cout << "Number==" << Number << "\n"; }

102. CSE333 URBSOO-102 Comments on URDH Class Library Approach  Since Changes aren't Allowed by Unauthorized Individuals the Need to Undo is Eliminated  Extensibility: As new URs are Changed/Added, Only URDH Class Library Must be Recompiled  Hides Security Code Once a User has been Identified  Better Job at Encapsulation of Enforcement Mechanism  Still Difficult to Quantify Entire Mechanism as a Single Unit  Steamlines Application Code  Reusability is Definitely Utilized/Superior

103. CSE333 URBSOO-103 Compare/Contrast the Three Approaches  Application Perspective  URBS Enforcement Mechanism Perspective

104. CSE333 URBSOO-104 Advanced URBS Approaches  Generic Security Classes  Streamline Security Defn. Process  Achieve Uniformity/Promote Reuse  Independent Design/Implementation/Validation  Exception Handling  Hide Security Code with Handlers  Raise Violations when UR Attempts Unauthorized Access  Review Four Approaches  Generic URSA (GURSA)  Basic Exception Approach (BEA)  Generic Exception Approach (GEA)  Advanced Exception Handling

105. CSE333 URBSOO-105 Generic URSA (GURSA)  Incorporates Generics into URSA  Introduce Generic_Prescription Template  Parameterized by URType  current_UR Pointer Determines Method Called Based on UR  Concepts  Each UR Has Own Copy of Prescription Class  Cast Based on Role  Review both Template and Main  Highlight Disadvantages

106. CSE333 URBSOO-106 The Item.h File #ifndef Item_h #define Item_h class Item { protected: char Physician_Name[64]; char Date[10]; public : Item(char* Name,char* D); char* Get_Physician_Name(); void Set_Physician_Name(char*); char* Get_Date(); void Set_Date(char*); }; #endif

107. CSE333 URBSOO-107 The Prescription.h File #ifndef Prescription_h #define Prescription_h #include "item.h" class Prescription: public Item { protected: int Prescription_No; char Pharmacist_Name[64]; char Medication[128]; public : Prescription(char* Name,char* D,int No, char* Name1,char* Med); virtual void copy_object(Prescription* P); virtual int Get_Prescription_No(); virtual void Set_Prescription_No(int); virtual char* Get_Pharmacist_Name(); virtual void Set_Pharmacist_Name(char*); virtual char* Get_Medication(); virtual void Set_Medication(char*); }; #endif

108. CSE333 URBSOO-108 The Staff RN Prescription.h File (s_pres.h) #ifndef Staff_RN_Prescription_h #define Staff_RN_Prescription_h #include "pres.h" class Staff_RN_Prescription: public Prescription { public : Staff_RN_Prescription(char* Name,char* D, int No,char* Name1,char* Med): Prescription(Name,D,No,Name1,Med){;} // int Get_Prescription_No(); void Set_Prescription_No(int); // char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); // char* Get_Medication(); void Set_Medication(char*); }; #endif

109. CSE333 URBSOO-109 The Attending MD.h File (a_pres.h) #ifndef Attending_MD_Prescription_h #define Attending_MD_Prescription_h #include "pres.h" class Attending_MD_Prescription: public Prescription { public : Attending_MD_Prescription(char* Name,char* D, int No,char* Name1,char* Med): Prescription(Name,D,No,Name1,Med){;} void Set_Pharmacist_Name(char*); }; #endif

110. CSE333 URBSOO-110 Generic_Prescription Template #include "s_pres.h" //Staff_RN_Prescription Class #include "a_pres.h" //Attending_MD_Prescription Class template class Generic_Prescription { private: URType *current_UR; public : Generic_Prescription() {current_UR = new URType("", "", 0, "", "");} int Get_Prescription_No() {return(current_UR->Get_Prescription_No());} void Set_Prescription_No(int No) {current_UR->Set_Prescription_No(No);} char* Get_Pharmacist_Name() {... etc...} void Set_Pharmacist_Name(char* Name) {... etc...} char* Get_Medication() {... etc...} void Set_Medication(char* Med) {... etc...} void copy_object(Prescription *P) {... etc...} };

111. CSE333 URBSOO-111 The Main Program - GURSA main() {Prescription* P; char user_name[64], char user_role[64], *Medication, *Name; int Number; cout > user_name; cout > user_role; P=new Prescription("Jessica","3-9-95”,1,"Kitty","Cold"); if (strcmp(user_role, "Staff_RN")==0) {Generic_Prescription *SP = new Generic_Prescription (); SP->copy_object(P); //copy Attributes from the parent SP->Set_Prescription_No(200); // Fails Number=SP->Get_Prescription_No(); // Succeeds cout << "Number==" << Number << "\n"; }

112. CSE333 URBSOO-112 The Main Program - GURSA else if (strcmp(user_role, "Attending_MD")==0) { Generic_Prescription *AP =new Generic_Prescription (); AP->copy_object(P); //copy attributes from the parent AP->Set_Prescription_No(200); // Succeeds AP->Set_Pharmacist_Name("Steve"); // Fails Number=AP->Get_Prescription_No(); // Succeeds Name = AP->Get_Pharmacist_Name(); // Succeeds cout << "Number==" << Number << "\n"; cout << "Name== " << Name << "\n"; } } // end of main

113. CSE333 URBSOO-113 Comments on GURSA  Current UR Encapsulated  Conditional Statement Hinders Code  Extensibility Severely Limited  IDevE Must Understand URBS  Can Presence of Conditional be Minimize?

114. CSE333 URBSOO-114 Minimizing Conditional What are Problems Here? if (strcmp(user_role, "Staff_RN")==0) Generic_Prescription *PP =new Generic_Prescription (); else if (strcmp(user_role, "Attending_MD")==0) Generic_Prescription *PP =new Generic_Prescription (); // Would allow one block of user-role independent code. PP->copy_object(P); //copy attributes from the parent //Success/Failure of Next Four Callas Based on UR PP->Set_Prescription_No(200); PP->Set_Pharmacist_Name("Steve"); Number=PP->Get_Prescription_No(); Name = PP->Get_Pharmacist_Name(); cout << "Number==" << Number << "\n"; cout << "Name== " << Name << "\n";

115. CSE333 URBSOO-115 Basic Exception Approach (BEA)  C++ Supports Excepting Handling  try Encapsulates a Block of Code that has Potential to Raise Exception  throw Used to Raise Exception  catch Process Exception  Recast Exception Handling to Support the Raising Catching, and Processing of Security Violations  BEA as Follows:  Extend Class with Exception Handling Methods  Capture Assigned/Prohibited Methods in Runtime Data Structure  Allows UR to be Validated via URDH

116. CSE333 URBSOO-116 Modifications to Prescription Class class Prescription: public Item { // Private data has been omitted public: Prescription(char* Name,char* D, int No,char* Name1,char* Med); int Get_Prescription_No(); void Set_Prescription_No(int); char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); char* Get_Medication(); void Set_Medication(char*); // New Methods for Exception Handling int rtn_int_check_valid_UR(int); char* rtn_str_check_valid_UR(char*); void set_int_check_valid_UR(int*,int); void set_str_check_valid_UR(char*,char*); void Check_UR(); // Can UR access method. class Unauthorized_UR { }; };

117. CSE333 URBSOO-117 Prescription Implementation Pseudo-Code to Illustrate Concepts int Prescription::Get_Prescription_No() { return(rtn_int_check_valid_UR(Prescription_No));} int Prescription::rtn_int_check_valid_UR(int AInt) { try {// try block has potential to raise exception this->Check_UR(); } // catch block processes any raised exceptions catch (Prescription::Unauthorized_UR) { cout << ”Access by unauthorized UR" << endl; return(INT_NULL); } return(AInt); } void Prescription::Check_UR() {// Shows invalid URs for Get_Prescription_No method. if ((Current_User->Get_User_Role() != Staff_RN) || (Current_User->Get_User_Role() != Attending_MD)) throw Unauthorized_UR(); // raises exception }

118. CSE333 URBSOO-118 main() Program for BEA main() { Prescription* P; char* Name, Date, Medication, name, role; int Number; char user_name[64], user_role[64]; cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; Current_User = new User(user_name, user_role); name = Current_User->Get_User_Name() ; role = Current_User->Get_User_Role() ;

119. CSE333 URBSOO-119 main() Program for BEA // Data is set as: // MDName, Date, Presc#, PharName, Medication P = new Prescription("Lois", "2-13-96", 1, "John", "Aspirin"); Name = P->Get_Physician_Name(); cout << "Name==" << Name << "\n"; Date = P->Get_Date(); cout << "Date==" << Date << "\n"; // Will fail for UR except Staff_RN or Attending_MD Number = P->Get_Prescription_No(); cout << "Pre_No==" << Number << "\n"; //If fails-Null // Will fail for Staff_RN P->Set_Pharmacist_Name("MeiYu"); // Unchanged if Staff_RN Name = P->Get_Pharmacist_Name(); cout << "Name==" << Name << "\n"; } // end of main

120. CSE333 URBSOO-120 Comments on BEA  Advantages Include:  Methods rtn, set, Check_UR Encapsulates URBS  Once UR is Set - Conditionals not Needed (GURSA)  Drawbacks Include:  Exception Handling Code Pervasive  Extensibility Problem When Changes to Prescription  Replicated Code in set and rtn  Reuse not Attained

121. CSE333 URBSOO-121 Generic Exception Approach (GEA)  Extends BEA with Generics  Alleviates BEA's Disadvantages  Template Class Centralizes Security Violation Code  Once Defined, Template Class can be Reused as Needed  Core Ideas Include:  rtn, set, prt Methods for Basic Types  Ability to Uniquely Identify Classes and Methods  Parameterized by Type of Application Class

122. CSE333 URBSOO-122 Generic Security Template template class Gen_Security { protected: int C_ID; // Class ID int M_ID; // Method ID public: Gen_Security() {C_ID = M_ID = 0;} void GS_Check_UR(); class Unauthorized_UR { }; // Exception int rtn_int_check_valid_UR(int); float rtn_flt_check_valid_UR(float); char* rtn_str_check_valid_UR(char*); char rtn_chr_check_valid_UR(char); void set_int_check_valid_UR(int*,int); void set_flt_check_valid_UR(float*,float); void set_str_check_valid_UR(char*,char*); void set_chr_check_valid_UR(char,char); void prt_int_check_valid_UR(int); void prt_flt_check_valid_UR(float); void prt_str_check_valid_UR(char*); void prt_chr_check_valid_UR(char); };

123. CSE333 URBSOO-123 Generic Security Implementation template void Gen_Security ::GS_Check_UR() { // Call Check of Owner Class if (Type::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR(); } template void Gen_Security ::prt_str_check_valid_UR(char* AString) { try {// try block has potential to raise exception this->GS_Check_UR(); } // catch block processes raised exception catch (Gen_Security::Unauthorized_UR) { cout << "Attempt to access by unauthorized UR" << endl; return; // return control without printing } cout << AString << endl;//output if no exception raised } // WHEN APPLIED TO PRESCRIPTION CLASS GS_CHECK_UR BECOMES: if (Prescription::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR(); // THIS VERIFIES IF UR CAN ACCESS METHOD C_ID+M_ID

124. CSE333 URBSOO-124 The Item Header Class #include "gen_security.C" class Item { // Private data has been omitted public : Item(char* Name,char* D); char* Get_Physician_Name(); void Set_Physician_Name(char*); void Print_Physician_Name(); char* Get_Date(); void Set_Date(char*); void Print_Date(); // Class specific URBS static int Check_UR(int); // Assigned methods static int Assigned_Methods(int); // Template Declaration Gen_Security Item_Sec; };

125. CSE333 URBSOO-125 The Prescription Header Class class Prescription: public Item {//Private data omitted public: Prescription(char* Name,char* D, int No,char* Name1,char* Med); int Get_Prescription_No(); void Set_Prescription_No(int); void Print_Prescription_No(); char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); void Print_Pharmacist_Name(); char* Get_Medication(); void Set_Medication(char*); void Print_Medication(); // Class specific URBS static int Check_UR(int); //Assigned methods static int Assigned_Methods(int); //Template declaration Gen_Security Pres_Sec; };

126. CSE333 URBSOO-126 Prescription Implementation void Prescription::Print_Pharmacist_Name() { Pres_Sec.prt_str_check_valid_UR(Pharmacist_Name); } int Item::Check_UR(int unique_method_id) { return(Item::Assigned_Methods(unique_method_id)); } int Prescription::Assigned_Methods(int meth_id) { // For now - simulate by hard-coding response. if ((strcmp(Current_User->Get_User_Role(), "Staff_RN")==0) ||(strcmp(Current_User->Get_User_Role(), "Attending_MD")==0)) return SUCC; else return FAIL; }

127. CSE333 URBSOO-127 Comments on GEA  Enhances BEA Advantages via Template  Software Reuse is Strongly promoted  Changes to Prescription/ Item Methods Don't Alter Method Signatures  URBS Enforcement is Therefore Hidden

128. CSE333 URBSOO-128 Advanced Exception Handling  Expand BEA and GEA with Advanced Capabilities  Focus on Added Code to Process Security Violations  Recast Generic Security Template Class with Multiple Exceptions  Explore Hypothetical Examples

129. CSE333 URBSOO-129 Revised Generic Security Template template class Gen_Security { protected: int C_ID; // Object ID int M_ID; // Method ID public: Gen_Security() {C_ID = M_ID = 0;} void GS_Check_UR(); class Unauthorized_UR { public: int meth_id; Unauthorized_UR(int m_id) { meth_id = m_id; // Remaining code to process exception cout " << meth_id << endl; cout << "by Unauthorized User Role!!!!" << endl; } }; // End Unauthorized_UR exception Class

130. CSE333 URBSOO-130 Revised Generic Security Template class Logauthorized_UR { public: int meth_id; FILE *f_id; Logauthorized_UR(int m_id) { meth_id = m_id; // Remaining code to process exception // Print message to FILE f_id that logs all // accesses to methods by authorized URs. } }; // End Logauthorized_UR exception Class // rtn, set, prt methods as given without changes };

131. CSE333 URBSOO-131 Revised Generic Security Template template void Gen_Security ::GS_Check_UR() { // Call Check of Owner Class if (Type::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR(C_ID+M_ID); else throw Logauthorized_UR(C_ID+M_ID); } // Two catches needed in relevant Gen_Security methods catch (Gen_Security::Unauthorized_UR) { cout << "Attempt to access by unauthorized UR" << endl; return; // return control without printing } catch (Gen_Security::Logauthorized_UR) { cout << "Logging of authorized access by UR" << endl; }

132. CSE333 URBSOO-132 Compare/Contrast the Four Exception Handling Based Approaches  How do the Four Approaches Compare?  Extensibility  Flexibility  Hiding/Encapsulation  Reusability  Is One Easier than Another?  How do they Rate vs. Earlier Three Approaches?  What’s Missing in the Process?

133. CSE333 URBSOO-133 Software Architectures for Consistency and Assurance of URBS Policies  Motivation  “How will Assurance and Consistency be Attained during the Definition and Usage of an application's User-Role Based Security Policy, particularly in an Object-Oriented context that stresses Change and Evolution?”  What is Consistency?  The Ability to Capture and Maintain Inter-Role and Inter-User Privileges as Changes are Made to the Security Policy over Time  What is Assurance?  The Ability to Guarantee that the Privileges of each User and Role are Adequate to Satisfy their Respective Functions over Time

134. CSE333 URBSOO-134 Context and Objectives  Programming Language Role - C++, Ada95, Java  Security Across Internet/Intranet  Impact of Application Domain  Health-Care: Life-Critical  CAD: Cooperation/Productivity  Promote Security as an Up-Front, Integral Player in Design and Development  Security Not Just a Database Requirement  Cohesive/Comprehensive Sec. Policy  Emphasize User Capabilities  Equal Partner in Process

135. CSE333 URBSOO-135 Background and Objectives  Consistent with OO Precepts and Principles  User-Role Based Security: Responsibility Focus  Integrate Programming, Software Engineering, Databases, and Security  Provide a Framework that Facilitates Development of Application Code Against Persistent Class Library (and its Underlying DBS)  During Runtime, Role of Logged In Individual Utilized to Enforce Security  Goal: Minimize Amount of Knowledge of Security by Software Engineer

136. CSE333 URBSOO-136Focus  Expand Research in Two Dimensions  Consistency and Assurance  Consistency of Security Policy in a Changing Environment  Assurance of Operation, Security, and Results  Instantaneous Availability of ``Correct'' Health Care Data in Life-Critical Situations  Software Architectures  URBS at System-Component Level  Class Libraries as Building Blocks  Alternative Integration Strategies  Single and Multi- Process and Processor Solutions

137. CSE333 URBSOO-137Overview  Assurance, Consistency, and Analyses  Software Architectures and URBS Mechanisms  Concepts and Definitions  Layered Systems  Communicating Processes - Client/Server  Comparison and Critique  Concluding Remarks on SW Architectures

138. CSE333 URBSOO-138 Assurance, Consistency, and Analyses  Who has Responsibility for URBS Policies?  What Tools and Techniques are Needed?  Design Techniques for:  Software & Security Engineers  Precisely/Accurately Define Applications  Non-Security and URBS Requirements  Suite of Tools for:  Design  Automatic Analyses of Impact When Changes Occur to Application or Its Security Policy  On-Demand Analyses to Assess State of Design  Generation of URBS Enforcement Mechanisms

139. CSE333 URBSOO-139 Consistency for User-Roles URs for OO Systems are Dynamic  Extension/Evolution of OO Systems is Norm  Consistency of User Roles  New UR: Internal Consistency  Modify UR: Intra-Role Consistency  Between URs: Inter-Role Consistency  Among URs: Intra-Hierarchy Consistency  Adhere to Two Principles  Least-Privilege: Necessary Privileges and No More for a UR  Mutual-Exclusion: Careful Definition of Can vs. Can't w.r.t. Privileges for URs  Analyses to Assess Attainment of Consistency and Principles

140. CSE333 URBSOO-140 Consistency for End User Authorizations URs for OO Systems are Dynamic  Trade off of End-users Behavior  Play Exactly One Role at Some Time  Play Multiple Roles Concurrently at Some Time  End-User Consistency  Relation of User to other Users Based on UR This is Inter-User Consistency by Role  If User Can Play Multiple Roles Must Consider Dependencies Among Simultaneous Roles This is Intra-User Consistency by Role  Analyses to Assess Attainment of Consistency and Principles

141. CSE333 URBSOO-141 Concepts and Definitions  OO Assumptions: Shared Class Library  Tools Designed Against Class Library  End-Users Access Application via Tools  Security Policy Enforced via Tools  Different Class Libraries  AppCL: Shared Application Class Lib.  SCL: Security Class Lib. with URBS Defn. and Enforcement  TCL: Tool Class Lib., e.g., a patient GUI  Software Architectures  Explore Variants for OO and URBS  Layered Systems  Communicating Processes

142. CSE333 URBSOO-142 Layered System Version 1 LS1: Application-Based Approach  Security at Level of Method Invocation  Processed by SCL Prior to Access Against Instance in ACL  Security Managed at Application Level  All Requests Pass Through Shared SCL  Once SCL OKs, Passed Through to ACL

143. CSE333 URBSOO-143 Layered System Version 2 LS2: Class-Based Approach  Like LS1, Security at Level of Method Invocation  Processed by SCL Prior to Access Against Instance in ACL  Security Managed at Instance Level  Tools Must Interact with Multiple SC/AppC Pairs  Sec. Policy and Application Distributed  Problem if Instances Refer to Non-Local Instances

144. CSE333 URBSOO-144 Communicating Processes Version 1 CP1: Single Process, Base Case, no C/S  Similar to LS1 - Each Tool Standalone Process  SCL and AppCL Analogous to Math Library  SCL Filter between TCLi and AppCL  SCL/AppCL Partially Replicated/Distributed  Changes to SCL/AppCL Impact Multiple Tools  Unclear How Sharing/DB Supported

145. CSE333 URBSOO-145 Communicating Processes Version 2 CP2: Multi-Process/Shared AppCL  AppCL Separated into Own Process  SCL Still only Subset Needed by TCLi  Like CP1, SCL Changes Impact Multiple TCLs  Less Impact for Changes to AppCL  Unlike CP1, Database Integration Supported

146. CSE333 URBSOO-146 Communicating Processes Version 3 CP3: Multi Process/Shared SCL/AppCL  SCL has Entire Security Policy  Changes to SCL/AppCL Shouldn't Impact TCLs  SCL/AppCL Potential Performance Bottleneck  Particularly with Database Integration

147. CSE333 URBSOO-147 Communicating Processes Version 4 CP4: C/S, Replctd SCL/Shared AppCL  Independence of TCLs (CP2)  Alleviate Performance Problems of CP3  Replicated/Entire SCL  Facilitates Database System Incorporation

148. CSE333 URBSOO-148 Comparison of Variants

149. CSE333 URBSOO-149 Critique of Variants Summary/Assessment of 6 Variants  Consistency/Assurance of Security Policy  Impact when Security Policy Evolves  Support for Persistency

150. CSE333 URBSOO-150 Concluding Remarks on SW Architectures  Consistency and Assurance for OO Systems Must Be an Equal Partner in Design Process  Consider Evolution of Application and Its Security Policy  Explore Solutions that Transcend Traditional Approaches  Software Architectures Offer  Componentwise Conceptualization and Realization  Variants LS1, CP3, and CP4 which are Comparable in Pros and Cons  CP4 which More Easily Supports Evolution to Include OODBS