Security Usecases

From Second Life Wiki
Revision as of 13:43, 15 October 2007 by Burhop Piccard (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Writing Usecases

These use case follow Alistair Cockburn's template. Note that there are several stages of usecase. If you want to grab a template for the early stage of a use case, you can get it here

Firewall Realted Use Cases

Use Case: Asset Security

Goal in Context:

Private assests owned by an avatar (identity) should not be identifiable or usable by any other avatars (identities) unless the avatar chooses to change the permission. Avatars should not lose control of these assets if they move to other regions.

Scope:

Permisions on assests

Level:

Primary Task

Primary Actor:

avatar, asset, asset permission

Priority:

Protecting personal assests and their value is a very high priority.

Frequency:

Expected to happen frequently (every session).


Use Case: Region Script Secruity

Goal in Context:

Regions should be able to control the execution of Scripts brought in by assets of avatars. For example, a secure region inside a firewall should be able to prevent scripts in rez'ed assets from listening to chat or scanning for other avatars. Basically, we need to prevent spying in secure regions.

Scope:

avatar operating inside a "secure" region

Level:

Primary Task

Prrimary Actor:

avatar inside a "secure" region such as behind a firewall.

Priority:

This is a priority for private regions where it is important to prevent the uncontroled outward flow of information.

Frequency:

This is expected to be a key issue for organizations and corporations attempting to protect information.


Use Case: Prevention of unauthorized Access

Goal in Context:

A secure region should be able to prevent unauthorized avatars (identities) from accessing or viewing a region. It should not be possible to "fake" the identity of a valid avatar.

Scope:

Avatar

Level:

Primary task

Primary Actor:

Avatar with invalid "identities" or faked "identities"

Priority:

This is a key requirement for any non-public region.

Frequency :

This will occur with any non-public region.