Administering Security Policies Data Sharing Arnon Rosenthal The

Administering Security Policies + Data Sharing Arnon Rosenthal The MITRE Corporation 1

Talk contents: Administration • Administration: the efforts that don’t look like programming • For data to be shared, we must administer – Policies (security, privacy, intellectual property, user interests) – Data exchange/integration metadata: describe, relate, prescribe 2

Viewpoint for talk • My employer, MITRE, thinks in terms of needs of end user organizations • Discuss the practical world, esp. painful areas – Identify needed capabilities – Extract research challenges that can simplify or empower – How “research” intertwines with tech transfer • Other tasks for researchers – Conceptualize, modularize – Illuminate the fallacies (repeatedly) – For UCI: Combine data-brokering and security • Opinions on what research is most useful 3

Commercial Break • We’re hiring researcher/consultants and prototypers • Suburban DC, Boston, other • 95% of openings require US citizenship (sorry!) 4

Policy administration outline • Overview – Typical technology ingredients – What sorts of policies • Foundational capabilities – – Models Mapping Metrics Improve SQL (M. S. projects? ) • Principles for scalable approaches – What has research contributed? – What do we need? 5

Aspects of policies • Interest protected: Secrecy, privacy, intellectual property, integrity, My_Alerts. . . • Actions: Allow/deny, second signature, intense audit, warn requester, filter the data accessed • Decision factors (it’s getting knowledge intensive) – – Resource: Object, operation User properties: identity, job, project, area of responsibility, role Request: purpose, submission time, data-destination Context: Any info, from anywhere • What’s missing? • Cost / benefit are not in the models! • Best available knowledge management 6

Major technologies • Policy languages – Programming languages with policy-friendly constructs – Predicate language ++ (e. g. , XACML) • Also: Select relevant policies, resolve conflicts • Role based access control – Aggregates users, privileges into roles – Authorization model (activation, reachability) – Standard But it’s one graph, 7

problem context Policy administration in enterprises • Single sign-on is typically the top priority, rather than policy specification • Cost of ownership for DBMSs is admin, not hardware, software – We can expect the same for security • 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 • State of the practice /product – Role based access control (RBAC) + predicate language – Chaos in distributed and n-tier systems 10

Security policy chaos in today’s n-tier systems Authenticate Application Server (e. g. , Web. Sphere, Web. Logic) Order Product Buy method Sell Ship Bill Databases (tables/docs) View/ Proc 11

Improving this mess seems a central problem • Opinion: Many SIGMOD researchers are working on “nondisclosure” – The problems seem worthwhile, and are getting nice results – But they seem less central to society’s needs • Low disclosure mining algorithms • Avoiding inference from published data • Outsourced untrusted databases 12

Policy administration outline • Overview – Typical technology ingredients – My cat is privacy-protecting • What sorts of policies? • Foundational capabilities • Principles for scalable approaches 13

Sorts of policies What is different about privacy? • • “Fair information practices” and human rights Legal requirements are frequent, may forbid sensible tradeoffs Purpose(? ) Millions of administrators, opting in and out. So can have very fine grained policy, with low admin cost 14

An easily-applied categorization • Ask what stakeholder a policy protects – Privacy: The person (or entity) described – Enterprise secrecy: The entity controlling the database – Intellectual property: The provider of the info 15

“Correct enough” + Delegation Trust management? Critical decisions of all sorts need correct data • Integrity, in security community: – – – • Authorized person entered it (e. g. , our sysop) He used the correct procedure It hasn’t been illegally changed (integrity) Main threats: Malice or improper procedures Issues ignored • • It was entered in 1991 Signed by our Springfield sysop … 16

Policy administration outline • Overview • Foundational capabilities – Models – Mapping – Metrics – Improve SQL (M. S. projects? ) • Principles for scalable approaches 17

1. How can one DBMS best support multiple security models? DBMS Security SQL security model Filter based on row labels XML sec. model P 3 P RDF sec. model OWL sec. model XACML 19

Policy Virtual docs Virtual tables Policy Polic y Virtual RDF Virtual OWL RDF OWL DBMS Add Tree graphic XML policy Add Table graphic SQL policy RDF policy OWL policy 20

How to support multiple security models? DBMS Security SQL security model XML sec. model RDF sec. model OWL sec. model Abstract Data Model Abstract Security Model Containment, Derived data, M’data… (in enough detail to drive security) Attach a policy to objects General security, e. g. , - Ownership - Revoke or limit privilege 22

2. Compile “business” policies to physical implementation Individually identified medical data shall be available only to professionals treating the patient, What data is “medical”, “individually identified” Metadata, ontologies For each implementation object (e. g. , lab test msg) • Determine relevant policies • Translate policy thru data mapping to execute on impl. object Who are “professionals treating this patient” User m’data 25

Connect “capital P” Policy to implemented objects • Medical personnel assigned to patient can read Lab test info for purpose of Treatment • Allergy. Test(PName, allergens) by Nurse, for drug interaction screen • Is Allergy. Test Lab test. Is nurse medical? Is drug interaction screen Treatment? Is she “Assigned” (on that ward or private nurse or… ) Decision-maker Policies Allergy. Test + request objects Mental, undocumented English Predicates 26

Connect “business” Policy (capital P) to implemented objects • Allergy. Test(PName, allergens) by Nurse, for drug interaction screen Medical. Person, personnel assigned to patient can read Lab test info for • • Allow: = Purpose: Treatment purpose. Assigned(Patient. Described), of Treatment Msg. Type: Lab. Test • Is Allergy. Test Lab test. Is nurse medical? Is drug interaction screen Treatment? Is she “Assigned” (on that ward or private nurse or… ) Decision-maker Policies On Allergy. Test and requests Mental, undocumented English Predicates Capture once, document, use for all affected objects Automate translation Enterprise knowledge: Rel’ships among vocabularies 27

Transfer or compare policy horizontally across organizations and systems Aetna Travel Insurance Enforcement: Application server Policy applied: US (NY) Roles: Hi. PAA spec (Aetna version) Who are What data is • Medical • Indiv identified ? • Professionals • Treating this patient Insurance approver role only in US Confidence in • Technical measures • Metadata admin • Partners Paris Hospital Enforcement: DBMS Policy applied: France Roles: Hospital (Emergency Care) 28

Today, policy engines receive a soup that combines all stakes Location is in User. Area. Of. Responsibility and Suspect. Threat. Level = high & Traveler. Date < 7 days from today & ((Suspect. Category=Domestic & Suspect. Threat. Level=high) or Suspect. Category=Foreign ) & User. Job is Investigator & User. Agency is Law enforcement • Hard to create, analyze, change • Alternative (EPAL, MLS, Oracle): Each stake has its own language and enforcer – No integrated picture, no orthogonality 29

More complex decomposition into several stakes Notional request: Info from Suspects join Travelers Policy: Location is in User. Area. Of. Responsibility and Suspect. Threat. Level = high & Protect secrets Traveler. Date < 7 days from today & (Suspect) ((Suspect. Category=Domestic & Suspect. Threat. Level=high) Privacy (Traveler) or Suspect. Category=Foreign) & User. Job is Investigator Safety fence & User. Agency is Law enforcement (Suspect) • Each stake requires one skill • Change is easy: Edit a small chunk • Stake can be on different granules, e. g. , Region, Dept 30

Separations of concerns that one might support Detailed controls ∧ ∧ multiple inputs, that raise different concerns

Policy Administration Research Challenges-- Outline • Foundational capabilities • What has research contributed? • Meta-level challenge: Models that scale 33

What’s been added to DBMS security since 1980 s • Roles, role hierarchies – SQL role is a set of privileges or users – But industry did roles, DB researchers arrived after • Receive “identity” information (but little more) from middleware or OS – SQL and JDBC are both barriers to extension • Filter query response based on row or column security labels (described later) • Security for new features added to SQL – Triggers, nested tables, objects, procedures – Security features are tightly coupled to data model 34

Which additions owed a debt to data security researchers? Why were we unable to help vendors (enterprises) improve this (now-critical) aspect? • Too few ideas were worth transferring • Some ideas were infeasible from the start • Few scaled to practical systems (many features, very much knowledge). 35

Giggle Test • Technologies are interrelated and must mesh to deliver a capability – Identify the entire package needed to achieve the desired impact for the user, and then ensure that it makes sense* • Can you – without giggling – say that the entire package seems feasible and desirable (now? someday? ) * Al Manning, MITRE 36

Examining transfer for a research idea: Inference control • You have a full description of attacker’s knowledge • No collusion between requests from different User IDs • Administrators have identified all sensitive fields – Or it’s worthwhile to protect just a few • Efficiency – extra factor of 5 is OK • No updates • You know what info the has already accessed Black bullets limit applicability. Not to zero, but is it a good place to invest scarce talent? 1 -2 probably can’t be removed by more research! Spend $$$$ for high certainty (locally), but partial solutions won’t give a large factor of protection 37

Policy Administration Research Challenges • Foundational capabilities • What has research contributed? • Meta-level challenge: Models that scale 38

Outline We need scalable approaches • Opinion: Scale-up should be the primary research criterion – Deemphasize work on specific capabilities – hard to integrate, so too few transfer • What do we need for scalability – Simplicity (for admin and software vendor) – Reach out (don’t duplicate) – Componentize – Metrics for scalability 39

Requirements for scale-up Simplicity • Opinion: “Simplicity” should be an absolute constraint on proposed “foundation” features • The lesson of relational dbs: Create a simple submodel – Use its tractability to provide great services (UIs, compilation, …) – Push tough things out of foundation • e. g. , to 3 GL or manually-coded policies 40

Requirements for scale-up Reach out, don’t do it all (1) • Don’t create own datatypes (time, space) – Create a framework for plug-ins – Don’t compete with bigger markets, more expertise – Can create your own for a prototypes, but call it a hack, not a model 41

Requirements for scale-up Reach out, don’t do it all (2) • RBAC is a large silo. It’s now time to look away – OWL seems more promising. (Much more powerful, simple and tractable enough) • Formalism silo: Employs a formalism from policy community for general enterprise knowledge – Policy itself should stay as a policy language • Role hierarchy is a silo knowledge base (very tenuously linked to general knowledge) – Cannot fit enterprise into a single graph – Integrity of vital info applies to general knowledge, not just stuff in security system 42

Requirements for scale-up Modularize • Create clean abstractions, with multiple elaborations – E. g. , multiple coexisting ways to remove privilege • Don’t build silo modules by hardwiring one choice on each abstraction – Where need new capability, make it available to all 43

Requirements for scale-up Objective comparisons • Recent papers compare models’ logical expressive power. – Top priority for logicians, – For vendors and admins, relevant but not as central as next • Admin effort (how much to enter, what skill level for people) • Implementation cost for vendors • Learning curve for admins • Possible approach – Draw correspondences between concepts – Improve by using generalization, separate interfaces 44

Backup foils 46

Security policies in the semantic web • Exploit semantic knowledge (in OWL) for all relevant aspects of a request (users, resources, …) [Qin+, Kagal+] – Little semantic web to secure, so far • Theoretical gaps – “Certain answer” mappings(? ? ) – Policy propagation rules are asserted without an underlying correctness criterion. Also hard to follow (negatives) • Pragmatic gaps – Applies to data already described by ontologies. No test of “just in time” semantic capture for a new policy – It’s not a component – no interface to more powerful rules – Execution by inference engine, not ordinary server 47

Challenges here – Use SQL to test your framework • Mature industrial standards force you to confront all the issues • Middleware security dominates, but SQL is significant 6 • 10 installations, 30%? (less? ) doing nontrivial security 48

What practitioners need from the research community A database industry would be alive and well … even if researchers had never entered the database arena. … Industry identified the problems and provided the early impetus. Researchers came along later and provided the clean abstractions and the elegant solutions. … Database researchers have contributed mainly by formalizing, simplifying. [David Lomet, Head of Database Research at Microsoft] 49

Some constructs? ? • Permissions (conditional OK) • Negatives X • Foundation should always work – don’t hardwire “ 70% guess” (e. g. , Deny wins) 50

2. The usual federated query problems: Compile to heterogeneous enforcers Policy: ON Person. Info If Age(Person. SSN) < Legal. Age(Hospital. State, Purpose) then Reject+Audit Person (relational DB) Hospital (document server) Medicaid_Approved (app server) Heterogeneous enforcers, each has own policy language Policy may reference confidential data 51

Enforcement mechanisms are very heterogeneous Compile high level policy to heterogeneous enforcers, which include: • User agents (P 4 P? ) • DBMSs, document and image servers (bottom tier) – Nagging issue: How to pass request attributes, when SQL call is not SAML-enabled • Middleware (on service/method calls) – Cannot act differently on each retrieved object • Application code • Boundary enforcement, e. g. , air gaps, high assurance guards, low assurance filters on email. • GUI (user friendly but low assurance) • Human decisions (expensive, slow, error-prone) Each of these is separately administered, today! 52