Security of Shared Data in Large Systems - PowerPoint PPT Presentation

1 / 144
About This Presentation

Security of Shared Data in Large Systems


SQL security seems mature, but ... Here are some neatly delineated needs ... and intelligence analysts (unfortunately, not Defense Secretaries and presidents) ... – PowerPoint PPT presentation

Number of Views:191
Avg rating:3.0/5.0
Slides: 145
Provided by: arnonrosen


Transcript and Presenter's Notes

Title: Security of Shared Data in Large Systems

Security of Shared Data in Large Systems
  • Arnon Rosenthal
  • Marianne Winslett

Obtain slides at http//,
or from speakers USB devices
  • 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

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

Disclaimers and notes
  • Dont blame
  • 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
  • We can elaborate the research directions, offline

What practitioners need from the research
  • 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

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
  • Receive identity information from middleware or
  • 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

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

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.

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

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

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

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

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
  • Improvements should be available to all
  • Applicable research metamodeling

Security policy chaos in todays n-tier systems
Application Server(e.g., WebSphere, WebLogic)
Buy method
View/ proc
2. Compile business policies to physical
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

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)
Common themes to these and other research
  • Reduce workload and skill to administer policies
  • Cope with heterogeneity
  • In security info (formalisms, role sets,
  • In data (data model, schema, instances,
  • Compare desired policy and actual result
  • Trust in partners for policy specification and/or
  • Cope with distribution, autonomy, evolution, but
    exploit favorable simpler cases

  • 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

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
  • Sticky policies work at IBM, elsewhere
  • How to check compliance?

security basics Confidentiality
  • Prevent information from going to the wrong
  • Not synonymous with privacy

security basics Privacy
  • Parties ability to control use of info about
  • Normally associated with individuals (human
  • 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.

security basics Privacy
  • Parties ability to control use of info about
  • Normally associated with individuals (human
  • 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
  • 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

Privacy-preserving X harmfully blurs a useful
  • 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

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,
  • IT Data quality
  • DB Satisfies all relevant constraints
  • E.g., ACID transactions, key constraints
  • Related issues trust
  • Too rarely all considered together

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
  • Particularly interesting in the context of
    derived data and in information integration

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

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

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

  • 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

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
  • Share only hashed version of information

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

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
  • 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
  • Trust management languages offer conditional
    delegation Authorize(Arnie, Purchase)
    Authorize(Marianne, Purchase), Purchase.Amt

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
  • Mobile (single sign-on, trust management)

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

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

security basics Evaluation criteria, 2
  • Flexible, extensible
  • Rapid response to unanticipated emergencies,
  • Modular/universal/orthogonal/ composable/compatibl
  • Applicable in many places, many futures
  • Can others build on your solution (clean, high
  • 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

  • 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

A common architecture each DB object belongs to
one server
Web Server
App. Server
other databases
problem contextPolicy administration in
  • 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
  • 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

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

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

problem context Policy administration in
  • 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

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

  • 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

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

General observations on SQL 2003 security (
vendor extensions)
  • From the start, simple and uniform
  • Centralized databases stored the grants, enforced
  • 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

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
  • Enable analysis queries across modes
  • Use grant option to control exceptions to label
    security rules

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

Build grad students musclesControl metadata
  • 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)

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
AdultPatient Select where Age18
LabTech butnot Doctor
Application usingSelect from Patientwhere
not LabTech
Problem privileges are on view table, not base
  • 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

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
  • Can we safely add invoker rights?
  • Dangerous if creator of procedure is not
    trustworthy, especially if invocation is
  • 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

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
  • This is a general problem in publish/subscribe
  • Handle federation and warehouse (materialized)
    views, with minimum new semantics and
  • 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)

SQL standard needs a more manipulable
  • SQL execution semantics spec is awkward
  • Described by a recursive, tuple-level
  • 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

Build grad students muscles Abstract models for
  • 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

Use ontological information in defining security
  • 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

  • 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
  • Role Based Access Control (RBAC) skip
  • Label-based access control
  • Policies as a unifying framework
  • Security issues and opportunities in example
    application areas

Privilege limitation constructs are needed in
many models
  • Want limits on many privileges, especially grant
  • Provide guarantees that an event/state wont
  • Decentralized admin ? greater risk of admin error
    (1/2 truth?)
  • Quickly turn something off (or on)
  • Disgruntled former employee activates Trojan
  • Extra privileges needed instantly, for an
  • 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
  • Devise an elegant, scalable facility
  • Integrate with revocation, views, granules,
  • Concepts, analyses, and displays to make the
    state understandable

Denials and delegation
Bond (role spy)
  • Hard to understand due to override, multiple
  • Global negatives conflict with decentralized grant

Delegation an denials (with predicates)
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??
Bond (role spy)
  • Hard to understand due to multiple granularities,
  • Global negatives conflict with decentralized grant

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,
  • Attach predicates to privileges (or denials)
  • Revoke
  • Test of uniformity is it an extreme case of
    privilege limitation?

Privilege factors enable collaboration
Entire privilege
Info factors
Execution factors
Safety Fence
Safety Fence
Parent is satisfied if all children are satisfied
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
  • Weak/strong denials
  • Criteria (in rough order)
  • Ease of administration (learning curve admin
    effort at small/large scales)
  • Expressiveness and flexibility (suiting the
  • Ease of implementation by vendors, in various
    architectures (e.g., policy mgmt system downloads
    grants to DBMS)
  • Efficient implementation
  • Efficient implementations of the best

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

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

  • 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

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
  • Can assign group to group, group to role, role to
    role (edge in the graph)
  • Path implies has privilege (if role is
  • Benefit Aggregates users (privileges) that are
    somehow similar, so one decision applies to the

Group/role graph
Reduces admin labor Decentralizes admin across
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

Group/role graph
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
  • Authorization is based on identity (role)
    attached to session, not to user
  • User identity is still available (e.g., for
  • One explicitly activated identity (role) at a
  • 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)

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
  • Infer logically, mine similar workloads to reduce
  • Elegant models needed!
  • Explain why a model is good, according to clear
  • 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,

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

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

  • 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

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

A mandatory policy multi-level secure databases
  • Read allowed if dominated SessionLabel ?
  • Public aspirin .1
    .5 .23
  • Proprietary aNewDrug .6 .9 .85
  • Public aNewDrug .6 .9
  • 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

High confidence MLS DBMSs were rejected! Why?
  • Meta-problem initiative by security and DBMS
  • 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

Market drivers for commercial label-based access
  • 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
  • Implementation techniques (hint view-like)

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
  • OS is not MLS can write files, send email,

Oracle Virtual Private Database
  • SessionLabel, ObjectLabel are tuples of atoms,
    e.g., (Secret, Manager, heart, blood) see
    Oracle website
  • Ordered slots Unclassified, , Secret, Top
  • 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

  • Views filter semantics are dangerous if
    unexpected by the application. Denial may be
  • 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
  • Determine the effect on legacy applications. Are
    they still safe?
  • Rows may not be the most natural units for
  • Cells within the row may differ in sensitivity

Research issues in label security
  • Support both filtering and deny semantics?
  • Manage structured, audited exceptions
  • 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
  • Partition data among rows, tables, DBMSs,
    machines, networks
  • What metrics, to drive the data allocator

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

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
  • System view may be partial, include history, and
    future (obligations)
  • Constraints, obligations are nondeterministic

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,
  • Asserted behavior can depend on many attributes
  • User, operation, role, object type, object
    attributes, where submitted, when submitted,
  • Policys action may include denial, filtering,
    notification, penalty,
  • Policies are requirements, and have the whole
    gamut of software engineering issues (details

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

Policies limiting allowable system
  • 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
  • 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

Security policy chaos in todays n-tier systems
Application Server(e.g., WebSphere, WebLogic)
Databases (tables/docs)
View/ proc
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
  • What do you do when your manager asks, what are
    our security-related policies?
  • How can you analyze your policies?

Gather into policy space one server
Application Server(e.g., WebSphere, WebLogic)
Policy Server
Databases (tables/docs)
View/ proc
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

Example enforcement points, objects in
decentralized systems
Let restriction be enforced wherever it is best
Traditional concept of subject in decentralized
  • Assumption I already know you

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

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)

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

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

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

  • 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

  • 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
  • Engines support arbitrary, richer policy
  • 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

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
  • Easy to control who can change policies
  • XACML allows many policies, with a conflict

Typical middleware policies (with DB other
  • 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

Motivation move toward open computing systems
  • Open resources shared across organizational
  • 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

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
  • Error handling may be opaque

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

What might they be doing?
  • Any sort of access to large-scale data
  • 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

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

Ingredients for generalized trust middleware, 2
  • Policy, e.g., for acceptable credit cards for
  • 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

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

Example use of trust negotiation middleware in
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//
rs/mywyb2, encoding UKs Electronic Health Record
Trust middleware for release policies
  • Problem
  • Sensitive content is frequently generated
    dynamically, making it difficult
Write a Comment
User Comments (0)