Lecture 3 – Multilateral Security

1. Lecture 3 – Multilateral Security Security Computer Science Tripos part 2 Ross Anderson

2. Decoupling Policy, Mechanism • Role-based Access Control is what we always used to do in banking! • Formalised by Ferraiolo & Kuhn of NIST • Extra indirection layer: ‘officer of the watch’, ‘branch accountant’, ‘charge nurse’ • You still need a policy – such as Bell-LaPadula or Biba • The policy may end up being expressed differently

3. Decoupling Policy, Mechanism (2) • SELinux – Linux hardened with help from the NSA – uses an architecture called Flask • Policy separated from mechanism; security server in the kernel manages attributes • Default security models: TE and MLS with RBAC • Red Hat uses it to separate services – a web server compromise doesn’t automatically get DNS too • Trusted BSD – now in iPhones • Common problem: complexity of software means it’s hard to design useful security policies

4. Decoupling Policy, Mechanism (3) • VMWare, Xen used to provide separation in hosting centres. Can we do the same client-side? • NetTop lets you run multiple Windows instances on a Linux box • Big problem: complexity of the modern PC! • Which VM does the mic/camera belong to right now? • What’s going on in the graphics card? • Other big problem: managing flow between levels. Typically done server-side by governments • What about commercial / domestic users?

5. Multilateral Security • Sometimes the aim is to stop data flowing down • Other times, you want to stop lateral flows • Examples: • Intelligence • Competing clients of an accounting firm • Medical records by practice or hospital

6. The Lattice Model • This is how intelligence agencies manage ‘compartmented’ data – by adding labels • Basic idea: BLP requires only a partial order

7. The Lattice Model (2) • The levels “Secret Crypto” and “Top Secret” are incomparable – no data flow either way • Codewords can have special handling rules – e.g. wartime “Ultra” (now “Umbra”) meant you could not risk capture • Problem: either you end up with millions of compartments, or you end up with all the good stuff in one pot (the CIA’s problem with Ames) • Post-9/11, the big-pot model is gaining ground …

8. The Chinese Wall Model • Industries such as investment banking, advertising and accounting have too few top firms for each big client to have its own • So maybe you’re auditing BP, and Shell too! • Traditional control: a “Chinese Wall” rule that stops the two teams communicating • Idea (Brewer and Nash, 1989): use a refinement of Bell-LaPadula

9. The Chinese Wall Model (2) • Idea: it’s not enough to stop a Shell analyst reading BP data • Must stop a BP analyst writing data to a Barclays file that the Shell analyst can also read • For each object O, let y(O) be the firm it relates to • Let x(O) be that firm’s conflict-of-interest class • Let x(O) = Ø if the information has been sanitized (so anyone can see it)

10. The Chinese Wall Model (3) • Then reading is allowed if the object belongs to a firm the subject has access to, or a different conflict-of-interest class S can read O iff for all O' to which S has access, y(O)=y(O') or x(O)  x(O') • Writing is allowed iff the user cannot read an object that contains unsanitised information S can write O iff S cannot read O' with y(O)y(O') and x(O) Ø • Practical issues: where is the state kept? Should you automate this at all?

11. Medical Record Systems • Perceived problem: many incompatible systems in hospital depts / GP surgeries, leading to higher costs, clunky procedures (e.g. pediatrics, geriatrics) and difficulty of collecting data for management • Proposed solution (92–95): integrated hospital system where everyone could see everything • 1995 roll-out in health minister’s constituency • Nurse in Basingstoke found that her ward system let her (and colleagues) see results of tests she’d had at her GP!

12. Medical Record Systems (2) • NHS ‘Information Management and Technology Strategy adopted an MLS policy • Problem 1: where is a prescription for ARV? • Problem 2: all GP receptionists see all UK records!

13. Medical Record Systems (3) • What should the security policy be? • Early attempt at policy for a ‘lifetime electronic medical record’ gave up after 60+ rules • BMA project 1995–6 • Key simplifying assumption: define the ‘record’ as the maximum set of health information with a single access control list • Reflects actual practice! Your lifetime GP record has pointers to further stuff in hospitals etc via referral letters and discharge summaries

14. Methodology • First, get the threat model right. Will the attackers be insiders or outsiders? Capable or opportunistic? Institutions or individuals? • Next, set protection priorities and get agreement from application experts • Then build a policy model • Then validate it by peer review, public consultation, pilot projects, … • So what are clinical privacy and safety, and what threatens them?

15. Ethical Foundations • GMC position, 1995: “Patients have a right to expect that you will not pass on any personal information which you learn in the course of your professional duties, unless they agree” • Department of Health position: access for individuals who claim a “need to know” • I v Finland, 2008: patients have a right to restrict their medical records to the clinicians involved directly in their care

16. Public Opinion • Poll in 1996: most people supported access to their records by health staff treating them, opposed access by officials, and supported research access only if they were asked • 2006 update: In an ICM poll, 2,231 adults were asked their view on a central records database with no opt-out strong support 12% tend to support 15% neither 14% tend to oppose 17% strongly oppose 36% don’t know 6% • Other studies give similar, stable results

17. Threat Model • ‘Pretexting’ is the standard way for private eyes to get data • 1996 pilot – staff at N Yorks Health Authority trained to log information requests, get them signed off, and call back to a number you can check independently • We detected 30 false-pretext calls per week! • BMA asked DoH to roll this protocol out nationwide – instead, pilot site told to stop it! • 2006: pretexting cost Hewlett-Packard chair her job • 2009: infected PCs are becoming a big deal. DoH won’t monitor levels of infection

18. The BMA Policy • Each record has a single access control list • Record opening: ACL = clinician + patient + referrer if any + team if notified • Ownership: one clinician must control the ACL • Notification: the controller must notify the patient of changes to the ACL • Persistence: no-one shall be able to delete data until the statutory time period has expired

19. The BMA Policy (2) • Attribution: all accesses (even reads) must be logged with name, date and time • Information flow: Information derived from record A may be appended to record B iff ACL(A)  ACL(B) • Aggregation: controls must exist, and patients must be notified if anyone on the ACL has access to many other patients’ data • TCB: the mechanisms that enforce this policy must be evaluated by independent experts

20. The BMA Policy (3) • The policy was put to consultation, and tested in general practice. Everything worked except auditing read access • Independently, System C built a hospital system for Hastings that did much the same but with capabilities instead of ACLs • A nurse can read the record of any patient who’s been on her ward that month • Consultants can override, but that’s logged • It all works in direct care. The hard problem was secondary uses!

21. Secondary Uses • CMO Sir Kenneth Calman set up the Caldicott Committee to study secondary uses • Caldicott documented many illegal information flows; e.g. it’s illegal to share info on VD without consent, yet public health folks did on AIDS • HSCA s60 allowed SS to ‘legalize’ most of these • There remains a serious conflict with European law – ‘sensitive’ data need consent or narrowly-drawn legislation • I v Finland makes this acute! • DoH hopes that ‘anonymisation’ will save the databases…