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
• WG11.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
type person
has-a name
has-a address
has-a father: person
type student
has-a field
type employee
private
has-a salary
type customer
private
has-a account
type account-manager
has-a Customers: coll_of customer
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? (WebNet 97)
• Example: WorkFlow 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: WordNet (++)
– 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-claimDB for the claim information
– TA-tripDB for the trip information
– oblDB for the obligations
• Authorization database with authorization
tuples; e.g.
– AUTH<IC-claimDB,approver,create,allowed>
•
AUTH<IC_claimDB,approver,create,
allowed>
AUTH<oblDB,approver,shift,allowed>
AUTH<oblDB,travel-agent,shift,not
allowed>
AUTH<claimDB,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
WG11.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-AccessControl) 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)
1.Definition certificate classes
2.Making Certificates
3.Assigning certificates
4.Defining checks in Aps
5.Checking at run time
-1.Defining collections
-2. Adding to collections
600 in SAP R/3
50 = # roles and persons
50 same as 2.
200 objects * 20 operations
each access
no
no
no
no
no
only as exceptions in triggers
checking membership of collections
same as in 2.
all patients in 50 collections
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 CyberSpace!!
THANK YOU