The PEI Framework for Application-Centric Security Prof. Ravi Sandhu

1. The PEI Framework for Application-Centric Security Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at San Antonio May 2009 ravi.sandhu@utsa.edu www.profsandhu.com PEI = Policy, Enforcement, Implementation

2. Application Context • Our Basic Premise There can be no security without application context • Orange Book and Rainbow Series era (1983-1994) Opposite Premise Application context makes high assurance security impossible to achieve • May need to settle for “reasonable” assurance or “good-enough” security • Its about “mission assurance” not “information assurance”

3. Rainbow Series • 34 titles listed in Wikipedia as the “most significant Rainbow series books” • Only 1 addresses applications • Trusted Database Interpretation (TDI) • Scope: “Trusted Applications in general and database management system in particular”

4. Application Context Software- Architect Project % Time Label Alice Vista 25% U Alice SecureVista 75% S Bob XP 100% U • What precisely is Secret? • There exists a SecureVista project • Alice works on SecureVista • Alice’s effort on SecureVista is 75% • All or some of the above • How do we maintain integrity of the database? • Depends Much work and $$$ by researchers and vendors, late 80’s-early 90’s

5. Orange/Rainbow Fatal Flaws • Enforcement of 1-way information flow in a lattice is not the dominant concern for most applications • Avoiding covert channels is not the highest priority for most applications • Exclusion of cryptography is not a smart decision for securing distributed systems The Common Criteria, an ISO standard, and successor to the Orange Book has its own problems

6. Post-Orange Era • Firewalls, patch cycle, vulnerability scanners, intrusion detection, intrusion prevention, Identity Management, Federation, SSL, VPNs, PKI, etc • Emergence and dominance of RBAC over MAC and DAC • Emergence of highly motivated, sophisticated and innovative attackers

7. Emerging Application-Centric Era (ACE) ECE Enterprise-Centric Era (Orange/Rainbow Era Post-Orange Era) ACE Application-Centric Era • Applications are cyber analogs of • previously existing enterprise-centric • applications • on-line banking • brokerage • e-retail • auctions • search engines • Future applications will be • fundamentally different • ? • ? • ? • ? • ?

8. ACE Characteristics • Multi-party interests • Fuzzy security objectives • Attack/threat models

9. PEI Models: 3 Layers/5 Layers

10. Secure Information Sharing (SIS) • A fundamental problem in cyber security • Share but protect • Current approaches not satisfactory • Classic models (DAC/MAC/RBAC) do not work • Recent approaches • Proprietary systems for Enterprise Rights Management • Many solutions: IBM, CA, Oracle, Sun, Authentica, etc. • Interoperability is a major issue • Many languages have been standardized • XrML, ODRL, XACML, etc. • Primarily, dissemination or object centric

11. Dissemination Centric Sharing • Attach attributes and policies to objects • Objects are associated with sticky policies • XrML, ODRL, XACML, etc. provide sticky policies Attribute + Policy Cloud Attribute + Policy Cloud Attribute + Policy Cloud Attribute + Policy Cloud Object Object Object Object Alice Bob Charlie Ravi Shashi Attribute Cloud Attribute Cloud Attribute Cloud Attribute Cloud Attribute Cloud Dissemination Chain with Sticky Policies on Objects

12. Group Centric Sharing (g-SIS) • Advocates bringing users & objects together in a group • In practice, co-exists with dissemination centric sharing Join Add Never Group Subject Current Group Subject Past Group Subject Never Group Object Current Group Object Past Group Object Join Add Remove Leave • Two useful metaphors • Secure Meeting/Document Room • Users’ access may depend on their participation period • E.g. Program committee meeting, Collaborative Product Development, Merger and Acquisition, etc. • Subscription Model • Access to content may depend on when the subscription began • E.g. Magazine Subscription, Secure Multicast, etc.

13. Core g-SIS Properties 1. Provenance: Authorization can only originate during a simultaneous period of membership Authz Authz Join Add Add Join 2. Bounded Authorization: Authorization cannot grow during non-membership periods 3. Persistence: Authorization cannot change if no group event occurs

14. g-SIS Operation Semantics Subjects Subjects Strict Leave Strict Join Join Leave GROUP Authz (S,O,R)? Liberal Join LiberalLeave GROUP Authz (S,O,R)? Strict Add 14 Strict Remove Remove Add Liberal Add Liberal Remove Objects Objects

15. Operation Semantics (Continued) • Strict Join (SJ): Only access objects added after Join time • Liberal Join (LJ): Also access objects added before Join time • Strict Leave (SL): Lose access to all objects • Liberal Leave (LL): Retain authorizations held at Leave time

16. Operation Semantics (Continued) • Strict Add (SA): Only accessible by existing subjects • Liberal Add (LA): No such restrictions • Strict Remove (SR): All subjects lose access • Liberal Remove (LR): Subjects who had authorization at Remove time can retain access

17. Family of g-SIS Models Traditional Groups: <LJ, SL, LA, SR> Secure Multicast: <SJ, LL, LA, *> Most Restrictive g-SIS Specification:

18. PEI Models: 3 Layers/5 Layers

19. Concept of Stale-Safety Update AIP: Authorization Information Point AIP AIP AIP AIP ADP: Authorization Decision Point ADP ADP ADP AEP: Authorization Enforcement Point AEP

20. g-SIS Enforcement Architecture/Models • Allows offline access • Assumes a Trusted Reference Monitor (TRM) • Resides on group subject’s access machine • Enforces group policy • Synchronizes attributes periodically with server • Objects available via Super-Distribution • Encrypt once, read wherever authorized

21. g-SIS Subject Attributes Join-TS Leave-TS Time of Join NULL Time of Join Time of Leave Object Attributes Add-TS Remove-TS Time of Add Time of Remove Time of Add NULL Join Add Never Group Subject Current Group Subject Past Group Subject Never Group Object Current Group Object Past Group Object Join Leave Add Remove Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & Remove-TS(o) = NULL

22. g-SIS Architecture 3.2 Set Leave-TS (s) 4.2 Add o to ORL CC: Control Center GA: Group Administrator CC 4.1 Object Remove (o) 5.1 Request Refresh 5.2 Update Attributes 3.1 Subject Leave (s) 1. Read Objects … Group Subjects GA TRM TRM TRM • Subject Attributes: {id, Join-TS, Leave-TS, ORL, gKey} • ORL: Object Revocation List • gKey: Group Key Object Attributes: {id, Add-TS} Refresh Time (RT): TRM contacts CC to update attributes

23. Staleness in g-SIS RT: Refresh Time Was never authorized Request (s, o2, r) Add (o1) Join (s) Add (o2) RT1 RT2 RT3 RT4 RT0 Request (s, o1, r) Leave (s) Was authorized at recent RT Authz (s,o,r) Add-TS(o) > Join-TS(s) & Leave-TS(s) = NULL & o NotIn ORL

24. Stale-Safe Security Properties • Weak Stale-Safety • Allows (safe) authorization decision to made without contacting the CC • Achieved by requiring that authorization was TRUE at the most recent refresh time • Strong Stale-Safety • Need to obtain up to date authorization information from CC after a request is received • If CC is not available decision cannot be made

25. Properties Stale-unsafe Decision RT Perform Join Add Authz Request Perform Request Perform Formula Formula Weak Stale-Safety: Strong Stale-Safety:

26. Conclusion Security tools for a brave new world • ACE • PEI • UCON