Security of Shared Data in Large Systems

1
Security of Shared Data in Large Systems

• Arnon Rosenthal
• Marianne Winslett

Obtain slides at http//dais.cs.uiuc.edu/pubs/,
or from speakers USB devices
2
Agenda

• Introduction
• History, and an attempt to diagnose what
  inhibited technology transfer
• Where we are, where were going
• Challenge problems appetizer
• Security basics
• State of the art and open problems
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

3
This tutorial is unusual

• We want to help researchers move into this area,
  and produce results with broad impact
• Most tutorials teach you about the state of the
  art
• Our main goal is to describe open problems
• Securing large systems and large information
  structures (databases, middleware objects,
  document bases)
• From n-tier to emerging
• Security problems where data management skills
  are helpful
• General DB problems whose solutions
• help us improve security
• can benefit from security techniques
• We select problems for
• leverage with previous DB research and skills
• benefit to the most widespread DB applications

4
Disclaimers and notes

• Dont blame
• MITRE
• Blagojevich
• Some discussion of data security fundamentals
• Data (and application) security protects
  information (data and methods), rather than
  networks or software
• For general security, see the many fine books
  white papers
• More definitions references are in noteshidden
  slides
• We can elaborate the research directions, offline

5
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

6
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 from middleware or
  OS
• But cant use it in a view definition
• Filter query response based on row or column
  security labels (described later)
• Security for new features added to SQL
• Triggers, nested tables, objects, procedures
• But approach could use improvement

7
Which additions owed a debt to data security
researchers?

• Why were we unable to help vendors (enterprises)
  improve this (now-critical) aspect?
• Vendors interest in security was mild (but
  nonzero)
• Too few ideas were worth transferring --- why?
• Do we respect the concerns of DBMS and tool
  vendors?
• Compatibility with the past
• Manageable size for each extension
• Robust basis for extension (clean rigorous
  semantics)
• Interact well with all other features
• These generate neat research issues, too

8
Wrong problems

• Unrealistic fail the giggle test, even long
  termWithout laughing, describe a full scenario
  where customers might pay -- buy the software,
  capture system descriptions, specify policies,
• No mass need until many other features in place
• Examples
• Distributed db security relied on Deny to
  override Grant
• Prevent an adversary from inferring info they
  cannot access Enterprise must first protect
  individual columns! Also, document what an
  adversary knows, forbid anonymous access, be able
  to query past accesses.

9
Right problems, wrong proposals

• Results were unready to transfer to developers
• Non-modular
• Need several difficult features at once
  (distribution, negatives)
• Also include non-security functionality, e.g.,
  query, temporal and spatial datatypes
• Useful functionality, but administration did not
  scale, or semantics were not robust, 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

10
SQL security seems mature, but

• Here are some neatly delineated needs
• SQL2003 and RDBMSs need clean ways to
• Manage security for a distributed relational
  database (even with identical table definitions)
• Infer a users right to view a subset of the data
  in a way that is fully transparent to
  applications (views are not transparent!)
• Guarantee that administrators do not delegate
  excessive privileges
• Decentralize power appropriately (ownership, DBA
  roles)

11
Three big research challenges to whet your
appetite

• How can one DBMS best support multiple security
  models?
• Compile high level policies down to executable
  mechanisms
• Rewrite another systems policy in your own terms
• (Pink indicates a research problem that we think
  is important, and specific enough for real
  progress)

12
1. How can one DBMS best support multiple
security models?
DBMS Security
OWL sec. model
SQL security model
RDFsec. model
XMLsec. model
XML v.2

• Security should be uniform, and improvements
  should be available, across all data models

13
Challenges here

• Each has its own way of specifying security, and
  they are incompatible
• Theres still time to create a common basis!
• Try for clean extension of SQL, since it has 106
  installations
• Improvements should be available to all
• Applicable research metamodeling

14
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
15
2. Compile business policies to physical
implementation
Individually identified medical data shall be
available only to professionals treating the
patient, with medium-high confidence
?
Install policies on tables, documents

• Suitable
• data allocation
• execution plan

16
3. Translate, transfer policy across organization
and system boundaries
Aetna Travel Insurance Enforcement Application
server Policy applied US (NY) Roles HiPAA
(Aetna version)
?
Paris Hospital Enforcement DBMS Policy applied
France Roles Hospital (Emergency Care)
17
Common themes to these and other research
challenges

• Reduce workload and skill to administer policies
• Cope with heterogeneity
• In security info (formalisms, role sets,
  policies)
• In data (data model, schema, instances,
  semantics)
• Compare desired policy and actual result
• Trust in partners for policy specification and/or
  enforcement
• Cope with distribution, autonomy, evolution, but
  exploit favorable simpler cases

18
Agenda

• Introduction
• Security basics
• Desirable properties
• Getting there
• State of the art and open problems
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

19
General issues for any security property

• How to specify what can be done, and what side
  effects should be?
• Must be easy for user to specify, amenable to
  automated analysis
• Must be followed throughout datas life
  cycle/transformations
• Sticky policies work at IBM, elsewhere
• How to check compliance?

20
security basics Confidentiality

• Prevent information from going to the wrong
  recipient
• Not synonymous with privacy

21
security basics Privacy

• Parties ability to control use of info about
  them
• Normally associated with individuals (human
  right)
• Need not involve confidentiality
• E.g., includes ability to see and protest
  statements about yourself
• Controls may be based on purpose of usage (e.g.,
  medical research)
• Often one is protecting a third party
• Some privacy policies require notification that a
  request was executed
• Some systems require permission for each request
  (originator control). Pressure to deemphasize
  this inhibits sharing.

22
security basics Privacy

• Parties ability to control use of info about
  them
• Normally associated with individuals (human
  right)
• Confidentiality is just one aspect
• E.g., includes ability to see and protest
  statements about yourself
• How to specify what can be done with information
  about someone?
• Must be easy for user to specify, amenable to
  automated analysis
• Must be followed throughout datas life
  cycle/transformations
• Sticky policies work at IBM, elsewhere
• How to check compliance?
• Often one is protecting a third party
• Some privacy policies require notification that
  the request has been executed
• Some systems require permission for each request
  (originator control). Pressure to deemphasize
  this inhibits sharing.
• Treat private info as intellectual property
• Controversial unsuited to, e.g., police records

23
Privacy-preserving X harmfully blurs a useful
distinction

• Inhibits communication with conventional systems,
  privacy advocates
• Confidential info sharing is useful for
  proprietary info, with no privacy issues
• Privacy advocates include many other measures in
  their policy e.g., must notify

Confidentiality
Privacy
24
security basics Integrity

• Ensuring data is right
• Definitions of right in different communities
• System Security Not changed inappropriately
• E.g., tamper-evident signed message digests
• IT Security Produced appropriately Biba,
  Clark-Wilson
• IT Data quality
• DB Satisfies all relevant constraints
• E.g., ACID transactions, key constraints
• Related issues trust
• Too rarely all considered together

25
security basicsTrust data provenance

• Trust willingness to rely on an entity for a
  particular purpose
• Hot topic in open systems
• Trust in data depends on its integrity,
  freshness, accuracy, provenance, its sources
  reputation and objective properties, etc.
• Data provenance is a hot issue for scientists and
  intelligence analysts (unfortunately, not Defense
  Secretaries and presidents)
• How can we integrate these concepts to specify
  and reason about the level of trust in a data
  item?
• Particularly interesting in the context of
  derived data and in information integration

26
security basics Authorization

• Can this party do this action on this object
• Some approaches to authorization policies
• Unix file system
• Role-based access control
• Attribute-based access control
• Security levels

27
security basics Intellectual property issues

• Easy case recipient cooperates, e.g., between
  government agencies
• Pass policy to recipient, in terms of objects the
  recipient understands
• IBM, others work on sticky policies
• Tough case adversary owns the machine
• Not necessarily about secrecy
• Goal cradle-to-grave control over access
• Not addressed in this tutorial

28
security basics Confidence

• Likelihood that desired security properties hold
• Relative to a threat model
• Some practices to judge confidence, and use it
• Certify reviewer announces their confidence in
  a description of system behavior
• Accredit executive decides that benefits exceed
  the risks

29
Agenda

• Introduction
• Security basics
• Desirable properties
• Getting there
• State of the art and open problems
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

30
security basics Uses of encryption, hashing in DB

• Usually part of the solution, never all of it
• Protects if files are stolen (via OS hack)
• Intellectual property, where adversary is
  holding the data
• Integrity of subsets of structured data (Merkle
  trees)
• Share only hashed version of information

31
security basics Access control and release

• Access control policy governs pull situations
• Bob wants to do an action on Alices object will
  Alice let him?
• Release policy governs push situations
• Assuming Alice has read an object, can she send
  Bob a copy?
• Used in government, and for proprietary info
  (mostly for read-only objects)
• Not independent
• Bob can Access ? Alice can
  Release to Bob

32
security basics Delegation

• Your declaration of when another party will be
  speaking for you / acting for you
• Most often one party grants a right to another
  party
• E.g., to perform a specific kind of action on a
  specific object
• Examples
• SQL with grant option unconditional delegation
  
• Verisign delegates right to create identity
  credentials
• Trust management languages offer conditional
  delegation Authorize(Arnie, Purchase)
  Authorize(Marianne, Purchase), Purchase.Amt
  100

33
security basics Enforcement, credentials

• Enforcement approaches
• Server routes all requests through a reference
  monitor (DBMS, application server, OS)
• Check when a boundary is crossed (usually
  physical) firewalls, gateways
• Can be very small server, hardware assisted, with
  high confidence for simple policies (e.g., filter
  for forbidden words, XML filtering)
• Credentials approaches
• Server holds them and checks (e.g., DBMS
  authorization)
• Mobile (single sign-on, trust management)

34
security basics How to decide if youre there

• Where is there?
• Decide what actions/states wrt your data are
  legitimate/forbidden (create your policies)
• Determine the likely threats
• Pick/develop technology to mitigate the risks to
  acceptable levels
• Consider implementation constructs resistance to
  known threats (e.g., data partitioning in case of
  machine takeover)
• Do a cost/benefit analysis
• Evaluate your proposed technology as follows

35
Evaluation criteria (for both researchers and
developers), 1

• Passes the giggle test (on cost/benefit)
• Usable
• No CS degree should be required of users or
  administrators
• Cheap enough
• Development effort, learning curve, admin
• Scalable
• To large numbers of objects, subobjects, actions,
  subjects, organizations, sites
• Analyzable
• Current state what a given subject/object can
  do/have done to it
• What-if queries determine effect of changes in
  advance

36
security basics Evaluation criteria, 2

• Flexible, extensible
• Rapid response to unanticipated emergencies,
  opportunities
• Modular/universal/orthogonal/ composable/compatibl
  e
• Applicable in many places, many futures
• Can others build on your solution (clean, high
  quality)?
• Rigorous (thorough)
• Behavior of foundational components should be
  fully captured by the model---hard to anticipate
  future uses
• If implementations leak info (e.g., about
  secret view definition), bring into the model
  by requiring release privilege

37
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Problem context (a reality check)
• SQL
• Privilege limitation
• Role Based Access Control (RBAC)
• Label-based access control
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

38
A common architecture each DB object belongs to
one server
SAP
PeopleSoft
Web Server
App. Server
other databases
39
problem contextPolicy administration in
enterprises

• Database security administration is often ignored
  
• 30 assign privileges to real users or roles
• 70 use DBMS security facilities only to permit
  access by a particular application
• Admin is too hard!
• Most of the 30 administer entire tables, not
  columns
• Packaged applications may move toward having a
  built-in security policy for the data they manage
• DBMSs are not the center of the policy
  administration universe
• Most researchers at SACMAT04 conference did not
  know the SQL security model
• Most policy is in middleware, which is not smart
  or fast with stored, structured data

40
problem contextScale

• SAP has 104 tables, GTE over 105 attributes
• A brokerage house has 80,000 applications, a US
  government entity thinks that it has 350K
• Admin and implementation require
• Automated help
• Massive delegation (within limits)
• Use broad generalizations, refine under pressure
• Beware in formal acquisitions, contractors often
  build to the letter of specifications, not the
  spirit

41
problem contextTesting accreditation bottleneck

• Testing and accrediting impose costly delays on
  adding new policies or technologies
• Design to minimize the amount to reaccredit
  retest, when policy or implementation changes
• Use an approved general model, and customize

42
problem context Policy administration in
enterprises

• 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
• Its a significant cost/delay to create detailed
  how to manuals simplicity!
• Single sign-on is greatly desired

43
problem context Management of security data

• We collect lots of security-related data
• Audit trails, surveillance video/camera, RFIDs,
  GPS, cell phones, electronic lock records, etc.
• How can we analyze it and assess its quality in a
  scalable manner?
• Relevant research mining patterns of normal/
  anomalous operation, metadata management,
  protection against alteration, privacy issues
• Not discussed much in this tutorial

44
Agenda

• Introduction
• State of the art and open problems
• Problem context
• SQL
• Privilege limitation
• Role Based Access Control (RBAC)
• Label-based access control
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

45
SQL security model overview

• Privileges on data objects (tables, columns),
  schema objects, stored procedures, triggers, more
  in the future
• grant on objectsto with grant
  option / right to delegate /
• A privilege must be supported by a chain from
  owner
• When grantor loses rights, revoke cascades. So
  DBA grants all?
• Delegation is only for privileges you have
• Object creator is owner, with full privileges
• Ownership cannot be transferred
• Metadata is visible iff user has some rights on
  the object
• Models for distributed trust, label security, XML
  security each proposes variations on these design
  choices

46
General observations on SQL 2003 security (
vendor extensions)

• From the start, simple and uniform
• Centralized databases stored the grants, enforced
  efficiently
• Specified in terms of low level operators or
  syntactic categories no helpful abstractions
• For analogous concepts, has 90 similar rules
• E.g., Procedures and Views differ a bit (Oracle
  invoker rights)
• Researchers help is needed for useful
  improvements, small and large

47
Some sources of admin pain

• Restriction mechanisms are poorly integrated
• Ordinary access controls (denial semantics only)
• Views that filter data
• Row labels that filter data
• Actions by middleware policy engines, firewalls,
  
• Issues include
• What objects they apply to
• Filter semantics versus Deny semantics
• Administration model (grant option)
• Integrate all these restriction mechanisms
• Provide choice of filter or deny in every
  case
• Enable analysis queries across modes
• Use grant option to control exceptions to label
  security rules

48
Build grad students musclesRework ownership

• Owner of container currently gets full rights to
  the contents!
• Owners real contribution was metadata and
  creating a container, not data content
• So why should they have full privileges?
• Allow any user (including owner) to move their
  rights to someone else
• Avoid cascading revoke
• Allow recipient to gain sole ownership
• Upon creation, transfer creators content and
  metadata privileges to domain administrators

49
Build grad students musclesControl metadata
visibility

• Select GoodCredit from Customer where
  scoringFunction(ZipCode, Age) 6789
• Devise a suitable model for metadata protection
• Protect business process info in view definitions
• Controlled browsing of catalogs by users who lack
  access to underlying data
• Requirements for the solution
• Minimize admin work
• Retain privileges that users have already granted
• Avoid loose ends (e.g., who may use each mdata
  item to enforce a constraint or rewrite a queries)

50
SQL view privilege ? the right to use
the view interface
Grant Read on Patient to Doctors
Grant Read on AdultPatient to LabTech
Application using view AdultPatient
Patient
AdultPatient Select where Age18
LabTech butnot Doctor
Application usingSelect from Patientwhere
Age65
not LabTech
51
Problem privileges are on view table, not base
data

• Create AdultPatient
• Select from Patient where Age 18
• Grant Read on Patient to Doctor
• Grant Read on AdultPatient to LabTech
• An application that retrieves Patients over 65
  must query
• Patient (if user is Doctor)
• AdultPatient (if user is LabTech)
• Doctor can phone DBA and get rights on
  AdultPatient tomorrow
• Automatic inference of Doctors privileges on
  AdultPatient makes sense only if Doctor is
  allowed to read the view definition for
  AdultPatient. SQL only lets Doctor see the view
  definition if Doctor has some right on the views
  contents.

52
Privileges on views Issues

• The theory is 80 known. Principle Grant
  privileges for actions you can detect could have
  been done anyway
• Interacts with metadata, distribution, ownership,
  
• Research issues for derived data
• Implement privilege inference efficiently
• Adapt the query optimizer to generate equivalent
  forms
• Can we safely add invoker rights?
• Dangerous if creator of procedure is not
  trustworthy, especially if invocation is
  transparent
• Parameterized views
• E.g., parameterized by pseudo-variable User or
  procedure calls
• Use as a step toward distributed security
• Federations, warehouses as views with autonomy
  issues added

53
Derived data, and beyondmore research tasks

• If query cannot be rewritten in terms of
  user-visible info, suggest an alternative query
  that the user can execute
• Explain to the user how it differs from what they
  requested
• This is a general problem in publish/subscribe
• Handle federation and warehouse (materialized)
  views, with minimum new semantics and
  implementation
• Autonomy is big issue control over security
  stops at organizational boundaries
• Build on SQL derived data, without requiring
  negative privileges (big, controversial add-on)
• Big meta-problem Create criteria for comparing
  proposed facilities simplicity
• Principled comparison of model features (easier
  than HCI study)

54
SQL standard needs a more manipulable
specification

• SQL execution semantics spec is awkward
• Described by a recursive, tuple-level
  interpretation
• Execution semantics should determine what
  privileges are needed for a complex statement
  (e.g., involving views, nested tables)
• Instead, the standard gives a separate algorithm
  to determine the privileges
• Opacity and size make it hard to
• Extend security to new SQL features
• Connect to other languages or security models
• Analogy monolithic 1990 query optimizers were
  given a principled transformational model

55
Build grad students muscles Abstract models for
SQL

• Help restate the standard ( vendor products), in
  a way that enables easier extension, integration
• Describe query/update execution semantics in a
  way that shows what operations may be executed
• Use it to explain needed privileges
• Rewrite statements on views as SQL statements on
  underlying tables
• Use abstract concepts, e.g., contains, is-a,
  derived object (perhaps from object models)
• Compare with constructs in other models

56
Use ontological information in defining security
policies

• Extend the relational data model so that we can
  apply security to a whole class of information
• E.g., define a general access control policy for
  patient medical info rather than for
  Records.bloodtype, for Records.height,
• Base on ontologies
• Particularly useful when a rich policy language
  is available (discussed later)
• The same themes arise with role research, XML

57
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Problem context
• SQL
• Privilege limitation
• Limit ordinary privileges
• Limit what can be delegated (and in what
  circumstances)
• Role Based Access Control (RBAC) skip
• Label-based access control
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

58
Privilege limitation constructs are needed in
many models

• Want limits on many privileges, especially grant
  option
• Provide guarantees that an event/state wont
  occur
• Decentralized admin ? greater risk of admin error
  (1/2 truth?)
• Quickly turn something off (or on)
• Disgruntled former employee activates Trojan
  horse
• Extra privileges needed instantly, for an
  emergency
• Attach a predicate to execution or delegation
• Only Accountants can update FundsTransfers
• Junior Accountant can do if
• Transfers over 1M can only be granted via
  on-site access by a person in the originating
  department
• Devise an elegant, scalable facility
• Integrate with revocation, views, granules,
• Concepts, analyses, and displays to make the
  state understandable

59
Denials and delegation
Holmes
UK
EU
Bond (role spy)
Clouseau
France
Maigret

• Hard to understand due to override, multiple
  granularities
• Global negatives conflict with decentralized grant

60
Delegation an denials (with predicates)
Holmes
All examples are With Grant Option EU Strong
Grant Read Table3 to UK, France UK Strong
Grant Read Table3 to Holmes, Bond Fr Grant
Read Table3 to Clouseau, Simenon EU Deny Read
Table3 Price to Spy EU Strong deny Read
Table3 to Holmes UK Deny Read Table3 Capacity
to Clouseau??
UK
EU
Bond (role spy)
Clouseau
France
Maigret

• Hard to understand due to multiple granularities,
  override
• Global negatives conflict with decentralized grant

61
Kinds of negative permissions

• Global Deny (asserted/revoked as grants),
  sometimes with predicates, overrides
• Violates delegated administration?
• Can administrator understand the state?
• Local Deny (w.r.t. a given grant)
• Privilege factors separation of concerns among
  collaborating administrators (Semi-static,
  organization-friendly)
• Attach predicates to privileges (or denials)
• Revoke
• Test of uniformity is it an extreme case of
  privilege limitation?

62
Privilege factors enable collaboration
Entire privilege
Info factors
Execution factors
Safety Fence
Payment
Property
Isolate
Safety Fence
Workload
Privacy
Parent is satisfied if all children are satisfied
63
Denial versus safety fences

• Compare pragmatics of denial-based approach and
  safety fence factors
• Safety fence only accountants can make purchases
  over 1K, only researchers can see scientists
  notes
• Weak/strong denials
• Criteria (in rough order)
• Ease of administration (learning curve admin
  effort at small/large scales)
• Expressiveness and flexibility (suiting the
  needs)
• Ease of implementation by vendors, in various
  architectures (e.g., policy mgmt system downloads
  grants to DBMS)
• Efficient implementation
• Efficient implementations of the best

64
Other open problems in privilege limitation

• Compare privilege factors/denials with a
  trust-management-based approach to the same
  problem
• Extend to heterogeneous environments
• E.g., one system has denial approach, other has
  safety fences, how to combine them when
  integrating the two systems?

65
References on privilege limitation

• Detailed survey identifying alternatives Ose
  Hagstrom, S. Jajodia, et. al.
• Negative privileges (samples) Jonscher
  Dittrich, Jajodia, Bertino,
• Some include predicates
• Local negatives Rosenthal Sciore 00
• Privilege factors Rosenthal Sciore 99, 04, 05

66
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Problem context
• SQL
• Role Based Access Control (and beyond)
• Label-based access control
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

67
Role-Based Access Control basics

• Group set of users, e.g., Clerk, Accountant
• Role set of privileges, e.g., needed to process
  travel expenses
• Single user is a group. Single privilege is a
  role.
• Can assign group to group, group to role, role to
  role (edge in the graph)
• Path implies has privilege (if role is
  activated)
• Benefit Aggregates users (privileges) that are
  somehow similar, so one decision applies to the
  set.

68
Group/role graph
Groups
Roles
Users
Privileges
Reduces admin labor Decentralizes admin across
organizations
69
Two guidelines for thinking about RBAC

• Security policy is hard, inevitably a tradeoff.
  Minimize the need to make it!
• Treat each group, each role as just a definition
• Create a clear membership criterion for new
  arrivals, suited to routine
• Now, authorizing a group for a role is the only
  real security decision
• The distinction between groups and roles is
  essential for admin, minor for enforcement
• Debates are confused, because both sides are right

70
Group/role graph
Groups
Roles
Users
Privileges
71
Roles in standard SQL

• Roles, groups are treated uniformly, as nodes
• Grant nicely handles creation of each sort of
  edge (e.g., grant group to user, role to group,
  privilege to role, role to role, or group to
  group)
• Authorization is based on identity (role)
  attached to session, not to user
• User identity is still available (e.g., for
  audit)
• One explicitly activated identity (role) at a
  time
• For privileges granted from a role
• Any role member can revoke privileges granted
  from that role
• Privileges granted from a role stay intact when
  the granting individual disappears. But
• Not all privileges are granted from roles
• Roles disappear (e.g., reorganization)

72
RBAC (and follow on)

• Role engineering What should the groups and
  roles be? (Clustering attempted)
• Mine the existing workload, to suggest good
  roles, groups, and privilege assignments
• Policy admin Which groups should get which
  roles(generalizes Which user gets which
  privilege?)
• Infer logically, mine similar workloads to reduce
  effort
• Elegant models needed!
• Explain why a model is good, according to clear
  criteria
• Be minimal, formalized enough to be analyzable
• New feature? New paper! No!
• Issues from earlier sections still apply
  Ownership, privilege limitation, use of
  ontologies in policy specification,

73
Attribute Based Access Control

• Parameterized roles define other relevant user
  attributes, and allow predicates over all. But
  they have a unique distinguished Role attribute
  
• Problems
• Unnecessarily asymmetric Analyst in Sales
  Department---which is the role?
• Several attributes can have hierarchy (e.g.,
  task, job-title, organization)
• Some attributes are not role-like (e.g., user
  location) or not associated with the user (e.g.,
  time of request submission)
• Attribute-based access control policy can be any
  predicate over any attributes
• e.g., roles, groups, where/when submitted,
  alert-level, approvals

74
ABAC research issues

• No formalized delegation models yet
• Goal delegate each attribute separately
• Integrate with trust management
• ABAC should have privilege inference rules
• E.g., for contained objects, views
• Improve pragmatics
• Administrative tools (discussed later)
• Give policy engines easy access to attributes
  from many sources
• E.g., DB, directory, attached to request

75
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Problem context
• SQL
• RBAC
• Label-based access control skip
• Policies as a unifying framework
• Research issues and opportunities in example
  applications

76
Mandatory versus discretionary security

• A party who possesses an object cannot
• Release it to arbitrary others
• Change the policy
• Policy is often inherent in object label
• E.g., Top Secret, Proprietary
• Discretionary owner and owners delegates can
  change the access rights
• Although controls over arbitrary delegation can
  be useful, to limit eventual spread of rights

77
A mandatory policy multi-level secure databases
(MLS)

• Read allowed if dominated SessionLabel ?
  ObjectLabel
• Public aspirin .1
  .5 .23
• Proprietary aNewDrug .6 .9 .85
• Public aNewDrug .6 .9
  .85
• Write allowed if ObjectLabel ? SessionLabel
• Cannot put high data where low sessions can
  read it
• Prevents inadvertent mistakes by programmers
• Protect against malicious user or Trojan Horse
  no info can leak
• For high confidence, must also restrict export
  from user program
• Inadvertent writes without needed labels
• Enforces hierarchical rules even if administrator
  is careless

78
High confidence MLS DBMSs were rejected! Why?

• Meta-problem initiative by security and DBMS
  experts
• Applications developers concerns not met!
• Need MLS environment top-to-bottom network,
  operating system, DBMS
• Real-world business processes often need
  exceptions to MLS rules
• Validating strength of protection took years
• The whole environment became obsolete
• Especially the application development tools
• Result Program managers resisted the mandate
• Researchers had fun with exotic threats, while we
  were needed on the basics, above

79
Market drivers for commercial label-based access
control

• First killer app application hosting
• Independent franchises share a single table at
  headquarters (e.g., Holiday Inn)
• Application runs under requesters label, cannot
  see other labels
• Its Read and Write operations on the shared table
  are quite safe
• Headquarters runs Read queries over them
• Aim also at protecting proprietary data
  consolidated from many sources
• E.g., at a government agency or system
  integration contractor
• Oracle has excellent white papers. But little on
• How the policy scales (can one represent complex
  data sharing arrangements without label
  proliferation)
• Implementation techniques (hint view-like)

80
Commercial label security

• Guarantees that application uses parameterized
  view, with right parameters
• Runs in normal environment
• Applies only to tables declared as labeled
• Conjunction with ordinary SQL security
• Finer grained than table privileges
• Transparent to user code, but changes semantics
• Applies only to direct DB writes (and
  downgrading/writedowns are easy)
• Some tables arent labeled, anyone can write into
  them
• OS is not MLS can write files, send email,

81
Oracle Virtual Private Database

• SessionLabel, ObjectLabel are tuples of atoms,
  e.g., (Secret, Manager, heart, blood) see
  Oracle website
• Ordered slots Unclassified, , Secret, Top
  Secret
• Group slots (management hierarchy, projects, )
• Unordered slots (compartments)
• Implementation system creates, manages views
• Admin declares a table as labeled (system adds
  label column)
• System generates labels on insert
• System rewrite users action, to apply only to
  the view
• For performance, tweak the query optimizer
• Semantics are returned filtered result, not
  reject

82
Difficulties

• Views filter semantics are dangerous if
  unexpected by the application. Denial may be
  safer
• Select Drugs for this patient that conflict with
  foo (but patients AZT usage is secret)
• Select FriendlyTroops near TargetLocation
• Explain the shortfall due to filtering
• Explain changes to user (assuming user is in the
  loop)
• Determine the effect on legacy applications. Are
  they still safe?
• Rows may not be the most natural units for
  labeling
• Cells within the row may differ in sensitivity

83
Research issues in label security

• Support both filtering and deny semantics?
• Manage structured, audited exceptions
  (downgrading)
• Integrate access controls with audit?
• Use SQL grant option for exceptions?
• Indexing and query optimization for row, column,
  cell labels
• Too slow to first filter, then merge
• Oracle said labels were too slow until query
  processor was tweaked
• Allocate (partition) data to provide sufficient
  confidence
• Partition data among rows, tables, DBMSs,
  machines, networks
• What metrics, to drive the data allocator

84
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas

85
What is a policy?

• A statement regarding who/what is allowed/
  required/forbidden to take what actions, when and
  where, with respect to whom/what objects
• May also describe what happens after the action
  is taken, or if the policy is not followed
• May be stated in terms of abstract security
  properties such as availability, privacy, etc.
• A consistent set of assertions a system view must
  satisfy
• System view may be partial, include history, and
  future (obligations)
• Constraints, obligations are nondeterministic
  policies

86
Example policies for access control,
authentication, info release

• EMTs can access blood type info in the ambulance
• Every patient can read their own medical record
• Physicians have dial-up access to medical records
• Nurses cannot examine billing information
• Hospital administrative staff can modify policies
• Purchase transactions over 1000 require 2 forms
  of authentication (retina scan, employee ID,
  passport)
• Asserted behavior can depend on many attributes
• User, operation, role, object type, object
  attributes, where submitted, when submitted,
  trust
• Policys action may include denial, filtering,
  notification, penalty,
• Policies are requirements, and have the whole
  gamut of software engineering issues (details
  later)

87
Policies for obligations

• Obligations actions that must be performed if a
  certain event occurs. These are constraints on
  the future.
• May be able to audit what obligations were never
  executed
• Like aspect-oriented programming, weaving many
  obligations into an executable may be challenging
  
• Familiar Event-Condition-Action rule issues
  ordering, execution context, response to failure,
  
• Examples
• If a patient reads their record, this event must
  be logged
• SIGMOD Treasurer must present a report on
  finances at each SIGMOD conference
• Hot in AI community via deontic logics
• KAoS, REI projects for semantic web

88
Policies limiting allowable system
states/transitions/implementations

• X may happen only if
• Checking account balance must be nonnegative
• Checking account balance can only drop below zero
  if customer has overdraft protection or manager
  approves it
• A constraint on some portion of the possible
  database state trajectories, at some level of
  abstraction
• No employees salary can be reduced
• A constraint on allowable system implementations
• E.g., highly proprietary data must be firmly
  protected, Firmly on systems that only drug
  researchers can access Firmly encrypted
  with secure key management

89
Security policy chaos in todays n-tier systems
Authenticate
Application Server(e.g., WebSphere, WebLogic)
Order
Product
Bill
Ship
Sell
Buy
Databases (tables/docs)
View/ proc
90
Problems with building policies into applications

• Do you really trust all your applications to have
  the right policies?
• What do you do when you want to change your
  policies? (You may not even own the
  applications)
• What do you do when your manager asks, what are
  our security-related policies?
• How can you analyze your policies?

91
Gather into policy space one server
Authenticate
Application Server(e.g., WebSphere, WebLogic)
Order
Product
Policy Server
Bill
Ship
Sell
Buy
Databases (tables/docs)
View/ proc
92
Where are policies captured and enforced today?

• They tend to stay in one place
• Captured for a database, app server, or policy
  server, in terms of objects that server knows
• Enforced there
• Desired scenarios
• Capture in server, enforce redundantly in client
  GUI (better interactive behavior)
• Capture at one server, but delegate enforcement
  to elsewhere
• E.g., ACM delegates to SIGMOD the task of
  ensuring adherance to its guidelines for
  in-cooperation conferences

93
Example enforcement points, objects in
decentralized systems
Let restriction be enforced wherever it is best
handled
94
Traditional concept of subject in decentralized
systems

• Assumption I already know you

95
Inability to define subject/object/ action by
arbitrary predicates

• Makes decentralized security admin difficult
• Often requires knowledge of all subjects, mapping
  an identity to a role
• Can make abstract policies hard to specify
• No way to talk about subjects attributes not
  already known to the system
• Hinders resource sharing/access across
  organizational boundaries

96
Abstraction in policies examples

• Subjects
• Residents of California over 21 years of age
• Parents and legal guardians of children enrolled
  in King School
• Purchasing agents of the University of Illinois
• Objects
• Anything containing the SSN 123456789
• Anything about underground democracy movements in
  country xyz
• May require IR techniques to identify
• Any file in any subdirectory of this directory
• Actions
• Sending email, FTP, GET/POST requests, IP packet
  transmission, queries, invoking a method,
• Push systems release control policy for
  object to be pushed to subject (see next slide)
• Actions triggered by the user request (including
  actions of the security system itself)

97
Making policies more abstract

• Describe policies
• At all levels of a system
• For all kinds of subjects, objects, and actions
• At least DBs, formatted messages, service calls,
  general documents
• From administrative and implementation viewpoints
• Specify each of subject/object/action in more
  declarative language (e.g., queries, views,
  datalog, OWL)
• More detail in trust management section
• Hot in AI community for semantic web

98
Policy analysis

• Administrator needs help to analyze policies
• Show me all the policies that definitely/possibly
  apply in this situation
• With the current set of delegations, are users of
  this type definitely able to perform this action?
  
• Who can potentially obtain the right to perform
  this action (via delegation from untrusted
  users)?
• What if questions
• When is inference tractable?
• Basic questions are undecidable in traditional
  HRU model. Even simpler ones are NP-hard
• Help user with policy constructs that break the
  inference engine
• Metaquestion can the underlying theory support
  convenient admin?
• E.g., how does stratification (for clear
  semantics) affect admin?

99
New application domains that need security policy
services

• Pervasive computing
• Sensor, mobile, wireless, and ad-hoc networks
• Semantic web, peer-to-peer systems, grid
  computing
• Security and privacy for these applications are
  open areas for research
• Arnies rebuttal Above are for wimps, the easy
  cases.
• We desperately need to simplify our existing
  mega-systems. And there are plenty of open
  problems in those existing systems.

100
Agenda

• Introduction
• Security basics
• State of the art and open problems
• Policies as a unifying framework
• Security issues and opportunities in example
  application areas
• Trust management in open systems
• Trust middleware
• Open problems
• Semantic web and XML
• Enterprise security

101
Motivation

• DBMS access controls are a small part of the
  overall security picture
• Enterprises control access largely in middleware
  policy engines
• Often associated with application server or web
  server
• Engines support arbitrary, richer policy
  languages
• Typical approach give an application (e.g.,
  payroll) full access to all the tables it needs,
  and let the application or app server enforce the
  complex access control policies

102
Put policies in middleware

• Middleware at app server knows policies and
  enforces them uniformly across applications
• Policies are gathered together in one place
• Policies may be written in a declarative
  language, making them easier to understand and
  analyze
• Easy to control who can change policies
• XACML allows many policies, with a conflict
  resolver

103
Typical middleware policies (with DB other
servers)

• Policies are very complex
• Who can do what to an object depends on the
  objects lifecycle attributes (creator, stage)
  and values
• Views are insufficient to implement policies
• Getting policies right (bug-free) is very hard
• Getting policy right is critical when system is
  accessed by strangers you cant punish
• Third party vendors sell and maintain policies
• Analyzability is not guaranteed, especially
  across multiple middleware providers

104
Motivation move toward open computing systems

• Open resources shared across organizational
  boundaries
• Ability to rapidly form relationships, cooperate
  to solve urgent problems is vital
• Requires unanticipated sharing
• Supply chain management, crisis response,
  peer-to-peer computing, semantic web, grid
  computing, cross-national military activities,
  joint corporate ventures

105
Current DB app trust middleware is awkward in
open systems

• Management headaches
• No abstraction at user (subject) level
• E.g., clothing vendor has to set up a separate
  login for each Walmart authorized purchaser
• Managing passwords is 1 help desk call
• High turnover in suppliers/users/customers
• What happens when an authorized purchaser is
  fired?
• Error handling may be opaque

106
Whats missing

• Traditional security describes monolithic
  building blocks
• Does not help in attaching separate blocks
  together to build a global perspective in
  distributed situations
• Distributed trust management, an emerging
  technology,
• Gives a box of Legos and a language (usually
  Datalog constraints) for connecting building
  blocks together
• Key goals of work on supporting modular,
  distributed, decentralized trust management
• Make it easy to use and administer
• Provide improved security and privacy
• Make it ubiquitous
• Facilities available to all types of parties
• Wherever they are
• Whatever they might be doing
•  

107
What might they be doing?

• Any sort of access to large-scale data
  repositories
• Financial transactions
• Purchases, auctions, account management
• Viewing/sending sensitive documents
• Medical records, military data
• Registration
• School, voting, passports, marriage license,
  visa, library card
• Government and business
• Adoption, citizenship, work permit, joint
  ventures

108
Ingredients for generalized trust middleware, 1

• Credentials, so subjects can prove what
  attributes they possess
• Verifiable, unforgeable
• Provide way to prove ownership or delegation of
  authority to use
• Party receiving a credential
• Read and interpret fields (ontologies)
• Verify ownership
• X.509, PKI and beyond

109
Ingredients for generalized trust middleware, 2

• Policy, e.g., for acceptable credit cards for
  purchases
• Acceptable issuers (VISA, MasterCard)
• Require ownership/delegation to be demonstrated
• Check for expiration
• Contact card issuer
• Revocation, credit limit
• More generally, an access control policy (and
  possibly other policies) for every resource that
  a stranger might be allowed to access

110
Ingredients for generalized trust middleware, 3

• Ability to export policies
• A stranger may need to understand them to gain
  access to my resources
• E.g., which credit cards does this merchant
  accept? What will I require from the merchant?
• Trust negotiation software to control the process
  of gaining trust

111
Example use of trust negotiation middleware in
e-commerce
Bob
Alice
112
Example policy in Cassandra
Treating-clinician reads patients record item
permits(cli, Read-record-item(pat, id))
? hasActivated(cli, Clinician(org,
spcty)), canActivate(cli, Treating-clinician(pat,
org, spcty))), count-access-denied-by-patient(0,
(pat,id), (org, cli, spcty)), Get-EHR-item-subje
cts(pat, id) ? Permitted-subjects(spcty) Prerequi
site for Treating-clinician canActivate(cli,
Treating-clinician(pat, org, spcty))
? org.canActivate(cli, Group-treating-clinician(p
at, group, spcty)), org_at_ra.hasActivated(x,
NHS-health-org-cred(org, start, end)), ra ?
NHS-registration-authorities( ), Current-time( )
? start, end Source http//www.cl.cam.ac.uk/use
rs/mywyb2, encoding UKs Electronic Health Record
policies
113
Trust middleware for release policies

• Problem
• Sensitive content is frequently generated
  dynamically, making it difficult