Difference between revisions of "User:Infinity Linden/OGP Trust Model"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
{{Quote|Computers should do exactly what you tell them, and no more.|John Steven (noted internet security expert)}}
<blockquote class="templatequote">
<div>
<p>Computers should do exactly what you tell them, and no more.</p>
</div>
<div class="templatequotecite">—<cite>John Steven (noted internet security expert)</cite></div>
</blockquote>


=Introduction=
=Introduction=


The term "trust" in the domain of information systems is a collection of related concepts, many of which do not yield gracefully to analysis. Without delving into the depths of academic descriptions of "trusted systems" or "verifiable security," we can describe trust as a system "doing what it's supposed to do" while not "increasing the opportunity for exploitation by bad actors." This "trust model" is an initial effort to enumerate stake-holders in the system and describe their security objectives. "Trust," in this since is simply the expectation that the system will "do the right thing" and how we plan to  verify remote system are behaving in a manner we expect.


We start with the User Stories section, introducing narratives describing situations legitimate system users may find themselves in and what the system should do to maintain "high confidence" that bad actors are not able to erode trust the system will either deny illicit manipulation or detect and allow recovery from it.


=Security Objectives=
We continue by enumerating stake-holders in the system and briefly noting their requirements. We've listed End Users, Content Creators, Corporate IT, Agent and Region Domain Operators as major stake-holders. These are the people who have an interest in maintaining "trust".


==secret things stay secret (confidentiality)==
Next we look at "security objectives." These are high level descriptions of behaviors we wish the system to express.


==you should know who you're talking to (origin integrity)==
The Common Threats section attempts to catalog "bad behaviors" that should be identified and defended against.


==you should be able to spot message tampering (message integrity)==
Finally, the Implementation Notes section provides guidance on converting information in this document into practical, deployable systems.


==accessing the grid shouldn't make your system or network unduely vulnerable (system integrity)==
=User Stories=
 
==you should be able to spot atypical events in the logs (adjudicated forensic evidence)==
 
==the permission system should be suitably expressive (expressive permissions)==


=Stakeholders and their Interests=
=Stakeholders and their Interests=
Line 68: Line 71:


* '''limitation of sensitive data''' - the system should not REQUIRE third parties to handle sensitive information
* '''limitation of sensitive data''' - the system should not REQUIRE third parties to handle sensitive information
=Security Objectives=
==secret things stay secret (confidentiality)==
==you should know who you're talking to (origin integrity)==
==you should be able to spot message tampering (message integrity)==
==purchases or transfers should be properly recorded (non-repudiation)==
==accessing the grid shouldn't make your system or network unduly vulnerable (system integrity)==
==you should be able to spot atypical events in the logs (adjudicated forensic evidence)==
==the permission system should be suitably expressive (expressive permissions)==


=Trust "Layers"=
=Trust "Layers"=
Line 78: Line 99:


==Political Layer==
==Political Layer==
=Common Threats=
=Implementation Notes=

Revision as of 15:57, 11 August 2008

Computers should do exactly what you tell them, and no more.

John Steven (noted internet security expert)

Introduction

The term "trust" in the domain of information systems is a collection of related concepts, many of which do not yield gracefully to analysis. Without delving into the depths of academic descriptions of "trusted systems" or "verifiable security," we can describe trust as a system "doing what it's supposed to do" while not "increasing the opportunity for exploitation by bad actors." This "trust model" is an initial effort to enumerate stake-holders in the system and describe their security objectives. "Trust," in this since is simply the expectation that the system will "do the right thing" and how we plan to verify remote system are behaving in a manner we expect.

We start with the User Stories section, introducing narratives describing situations legitimate system users may find themselves in and what the system should do to maintain "high confidence" that bad actors are not able to erode trust the system will either deny illicit manipulation or detect and allow recovery from it.

We continue by enumerating stake-holders in the system and briefly noting their requirements. We've listed End Users, Content Creators, Corporate IT, Agent and Region Domain Operators as major stake-holders. These are the people who have an interest in maintaining "trust".

Next we look at "security objectives." These are high level descriptions of behaviors we wish the system to express.

The Common Threats section attempts to catalog "bad behaviors" that should be identified and defended against.

Finally, the Implementation Notes section provides guidance on converting information in this document into practical, deployable systems.

User Stories

Stakeholders and their Interests

End User

This is the traditional user of the system. They may be a casual user of Second Life or a corporate user, come to the grid to collaborate on "work" projects. In either case, their interests include:

  • credential integrity - "bad guys" shouldn't be able to steal their online identity
  • inventory integrity - the system should protect against inventory theft, loss, or usability problems
  • specie integrity - the system should protect against loss of Linden Dollars

Content Creator

These are users who derive an income stream from Second Life. In addition to interests of traditional End Users, Content Creators also have these interests:

  • content integrity - content creators want to know that content they create cannot be illicitly duplicated, lost or stolen

Corporate IT and ISP Operations

These are the people who maintain networks connecting the client's machine to the network, and in the case of corporate IT operations. they likely manage the user's systems as well.

  • 'network security - no system component (client software, agent domain software, region domain software, third party web service) should decrease the general availability, reliability or security of the network
  • peer system security - no system component (client software, agent domain software, region domain software, third party web service) should increase the risk of successful attack versus other systems in the network on which they operate

Client Software

This is the actual software running on the client machine; usually a viewer, but could be a web application using standard published APIs into the Agent or Region domains.

  • system security - use of the Second Life viewer or other client software should not place the user's system at greater risk of successful attack
  • flexible peer authentication - the system should be flexible enough to support multiple legacy peer authentication schemes

Agent Domain Administrator or Region Domain Administrator

This is the organization that operates an agent and/or region domain.

  • peer authentication - the system should support strong authentication techniques to ensure the identity of peer systems
  • flexible agent authentication - the system should be flexible enough to support domain-specific user authentication
  • forward security - for the purpose of third party the system interoperability, the system should provide authentication tokens usable ONLY for the explicit purpose described

Agent Domain Software / Systems or Region Domain Software / Systems

This is the software that implements agent and/or region domain services.

  • flexible peer authentication - the system should be flexible enough to support multiple legacy peer authentication schemes

Third Party Web Service Operators

These are systems operated by third parties for the benefit of Second Life users, Agent or Region Domain operators.

  • limitation of sensitive data - the system should not REQUIRE third parties to handle sensitive information


Security Objectives

secret things stay secret (confidentiality)

you should know who you're talking to (origin integrity)

you should be able to spot message tampering (message integrity)

purchases or transfers should be properly recorded (non-repudiation)

accessing the grid shouldn't make your system or network unduly vulnerable (system integrity)

you should be able to spot atypical events in the logs (adjudicated forensic evidence)

the permission system should be suitably expressive (expressive permissions)

Trust "Layers"

System Layer

Network Layer

Application Layer

Political Layer

Common Threats

Implementation Notes