Attacking a System
For this assignment, you job is to figure out how best to attack a system. I leave it up to you to figure out which component to attack and what the goals of the attack should be—the goal or goals merely have to be plausible. (Why do I leave it up to you? One of the jobs of a security analyst is figuring out the threat model—the system developers may not have thought about it.)
The (hypothetical) system in question is a nationwide medical records and billing system. Many entities participate:
Each of these entities has its own structure.
Doctor's office: |
A doctor's office has one or more doctor's computers, one or more administrative computers, and one or more serves, for local medical records and local billing records. Those latter two functions may be done on a single computer in a small office. The doctors use a browser to enter medical records. The administrative staff looks at medical records and updates the billing records with a price and a "significant condition" record. They then trigger uploads. The medical records go to the medical record server (indexed by the patient's ID number); this is a specialized, non-web protocol. The bill goes to the proper insurance company, along with a "procedure code", i.e., what the doctor did, and any serious medical conditions. Again, this is a non-web protocol. |
Medical Records |
The medical records site is used to have all patients' records available in one place. Both individuals and doctors log in via web browsers and HTTPS, using their own credentials, to view records. Individuals can only see their own records; doctors can see records of any of their patients once they know the patients' ID numbers. Again, the records are updated via a non-web, server-to-server protocol. |
Health Insurance |
Health insurance companies receive bills from doctors' offices via a non-web protocol. Consumers can log in to their insurance company to see their claims and bills and do other administrative things, including paying bills via credit card. There are also financial transactions originating from this site: patients are billed, doctors are paid, etc. Financial transactions to the doctor and interactions between the insurance companies and banks are out of scope. Insurance companies send significant conditions to the clearinghouse, using a non-web protocol; however, employees of these companies can use a browser to query an individual's pre-existing conditions. |
Clearinghouse |
The clearinghouse receives records from insurance companies, via a non-web protocol. Insurance company employees can use the web to view records; individuals can use a browser to view their own records. |
Individuals |
Individuals can use web browsers to interact with the medical record server, their health insurance company, and the clearinghouse. They can only see their own records. |
There are a number of aspects I've deliberately left unspecified. Make any reasonable assumptions you like, but document them. If there is a more secure option than the one you choose, explain why your choice is better under the circumstances, given the usual tradeoffs of cost, usability, etc.
Here are two possibly-useful diagrams. The first is an overall system flow; the second is the flow with a doctor's office.