1 / 22

Flexible Regulation of Virtual Enterprises

Flexible Regulation of Virtual Enterprises. Naftaly Minsky Rutgers University. Joint work with Xuhui Ao. Outline. The challenges to access control posed by e-commerce. Regulation of virtual enterprises — a case study.

salali
Download Presentation

Flexible Regulation of Virtual Enterprises

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Flexible Regulation of Virtual Enterprises Naftaly Minsky Rutgers University Joint work with Xuhui Ao

  2. Outline • The challenges to access control posed by e-commerce. • Regulation of virtual enterprises — a case study. • The law-governed interaction (LGI) mechanism, and how it meets the challenges to access control. • Conclusion

  3. The Challenges to AC • The distributed and open nature of E-commerce, and its scale. • PKI facilitates scalability; • but enforcement of AC policies is still done largely in a centralized fashion, making it hard to scale. • The need for more sophisticated policies, e.g., • Stateful policies, sensitive to the history of interaction, like budgetary control. • Policies that mandate extra actions, like state change, or auditing.

  4. The Challenges to AC (cont) • The need for communal (rather than “server-centric”) policies, such as: • An enterprise-wide policy governing a set of servers. • Decentralized electronic marketplace. • B2B commerce, and supply chains. • The need for interoperation between different policies, and for hierarchical organization of policies. • All these challenges need to be met via a single scalable mechanism—for specifying policies, and for enforcing them.

  5. E3 P3 E2 E1 P1 P2 PC Governance of Virtual Enterprise(a Case Study) • Consider a coalition C of enterprises {E1,..., En}, governed by a coalition-policy PC---where each Ei is governed by its own internal-policy Pi . • As in: virtual enterprises, supply chains, grid computing, etc.

  6. $1 E3 $1 $1 $1 E2 E1 $1 $1 $1 P1 P2 PC Policies Governing a Virtual Enterprise(an Example) Roles: each Ei should have its director Di(*); and the coalition C a director DC. A director Di can mint Ei-currency $i needed to pay for services provided by Ei and it can giveDC some of this currency A director DC can distributesome of its $i currency among other directors. $i Currency cannot be forged—by anyone! Servers at E1 can send their earning in $1 back to their director A director D2 can distribute its $i budget among agents at its enterprise

  7. The Main Challenges • The flexible formulation of such policies, so that: • they will be consistent, and • their specification and evolution would be manageable. • Enforcement of such policies, and in a scalable manner.

  8. The Compositions Approach… • Given the set {PC , P1,. . ., Pn} of policies. • Construct a set composed policies: {Pi,j = composition (Pi , PC , Pj)} • Provide these compositions to the reference monitor (RM) that mediates all coalition-relevant interactions. • Compositions were studied by: Gong & Qian 96, and by Bidan & Issarny 98, ...

  9. … and its Problematics • It is unlikely for arbitrary, and independently formulated, policies to be consistent—so such composition is likely to fail. • Policy composition is computationally intractable(McDaniel & Prakash 2002)—and, we need N^2 such compositions! • Inflexibility: consider changing a single Pi . . .

  10. The Proposed Approach • Instead of creating N^2 compositions (Pi , PC , Pj), we will enable each enterprise Ei to create it own policy Pi , subject only to the constraint that Pi would conform to PC . • We will then allow Ei and Ej to interoperate, each enforcing its own policy, Pi & Pj respectively • We will do this via the control mechanism called law-governed interaction (LGI).

  11. Law-Governed Interaction (LGI)(main characteristics) • LGI is an access-control and coordination mechanism • LGI is communal: can impose mandatory policies (called “laws”) over an entire community. • Enforcement is decentralized for scalability (actually, supports a whole spectrum of decentralization). • Supports a wide range of laws including those that mandate extra actions, in a stateful manner. • Supports hierarchy and interoperability. • Efficient (overhead of about 0.1 ms), and incremental. • Due to be released this summer.

  12. v u m ==> x m P m’ m ==> y y x I S Reference monitor Legend: P---Explicit statement of a policy. I---Policy interpreter S---the interaction state of the community Centralized Enforcement of Communal Policies * The problems: potential congestion, and single point of failure * Replication does not help, if S changes rapidly enough

  13. m ==> y m m v u L L I L I L m ==> y y Su Sy I x I Sx S L m’ I Sv m’’ Distributed Law-Enforcement under LGI

  14. controller server controller server I I I I I I m ==> y y x m’ adopt(L, name) L L adopt(L, name) m’’ Deployment of LGIvia a Distributed TCB (DTCB)

  15. L I L m ==> y y CSy I x CSx [m’,hash(L)] Cx m’’ Cx Cy On the basis for trust between members of a community • For a pair of interlocutors to trust each other to comply with the same law, one needs to ensure: • that the exchange of messages is mediated by correctly implemented controllers . • that interacting controllers operate under the same law L. • Such assurances are provided, basically, via certification of controllers, and the exchange of the hash of the law.

  16. Hierarchy Organization of Coalition Policies(back to the case study) PC superior subordinate P1 P2 Pn Pi is defined as subordinate to Pc, as thus constrained to conform to it.

  17. E3 P3 E2 E1 P1 P2 PC Interoperability • Let us focus on the interoperability between E2 and E1

  18. controller controller P1 P2 export(m,y,P1) imported(x,P2,m) m I I CSx CSx x y Cx Cy E2 E1 Authenticated by CA2and CAC Authenticated by CA1and CAC Interoperability (cont.)

  19. Conclusion • LGI implementation via the Moses middleware is to be released in May 2005, via:http://www.cs.rutgers.edu/moses/ • This initial release would not support policy hierarchy. • For a complete treatment of the coalition problem, see: Flexible Regulation of Distributed Coalitions Ao and Minsky In Proc. of the 8th European Symposium on Research in Computer Security (ESORICS) October 2003.

  20. Questions?

  21. Server-Centric Access-Control (AC) server Reference Monitor(RM) It generally supports only stateless, purely reactive, ACL-based policies, enhanced with RBAC—and this is far from sufficient.

  22. delegate The communal policy may be that certain type of transactions need to be monitores… Enforcing a Communal AC Policy Enterprise-wide (communal) policy P Enterprise

More Related