UIUC 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
UIUC
1
Security of Shared Data in Large Systems
Arnon RosenthalMarianne Winslett
Obtain slides at http://dais.cs.uiuc.edu/pubs/, or from speakers’ USB devices
UIUC
2
Agenda
• Introduction– History, and an attempt to diagnose what
inhibited technology transfer– 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
UIUC
3
This tutorial is unusualWe 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
UIUC
4
Disclaimers and notes
• Don’t 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 and
white papers– More definitions & references are in notes and hidden
slides
UIUC
5What practitioners need from the research communityA 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]
UIUC
6What’s been added to DBMS security since 1980s• Roles, role hierarchies
– SQL role is a set of privileges or users– But industry did roles, DB researchers arrived after
• Receive “identity” information from middleware or OS– But can’t 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
UIUC
7Which 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?
• Simple, rigorous semantics, e.g.,– Few fundamental constructs– Few tricky feature interactions
• Compatibility with the past• Manageable size for each extension
These generate neat research issues, too
UIUC
8
Wrong problems• Inelegant – unlikely to yield clear insights
that may be useful in other situations• Unrealistic: fail the “giggle test”, even long term
Without 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– 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, documentwhat an adversary knows, forbid anonymous access, be able to query past accesses.
UIUC
9
Right problems, wrong proposals
Results were unready to transfer to developers• Non-modular
– Reinvents non-security functionality, e.g., query, temporal and spatial datatypes
– Need several difficult features at once (distribution, negatives)• Useful functionality, but administration did not scale • Semantics were filled with special cases (e.g., Deny)• Features not reconciled with full SQL
– Often created for middleware policy engines– Unknown interactions with view and metadata security, trigger
semantics, …
Excellent problems for a beginning researcher
UIUC
10
SQL lacks many essentialsSome (neatly bounded) extensions needed by SQL2003,
RDBMSs, and many other models• Manage security for a distributed relational database
(starting with identical table definitions, local autonomy)• Infer a user’s right to view a subset of the data,
transparent to application writers (views are not)• Guarantee that administrators do not delegate excessive
privileges• Decentralize power appropriately (ownership, DBA roles)• Abstract and modularize the specification of the
standard, so it can be extended safely and easily
UIUC
11Three “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 system’s policy in your own
terms
(Pink indicates a research problem that we think is important, and specific enough for real progress)
UIUC
121. How can one DBMS best support multiple security models?
SQL security model
DBMS Security
RDFsec. model
OWL sec.
model
OWL sec.
model XML
sec. model
How can security model be orthogonal to data model?
UIUC
13
Challenges here
• Each has its own way of specifying security, and they are incompatible
• There’s 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
UIUC
14Security policy chaos in today’s n-tier systems
Bill
Application Server(e.g., WebSphere, WebLogic)
ShipSellBuy method
Product Order
Authenticate
Databases (tables/docs)
View/ Proc
UIUC
152. Compile “business” policies to physical implementation
Individually identified medical data shall be available only to professionals
treating the patient, with medium-high confidence
Install policieson tables, documents
Suitable • data allocation• execution plan
?
UIUC
163. Translate, transfer policy across organization and system boundaries
Paris HospitalEnforcement: DBMSPolicy applied: FranceRoles: Hospital (Emergency Care)
Aetna Travel InsuranceEnforcement: Application serverPolicy applied: US (NY)Roles: HiPAA (Aetna version)
?
UIUC
17Common 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
UIUC
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
UIUC
19security basicsConfidentiality• Prevent information from going to the
wrong recipient• Not synonymous with privacy
UIUC
20security basicsPrivacy• Parties’ ability to control use of info about them
– Normally associated with individuals (human right)– May limit what is collected, as well as what is released– Need not involve confidentiality
• E.g., includes ability to see and protest statements about yourself– Often decide based on intended use (e.g., medical research,
active police investigation) rather than requester’s identity
• 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.
UIUC
21“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
UIUC
22security 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 (freshness, precision, provenance, …)DB: Satisfies all relevant constraints
• E.g., ACID transactions, key constraints• Related issues: trust• Too rarely all considered together
UIUC
23security 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 source’s reputation and objective properties, etc.– Data provenance is a hot issue for scientists and intelligence
analysts• 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
UIUC
24security basics
Authorization• Can this party do this action on this object
– Should there be a side effect (e.g., audit log entry, email notification,…)
• Some approaches to authorization policies– Unix file system– Role-based access control– Attribute-based access control – Security levels
UIUC
25security 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 accessNot addressed in this tutorial
UIUC
26security 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
UIUC
27
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
UIUC
28security 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
UIUC
29security basics
Access control and release• Access control policy governs pull situations
– Bob wants to do an action on Alice’s 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
UIUC
30security 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
UIUC
31security 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)
UIUC
32security basics
How to decide if you’re “there”1. Where is “there”?
– Decide what actions/states wrt your data are legitimate/forbidden (create your policies)
– Determine the likely threats2. 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 analysis3. Evaluate your proposed technology as follows
UIUC
33Evaluation 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
UIUC
34security basics
Evaluation criteria, 2• Flexible, extensible
– Rapid response to unanticipated emergencies, opportunities
• Modular/universal/orthogonal/ composable/compatible
– 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
UIUC
35
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
UIUC
36A common architecture: each DB object belongs to ~one server
Web Server App. Server SAP PeopleSoft
other databases…
UIUC
37problem contextPolicy administration in enterprises• DBs are not the center of the policy admin universe
– Few researchers at the Access Control conference (SACMAT04) really knew the SQL security model
• A policy must be conceptually near the resources it controls– Middleware knows application methods, e.g., Admit(Patient)– DBMS is smart, fast with structured info, consistent when there
are multiple paths to same datum• Database security administration is often ignored
– 30% assign privileges to real users or roles, mostly to entire tables
– 70% use DBMS security only to restrict each table to one app• Consider nontechnical fixes: Packaged applications may
move to a built-in security policy
UIUC
38problem contextScale• SAP has 10**4 tables, GTE over 10**5 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
UIUC
39problem contextTesting & accreditation bottleneckTesting 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
UIUC
40
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
• Administrators need training in both technology and judgment – making evolution costly and slow. Simplify!
• Single sign-on is typically the top priority, rather than policy specification
UIUC
41problem 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
UIUC
42
Agenda• Introduction• Security basics• State of the art and open problems
– Problem context– SQL– Role Based Access Control (RBAC)– Label-based access control
• Policies as a unifying framework• Security issues and opportunities in example
application areas
UIUC
43
SQL security model overview• Privileges on data objects (tables, columns), schema
objects, stored procedures, triggers, more in the futuregrant <list of operations> on <list of objects>to <list of identities>[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 objectModels for distributed trust, label security, XML security
each propose variations on these design choices
UIUC
44General observations on SQL 2003 security (+ vendor extensions)• At 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)
• Roles have been integrated well, labels less well
UIUC
45
SQL lacks many essentialsSome (neatly bounded) extensions needed by SQL2003,
RDBMSs, and many other models• Manage security for a distributed relational database
(starting with identical table definitions, assumption of local autonomy in granting privileges on local data)
• Infer a user’s right to view a subset of the data, transparent to application writers (views are not)
• Guarantee that administrators do not delegate excessive privileges
• Decentralize power appropriately (ownership, DBA roles)• Abstract and modularize the specification of the
standard, so it can be extended safely and easily
UIUC
46Build grad students’ musclesRework “ownership”• Owner of container currently gets full
rights to the contents!– Owner’s 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 creator’s content and metadata privileges to “domain” administrators
UIUC
47Build 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 m’data
item to enforce a constraint or rewrite a queries)
UIUC
48SQL view privilege ≡the right to use the view interface
Grant Read on Patient to Doctors Grant Read on AdultPatient to Researcher
Application using view
AdultPatient
Researcher but not Doctor
ApplicationusingSelect * from Patientwhere Age>65
AdultPatient = Select where Age>18
Patient
not Researcher
UIUC
49Problem: privileges are on view table, not base dataCreate AdultPatient =
Select * from Patient where Age > 18
Grant Read on Patient to DoctorGrant Read on AdultPatient to Researcher
An application that retrieves Patients over 65 must queryPatient (if user is Doctor)AdultPatient (if user is LabTech)
Doctor can phone DBA and get rights on AdultPatient –tomorrow
Automatic inference of Doctor’s 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 view’s contents.
UIUC
50Privileges on views and procedures (i.e., derived objects) • The theory is 80% known. Principle: Infer a privilege when you
detect that it does not increases user’s power– Interacts with metadata, distribution, ownership, …
• Implement privilege inference efficiently– Adapt the query optimizer to generate equivalent forms
• Handle federation and warehouse (materialized) views, with minimum new semantics and mechanism– Autonomy: control over security stops at organizational boundaries.– Negative privileges are a big, controversial add-on
Often a query will not be answerable from user-visible info. (This is a general problem in publish/subscribe)
• Suggest an alternative query that the user can execute, and explain how it differs from what they requested
UIUC
51SQL standard needs a moremanipulable 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 modelsAnalogy: monolithic 1990 query optimizers were given a
principled transformational model
UIUC
52Build grad students’ musclesAbstract 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 [RoSc04b]• 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
UIUC
53Use 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
UIUC
54SQL has multiple (unintegrated) ways to restrict access to a table• Restriction constructs• Ordinary access controls (“reject” 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 Reject semantics– Administration model (grant option)
• Integrate all these restriction mechanisms (and with privilege limits)– Provide choice of “filter” or “reject” in every case– Enable analysis queries across modes– Use grant option to control exceptions to label security rules
UIUC
55Privilege limitation constructs are needed in many models• Want limits on many privileges, especially grant option
– Provide guarantees that an event/state won’t 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 < $1000– 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
UIUC
56Delegation and denials (with predicates)
EU
UK
France
Holmes
Clouseau
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)
Maigret• Hard to understand due to multiple
granularities, override• Global negatives conflict with
decentralized grant
UIUC
57
Denials and delegation
EU
UK
France
Holmes
Clouseau
Bond (role: spy)
Maigret• Hard to understand due to override,
multiple granularities • Global negatives conflict with
decentralized grant
UIUC
58
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– A separate animal, or an extreme case of privilege limitation?
UIUC
59Help administrators collaborate:Decompose privileges
Privilege for “Display FrOB(Iraq)”
Info factors
Secrecy
Privacy Safety Fence
Execution factors
HackingSafety FencePerformance
Get an attribute if all children are satisfied or by direct assertionSimpler decisions, single skill, independently administeredChanges easily: When situation changes, review just that partSafety fence provides guarantees
UIUC
60
Denial versus safety fences• Compare pragmatics of denial-based approach
and “safety fence” factors– Reformulate as a trust management problem, with factors as
predefined attribute types
• Meta-problem: Define and apply criteria for comparing proposed facilities’ “simplicity”
• 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
• Implement the best admin models (once known)
UIUC
61
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]
UIUC
62
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
UIUC
63
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 whole set.
UIUC
64
RBAC group/role graphGroups
Roles
• Reduces admin labor• Decentralizes admin
Manager
Task MgrDept Mgr
DoDFFRDC
CIIS AFC WC3 …
Project Planning
CostingStaffing
Alice Bob Joe Jane
ReadSkillsAssign
Work
UIUC
65Aggregation techniques: Beyond groups and roles
Groups Roles Vehicle Session Security
Car HMV …
How far can the “graph” model go?- Grants that require multiple authorizations- Communities of mutual trust
Approvers
UIUC
66Unify reasoning about semantic aggregates (i.e., support “is-a” just once)
Intelligence about usage of hostile air defense facilities can be analyzed by operational planners with secure access
Who are “ops
planners”?
What ops are part ofanalysis? (Annotate?Color-map?)
Info ontology Group metadata
What are“air defense facilities”?
Role metadata
Detailed Authorizations
Which requestsare received“securely”?
Model of secure access
Which requestsare received“securely”?
UIUC
67Two 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
UIUC
68
Group/role graph
UsersGroups Roles
Privileges
UIUC
69
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)
UIUC
70
RBAC (and follow on)• Role engineering: What should the groups and roles
be? (determine appropriate clusters)– Mine the existing workload, to suggest “good” roles, groups, and
privilege assignments• Policy admin: Which groups should get which roles
(generalizes “Which users should get which privileges?”)– Infer logically, mine similar workloads to reduce effort
• Elegant models needed! – Provide clear criteria to explain why a model is good
• E.g., be minimal, formalized enough to be analyzable– New feature = New paper? More is better? No!
• Issues from earlier sections still apply: Ownership, privilege limitation, use of ontologies in policy specification, …
UIUC
71
Attribute Based Access Control• RBAC extensions are awkward
– Unnecessarily asymmetric: Analyst in Sales Department---which is the role?
• Several attributes can have hierarchy (e.g., task, job-title, organization)
– Parameterized roles define other relevant user attributes, and allow predicates over all. But they have a unique distinguished“Role” attribute
– 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 anypredicate over any attributes– e.g., roles, groups, where/when submitted, alert-level, approvals…
UIUC
72
Supporting technologies for ABAC
• Standards– Pass attribute assertions (SAML)
• [email protected] says Patient.BirthYear = 1984– For each action, attach predicates that reference
attributes (XACML)• Four valued propositional logic expressions• Connect actions to policies (with conflict resolution)
• Federated data perspective needed to get attributes to evaluators– CORBA specified a standard way to request an
attribute• Evaluator must know which server• Only pull
UIUC
73
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
UIUC
74Mandatory 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 owner’s delegates can change the access rights– Although controls over arbitrary delegation can be
useful, to limit eventual spread of rights
UIUC
75A mandatory policy: multi-level secure databases (MLS)• Read allowed if dominated: SessionLabel ≥ ObjectLabel
Public: aspirin .1 .5 .23Proprietary: aNewDrug .6 .9 .85Public: aNewDrug .6 .9 .85
• Write allowed if ObjectLabel ≥ SessionLabelCannot 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
UIUC
76High 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 toolsResult: Program managers resisted the mandate
• Researchers had fun with exotic threats, while we were needed on the basics, above
UIUC
77Market 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 requester’s 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)
UIUC
78
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 aren’t labeled, anyone can write into them– OS is not MLS – can write files, send email, …
• Manages views – no hassle over update, privileges
UIUC
79
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 user’s action, to apply only to the view– For performance, tweak the query optimizerSemantics are “returned filtered result”, not “reject”
UIUC
80
Difficulties
• Views’ “filter semantics” are dangerous if unexpected by the application. “Reject " may be safer– Select Drugs for this patient that conflict with foo
(but patient’s AZT usage is secret)– Select FriendlyTroops near TargetLocation
• Rows may not be the most natural units for labeling– Cells within the row may differ in sensitivity
UIUC
81
Research issues in label security
• Support both filtering and reject 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
– Precategorize potential implementations w.r.t. how much “confidence” they give
– Partition data among rows, tables, DBMSs, machines, networks
UIUC
82
Agenda
• Introduction• Security basics• State of the art and open problems• Policies as a unifying framework• Security issues and opportunities in
example application areas
UIUC
83
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
UIUC
84General issues for any security-related policy• How to specify what can be done, and what side
effects should be?– Must be easy for user to specify, amenable to
automated analysis• How to follow the policy throughout data’s life
cycle and transformations– E.g., sticky policies work at IBM, elsewhere; passing a
policy for a partner to enforce• How to audit compliance?
UIUC
85Example 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– Policy’s action may include "reject", filtering, notification, penalty,
…• Policies are requirements, and have the whole gamut of
software engineering issues (details later)
UIUC
86
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
UIUC
87Policies limiting allowable system states/transitions/implementations• X may happen only if <predicate> | <action>
– 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 employee’s 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 accessFirmly:= encrypted with secure key management
UIUC
88Security policy chaos in today’s n-tier systems
Bill
Application Server(e.g., WebSphere, WebLogic)
ShipSellBuy
Product Order
Authenticate
Databases (tables/docs)
View/ proc
UIUC
89Problems 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?
UIUC
90Gather into policy space: one server
Bill
Application Server(e.g., WebSphere, WebLogic)
ShipSellBuy
Product Order
Authenticate
Databases (tables/docs)
View/ proc
PolicyServer
UIUC
91Where 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
UIUC
92Example enforcement points, objects in decentralized systemsLet restriction be enforced wherever it is best handledProtocol Potential Sensitive Information
SOAP, J2EE method parameters and names
SMTP email messages, attachments
FTP transferred files
HTTP form data, headers, cookies, URLs
NNTP uploaded news posting
SQL, Google query, query response
UIUC
93Traditional concept of “subject” in decentralized systemsAssumption: I already know you
Not a member?
UIUC
94Inability 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 subject’s attributes not already known to the system
• Hinders resource sharing/access across organizational boundaries
UIUC
95Abstraction 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)
UIUC
96
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) rather than extensionally (by object identity or user identity)
• More detail in trust management section• Hot in AI community for semantic web
UIUC
97
Example policy in CassandraTreating-clinician reads patient’s 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-subjects(pat, id) ⊆ Permitted-subjects(spcty)
Prerequisite for Treating-clinician
canActivate(cli, Treating-clinician(pat, org, spcty))
org.canActivate(cli, Group-treating-clinician(pat, group, spcty)),
[email protected](x, NHS-health-org-cred(org, start, end)),
ra ∈ NHS-registration-authorities( ),
Current-time( ) ∈ [start, end]Source: http://www.cl.cam.ac.uk/users/mywyb2, encoding UK’s Electronic Health Record policies
UIUC
98
Policies as a basis for ABAC• Policies provide a way of describing what
attributes are required to perform an action• How to determine whether a user possesses an
arbitrary attribute mentioned in a policy?– Who “owns” the definition of that attribute?
• Semantic integration issues• Current solution approach: plan to leverage ontologies
– How to know when to push/pull an attribute?– How to know where to pull an attribute from?
• View as a federated DB problem• Will the solution scale?
– Discussed in more detail in a later section
UIUC
99
ABAC research issues• Trust management policy languages are logic-based
– Express/reason about arbitrary relationships, e.g., delegation– But logic is not user-friendly
• Needed: policy templates and methodologies for policy administration – Usable at enterprise, cross-enterprise levels– Appropriate expressiveness
• “This attribute value has been asserted, and here’s why you should trust it”
– Requires ability to formulate, reason about trust metrics– Internal DBMS support for these new security-related features
• Monotonic privilege limitation constructs to guarantee what willnever happen
• Simple delegation models, with revocation• Privilege inference rules, integrated with data ontologies, rules,
groups, derived data (views, procedures)
UIUC
100
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
– Get user help 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?
UIUC
101New 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
Arnie’s rebuttal: Above are useful, but are the easy cases, for wimps. For a big challenge:
Security research that simplifies mega-systems
UIUC
102
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
UIUC
103
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
UIUC
104
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
UIUC
105Typical middleware policies (with DB & other servers)• Policies are very complex
– Who can do what to an object depends on the object’s 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 can’t punish
– Third party vendors sell and maintain policies• Analyzability is not guaranteed, especially
across multiple middleware providers
UIUC
106Motivation: move toward open computing systemsOpen = resources shared across
organizational boundariesAbility 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
UIUC
107Current 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
UIUC
108
What’s 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 togetherKey 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
UIUC
109
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
UIUC
110Proposed trust middleware philosophy• Provide trust middleware facility hooks at all
useful boundary/request enforcement points– SMTP, TLS/SSL, FTP/GridFTP, IPSec, …
• Subject, object, action may not be traditionally delineated– Need to abstract the notion of all three: attribute-
based access control, IR techniques• Base everything on explicit policies
UIUC
111Ingredients 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
UIUC
112Ingredients 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
UIUC
113Ingredients for generalized trust middleware, 3
• Ability to export policies (to be read elsewhere, enforced elsewhere) – 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
UIUC
114
Step 1: Alice requests a service from Bob
Example use of trust negotiation middleware in e-commerce
Step 5: Alice discloses her VISA card credential
Step 4: Bob discloses his BBB credential
Step 6: Bob grants access to the serviceService
BobAlice
Step 2: Bob discloses his policy for the service
Step 3: Alice discloses her policy for disclosing her VISA
UIUC
115Trust middleware for release policies• Problem
– Sensitive content is frequently generated dynamically, making it difficult to associate release policies with the content in advance
– How to know whether recipient satisfies release policy for info?
• Solution approach– A (non-malicious) attempt to transmit sensitive data
generates appropriate policies dynamically, using IR techniques to determine the appropriate policies
• BYU TrustBuilder project
UIUC
116
SMTP-based trust middleware for release policies
UIUC
117Example use of trust middleware in phishing attacks• Definition:
“The mass distribution of e-mail messages with return addresses, links, and branding which appear to come from legitimate companies, but which are designed to fool the recipients into divulging personal authentication data”(www.antiphishing.org)
• “Up to 20% of recipients may respond to [the phishingattack], resulting in financial losses, identity theft, and other fraudulent activity.”(www.antiphishing.org)
UIUC
118
Phishing attack example
UIUC
119
Phishing attack example
UIUC
120
travis2004
*******
Possible URL spoofing attack:http://pages.ebay.com/reactivate[null]@steal_your_identity.com
Add filter on outgoing content, policy that logins/ passwords only go to the relevant site; automatic enforcement by trust negotiation middleware in TLS/SSL
UIUC
121
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– Enterprise security
UIUC
122Policy, credential capture and interpretation
• Expressive policy languages (details follow)
• Administrative tools and algorithms– Write, update, understand, and analyze (details follow) policies
• Standard schemas/ontologies for popular types of credentials and policies
• Efficient policy compliance checkers• First-class policies
– Search them, query them, …– Give them protection as strong as for any other resource
• Policy integration, translation, compilation (details follow)
• Verification of approaches to all the above in the context of particular applications
UIUC
123Needed policy language features for trust negotiation• Well-defined semantics• Monotonicity (sort of)
• Everything relational algebra can do, plus transitive closure
• Support for delegation• Clean integration with
reputation-based trust systems
• References to the local environment and external functions (e.g., time of day, current user)
• Explicit specification of authentication requirements
• Tractable for analysis
Datalog + constraints [Cassandra, RT], OWL (for its ontologies) are viewed as likely policy language choices in various research communities
–May have good complexity for analysis tools
UIUC
124
Monotonicity and outcallsPurely monotonic languages are not expressive
enough for trust negotiation– Do not want customer’s withholding of a credential
to increase their privileges– But need elegant handling of time, revocation
checks, …– Anything less than Turing-complete will require
outcalls (but must bound them, as analysis capability is vital)
For realism, language design needs to be application driven
UIUC
125Language features that will make policy engineering hard• Analyzability is critical. Don’t give it up by dropping
prematurely into low level, non-analyzable code• Positive and negative policies
– Can nontrivial conflict resolution scale?
• What side effects are allowed, and can they conflict? Synchronization?
– None, audit trail only, notification to user …
• What information can the policy reference?– User, ReferencedObject, Location, Time, other context properties– Arbitrary data sources– Other policies
• E.g., on when info can be trusted for use
• Expressiveness vs. predictability and speedReferences: IEEE Policy Conference (2/3 quality of service, 1/3 security)
UIUC
126
Trust middleware architectures
• Trusted third parties that are not vulnerable to attack
• Direct peer-to-peer– With disclosure of credentials/policies– Zero knowledge/hidden credentials/OSBE
UIUC
127
Obtaining and storing credentials
• How do I get them?• Where do I keep them, to keep them private?• How can I quickly find credentials I haven’t
cached already, during a negotiation?– Credential chain discovery, n-party trust
negotiation, push/pull paradigms, federated DBs, …
• Efficient ways to deal with revocation– Get rid of revocation, don’t check for revocation,
check quickly, …
UIUC
128
Scalability and deployment• Good implementations of trust
management facilities – Modular, scalable, reusable – Support ubiquitous trust negotiation
• Deployment of trust negotiation – In today’s popular communication and
query/response protocols (SOAP, IPsec, TLS, etc.)
– Backward compatible
UIUC
129
Vulnerabilities
• What kinds of attacks is trust negotiation vulnerable to?
• How can we mitigate the danger?• What parts of the process/system must be
trusted, and to what degree?• What integrity/privacy/confidentiality/…
guarantees can we give?
UIUC
130
Confidentiality guarantees
• Can outsiders eavesdrop on negotiations?• Can I disclose just part of a credential?• Can there be a concept of “need to
know”?• What can be inferred about my credentials
without my directly disclosing them?– Fix by adding release privileges for “leaked”
info?
UIUC
131
Managing multiple identities
• Support for many identities has many benefits for issuers and owners, today and in the future
• How to prove I possess several identities, while preventing or penalizing collusion?
• How to make my identities unlinkable?
UIUC
132
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 middleware– DB capabilities for security-critical data
• Attribute Based Access Controls as a DB application• General data mgt challenges for security-critical data?
– Semantic web and XML– Enterprise security
UIUC
133How today’s policies get attributes they need
Release Decider
Access DeciderUser Request
User Request
Policies
whole profiles
Access Decider
...User attributes
from directory
Submission attributes in request msg
ApprovalSignatures
Submission attributes from app server
ApplicationData
Attribute providers
UIUC
134
Evolution is hard• Each decider engine either
– Assumes that all attributes come from its own directory; or– Has code that knows who provides each attributeTo add attribute provider or attribute type, must modify code
• Directory could pass large, fixed user profile– Confidentiality issues (from other agencies)– Cost, when attributes require humans, or remote data
• Reverse approach: pass (all or part of) the policy function– Pass a predicate (e.g., Has Secret Clearance?) that defines
a virtual attribute– Confidentiality, e.g., has Enigma clearance?– Executable policies may not be allowed
UIUC
135
XACML approach
User Request
...User attributes
from directory
Submission attributes in request msg
ApprovalSignatures
Submission attributes from app server
ApplicationData
Attribute providers
Add attributes thepolicy will need
Access Decider
UIUC
136Security policy evaluation as an ordinary data intensive application • Things to manage:
– Semantics: what do attributes mean, across agencies?– Access: from directories, DBs, services
• Prime directive: Insulate applicns from source of data– i.e., insulate policy deciders’ code from attribute providers
• Options– Coordinate policy-writing with attribute provision (XACML)– Federated LDAP directory – normally only users info – Federated database technology, culminating in publish/subscribe
• Ordinary access controls should protect these attributes
• Reasoning about policies: Finally a killer app for logic databases?– What logic – Datalog++ or OWL?
UIUC
137Hardening a DBMS-based system against malice• Secrecy, correctness are crucial in many data
intensive applications – Finance, medicine, military operations, control
systems (chemical, nuclear, aircraft, …)– Security (user and other attributes)
• DBMSs are used in such environments (less for security), but … How to mitigate malice?– Threat models:
• Difference in classification level• Arbitrary “group gets role”, e.g., Ford user reads Gen. Motors
data– Help design physical separation
UIUC
138Approaches based on physical separation• Harden the system against attack, e.g.
“Appliance” offering few services, no end user access
• Physically separate sensitive data from users who may attack itMethodologies are ad hoc, seem to have no tools
Ford, Gen. Motors, and TV network data
UIUC
139Approaches based on physical separation• Harden the system against attack, e.g.
“Appliance” offering few services, no end user access
• Physically separate sensitive data from users who may attack itMethodologies are ad hoc, seem to have no tools
Ford supplierGen.
Motors
UIUC
140Approaches based on physical separation• Harden the system against attack, e.g.
“Appliance” offering few services, no end user access
• Physically separate sensitive data from users who may attack itMethodologies are ad hoc, seem to have no tools
Ford +supplier
Gen. Motors +supplier
UIUC
141Data intensive applications and security/correctness • Target systems: DBMSs, document
managers, middleware• Create models and tools to
– Calculate attack resistance of a particular design, from a given threat
– Allocate data automatically– Adjust query processing techniques
• Integrate data quality, provenance and transitive trust
UIUC
142
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 middleware– DB capabilities for security-critical data– Semantic web and XML– Enterprise security
UIUC
143Semantic web context
Grid Computing & Grid Services
Syntax: Data
Structure
Semantics
Higher Semantics
Reasoning/Proof
XML
XML Schema
RDF/RDF Schema
OWL (ontologies)
Inference Engine
Trust Security/Identity
Use, Intent Pragmatic Web
Intelligent Domain Services, Applications
Agents, Brokers, Policies• Semantic Brokers
• Intelligent Agents
• Advanced Applications
• Grid & Semantic Grid
Mature Web Technologies
Semantic Web Technologies
UIUC
144
XML security directions: examples
• Use XML as a language syntax for any sort of language, to make it tool-friendly– For security languages too: XACML for access policy
on any resource• There are standard ways to express security
labels, now also in XML– “UltraProprietary, release to Drug_Trial(foo)”– “Secret, No Foreign except Canada”
• Many XML security issues also arose with object DBs– E.g., IS-A, part-of– Arise also with SQL’s object constructs
UIUC
145
XML security research examples
• Several models to protect XML documents– E.g., Bertino, Damiano, …- Exploit and extend X-languages, SQL security, domain models
(temporal, spatial); don’t duplicate other sublanguages• Policy partly at schema level, partly instance-specific
– Accommodate nesting and other XML properties• Efficient processing of schema-level labels
– E.g., twig queries with MLS labels [Cho et al.] • Is MLS realistic there? DoD will not mix major levels on same
system. What if labels are not totally ordered?
• Protect schema-less documents– Use IR to derive document attributes (described earlier)
UIUC
146
Semantic web languages
• RDF and OWL are likely to become important, even if the ambitious vision remains elusive– RDF offers schema-less entry of individual facts,
natural labeled “graph” structures• Resource is anything on the web
– OWL adds inference
• There will be a niche for security models optimized for each of XML, RDF, OWL– But will they play well together?
UIUC
147
PolicyPolicyPolicyPolicyPolicy
OWL policy
AddTree graphic
AddTable graphic
DBMS
Virtualdocs
Virtualtables
SQL policy
OWL
VirtualRDF
VirtualOWL
RDFpolicy
RDF
XML policy
UIUC
148How to support multiple security models?
SQL security model
DBMS Security
RDFsec. model
OWLsec.
model
OWLsec.
model
Abstract Data ModelContainment,Derived data, …
(in enough detail to drivesecurity)
Abstract Security ModelAttach a policy to objects General security, e.g.,
•Revoke privilege•Limit privilege
XMLsec. model
UIUC
149
Security for multi-model databases
• DBMSs are becoming dual personality– They see (+ store) the same data as relations or XML– Support SQL, XPath, XSL, XQuery, …
• But have separate security systems for each of these, plus RDF, OWL, etc.
• For vendors: Support SQL, XML, RDF, OWL security models on the same code base
• Avoid double administration, inconsistent policy, when crossing model boundaries– Translate policies across models
• To provide consistency regardless of model used to access data• To apply policies consistently to subobjects/across links
– Double enforcement is OK
UIUC
150
A possible research approach
• Devise rich object metamodel and map it to SQL, XML – Identify common abstractions for models of
• data (metadata, derived object, is-a, part-of, …) • security (delegation, revoke, limit privilege, session…)
– Cover all objects that SQL protects• Avoid gratuitous incompatibility with SQL
– Where new applications really need more, generalize to apply to both models
– Implement the delta, not separate systems
UIUC
151
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– DB support for security-critical data– Semantic web and XML– Enterprise security
• From high level statement to implementation• Between organizations
UIUC
152
Evaluation
what an enterprise needs:Policy engineering environment
BusinessExperts---
SystemsExperts
Capturedecisions, reasoning
Desired policies stated at business model level. Incomplete, conflicting
Compilation(partially automated)
Compilationassistance
Confidence estimation
Policies, stated at business model level. Consistent, coarse, incomplete
Implementationof policiesPolicy
analysis
Conflict resolution
Humans Tools Processes Artifacts
Conflict detection,
explanation
UIUC
153
First stages of policy engineering• Overall policy engineering goal: Support humans working together
to devise consistent policies out of inconsistent fragments• Support incremental, evolving policy specs
– Users will specify most important policies first– Record evolution from initial conflicting desires to final consistent
policies• Assist in conflict recognition, resolution
– Detect and explain conflicts between policies• Cannot always tell in advance whether two policies conflict• Proposed resolution processes scale poorly
– Except “most severe wins”, e.g., in XACML– Addition of new policy is not opaque to previous policies
– Automated policy conflict resolution should not be focus• Hot topic in AI community, but impractical
• Assist in policy compilation (next slides)
UIUC
154Reprise: Compile “business”policies to physical implementation
Individually identified medical data shall be available only to professionals
treating the patient, with medium-high confidence
Install policieson tables, documents
?Suitable • Data allocation• Execution plan
UIUC
155Compile “business” policies to physical implementation
Individually identified medical data shall be available only to professionals
treating the patient, with medium-high confidence
Who are “professionals
treating this patient”
Confidence needed in:•Technical measures• Metadata admin• Partners
Metadata, ontologies
Userm’data
Install policieson tables, documents
Suitable • Data allocation• Execution plan
Systemm’data
What data is“medical”,
“individually identified”
UIUC
156Subject/object/action each require own set of mappings
Policy written in terms of business model
Info mapping User mapping System mapping
Info mapM’data
UserM’data
Substantive policy
(who can do what)Physical schemas
SystemM’data
UIUC
157
Kinds of mappings needed• Use same underlying theory and/or
implementation for all?• Down: compile from policy specification to
implementation– Up: Reverse engineer a rough high level policy from a
detailed policy• Analogy: derive ER schema from relational schema
• Down: allocate data and execution, for suitable confidence (next foil)
• Horizontal: translate policies between organizations, data models
UIUC
158
Physical DB design problemsPhysical design systems need to know about security req’s• Organizations partition data to minimize the number of
users “close” to sensitive info– Partition among machines, DBMSs (some not on internet),
tables, tuples, … (increasingly easy to hack)– Which systems are trusted to filter what data in queries– Select appropriate communications (e.g., encrypt wireless)– Enhance data allocators, query planners to provide necessary
confidence
• Index securely– Imagine the risk of having one file with a full text index for an
entire intelligence agency• Encryption helps in special cases, poor in many others
– How to partition indexes for security?
UIUC
159General issues for both downward and horizontal automated mappings• Automated mapping will be safer (less buggy, revised
faster) than manual mapping between two levels– Manual implementation hints are OK
• Validate that one policy is enforced by another (if it is)– Else explain the gap (+ and -)
• Determine level of confidence in policy implementation– Analyze, model the confidence of various basic DB
configurations– Devise composition rules for DB configurations– Compose the analyses to determine confidence in proposed
setup
UIUC
160
Devising vertical mappings
• Don’t try too hard to standardize how to model things – E.g., who are “medical personnel”, who is a “full-time
student”– Your partner will choose a different standard– More important to focus on the current situation
• Map from policies on system components to effects on applications– Wireless transmission to ambulances, accounting
DBs, paper & electronic medical records, communications with external labs …
UIUC
161Don’t expect standard info/user models• Standardizing is good – but has direct effect only on new
development• Some systems will remain noncompliant with your standard (legacy,
special needs, external partners, …)– US govt agencies cannot standardize roles, beyond the trivial (e.g.,
levels GS-1, GS-2, …)• Some agencies consider their business processes (and role
structures) too secret to share• Need approaches to defining levels of aggregation
– For subjects, objects, actions: people into roles, data into chunks, etc.– Approach 1: Data meta-model levels
• E.g., concept, schema, instance, element [BBGJ04]• Fairly fixed levels, good for explaining
– Approach 2: Standard types of relationships (IS-A, consists-of, …)• Seems more flexible, better as underlying model to which others map
UIUC
162Reprise: Translate and transfer policy across organizations and systems
Paris HospitalEnforcement: DBMSPolicy applied: FranceRoles: Hospital (Emergency Care)
Aetna Travel InsuranceEnforcement: Application serverPolicy applied: US (NY)Roles: HiPAA spec (Aetna version)
?
UIUC
163Translate and transfer policy across organizations and systems
Paris HospitalEnforcement: DBMSPolicy applied: FranceRoles: Hospital (Emergency Care)
What data is• Medical• Indiv identifiedReligion: require inUS, forbid in France
Who are • Professionals• Treating this patientInsurance approver role only in US
Confidence in• Technical measures• Metadata admin• Partners
Aetna Travel InsuranceEnforcement: Application serverPolicy applied: US (NY)Roles: HiPAA spec (Aetna version)
UIUC
164Policy translation(horizontal mappings)• Agencies won’t share unless they approve the partner’s
protections. Each has its own policies• How to enforce X’s policies in Y’s domain, overcoming
differences in data and security?– Data: structures, query operators, instance identification [ss#,
emp#] , schema, …– Security: model, policy language, policy implementations
• How to explain to X what Y is enforcing, and the difference?
Impression: 70% of semantic integration challenges have security analogs– Semantic integration seems to precede security integration
UIUC
165
Policy integration challenges
Air France
Alliance (“Sky team”) policies
Alitalia Delta
Integration challenges: conventional semantic integration plus: – Integrate role & group hierarchies– Integrate policiesConsider OWL as a common formalism
UIUC
166Research areas applicable to mapping of security specs• Semantic modeling • Query processing for federated
heterogeneous databases– Secrecy-friendly algorithms
• Automated physical design• Model management theory [Bernstein]
UIUC
167Scalability challenges:General administrationChallenge: 10**3 – 10**5 tables
• Centralization (one person/role does all)– Burdensome, lacks defense in depth
• “Override” semantics (strong and weak negatives) – Hard to follow– No “weak” policy is guaranteed to hold
• Obligations to be fulfilled at uncertain future times
UIUC
168Scalability challenge: Determining “need to know”• Data owner often approves requesters’ “need to know”
– Unscalable, to authorize release of each product, to every reasonable recipient
– Trust management can help judge users’ trustworthiness, not their need to know
• Involve the user– User understands their general requirement
• e.g., do they need imagery: for this point, or within distance d, or in political unit, or along this road, …
– Help nontechnical user to state candidate “grants” at right level of generality
– Identify privileges that may be unneeded (examine workload)
UIUC
169Do you believe the specified policy is really “right”?• Unmeasured risk: the stated policy is
wrong– Or becomes wrong over time
• Admin is currently low-tech e.g., GUIs over the enforcement product
• Can we do better?– E.g., compare with similar users, other
organizations?
UIUC
170Confidentiality-preserving info integration• Organizations want to compute over combined data,
without revealing the data to each other– Protect privacy– Protect company-confidential data– Provide legal defense (“we tried our best”)– Remove an excuse used by those who prefer not to share
• How can we integrate information from multiple organizations while maintaining confidentiality?– Focus is efficient ~zero-knowledge algorithms for joining and
mining, to meet the extreme case of very high confidence• IBM (“Sovereign information sharing”), Purdue, others
– May have a stampede of researchers soon
UIUC
171Confidentiality-preserving info integration: a contrarian viewSkeptical notes• How often is such high confidence essential?• Exact match rarely works for names!• Do we want to treat these queries different from all
others?Unifying perspective (U. Maurer @ SIGMOD04)
• We can do it all with a “trusted subject” in the middle– Cryptography is one way to create a trusted subject. – Other techniques may be more flexible or efficient, but lower
confidence, e.g., a trusted SQL DBMS appliance– Describe what they’re trusted to do, and how confident we’ll be
UIUC
172
Pragmatics: FlexibilityLegend
Y axis: execution + setup cost
Ordinary computing
Zero info
X axis: confidence in secrecy
Carefully designed
export viewsTrusted 3rd partyY axis:
flexibility
UIUC
173
Alternative formulation
• Start from an ad hoc SQL query, access policy, and required confidence level
• Extend query processing to choose appropriate join implementations– Private functions, ordinary join, and trusted
third party (e.g., stripped down appliance) areeach appropriate in some circumstances
– How to choose among them automatically?
UIUC
174
Agenda
• Introduction• Security basics• State of the art and open problems• Policies as a unifying framework• Security issues and opportunities in
example application areas• Summary
UIUC
175
Summary advice, 1• The big wins occur when tools drive the cost of
something to zero (not 50%)– Compile specs (functional + implementation
properties) to an implementation– Automate “where are we” and “what if” analyses
• Exploit common abstractions for multi-lingual security– Containment, IS-A, derived data, delegation, …
• Extend SQL smoothly -- do not be gratuitously different – Feature interactions, granularity differences appear
when constructs are examined in full context
UIUC
176
Summary advice, 2• Security should not be a stovepipe
– Reuse existing concepts from query languages/ derived data/…, rather than reinventing them
– Security components that can be reused (services, policies)
• Rich policies need rich runtime input– General data access and exchange services,
federated DB capabilities will be needed at run time to feed into policy decisions
• Trust models are relevant to data quality, suitability
UIUC
177
Summary advice, 3
• Security system has high requirements for data integrity, availability, threat resistance– Could build DBMSs to treat these as “normal”
requirements (i.e., to provide high integrity, availability, threat resistance)
• First define correctness criteria. Do algorithms afterward– e.g., for role hierarchy integration, privilege
inference rules
UIUC
178
Some relevant further reading• Policies
– IEEE Policy Conference• Data security
– Conferences: IFIP 11.3, ACM SACMAT • Modeling and analysis weak by SIGMOD standards
– Journals: ACM TISSEC– Books: Castano et al. 1995, for earlier research
• General security – Textbooks: many choices – Conferences (systems-oriented): CCS, NDSS, Oakland
• Mostly aim at securing systems and system access
UIUC
179What problems receive too much attention, in unreal settings?Inference control (1990s)• Limiting the ability of a party to use additional
knowledge to figure out things that they have not been told explicitly
• Relevant only with relatively fine grained policies (e.g., columns, not tables)
• Many proposals require– Tracking requesters’ identity – Figuring out requesters’ external logical or statistical
knowledge– Assuming requesters don’t collude– Keeping a history of all past requests and responses
UIUC
180
Too unreal, continued• Conclusion re inference control:
– Worth doing for carefully examined static publications (census bureau, health statistics)
– For enterprise systems, it’s like locking a 5th floor window– Research on inference control is unlikely to attract vendors, and
hence will lack broad real-world impact“Privacy-preserving” data mining• The work to date looks costly, fragile• Probably not a great place for a stampede of
researchers unless more practical look is given• Trusted third party appliances (stand-alone machine &
software) could help
UIUC
181
Appendix: Definitions
• Security-related properties• Threats• Means of addressing the threats
UIUC
182appendix: security propertiesConfidentiality• Prevent information from going to the
wrong recipient• Not synonymous with privacy
UIUC
183appendix: security propertiesPrivacy• 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
• 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• Treating “private” info as intellectual property
– Controversial: does individual always know best?– Unsuited to, e.g., police records
UIUC
184appendix: security properties
Integrity• Ensuring data is right• Defns of “Right” in different communities:
IT: Produced appropriately [Clark-Wilson]Security: Not changed inappropriately
• E.g., tamper-evident signed message digestsDB: Satisfies all relevant constraints
• E.g., ACID transactions, key constraints
• Related issues: trust, data quality
UIUC
185appendix: security properties
Authentication• Determining who you are talking to• Examples
– Unix logins and passwords, X.509 identity credentials, retina scans, and fingerprint scans are approaches to providing authentication
UIUC
186appendix: security properties
Authorization/access control• 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
UIUC
187appendix: security properties
Accountability• Holding people responsible for what they
have done• Nonrepudiation = a party cannot plausibly
deny actions they have taken• Example
– Purchases with credit cards do not provide non-repudiation; customer can dispute charges, claim that they were made by someone else
UIUC
188appendix: security properties
Availability, survivability• Being able to use a resource when desired
– Denial-of-service attacks can compromise availability
– Fault-tolerant hardware and software can improve availability
• Repair a damaged database [Jajodia]
• Survivability: the ability to emerge relatively unscathed from a relatively catastrophic event
UIUC
189appendix: security properties
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
UIUC
190appendix: security properties
Trust• Willingness to rely on an entity for a particular
purpose– Trust management = hot topic in open systems
• Trust in data depends on its integrity, freshness, provenance, reputation and objective properties of the data’s source, etc.– Data provenance is a hot issue for scientists and
intelligence analysts– How can we automatically specify and reason about
the level of trust in a data item?• Particularly interesting in the context of derived data and in
information integration
UIUC
191appendix: security properties
Linkability• Recognizing that two actions were taken
by the same party• Example motivations
– Hide pattern of interest in certain prior patents– Avoid consumer profiling of electronic
purchases• Privacy-preserving technologies often try
to keep links confidential– Cash provides non-linkability
UIUC
192appendix: security propertiesDigital rights management• Controlling the propagation and spread of
the content/data/information that you “own”
• Big deal for entertainment, where the threat is from the machine owner
• Also mandated by law in some arenas• Not discussed in this tutorial
UIUC
193appendix: addressing threatsData and application security• Protection for information and functions (based
on structure, type, value, …)• Contrasted with protecting systems, networks, or
even DBMSs from intrusion• For enterprises, the insider threat is particularly
important• One tries to specify and implement policies that
distinguish legitimate vs. wrongful use– The written policy is an approximation to “legitimate”
UIUC
194
Appendix: Definitions
• Security-related properties• Threats• Means of addressing the threats
UIUC
195appendix: threats
Threat model• Description of the kind of attacks that the system owners/builders
want to protect against– Likelihood of threat, cost if it materializes, also needed for cost/benefit
analysis of risk amelioration approaches• Security can only be defined in terms of resistance to particular
threats---there is no perfectly secure system• Example
– All passwords shall be secure against dictionary attacks and eavesdroppers on the network
– A top secret system shall be secure against all attacks from the public Internet
– A patient information system shall be secure against nontechnicalprobes
Weakness: Rarely considers the chance that the formalized policy does not capture the real goals
Standards? Some US agencies discuss mixtures of user classes andmandate appropriate security measures (http://www.fas.org/irp/offdocs/dcid1-7.html)
UIUC
196appendix: threats
Dictionary attack• Attacker knows the set (dictionary) of likely
values for a field, and the function that they are encrypted with
• Attacker encrypts every value in the dictionary, and compares it to the value seen in the data, looking for a match
• Used to guess passwords– Can compromise some “privacy-preserving”
join approaches
UIUC
197appendix: threats
Denial of service attack• Flood of requests for service, with the goal
of making the resource unavailable to other requesters
UIUC
198appendix: threats
Replay attack• Alice and Bob carry out a legitimate interaction• Cindy records the messages in the interaction• Cindy then starts an interaction with Alice, using
some or all of Bob’s messages to gain access to Alice’s resource
• Usual protection is via nonces: short bit strings generated on the fly and required to be included in responses– Bob’s response won’t have the right nonces in it for
Cindy’s interaction with Alice
UIUC
199appendix: threats
Intrusion• Unauthorized party gains access to a
resource• Intrusion detection = the ability to
determine when this has occurs• Honeypots = systems set up for the goal of
enticing intruders and observing their actions
UIUC
200appendix: threats
Collusion• Two or more parties acting together to
obtain rights/information that neither one of them could get alone
• Example– If bank and merchant collude and accuse a
party of spending digital cash twice, can the party still prove that they did not?
UIUC
201appendix: threats
Impersonation• Appearing to be someone other than who
you are
UIUC
202appendix: threats
Man in the middle attack• Alice and Bob carry out an interaction• Cindy sits between them, intercepting their
messages• When Alice thinks that she is talking to
Bob, actually she is talking to Cindy, for part or all of the interaction
• Bob may be totally unaware of the deception
UIUC
203
Appendix: Definitions
• Security-related properties• Threats• Means of addressing the threats
UIUC
204appendix: addressing threats
Encryption• Main players are shared-key and
public/private key approaches• Many exotic schemes with potentially
useful properties– Flaws are very common in new
implementations
UIUC
205appendix: addressing threatsCryptography: what does it buy you?• Encrypting information rarely suffices on its own
– Dictionary attacks, replay attacks, other considerations limit effectiveness
• “Designer” cryptography schemes can provide amazing properties– David Chaum is limitless source of ideas– But implementing them correctly is probably harder
than thinking them up– Ross Anderson’s book has many examples
UIUC
206appendix: addressing threats
Digital signatures• Provide evidence that data came from a
given source– Helps with integrity, nonrepudiation
• Techniques– Take a piece of data– Shorten it (e.g., hash it)– Sign the hash (e.g., encrypt with private key),
and send the signed hash along with the data
UIUC
207appendix: addressing threatsReference monitor• Code or hardware that intercepts a request and
applies a policy before the request may proceed– Example requests: access, release, method call– Example policies: Access control, audit, notify
individual concerned, …• Alternative: user makes request indirectly, to a
somewhat privileged server– Server either produces a credential to pass onward,
or executes request under its own privileges
UIUC
208appendix: addressing threats
Access control and release• Access control policy governs pull situations
– Alice says: Bob can do this action on this object• 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
UIUC
209appendix: addressing threatsRevocation• The removal of access rights
• Difficult when the revoked data is mobile or maintained remotely– Expensive to check remotely at run time– Many publications address caching, expiration
UIUC
210appendix: addressing threats
Audit trail• Log of actions taken, events, activities• Available for analysis after the fact
– If something goes wrong– To look for anomalous behavior and
understand “normal” behavior
UIUC
211appendix: addressing threats
Delegation• Declaring that another party will be speaking
for you / acting on your behalf• 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:
Authorize(Arnie, Purchase) := Authorize(Marianne, Purchase), Purchase.Amt < $100
UIUC
212appendix: addressing threats
Separation of duty• No party is allowed to do every kind of action
– Minimizes concentration of power• Example
– The person with authority to sign checks is not the person who deposits checks and reconciles the bank account statements
• SQL security concentrates power– SQL DBA has few limits
• Use audit as after-the-fact enforcement– SQL object creator controls metadata they provide,
and also instance data placed in the object
UIUC
213appendix: addressing threats
Chinese wall policy• If a party knows about/can do X, then they
cannot know about/do Y• Examples
– In a financial firm, if you are working on company X’s bid to take over company Y, then you are not allowed to work on company Z’s bid to take over company Y
UIUC
214appendix: addressing threatsIntellectual 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
• Hippocratic databases (IBM) aim to build trustworthy DBMSs for well-intentioned organizations
• Tough case: adversary owns the machine– Not necessarily about secrecy – Goal: cradle-to-grave control over access– [Stanford group, Aggarwal et. al. VLDB04] proposes to give
every person the ability to control their own data, by giving/withholding keys
Not addressed in this tutorial