A System for Privacy Policy Enforcement

1
A System for Privacy Policy Enforcement Access
Control for Web Applications

• Hemant Goyal, Assim Deodia, Anand Gupta
• B.E. (Division of Information Technology)
• Netaji Subhas Institute of Technology, Dwarka
• New Delhi

2
Introduction

• Organizations are gathering and storing a lot of
  user data.
• Important for them to ensure the ethical usage of
  the data to have a good standing in society
• Robust systems are needed to limit disclosure of
  data to individuals/users while abiding by
  various policies defined by them and by external
  laws.

3
Motivation

• Web Service applications enforce access control
  by hard coding different access rules in the
  application.
• Little scope for scalability of the system when
  newer access policies are created.
• Tough for the end user to introduce his own type
  of roles and define the corresponding access
  policies.
• Modification of application code to change
  policies provides only a temporary solution.

4
Aims

• Various web applications are written in PHP and
  use MySQL as the storage database.
• Our system can be used as a framework/starting
  point to provide privacy policy enforcement and
  access control for such applications.
• Application developers hence only need to focus
  on writing the services and do not need to worry
  about developing the privacy aware and access
  control environment.
• Making access control privacy aware by
  associating intent with an access control
  policy.

5
Scenario Chosen

• A Hospital which maintains information of its
  patients, doctors, and researchers in a database.
• Hospital maintains a detailed access control and
  privacy policy document specifying who can access
  what data and for what purpose.

6
Roles Patient, Mary

• She must first register and provide her personal
  details to the hospital administration.
• Given a choice whether she would like to reveal
  specific information about her for research
  purposes.
• Based on the information that is disclosed Mary
  can choose to give her consent for disclosure.
• Mary would also like the fact that only the
  doctors who are treating her, have access to
  information about her condition.
• Mary also wants to be guaranteed that her
  personal information will only be accessed by the
  administrative staff for billing purposes, and
  that no one else in the hospital can access it.

7
Roles Surgeon, Thompson

• Thompson is a Surgeon who specializes in the
  field of Lung Cancer.
• He wishes that his professional information like
  published papers, email id etc are revealed only
  to researchers who are researching in the field
  of Lung Cancer.

8
Roles Systems Admin, Charlie

• Responsible for ensuring the smooth working of
  the system.
• Has developed his own algorithms for regular
  maintenance of the server, which only he can
  access.
• He is responsible for preparing the access
  control document, and policies for the system.
• Charlie is a trustworthy system administrator

9
System Design - Modules

• User Account and Information Management
• User registration, Profile modification, consent
  control, password retrieval etc..
• Policy Developer and Enforcer
• Receiving data access requests along with the
  intent.
• Evaluates all applicable policies that are
  defined to create a list of data resources that
  can be accessed.
• Services
• Set of scripts that perform some particular
  function which can be added according to the
  requirements of the end developer using our
  system.
• E.g. Billing, Administration, Patient information
  module etc..

10
Policy Developer and Enforcer
Application Specific Services
Application Specific table
System Specific table
Policy Developer
Policy Checker
Service Handler
Data Handler
Condition Evaluator
Database
11
Policy Developer and Enforcer

• Supposed to find all policies that may or may not
  be applicable to a particular context.
• Intelligent Searching
• Least number of policies should be checked
• Ensuring no applicable policy is left out and not
  enforced.
• Develops a list of policies to be checked and
  passes it to the Policy Checker.
• Policy Checker returns a valid subset of the list
  of policies to be enforced

12
Policy Developer and Enforcer

• Based on the data access allowed according to the
  enforced policies, a list of attributes and table
  name is constructed.
• The list is passed to the requesting module/data
  fetcher for data retrieval.

13
Policy Checker

• The policy checker bases its decision upon the
  following parameters
• Whether the policy is meant for the requester who
  is currently logged in to the system or not.
• Whether the requester is allowed to access the
  attribute of the particular target type.
• Whether the additional conditions for the
  policies are true or not.
• The result of parameter 3 is received from the
  Condition Evaluator. A list of applicable and
  enforced policies is created and returned back to
  the policy developer.

14
Policy Modeling

• We want to model the following policy
• A Doctor can View the X-Ray Report attribute for
  Treatment purpose if the condition (Doctor ID
  must be same as ID of Doctor referred to) OR
  (Doctor ID must be same as ID of Doctor referred
  by) is satisfied.
• Refer to PolicyID 3 in the figure.

15
Condition Modeling

• The aggregate condition can be broken down and
  modeled in the Atomic Conditions Table
• DoctorID must be same as ID of Doctor referred to
  (modeled as ConditionID1)
• DoctorID must be same as ID of Doctor referred by
  (modeled as ConditionID6)

16
Advantages Achieved

• Existing Method- Refer 4
• New condition must be created and stored in the
  database to represent any aggregate condition.
• Increases the table size.
• Requires human effort to re-write the entire
  aggregate condition.
• Our approach-
• Existing atomic conditions are logically clubbed
  together to form a new aggregate condition.
• No explicit creation of new condition to
  represent the aggregate condition.

17
Policy Sets Modeling and Storage

• A new aggregate purpose can be created by the
  aggregation of atomic purposes.
• Instead of re-writing the policies for the new
  aggregate purpose, older policies applicable for
  atomic purposes can be brought together to form a
  policy set.
• We can also write new policies which are
  applicable especially for this aggregate purpose.

18
Conclusion Summary

• A practical approach to actively enforce privacy
  policies and access control.
• Associating intent with access control policies.
• Logically clubbing atomic conditions to form
  aggregate conditions.
• Creation of roles by system developers.
• Higher level aggregation of policies into policy
  sets.

19
Future Goals Scope for Improvements

• System can be modified such that it behaves as a
  middleware for existing PHP MySQL based
  applications. This can be achieved by methods
  like query catching and re-writing4.
• The algorithms designed can also be proven to
  work with other scripting languages hence the
  method is not limited to only PHP MySQL based
  web applications.
• Algorithms for automatic installation of the
  system can also be developed, along with GUI for
  administrative management of the system.
• Access control to the various services end system
  developers create. Can be achieved through
  underlying policy enforcement mechanism only.

20
References

• R. Agrawal, J. Kiernan, Ramakrishnan, and S. Y.
  Xu, Hippocratic databases, 2002. 
• H. Goyal. (2007, August) Xacml policy for
  physician. Online. Available
  http//www.nsitonline.in/hemant/stuff/xacml/physic
  ian.xml 
• P. Griffin. (2004, February) Introduction to
  xacml. Online. Available http//dev2dev.bea.com
  /pub/a/2004/02/xacml.html 
• K. LeFevrey, R. Agrawal, V. Ercegovac, R.
  Ramakrishnan, , and Y. X. D. DeWitt, Limiting
  disclosure in hippocratic databases, 2004. 
• M. Lorch, S. Proctor, R. Lepro, D. Kafura, and
  S. Shah, First experiences using xacml for
  access control in distributed systems, October
  2003. 
• (2004, July) Suns xacml implementation. Sun
  Microsystems, Inc. Online. Available
  http//sunxacml.sourceforge.net/
• M. C. Mont and R. Thyne, A systematic approach
  to automate privacy policy enforcement in
  enterprises, March 2006.
• D. Wijesekera and S. Jajodia, A propositional
  policy algebra for access control, ACM
  Transactions on Information and System Security
  (TISSEC), vol. Volume 6 , Issue 2, 2003.