Security of Shared Data in Large Systems - PowerPoint PPT Presentation

Loading...

PPT – Security of Shared Data in Large Systems PowerPoint presentation | free to view - id: 24d06-MmJmN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Security of Shared Data in Large Systems

Description:

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:130
Avg rating:3.0/5.0
Slides: 145
Provided by: arnonrosen
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com