Healthcare Privacy Privacy Policy Hospital Auditor Patient Patient Patient information information information Drug Company Patient Nurse Physician 2 20/02/15 PARCOMTECH, Bengaluru
Why is it being formalized? • A patient goes to a hospital and provides medical information to a physician. • Physician needs help and passes some of this information along to a nurse. • The nurse then turns around and sells the information to a drug company that uses it for marketing. • Since some patients object to such uses of their health information and we, as a society, want to encourage open communication between patients and their physicians, we have adopted privacy policies, such as HIPAA, that prohibit such uses of patient information without their consent. • To ensure that employees comply with these policies, hospitals employ auditors who examine accesses to and transmissions of protected information looking for actions that violate the privacy policies in place. 20/02/15 PARCOMTECH, Bengaluru 3
A Research Area • Formalize Privacy Policies – Precise semantics of privacy concepts • Enforce Privacy Policies – Audit • Detect violations of policy – Accountability • Identify agents to blame for policy violations • Punish to deter policy violations (resource allocation) 20/02/15 PARCOMTECH, Bengaluru 6
Purpose in Privacy Policies • Yahoo!'s practice is not to use the content of messages […] for marketing purposes . • By providing your personal information, you give [Social Security Administration] consent to use the information only for the purpose for which it was collected. • Purpose =??= Operation • Purpose = ??= Operation + Context 20/02/15 PARCOMTECH, Bengaluru 7
Purpose Restrictions in Privacy Policies • Yahoo!'s practice is not to use the content of messages […] for marketing purposes . Not for • By providing your personal information, you give [Social Security Administration] Only for consent to use the information only for the purpose for which it was collected. 20/02/15 PARCOMTECH, Bengaluru 8
Purpose-of-use • Several privacy policies and laws are defined in terms of the purposes for which the information may be used – For example, the HIPAA privacy rule stipulates that medical information may be used only for certain purposes like treatment 20/02/15 PARCOMTECH, Bengaluru 9
Purpose Restrictions are Ubiquitous • OECD’s Privacy Guidelines • US Privacy Laws – HIPAA, GLBA, FERPA, COPPA,… • EU Privacy Directive • Enterprise Privacy Policies – Google, Facebook, Yahoo,… – Hospitals, banks, educational institutions, govt 20/02/15 PARCOMTECH, Bengaluru 10
Goal of Current Approaches • Give a semantics to – “Not for” purpose restrictions – “Only for” purpose restrictions that is parametric in the purpose • Provide automated enforcement of purpose restrictions for that semantics 20/02/15 PARCOMTECH, Bengaluru 11
Auditing Purpose Obeyed restriction Auditee’s Inconclusive behavior Environment Violated Model 20/02/15 PARCOMTECH, Bengaluru 12
Information Privacy • In the context of information systems, where sensitive information is collected, stored, processed and communicated automatically among the components in a digital form, the challenge is to design a workflow that complies with the relevant / applicable privacy laws and enforce strict controls on access and disclosure of information 20/02/15 PARCOMTECH, Bengaluru 13
Facebook Zynga Policy 20/02/15 PARCOMTECH, Bengaluru 14
Web Security • The web is a complex heterogeneous platform for sharing information and distributed applications that process the information from multiple sources / stakeholders each with their own security requirements – Entertainment – Education – Financial transactions – Social interactions
Schematic of the Web depicting the interactions among its components
Request (Rq) C S Response (Rsp) (a) C (C,{C,S}, ) C (C,{C,S}, ) C creates Rq S (S,{C,S}, ) S (S,{C,S}, ) Rq (C,{C,S},{C}) C (C,{C,S}, ) S (S,{C,S},{C}) Rq (C,{C,S},{C}) C (C,{C,S}, ) C (C,{C,S},{C,S}) C reads Rsp S (S,{C,S},{C}) S (S,{C,S},{C}) Rq (C,{C,S},{C}) Rq (C,{C,S},{C}) Rsp (S,{C,S},{C,S}) Rsp (S,{C,S},{C,S}) (b) Typical web interactions of a client (C) with a server (S)
1. Rq1 2. Rsp1 S1 5. Rq3 C 3. Rq2 S2 4. Rsp2 (a) Interactions in the case of a cross-origin request
C (C,{C,S1}, ) C (C,{C,S1}, ) C (C,{C,S1}, ) S1 (S1,{C,S1}, ) S1 (S1,{C,S1},{C}) S1 (S1,{C,S1}, ) C creates S1 reads C (C,{C,S2}, ) C (C,{C,S2}, ) C (C,{C,S2}, ) Rq1 Rq1 S2 (S2,{C,S2}, ) S2 (S2,{C,S2}, ) S2 (S2,{C,S2}, ) Rq1 (C,{C,S1},{C}) Rq1 (C,{C,S1},{C}) S1 creates Rsp1 C (C,{C,S1},{C,S1}) C (C,{C,S1}, ) C (C,{C,S1},{C,S1}) S1 (S1,{C,S1},C) S1 (S1,{C,S1},C) S1 (S1,{C,S1},{C}) C (C,{C,S2}, ) C (C,{C,S2}, ) C (C,{C,S2}, ) C creates C reads S2 (S2,{C,S2}, ) S2 (S2,{C,S2}, ) S2 (S2,{C,S2}, ) Rq2 Rsp1 Rq1 (C,{C,S1},{C}) Rq1 (C,{C,S1},{C}) Rq1 (C,{C,S1},{C}) Rsp1 (S1,{C,S1},{C,S1}) Rsp1 (S1,{C,S1},{C,S1}) Rsp1 (S1,{C,S1},{C,S1}) Rq2 (C,{C,S2},{C}) S2 reads Rq2 Information flow diagram in the case of a cross-origin request
S2 reads Rq2 C (C,{C,S1},{C,S1}) C (C,{C,S1},{C,S1}) C (C,{C,S1},{C,S1}) S1 (S1,{C,S1},C) S1 (S1,{C,S1},C) S1 (S1,{C,S1},C) C (C,{C,S2}, ) C (C,{C,S2},{C,S2}) C (C,{C,S2}, ) S2 (S2,{C,S2},{C}) S2 (S2,{C,S2},{C}) C reads S2 creates S2 (S2,{C,S2},{C}) Rq1 (C,{C,S1},{C}) Rsp2 Rq1 (C,{C,S1},{C}) Rsp2 Rq1 (C,{C,S1},{C}) Rsp1 (S1,{C,S1},{C,S1}) Rsp1 (S1,{C,S1},{C,S1}) Rsp1 (S1,{C,S1},{C,S1}) Rq2 (C,{C,S2},{C}) Rq2 (C,{C,S2},{C}) Rq2 (C,{C,S2},{C}) Rsp2 (S2,{C,S2},{C,S2}) Rsp2 (S2,{C,S2},{C,S2}) C (C,{C,S1},{C,S1}) S1 (S1,{C,S1},C) C (C,{C,S2},{C,S2}) S2 (S2,{C,S2},{C}) C creates Rq1 (C,{C,S1},{C}) Rq3 Rsp1 (S1,{C,S1},{C,S1}) Rq2 (C,{C,S2},{C}) Rsp2 (S2,{C,S2},{C,S2}) Rq3 (C,{C,S2},{C,S2}) (b) Information flow diagram in the case of a cross-origin request
Cross-Origin Requests • It is a common occurrence to have a web page combine content (scripts and other resources) from several sources – mashups • One of the top 10 web security concerns • Important web security issues including cross- origin requests, origin header, referrer validation, open redirectors etc share a common cause – Failure to accurately identify all the stakeholders responsible for a request
Cross-Origin Requests • Using our approach, request 3 (Rq3) in the example is labelled (C,{C,S2},{C,S2}) indicating that it is created by C, readable by C and S2, and has been influenced by C and S2 • As such, if this is sent to S1, it cannot read it • Declassification is required to allow S1 to read – Possible only under certain trust assumptions
Cross-Origin Requests • Assume, S2 has the necessary trust in S1 permitting downgrading of Rq3 to (C,{C,S1,S2},{C,S2}) to enable S1 to read it • When S1 receives the message it can clearly learn that the message has been influenced by both C and S2 • Depending on the trust S1 has on S2, S1 responds appropriately to the message
WebAuth Protocol • WebAuth # is a web-based authentication protocol based on Kerberos • Three stakeholders – User-Agent (UA), the user's browser – WebAuth-enabled Application Server (WAS), a web server that serves content authenticated via WebAuth – WebKDC, the login server and provider of authenticators to the other two components # http://webauth.stanford.edu/protocol.html#rfc.references
WebAuth protocol for a user logging in for the first time
MODELLING FUNCTIONAL REQUIREMENTS
Information flow diagram in the case of WebAuth
Information flow diagram in the case of WebAuth
Information flow diagram in the case of WebAuth
Information flow diagram in the case of WebAuth
Labels of objects in the WebAuth scenario
INCORPORATING THE SECURITY REQUIREMENTS
Security Requirements • From the detailed descriptions of the steps involved in the protocol, it becomes apparent that certain data objects are not meant to be read by certain subjects – request_token provided by WAS to UA in steps 4 and 5 is not meant for consumption of UA, but just to be forwarded to WebKDC
Security requirements of objects in the WebAuth scenario
Refined Information Flow Diagram • Refined information flow diagram that accounts for the security requirements also, is obtained by introducing appropriate (at states marked with a ) relabelling actions and the associated state transitions
Vulnerabilities in WebAuth • Mitchell et al. # formally modelled WebAuth and using the Alloy tool discovered the following vulnerability – an attacker carries out steps 1 - 8 of the protocol, and shares the link to WAS resource (containing his id token) with a honest user, thereby providing honest user access to sensitive information on the server, thus violating session integrity #Devdatta Akhawe, Adam Barth, Peifung E. Lam, John Mitchell, and Dawn Song. Towards a formal foundation of web security. IEEE CSF 2010
Recommend
More recommend
