1

Administering Security Policies + Data Sharing

Arnon Rosenthal

The MITRE Corporation

2

Talk contents: Administration

• Administration: the efforts that don’t look like programming

• For data to be shared, we must administer – Policies (security, privacy, intellectual

property, user interests)– Data exchange/integration metadata:

describe, relate, prescribe

3

Viewpoint for talk

• My employer, MITRE, thinks in terms of needs of end user organizations

• Discuss the practical world, esp. painful areas – Identify needed capabilities– Extract research challenges that can simplify or

empower– How “research” intertwines with tech transfer

• Other tasks for researchers– Conceptualize, modularize– Illuminate the fallacies (repeatedly)– For UCI: Combine data-brokering and security

• Opinions on what research is most useful

4

Commercial Break

• We’re hiring researcher/consultants and prototypers

• Suburban DC, Boston, other

• 95% of openings require US citizenship (sorry!)

5

Policy administration outline

• Overview– Typical technology ingredients– What sorts of policies

• Foundational capabilities– Models– Mapping– Metrics – Improve SQL (M.S. projects?)

• Principles for scalable approaches– What has research contributed? – What do we need?

6

Aspects of policies

• Interest protected: Secrecy, privacy, intellectual property, integrity, My_Alerts ...

• Actions: Allow/deny, second signature, intense audit, warn requester, filter the data accessed

• Decision factors (it’s getting knowledge intensive)– Resource: Object, operation– User properties: identity, job, project, area of responsibility, role – Request: purpose, submission time, data-destination– Context: Any info, from anywhere

• What’s missing?• Cost / benefit are not in the models!• Best available knowledge management

7

Major technologies

• Policy languages– Programming languages with policy-friendly

constructs– Predicate language ++ (e.g., XACML)

• Also: Select relevant policies, resolve conflicts

• Role based access control– Aggregates users, privileges into roles– Authorization model (activation, reachability)– Standard

But it’s one graph,

10

problem context Policy administration in enterprises

• Single sign-on is typically the top priority, rather than policy specification

• Cost of ownership for DBMSs is admin, not hardware, software– We can expect the same for security

• DBAs are considered untrustworthy (too casual) to be given superuser-type powers– But they still have complete privileges– Thus: extra layer, controlled by security officers, to limit/audit DBAs

• State of the practice /product– Role based access control (RBAC) + predicate language– Chaos in distributed and n-tier systems

11

Security policy chaos in today’s n-tier systems

Bill

Application Server(e.g., WebSphere, WebLogic)

ShipSellBuy method

Product Order

Authenticate

Databases (tables/docs)

View/ Proc

12

Improving this mess seems a central problem

• Opinion: Many SIGMOD researchers are working on “nondisclosure”– The problems seem worthwhile, and are

getting nice results– But they seem less central to society’s needs

• Low disclosure mining algorithms

• Avoiding inference from published data

• Outsourced untrusted databases

13

Policy administration outline

• Overview– Typical technology ingredients

– My cat is privacy-protecting• What sorts of policies?

• Foundational capabilities

• Principles for scalable approaches

14

• “Fair information practices” and human rights• Legal requirements are frequent, may forbid sensible tradeoffs• Purpose(?)• Millions of administrators, opting in and out. So can have very fine

grained policy, with low admin cost

Sorts of policies

What is different about privacy?

15

An easily-applied categorization

• Ask what stakeholder a policy protects– Privacy: The person (or entity) described– Enterprise secrecy: The entity controlling the

database– Intellectual property: The provider of the info

16

“Correct enough” + Delegation Trust management?

Critical decisions of all sorts need correct data• Integrity, in security community:

– Authorized person entered it (e.g., our sysop) – He used the correct procedure– It hasn’t been illegally changed (integrity) Main threats: Malice or improper procedures

• Issues ignored• It was entered in 1991• Signed by our

Springfield sysop …

17

Policy administration outline

• Overview

• Foundational capabilities– Models– Mapping– Metrics – Improve SQL (M.S. projects?)

• Principles for scalable approaches

19

1. How can one DBMS best support multiple security models?

SQL security model

DBMS Security

RDFsec. model

OWL sec.

model

OWL sec.

model

XMLsec. model

P3PFilter

based on rowlabels

XACML

20

OWL policy

AddTree graphic

AddTable graphic

DBMS

Virtualdocs

Virtualtables

SQL policy

PolicyPolicy

OWL

VirtualRDF

VirtualOWL

RDFpolicy

RDF

Policy

PolicyPolicy

XML policy

22

How to support multiple security models?

SQL security model

DBMS Security

RDFsec. model

OWL sec.

model

OWL sec.

model

Abstract Data Model Containment, Derived data, M’data…(in enough detail to drive security)

Abstract Security ModelAttach a policy to objects General security, e.g., - Ownership - Revoke or limit privilege

XMLsec. model

25

2. Compile “business” policies to physical implementation

Individually identified medical data shall be available only to professionals

treating the patient,

Who are “professionals

treating this patient”

Metadata, ontologies

Userm’data

For each implementation object (e.g., lab test msg) • Determine relevant policies • Translate policy thru data mapping to execute on impl. object

What data is“medical”,

“individually identified”

26

Connect “capital P” Policy to implemented objects

• Medical personnel assigned to patient can read Lab test info for purpose of Treatment

• AllergyTest(PName, allergens) by Nurse, for drug interaction screen

• Is AllergyTest Lab test. Is nurse medical? Is drug interaction screen Treatment? Is she “Assigned” (on that ward or private nurse or… )

Decision-maker Policies

English

Predicates

Mental, undocumentedAllergyTest + request objects

27

Connect “business” Policy (capital P) to implemented objects

• AllergyTest(PName, allergens) by Nurse, for drug interaction screen

• Medical personnel assigned to patient can read Lab test info for purpose of Treatment

• Is AllergyTest Lab test. Is nurse medical? Is drug interaction screen Treatment? Is she “Assigned” (on that ward or private nurse or… )

Decision-maker Policies

English

Predicates

Enterprise knowledge:Rel’ships among vocabularies

Mental, undocumented

Automate translation

Capture once, document,use for all affected objects

On AllergyTest and requests

• Allow:= MedicalPerson, Purpose:Treatment Assigned(PatientDescribed), MsgType: LabTest

28

Paris HospitalEnforcement: DBMSPolicy applied: FranceRoles: Hospital (Emergency Care)

Transfer or compare policy horizontally across organizations and systems

What data is• Medical• Indiv identified

Who are • Professionals• Treating this patientInsurance approver role only in US

Confidence in• Technical measures• Metadata admin• Partners

Aetna Travel InsuranceEnforcement: Application serverPolicy applied: US (NY)Roles: HiPAA spec (Aetna version)

?

29

Today, policy engines receive a soup that combines all stakes

Location is in User.AreaOfResponsibility and Suspect.ThreatLevel = high & Traveler.Date < 7 days from today & ((Suspect.Category=Domestic & Suspect.ThreatLevel=high) or Suspect.Category=Foreign ) & User.Job is Investigator & User.Agency is Law enforcement

• Hard to create, analyze, change• Alternative (EPAL, MLS, Oracle): Each stake

has its own language and enforcer– No integrated picture, no orthogonality

30

More complex decomposition into several stakes

Notional request: Info from Suspects join TravelersPolicy: Location is in User.AreaOfResponsibility and

Suspect.ThreatLevel = high & Traveler.Date < 7 days from today & ((Suspect.Category=Domestic & Suspect.ThreatLevel=high) or Suspect.Category=Foreign) & User.Job is Investigator & User.Agency is Law enforcement

• Each stake requires one skill• Change is easy: Edit a small chunk• Stake can be on different granules, e.g., Region, Dept

Privacy (Traveler)

Protect secrets (Suspect)

Safety fence (Suspect)

32

∧ multiple inputs, that raise different concerns

Separations of concerns that one might support

Detailed controls ∧ Coarse guarantees (safety fence, e.g., ?????? clearance)6Suspec

t join Traveler

Suspect join Traveler6 Suspects Travelers

(e.g., CIA, TSA)

Safety fenceNeed to know

∧ Policy types:PrivacySecrecy3rd party (Intell. Prop)

Throttles & bans - alert user -bandwidth

33

Policy Administration Research Challenges-- Outline

• Foundational capabilities

• What has research contributed?

• Meta-level challenge: Models that scale

34

What’s been added to DBMS security since 1980s

• Roles, role hierarchies– SQL role is a set of privileges or users– But industry did roles, DB researchers arrived after

• Receive “identity” information (but little more) from middleware or OS– SQL and JDBC are both barriers to extension

• Filter query response based on row or column security labels (described later)

• Security for new features added to SQL– Triggers, nested tables, objects, procedures– Security features are tightly coupled to data model

35

Which additions owed a debt to data security researchers?

Why were we unable to help vendors (enterprises) improve this (now-critical) aspect?

• Too few ideas were worth transferring

• Some ideas were infeasible from the start

• Few scaled to practical systems (many features, very much knowledge).

36

Giggle Test

• Technologies are interrelated and must mesh to deliver a capability– Identify the entire package needed to achieve the

desired impact for the user, and then ensure that it makes sense*

• Can you – without giggling – say that the entire package seems feasible and desirable (now? someday?)

* Al Manning, MITRE

37

Examining transfer for a research idea: Inference control

• You have a full description of attacker’s knowledge• No collusion between requests from different User IDs• Administrators have identified all sensitive fields

– Or it’s worthwhile to protect just a few • Efficiency – extra factor of 5 is OK• No updates• You know what info the has already accessed

Black bullets limit applicability. Not to zero, but is it a good place to invest scarce talent?

1-2 probably can’t be removed by more research!Spend $$$$ for high certainty (locally), but partial solutions

won’t give a large factor of protection

38

Policy Administration Research Challenges

• Foundational capabilities

• What has research contributed?

• Meta-level challenge: Models that scale

39

Outline

We need scalable approaches

• Opinion: Scale-up should be the primary research criterion– Deemphasize work on specific capabilities –

hard to integrate, so too few transfer

• What do we need for scalability– Simplicity (for admin and software vendor)– Reach out (don’t duplicate)– Componentize– Metrics for scalability

40

Requirements for scale-up

Simplicity

• Opinion: “Simplicity” should be an absolute constraint on proposed “foundation” features

• The lesson of relational dbs: Create a simple submodel– Use its tractability to provide great services

(UIs, compilation, …)– Push tough things out of foundation

• e.g., to 3GL or manually-coded policies

41

Requirements for scale-up

Reach out, don’t do it all (1)

• Don’t create own datatypes (time, space)– Create a framework for plug-ins– Don’t compete with bigger markets, more

expertise– Can create your own for a prototypes, but call

it a hack, not a model

42

Requirements for scale-up

Reach out, don’t do it all (2)• RBAC is a large silo. It’s now time to look away

– OWL seems more promising. (Much more powerful, simple and tractable enough)

• Formalism silo: Employs a formalism from policy community for general enterprise knowledge– Policy itself should stay as a policy language

• Role hierarchy is a silo knowledge base (very tenuously linked to general knowledge)– Cannot fit enterprise into a single graph– Integrity of vital info applies to general knowledge, not

just stuff in security system

43

Requirements for scale-up

Modularize

• Create clean abstractions, with multiple elaborations– E.g., multiple coexisting ways to remove

privilege

• Don’t build silo modules by hardwiring one choice on each abstraction– Where need new capability, make it available

to all

44

Requirements for scale-up

Objective comparisons • Recent papers compare models’ logical expressive

power. – Top priority for logicians, – For vendors and admins, relevant but not as central as next

• Admin effort (how much to enter, what skill level for people)

• Implementation cost for vendors• Learning curve for admins• Possible approach

– Draw correspondences between concepts– Improve by using generalization, separate interfaces

46

Backup foils

47

Security policies in the semantic web

• Exploit semantic knowledge (in OWL) for all relevant aspects of a request (users, resources, …) [Qin+, Kagal+]– Little semantic web to secure, so far

• Theoretical gaps– “Certain answer” mappings(??)– Policy propagation rules are asserted without an underlying

correctness criterion. Also hard to follow (negatives)

• Pragmatic gaps – Applies to data already described by ontologies. No test of “just

in time” semantic capture for a new policy– It’s not a component – no interface to more powerful rules– Execution by inference engine, not ordinary server

48

Challenges here

– Use SQL to test your framework• Mature industrial standards force you to confront all the

issues • Middleware security dominates, but SQL is significant

• 106 installations, 30%? (less?) doing nontrivial security

49

What practitioners need from the research community

A database industry would be alive and well … even if researchers had never entered the database arena. …

Industry identified the problems and provided the early impetus.

Researchers came along later and provided the clean abstractions and the elegant solutions. …

Database researchers have contributed mainly by formalizing, simplifying.

[David Lomet, Head of Database Research at Microsoft]

50

Some constructs??

• Permissions (conditional OK)

• Negatives X

• Foundation should always work – don’t hardwire “70% guess” (e.g., Deny wins)

51

2. The usual federated query problems: Compile to heterogeneous enforcers

Policy: ON PersonInfo If Age(Person.SSN) < LegalAge(Hospital. State, Purpose) then Reject+Audit

Person(relational DB) Hospital

(document server)

Heterogeneous enforcers, each has own policy language

Policy may reference confidential data

Medicaid_Approved(app server)

52

Enforcement mechanisms are very heterogeneous

Compile high level policy to heterogeneous enforcers, which include:

• User agents (P4P?)• DBMSs, document and image servers (bottom tier)

– Nagging issue: How to pass request attributes, when SQL call is not SAML-enabled

• Middleware (on service/method calls)– Cannot act differently on each retrieved object

• Application code• Boundary enforcement, e.g., air gaps, high assurance guards,

low assurance filters on email. • GUI (user friendly but low assurance)• Human decisions (expensive, slow, error-prone)Each of these is separately administered, today!