Security and Privacy in Cyberspace Reind van de

Security and Privacy in Cyberspace Reind van de Riet Dept of Computer Science Vrije Universiteit in Amsterdam with: Radu Serban (VU), Hans Burg, Martin Olivier (S-Africa) Ehud Gudes (Israel), Andrea Junk, Wouter Janssen (Deloitte&Touche) Wouter Teepe (Un. of Groningen)

Contents • • Introduction 1. Cyberspace inhabited by Alter Egos 2. S&P and Work Flow 3. Architectural issues: S&P in Mokum versus S&P in ERP

Introduction • Treatment on high application level • For technicalities on Crypto-techniques: with symmetric and asymmetric keys see standard books: Denning&Denning: Internet besieged

Garfinkel&Spafford: Web Security & Commerce

Or Conference Proceedings • WG 11. 3 S&P in Database Applications in …. , Schoorl, . . .

I Cyberspace inhabited by Alter Egos • Cyberspace = Space filled with objects • some passive (structured information); • some active (agents), with information and able to communicate; • Alter-egos belong to human beings (individuals) and represent them in Cyberspace; give and protect (private) information about the individual and get information (from other objects) • Alter-ego = (information reachable by SSN) + email-address/URL of individual

The Mokum Approach • Simulation in the form of Mokum program • Objects have – type: attributes: private, public; states; – script: triggers for receiving and sending messages like FSAs or STDs • inheritance of properties (hierarchy) • Security is based on two principles: – epistemological (compile-time) principle – ontological (run-time) principle

Epistemological = Structural based on is-a inheritance and keeper-of relations ‘salary’ can be seen by employee and by account-manager; not by person, student, customer ‘account’ can be seen by customer and by account-manager, because of “coll_of customer”

Ontological principle • Each account manager has his own collection of customers and can only access the accounts of these customers • An employee can access his own salary; not the salary of his father, although the epistemological rule allows: “salary of father of me”

Simulation in Mokum

An Advanced Application • Another bank brach is introduced • Individual has accounts in both branches • likes to transfer money from one account in the other • needs additional authentication of user • one site has had security problems: needs logging • transfer needs extra authorization from senior bank employee

Script for Advanced Application

Implementation in the Large • How to distribute the Mokum system? • System is supposed to consist of three layers: – Physical site layer – Logical object layer – Application Layer • Problems: – objects may consist of sub-objects in different sites – values of attributes may be at different sites

Proposal • Add to each type a keeper object type, responsible for checking messages sent and received; knowledge for this keeper is derived from: – application source – site source – policy source • Use CORBA for interfacing the Mokum systems

Conclusion on I: Cyberspace inhabited by Alter-egos • An architecture of the world of Alter-egos in Cyberspace has been set up; • Security & Privacy questions can be studied; • Simulations can be carried out in the Mokum system.

II S&P and Work Flow • Modelling Alter-egos in Cyberspace using a Work Flow Management Tool: who takes care of S&P? (Web. Net 97) • Example: Work. Flow specification for dealing with thousands of claims in an Insurance Company • Derive access rules from WF spec • Investigate illegal access to private information

A verbal specification:

Data structures involved • • Submitter SU Approver AP Expert EX Cashier CA Travel Agent TA Claim CL Trip TR; incident IN; amount AM

Work Flow Specification as a Color-X diagram • Color-X developed by Hans Burg and is based on: – CPL (Frank Dignum) based on FG (Simon Dik) (Hans Weigand) – linguistic tools: Word. Net (++) – FSA’s for more than one objects • Modalities: – NEC: a specification for the system – MUST: a specification for an external entity

Deriving Security rules from the WFD • There are databases: – IC-claim. DB for the claim information – TA-trip. DB for the trip information – obl. DB for the obligations • Authorization database with authorization tuples; e. g. – AUTH<IC-claim. DB, approver, create, allowed>

• AUTH<IC_claim. DB, approver, create, allowed>

AUTH<obl. DB, approver, shift, allowed> AUTH<obl. DB, travel-agent, shift, not allowed>

AUTH<claim. DB, cashier, read: amount, allowed>

Advantages • • Access automatically computed (no errors) Access only when necessary (need to know) Access just in time Checking privacy rules is possible (paper in WG 11. 3 Schoorl) – has every agent enough information? – Can agents conspire to get more information than allowed by privacy rules?

Checking Workflow on maintenance of Privacy Rules • Can someone/agent get information about an individual to which he is not authorized? • Assuming that the Workflow defines correctly what the agents may/must know. • But they can conspire using the sendmessage mechanism (possibly covertly) • Two examples:

1. Travel Agent TA cannot see the age of the submitter SU, but can ask Approver AP, who knows SU and SU. age.

2. Cashier CA can only see the bank of SU, but, conspiring with AP, may know SU’s name.

Conclusion on II: S&P and Work Flow • For two applications it has been shown that Workflow diagrams can be profitably used to analyse: • giving and removing access rights just on time and only when needed; • conspiration of agents/workers to get private information of an individual.

III • • Architectural issues: S&P in Mokum versus S&P in ERP Example: Hospital + Insurance Company How to implement in Mokum How to implement in an ERP system (SAP) Comparison wrt complexity of dealing with access control with privacy rules • Conclusion: the structure-based architecture in Mokum is far superior to the certificatebased architecture of ERP

The Hospital (H)-Insurance Company (IC) example • Hospital has – medical staff (doctors and nurses) and – administrative staff • Patients are persons with a medical record, only accessable by their own doctors • A nurse of a patient is not allowed to access patient’s medical record, unless patient’s doctor is absent and patient is in an emergency

H-IC example continued • Employee HA of H in the administrative department of H has access to the financial record of the patients. • IC has a claim department with employee CE and communicates with HA about the financial records, who is allowed to answer.

Test Queries • 1. Nurse wants to see medical record. • 2. CE sends message to HA asking about financial status of patient. • 3. CE wants to see a medical record of a patient and pretends to be a nurse and sends a request to the doctor of that patient.

Notation • • +: public attribute -: private attribute k_o: keeper of collection Following collections/databases to protect – financial patients – medical patients – clients (policies)

Access protection in Mokum • In the script part of a type definition, the following attribute-names are allowed: – public attributes of any type – private attributes defined in this type, including inherited attributes – private attributes of objects in the collections of which this object is the keeper

Visiblity is defined by the following Prolog rules: • vis(A, T): is_a_attr(A), is_a_type(T), not private(A). • vis(A, T: is_a_attr(A), is_a_type(T), private(A), ([1]attr(T, A, _); (attr(T, _, [3][coll, S]); [2]is_a(T, S)), vis(A, S)).

• Visibility: • ? - vis(medical_record, T). – T = doctor; – T = medical_patient; • Test Query 1, 2: “medical_record” not allowed in script of nurse; same for claim_employee • ? -vis(financial_record, T). – T = h_administrator; – T = financial_patient; • Test Query 3: “financial_record” not allowed in script of claim_employee

Ontological Principle (run-time check) • Example: Doctors can acces only their own patients therefore the following Prolog rule: [CO = Calling Object; O = Object, A= Attribute] • acc(CO, O, A): - has_attr(O, A), not private(A). • acc(CO, O, A): - has_attr(O, A), has_type(CO, T), pivate(A), vis(A), (CO=O; keeper(CO, O)).

Parts of scripts

Test Queries are OK, but for #3 • Claim employee pretends to be a nurse by performing: add_type(me, nurse) and sending the doctor of patient P a message: • D from doctor of P, send(D, nurse_asks_for_medical_record, message) • Indeed, nurses have to be put in a collection, protected by some boss and the script of doctor has to be changed!!

Certificate driven S&P systems, such as ERP • An ERP system integrates personnel information with company information: patients, medical, financial, etc. • Personnel has roles, to which tasks with access rights are attached: (RBAC=Role-Based-Access-Control) in the form of certificates. • When a person P wants to perform operation F on a piece of data D, it is checked whether he has certificates for the combination (F, D).

Stages using certificates • • 1. Definition of certificate class; 2. Creation of certificates; 3. Assigning them to roles, persons; 4. Building in of checks for certificates in Application Programs; • 5. Checking presence of certificates.

Stage 1. Definition of certificate classes; • For nurses: • class auth_obj_nurse – fctn: read – data: medical_records – key: patient_id – sel: patient_id. state = emergency and not present(patient_id. doctor)

Stage 1. Continuation • For doctors: • class auth_obj_doctor – fctn: read and write – data: medical_records – key: patient_id – sel: patient_id. doctor = <USER_ID>

Stage 1. Continuation: Creation of a specific certificate class; • Class auth_obj_doctor_ophth subclass_of_auth_obj_doctor – sel: patient_id. disease = ophthalmia

Stage 2. Creation of certificates using the certificate classes; • Make instance of auth_obj_nurse e. g. auth_obj_nurse_25 • Make instance of auth_obj_doctor_ophth e. g. auth_obj_doctor_ophth_17

Stage 3. Assigning them to roles and persons • Put auth_obj_nurse_25 in the list of certificates of the role “nurse”. • Assign this role to nurse Florence Nightingale • Put auth_obj_doctor_ophth_17 in the list of certificates of ophthalmologist Johnson

Stage 4. Building in of checks in Application Programs • In all application programs accessing databases, checks have to be inserted to be sure that the user of that program is entitled to use them on particular pieces of data. • For example: require(auth_obj_nurse_25, medical_records)or require(auth_obj_doctor_ophth _17, medical_records)

Stage 5: Checking the presence of a certificate • Nurse N wants access medical status of P(read, medical_records, P) • Application Program then executes an equivalent of: SELECT patient’s_status FROM medical_records WHERE patient_id = P AND patient_id. state = emergency AND NOT present(patient_id. doctor)

Stage 5: Continuation • Doctor D requests medical record of Patient P: (read, medical_records, P) • Application Program then executes an equivalent of: SELECT patient’s_anamnesis FROM medical_records WHERE patient_id = P AND patient_id. doctor = D AND patient_id. disease = ophthalmia

Global Access Control • Insurance Company IC with employee CE wants access to financial record of patient P in the hospital. In the hospital an object VCE is created as a virtual employee, with appropriate authentication class: class auth_obj_CE – fctn: read – data: financial_records – key: patient_id – sel: patient_id. insurance_company = IC

Comparison of Structure-based versus certificate-based Access Control for a typical practical situation (numbers from Deloitte&Touche)

Conclusion on III: Architectural issues: S&P in Mokum versus S&P in ERP • Structure-based approach much superior to certificate-based approach of access control. • Structure-based: can be proven correct by running a simple Prolog program. • Specific privacy rules are translated in scripts in Mokum; in authentication classes with special selection criteria. • Global access is no problem; so the above is also valid in Cyber. Space!!

THANK YOU