Administering Security Policies Data Sharing

1
Administering Security Policies Data Sharing

• Arnon Rosenthal
• The MITRE Corporation

2
Talk contents Administration

• Administration the efforts that dont 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

• Were 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 (its 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
• Whats 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 its one graph,

8
Role-Based Access Control basics

• Group set of users, e.g. Doctor, Nurse
• Role set of privileges, e.g., needed to process
  travel expenses
• Single user is a group. Single privilege is a
  role.
• Benefit Aggregates users (privileges) that are
  somehow similar, so one decision applies to the
  whole set.
• Can aggregate the aggregates, e.g.,
• Medical Staff includes Doctor, Nurse, Technician
• The distinction between groups and roles has
  spawned a debate --confusing, because both sides
  are right
• Minor distinction for enforcement, but excellent
  for admin

9
Group/role graph

• Reduces admin labor
• Decentralizes admin

Groups
Roles
Users
Privileges
How far can this graph visualization go? -
Grants that require multiple authorizations?
- Communities of mutual trust?
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 todays n-tier systems
Authenticate
Application Server(e.g., WebSphere, WebLogic)
Order
Product
Bill
Ship
Sell
Buy method
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 societys 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
Sorts of policiesWhat is different about privacy?

• 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

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 hasnt 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

18
Policy Administration Research Challenges

• Foundational capabilities
• Security model for multi-model DBMSs
• Map policies from abstract to implementation
  objects
• Onward to the enforcement languages
• Map between organizations policies
• Decompose into independently-specified stakes
• (Fix SQL security -- substance, standards
  document)

19
1. How can one DBMS best support multiple
security models?
DBMS Security
SQL security model
RDFsec. model
XMLsec. model
OWL sec. model
Filter based on rowlabels
P3P
XACML
20
Policy
Policy
Policy
Policy
Virtual OWL
Virtualtables
Virtual RDF
Virtual docs
DBMS
OWL
RDF
AddTree graphic
AddTable graphic
OWL policy
XML policy
RDFpolicy
SQL policy
21
A possible research approach

• On the same code base
• Support SQL, XML, RDF, OWL, P3P, XACML policies
• Filter input (to mask sensitive values) vs.
  Reject
• Devise rich object metamodel and map it to SQL,
  XML
• Identify common abstractions for models of
• data (metadata, derived object, is-a, part-of, )
  
• security (delegation, revoke, limit privilege,
  session)
• Distinctions irrelevant to protection can be
  ignored
• Do cover all objects that SQL protects (e.g.,
  definitions)

22
How to support multiple security models?
DBMS Security
SQL security model
OWL sec. model
RDFsec. model
XMLsec. model

Abstract Data Model Containment, Derived
data, Mdata (in enough detail to drive
security)
Abstract Security Model Attach a policy to
objects General security, e.g., - Ownership
- Revoke or limit privilege
23
Contributions requiring expertise in security
heterog. db

• Many system challenges require federated query
  expertise
• Apply that technology to the security
  world(warning may be hard to publish)
• Map events, policies across heterogeneous
• Semantics
• Servers

24
Challenge 2 The Official Policy is not in terms
of implementation artifacts
Individually identified medical data shall be
available only to professionals treating the
patient, (with assurance profile P3)
?
Lab message Blood type
Firewalls Physical DB schemas
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
What data is medical, individually identified
Metadata, ontologies
For each implementation object
(e.g., lab test msg) Determine relevant
policies Translate policy thru data mapping
to execute on impl. object
Usermdata
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
AllergyTest request objects
Mental, undocumented
English Predicates
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 )

• Allow MedicalPerson, PurposeTreatment
  Assigned(PatientDescribed), MsgType LabTest

Decision-maker Policies
On AllergyTest and requests
Mental, undocumented
English Predicates
Capture once, document,use for all affected
objects
Automate translation
Enterprise knowledgeRelships among vocabularies
28
Transfer or compare policy horizontally across
organizations and systems
Aetna Travel Insurance Enforcement Application
server Policy applied US (NY) Roles HiPAA
spec (Aetna version)
?

• What data is
• Medical
• Indiv identified

• Who are
• Professionals
• Treating this patient
• Insurance approver
• role only in US

• Confidence in
• Technical measures
• Metadata admin
• Partners

Paris Hospital Enforcement DBMS Policy applied
France Roles Hospital (Emergency Care)
29
Today, policy engines receive a soup that
combines all stakes

• Location is in User.AreaOfResponsibility and
  Suspect.ThreatLevel high Traveler.Date lt 7
  days from today ((Suspect.CategoryDomestic
  Suspect.ThreatLevelhigh) or
  Suspect.CategoryForeign ) 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
  Travelers
• Policy Location is in User.AreaOfResponsibility
  and Suspect.ThreatLevel high
  Traveler.Date lt 7 days from today
  ((Suspect.CategoryDomestic Suspect.ThreatLevel
  high) or Suspect.CategoryFor
  eign) 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

Protect secrets (Suspect)
Privacy (Traveler)
Safety fence (Suspect)
31
Problems with todays approachesSummary
Users Request properties
Data and services to share

• All stakes combine in one big expression
• Need an access rule for each implementation
  object type
• Every decision must balance risk/reward
• Complex rule language

Context
Enforcement mechanisms
Different stakes
Knowledge of domain and organizational structures
32
Separations of concerns that one might support
Suspect join Traveler
? Policy typesPrivacySecrecy3rd party
(Intell. Prop) Throttles bans - alert user
-bandwidth
Detailed controls ? Coarse guarantees
(safety fence, e.g., ?????? clearance)
? multiple inputs, that raise different concerns
Need to know
Safety fence
Suspects Travelers (e.g., CIA, TSA)
33
Policy Administration Research Challenges--
Outline

• Foundational capabilities
• What has research contributed?
• Meta-level challenge Models that scale

34
Whats 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 attackers
  knowledge
• No collusion between requests from different User
  IDs
• Administrators have identified all sensitive
  fields
• Or its 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 cant be removed by more research!
• Spend for high certainty (locally), but
  partial solutions wont 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 (dont duplicate)
• Componentize
• Metrics for scalability

40
Requirements for scale-upSimplicity

• 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-upReach out, dont do it
all (1)

• Dont create own datatypes (time, space)
• Create a framework for plug-ins
• Dont 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-upReach out, dont do it
all (2)

• RBAC is a large silo. Its 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-upModularize

• Create clean abstractions, with multiple
  elaborations
• E.g., multiple coexisting ways to remove
  privilege
• Dont build silo modules by hardwiring one choice
  on each abstraction
• Where need new capability, make it available to
  all

44
Requirements for scale-upObjective 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

45
Right problems, wrong proposals

• Results were unready to transfer to developers
• Non-modular
• Reinvents non-security functionality, e.g., new
  query optimizers, temporal and spatial datatypes
• Need several difficult features at once
  (distribution, negatives)
• Useful functionality, but administration did not
  scale
• Semantics were filled with special cases (e.g.,
  Deny)
• Features not reconciled with full SQL
• Often created for middleware policy engines
• Unknown interactions with view and metadata
  security, trigger semantics,
• Excellent problems for a beginning researcher

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
• Its 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 dont 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) lt
LegalAge(Hospital. State, Purpose) then
RejectAudit
Medicaid_Approved (app server)
Hospital (document server)
Person (relational DB)
Heterogeneous enforcers, each has own policy
language Policy may reference confidential data
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!