Security of Shared Data in Large Systems · Security of Shared Data in Large Systems Arnon Rosenthal ... Also, document what an adversary knows, forbid anonymous access, be able to

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


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


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


– 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


– 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


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


ShipSellBuy

Product Order

Authenticate


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


ShipSellBuy

Product Order

Authenticate


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


• 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


• 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


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


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




Ford supplierGen.

Motors

UIUC




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


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


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




?Suitable • Data allocation• Execution plan

UIUC

155Compile “business” policies to physical implementation



Who are “professionals

treating this patient”

Confidence needed in:•Technical measures• Metadata admin• Partners

Metadata, ontologies

Userm’data


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


Aetna Travel InsuranceEnforcement: Application serverPolicy applied: US (NY)Roles: HiPAA spec (Aetna version)

?

UIUC

163Translate and transfer policy across organizations and systems


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


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


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


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


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


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


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


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



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


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


Denial of service attack• Flood of requests for service, with the goal

of making the resource unavailable to other requesters

UIUC


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


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


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


Impersonation• Appearing to be someone other than who

you are

UIUC


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



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


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


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


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


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


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


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

Documents

Security of Shared Data in Large Systems · Security of Shared Data in Large Systems Arnon Rosenthal ... Also, document what an adversary knows, forbid anonymous access, be able to