TAMI Scenario 9
From TAMI
Contents |
Overview
Goals
Scenario 9 is a test-bed for policy language and policy checking mechanisms in our accountability infrastructure with the following goals:
- enumerate related laws and policies and verify whether the policy language can correctly represent these laws and policies
- enumerate policy checking test-cases and verify whether our policy engine can consistently find the use of data which constituted a violation of law or policy in the transaction logs
Below are several important notions used throughout this report:
- transaction logs - audit logs of data-manipulation events, maintained by accountability servers (ASs)
- laws and policies - a list of laws and policies that apply to the data or data manipulation in the transaction log
- violation of laws or policies - violations may be in the form of unauthorized access, dissemination, manipulation, or conclusions derived from them
Part of our motivation is to ensure that people who suffer adverse consequences (e.g., ranging from the loss of an apartment or job to the loss of life or liberty) as a result of such violations of their privacy will have an aid in their path to redress. For this reason, each of our scenario's variation illustrates a real-world harm that might result from law and policy violations and how this technology might help to identify the system or human failure which caused it.
Requirements
The scenario should be "real" such that:
- Events similar to those in the transaction logs can be found in real world electronic audit systems
- Policy-checking process simulates real world lawyers' activities
- Policy-checking results can be consumed by judges, government managers, and lawyers
- There should be a reasonable number of events for scalability test.
The scenario should demo complex points of failure such that:
- it is not possible to avoid the failure by telling a single person or group, "Don't do x again.".
- In other word, the violation cannot be caught simply by stopping a single transfer or group of transfers. For example, even though actor A is entitled to have access to data D, it is not permissible to use D for purpose P.
The policy checking process may need OWL DL inference.
- OWL DL inference over transaction logs, policies, or both may ensure completeness of policy checking. For example, knowing the diagnose of Mycobacterium tuberculosis may not directly tell whether it will lead to "imminent risk of harm to the individual or others". If we use additional OWL inference on an disease ontology to infer that Mycobacterium tuberculosis is a kind of contagious diseases, we can easily see the relation because the "imminent risk" is part of contagious diseases' definition.
Scenario Description
Plot Summary
- Index case: A hospital discovers that patient has a rare form of Tuberculosis (TB) that is resistant to known treatment.
- Since 20-30% of people with whom a patient has had close contact will get LBTI (the latent form of TB), there is a high likelihood that the patient has infected a significant number of other people.
- The patient is in a coma and cannot be interviewed by the CDC.
- A Google search reveals that he is a University researcher;
- His university webpage says he sings in a large choir and helps out with his daughter's Daisy Girl Scout troop.
- Since singing provides a higher than average rate of transmission and children under 5 fall in the high risk category, the CDC is anxious to investigate quickly
- The CDC decides to follow a traditional forensic investigation and to find all of the patient's repeated or high risk contacts during the previous three months.
- Since they cannot interview the patient, their normal means of determining contacts, the CDC decides to determine the contacts through data mining because it should be faster and more thorough.
- To develop a list of possible contacts, the CDC identifies the people
- who live in the patient's condo (Thomas reverse-directory search);
- who work in his department (mit.edu search);
- are members of the choir (FOAF); and
- are related to the Daisy Girl troop (PAW site).
- To narrow the list, the CDC attempts to find the patient's most frequent contacts by pulling and cross-matching:
- credit card transactions records
- telephone records
Thread 1: Medicare transactions over an index case
- Background: A hospital discovers that a patient has a rare form of Tuberculosis (TB) that is resistant to known treatment and has a high likelihood of infecting recently contacted people
- Data collection: Upon receiving the index case, the CDC gathers information about the person and the patient's contacts, acquiring data from various sources including the Web, university administrators, credit card companies, phone companies, etc..
- Data mining: the CDC uses the collected information to find a subset of contacts who have a high probability of being infected
- Action: the CDC contacts the patient's contacts prioritized by the data mining results.
Thread 2: Business transactions that denies a service request
- Background: After the CDC investigation, a phone company retains records that associate the CDC investigation with the record of each customer about whom the CDC inquired.
- Data mining: Upon receiving a request for service from one such customer, a customer service specialist checks the company's database and collected information about the customer
- Action: The specialist denied the service request based on collected information
Thread 3: Legal investigation on adverse consequence
- Background: A customer files a complaint asserting that his phone service request was denied as the result of discrimination over his health status
- Data collection: In response to a discovery request, the phone company's lawyer queries the TAMI system through interactive interface for the relevant transaction logs, the lawyer infer additional facts, and then manually finds corresponding legal policies (e.g. HIPAA, MA-disability- discrimination)
- Policy checking: The customer's lawyer asks the TAMI system to walk the policies over the collected and manually inferred facts and TAMI finds apparent violations
- Action: The customer's lawyer files a motion for a finding in the customer's favor, presenting the policy checking results and justifications to the judge
Demo
A variation of scenario 9 can be used as a competence test for the expressiveness of policy language or the functionality of policy reasoner. A variation involves of three components:
- transaction logs: applicable events from scenario 9 transaction logs
- laws and policies: applicable laws and policies from scenario 9 laws and policies
- expected results: the expected policy language representation requirements and the expected results in determining violation of laws and policies
Variation 1: One step policy evaluation
In this variation, we show how one event (the event in red color) in the transaction log directly violated one policy. The violation is raised because Betty should not use Bob's health information to deny Bob's benefit request while Bob is a resident of MA.
Demo (s9v1):
- TAMI_Log_S9_V1, live RDF/XML dump
- MA_Disability_Discrimination_Law_V1, live N3 dump
- [+] online demo on live data
Variation 2: Multi-step policy evaluation
In this variation, we show a rule violated by a chain of events. Betty denies the customer a benefit using customer's records obtained by someone else about his health information. Indeed she is not supposed to use any data derived from the health information.
Demo (s9v2):
- TAMI_Log_S9_V2, live RDF/XML dump
- MA_Disability_Discrimination_Law_V2, live N3 dump
- [+] online demo on live data
