Lecture 3 multilateral security
1 / 21

Lecture 3 Multilateral Security - PowerPoint PPT Presentation

  • Updated On :

Lecture 3 – Multilateral Security. Security Computer Science Tripos part 2 Ross Anderson. Decoupling Policy, Mechanism. Role-based Access Control is what we always used to do in banking! Formalised by Ferraiolo & Kuhn of NIST

Related searches for Lecture 3 Multilateral Security

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Lecture 3 Multilateral Security' - aglaia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Lecture 3 multilateral security

Lecture 3 – Multilateral Security


Computer Science Tripos part 2

Ross Anderson

Decoupling policy mechanism
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

Decoupling policy mechanism 2
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

Decoupling policy mechanism 3
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?

Multilateral security
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

The lattice model
The Lattice Model

  • This is how intelligence agencies manage ‘compartmented’ data – by adding labels

  • Basic idea: BLP requires only a partial order

The lattice model 2
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 …

The chinese wall model
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

The chinese wall model 2
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)

The chinese wall model 3
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?

Medical record systems
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!

Medical record systems 2
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!

Medical record systems 3
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


  • 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?

Ethical foundations
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

Public opinion
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

Threat model
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

The bma policy
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

The bma policy 2
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

The bma policy 3
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!

Secondary uses
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…