Advanced Collaborative Environments Research Group
Page 1 of 1
Advanced Collaborative Environments Research Group
Agenda for GGF5
Session 1
z
z
Review merged security requirements document
Areas covered:
{ AccessGrid environments
{ Tele-Immersive environments
{ Remote Visualization environments
{ Dynamic and Asynchronous environments
Session 2
z
z
Discuss other areas relevant to ACE:
{ File transfer: William Allcock
{ Web services: Markus Lorch [mlorch@vt.edu]
Fusion community- General Atomics to talk about their requirements for collaborative environments.
file://C:\Documents%20and%20Settings\Jason%20Leigh\My%20Documents\Spiff\Grid%2... 7/2/2002
Application-specific Security Requirements of
Advanced Collaborative Environments
Final Template due May 13, 2002
Deb Agarwal, Brian Corrie, Yuri Demchenko, Jason Leigh,
Markus Lorch, Bob Olson, Mike Papka, Mary Thompson,
Jimmy Scott, Derek Simmel, Von Welch
-
-
-
-
Authors of document
Contact email address
Short name of the scenario
Description of the scenario (use diagrams where helpful)
Intended community for the scenario
What needs to be protected?
o Access (read/write) to stored data
o Access (execute/modify) to shared code
o Communication channels (send/receive)
ƒ Control channels
ƒ Data channels
o Mailing lists/addresses (read/send)
o Special vulnerabilities for this scenario
For each asset (data, code, communication, etc), estimate its value in terms of cost to recover it if
lost, damaged, or compromised:
o If sensitive information is inappropriately disclosed, what regulatory penalties may
apply? What losses are anticipated in terms of intellectual property control?
o If data is lost or damaged, what are the costs associated with recovering it? If
preparations need to be made to detect such loss or damage, and allow recovery (i.e.
backups, checkpoints, etc), what are the costs to deploy and operate such recoverability
means?
o What costs are expected in terms of time and effort to reschedule and reprocess data?
What threats are expected?
o Random hackers who want to disrupt something
o Colleagues who have been explicitly excluded
o Outsiders who want to steal software, data or compute cycles
What Security features do you need and which of the protected items need them?
o Integrity - messages and data can't be secretly modified
o Confidentiality - protection from disclosure to unauthorized persons
ƒ For how long
ƒ Confidentiality of persistent data and data in transit
o Authorization, access control - Unauthorized users are kept out
ƒ Should all the collaborators know who is authorized or just the administrator
o Authentication - assurance of identity of persons
ƒ As individuals or just as a group members
o Auditing - permanent log kept for accountability and possible error recovery
o Non-repudiation - originator of data can't deny it later
o Survivability - recovery from attack or failure
o Availability – performance and access
Template Designers:
Mary Thompson (MRThompson@lbl.gov)– get the security jargon correct for us
Derek Simmel (dsimmel@psc.edu) - best practices: will help find a security person who can describe
known models- like ones in IETF – and ask them to volunteer to give a presentation
Jason Leigh (spiff@evl.uic.edu), Brian Corrie (brian.corrie@newmic.com) - Teleimmersion
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Deb Agarwal (DAAgarwal@lbl.gov), Markus Lorch (mlorch@vt.edu) – Dynamic and asynch collaboration
Bob Olson (olson@mcs.anl.gov) – Access Grid
Mike Papka (papka@mcs.al.gov), Jimmy Scott (jcs@sgi.com) – Remote visualization
Yuri Demchenko (demch@terena.nl) - European reviewer
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Summary of Security Requirements for Advanced Collaborative Environments
Summary of Security Requirements for Advanced Collaborative Environments
Global Grid Forum Draft
July 1, 2002
June 26, 2002 8am
AccessGrid
Contributor
Robert Olson
Jason Leigh
(olson@mcs.anl.gov
(spiff@evl.uic.edu
Argonne National Lab) Electronic Visualization
Lab, UIC), Brian Corrie
(brian.corrie@newmic.com
New Media Innovation
Center, Canada)
Meetings over AG.
Permanent & persistent
Colleagues presenting meeting space that supports
results to each other.
collaborative discussion,
Distribution of
analysis, discovery using
presentation files.
tele-immersive technologies
such as CAVEs,
ImmersaDesks,
ImmersaWalls.
Audio/video
3 types of data- bulk
communications is
distributed data,
via Multicast
communication data
Distributed
(audio/video), state
presentation uses
data.
TCP for control
Central server keeps
messages
most recent state of
Spatial metaphor
persistent
for scoping
environment
Description
Assumptions
Tele-Immersion
Page 1
Remote Visualization
Michael Papka
(papka@mcs.anl.gov
Argonne National Lab)
Dynamic &
Asynchronous
Environments
Deb Agarwal,
(DAAgarwal@lbl.gov
Lawrence Berkeley
National Lab), Markus
Lorch (mlorch@vt.edu
Virginia Tech)
Coupling of AG with
On-going or ad hoc
need to access remote data collaboration that spans
servers that pass on data to time zones & involves a
visualization servers, that changing set of participants
then distribute the images & Grid resources
to multiple collaboratorswho can steer the
visualization.
Similar to TeleNot necessarily a
Immersion & AG
persistent central
See document for
authority for
details.
collaboration.
Set of authorized
collaboratiors is
larger than the set of
currently logged in
collaborators Both
Summary of Security Requirements for Advanced Collaborative Environments
for scoping
sessions- Virtual
Venues
Multimedia server
records raw media
streams- hence
server needs to be
considered a
particpant in the
meeting.
Community
What needs to be protected?
environment.
Bulk data sets are
downloaded,
modified and
infrequently
synchronized with
main server.
Small state data are
updated frequently.
3 types of
communication
channels- persistent
connections, transient
connections (e.g. each
bulk data access),
connectionless (e.g.
video or avatar)
Overhead must be
low for interactive
streams.
See document for
further details.
collaborators. Both
sets are changing
dynamically over
time.
Collaboration uses
wide variety of toolstext chat, audio,
video, whiteboards,
etc.
Academic & industrial Academic & industrial users Mainly research
users in many countries in many countries
communities.
Access to spatial
venues
Audio and video
streams
Presentation data
files- but not
control messages
(e.g. for "next
slide")
Recorded sessions
(open issue- see
Access to venues
(collaboration spaces)
Access to bulk data
sets
Access to
communication data
(audio, video)
Access to state data
(may or may not need
to be protected)
Business community:
Page 2
On-going & adhoc
collaborations in business
& academia
Access to data sets
2 types of data: data
Resulting images &
about the
image transmissions
collaboration, & data
Temporary data sets
generated as a result
that are created at
of the collaboration.
each stage of the
Both need to be
visualization
protected.
pipeline.
Minimum
expectation is only
authorized users can
read/write/create
Summary of Security Requirements for Advanced Collaborative Environments
document for
details)
What are expected threats?
Disruption
data should only be
viewable &
modifiable by
authorized groups /
individuals.
Audio/video must
always be encrypted.
Academic
community: Data may
be sensitive in some
cases (e.g. medical
data). But for the most
part data is publically
viewable, but not
modifiable.
Audio/video need not
be encrypted.
Unauthorized
Same as AG
connections to
specific comm
ports that a
distributed app
uses
Intrusion of
unwanted media
streams into
session from
outside users
Intrusion of badlyformatted media
streams that causes
stability problems
in distributed apps
Intrusion of highb d id h di
Page 3
data. Permission to
delete data is limited
to smaller set of
users.
Distributed data
storage facilities.
Audit trail needed to
track changes in
different versions of
the same file.
Same as AG
Same as AG
Summary of Security Requirements for Advanced Collaborative Environments
bandwidth media
streams that
consime more
bandwidth than is
available
Denial of Service
attacks
Privacy
Access
Data security
What security features are needed?
Integrity
(messages & data cannot be secretly be
modified)
Confidentiality
(protection from disclosure to
unauthorized persons)
Illegal snooping of
Same as AG
communications
channels may occur
Authorized &
Same as AG
unauthorized users may
attempt to illegally
read/modify presentation
data or media streams
Data may become
Same as AG
corrupted during
intentional / accidental
disruptions
Desired to prevent
spoofing of
presentation data
files.
Not neecessarily
needed for media
streams, especially
when participants
are known to each
other
Needed mainly for
corporate apps
Academic may need
to prevent accidental
modifications
Desired for
privacy of media
streams
Potentially
i df
For corporate dataAlways
For academic needed for duration of
j
Page 4
Same as AG
Same as AG
Same as AG
Same as AG
Same as AG
Same as AG
Likely to be minimal.
Encryption & secure data
storage is sufficient.
Both for original &
intermediate data
Encrypted graphics
streams should have
l l
Same as for
Integrity.
Length of time that
data should remain
fid i l i
Summary of Security Requirements for Advanced Collaborative Environments
required for
presentation data
files
Authorization, access control
(unauthorized users are kept out)
Authentication
(assurance of identity of persons)
Auditing
(log kept for accountability & error
recovery)
Desired that access to
Venues is controlled
when desired
Required perhaps @ level of
identification of
participating sites
Desired that
multiple
individuals @ AG
nodes be able to
authenticate to
session, in order to
implement finergrained access
control or to allow
credentials of an
individual to give
the AG node the
necessary access
to protected spaces
Logging of identities
may be good
project
Confidentiality for
bulk data can use
slower encryption
schemes
Streaming data should
use fast schemes
All collaborators should
know who is part of the
collaboration
low latency
confidential varies.
For data & visualization
resources
Required. But also need to
give limited access
permissions to some
participants.
Corporate: Individual Same as for Authorization Initial authentication should
authentication needed
be minimal & access rights
to track modifications
are granted incrementally
by individuals. Group
during collaboration.
authentication needed
for "show & tell" for
read-only data.
Group authentication
sufficient for
academic.
Crucial for corporate Not likely to be major
(track when someone requirement
has read / changed a
document)
Useful for academic
to track hen a
Page 5
Important. Audit needs to
identify the entity
participating & the entity
that authorized
participation.
Summary of Security Requirements for Advanced Collaborative Environments
to track when a
change was made &
by whom
Non-repudiation
Not an Issue
(originator of data cannot deny it later)
Not an Issue
Survivability
(recovery from attack/failure)
Mainly in corporate
Not an Issue
applications for
accountability. Nonrepudiation of what is in the
audit log is important.
Needed for both Same as AG
Most likely covered by
corporate &
authorization /
academic/scientific
authentication services
apps
Prevent illegal
messages or
messages from
unauthorized
sources
Not needed for minimal
system. Perhaps enhanced
system.
Prevent
Same as AG
connections from
unauthorized
clients
Prevent denial of
service attacks
Critical but should be
flexible. Denial of
unauthorized clients can
sometimes discourage
possible collaborations.
Availability
(performance & access)
To dos:
prioritization of security issues to address for each application
identify Grid services that can be most easily used to achieve requirements
identify Grid services still missing
Page 6
Application Security Requirements of
Access Grid Collaborations
July 2, 2002
Robert Olson
olson@mcs.anl.gov
Scenario: An Access Grid meeting
Description
A meeting of geographically distributed collaborators each using an Access Grid node. Several
collaborators are presenting results to their colleagues using a distributed presentation application. This
application requires the distribution of a presentation data file to each participating site.
Meetings may be recorded by a multimedia server for later playback.
[Scope question: do we want to discuss web services-based models? how much detail are we looking
for here; my understanding at the moment is that these are high-level scenarios]
Assumptions
- Communication between AG node users is via multicast audio and video.
- The distributed presentation application uses TCP connections between the sites to exchange
control messages.
- The Access Grid utilizes a strong spatial metaphor for the scoping of sessions. This metaphor is
implemented by a central Venues Server.
- The multimedia server records the raw media streams. This implies the server needs to be an
active participant in the meeting (from the point of view of the other participants and of the
infrastructure providing the mechanisms implementing the spatial metaphor.)
Community
The Access Grid community includes both academic and industrial users in many countries.
What needs to be protected?
To maintain the spatial metaphor, it is desirable that at all times it is well-known who the participants
in an Access Grid meeting are. Due to the nature of IP multicast routing, it is possible, knowing the
underlying multicast addresses used by a particular Access Grid session, to snoop on an unencrypted
audio or video session without the participants in the session knowing. This is a serious breach of the
metaphor, and can lead to the detrimental leakage of information from the session.
Therefore, to enforce the strict spatial metaphor, encryption of the audio and video streams is also
desirable. (However, there are uses of the Access Grid where strict adherence to the spatial metaphor is
not required, and the multicast addresses of the media sessions are widely disseminated. This scenario
does not address this situation).
Presentation data files need to be distributed to the sites involved in the collaboration. As the
distribution of these files can be accomplished by means which are not as easily snooped as the
multicast media traffic, protection of the files is not necessarily required. However if the data in the
files is sensitive, the owners of the files may determine that they should be protected from
unauthorized viewing.
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
The control connections used in the distributed presentation application need not necessarily be
protected, as sensitive data is not transferred over them. However, it may be the case that protection is
required to prevent disruption of a distributed presentation by a third party.
The recorded session (on the multimedia recording server) must be protected from unauthorized
examination. An as-yet-open issue here is the management of the session data. Options include
• Saving the data as it was presented on the wire. If it was encrypted, this implies the session
encryption key(s) are stored somewhere for the long term. It also implies that the server need
not know what the keys are.
• Decrypting the data as it arrives, storing it as cleartext, and re-encrypting upon playback with
the appropriate session key. This poses the risk where the data may be vulnerable while in
storage.
• Decrypting the data arrives, and re-encrypting it for storage with a different session key.
-
For each asset (data, code, communication, etc), estimate its value in terms of cost to recover it if
lost, damaged, or compromised:
o If sensitive information is inappropriately disclosed, what regulatory penalties may
apply? What losses are anticipated in terms of intellectual property control?
o If data is lost or damaged, what are the costs associated with recovering it? If
preparations need to be made to detect such loss or damage, and allow recovery (i.e.
backups, checkpoints, etc), what are the costs to deploy and operate such recoverability
means?
o What costs are expected in terms of time and effort to reschedule and reprocess data?
What threats are expected?
-
-
Disruption
o Unauthorized connections to specific communication ports that the distributed
presentation application uses.
o Intrusion of unwanted media streams into the session from outside users.
o Intrusion of badly-formatted media streams that may cause stability problems with the
media tools.
o Intrusion of high-bandwidth media streams that consume more bandwidth than is
available.
o Denial of service attacks
Privacy
o Illegal snooping of communications channels may occur.
Access
o Authorized and unauthorized users may attempt to illegally read or modify presentation
data or media streams.
Data security
o Data may become corrupted during intentional or accidental disruptions.
What security features are needed?
-
-
Integrity (messages and data can't be secretly modified)
o Desired to prevent the spoofing of presentation data files.
o Not necessarily required for media streams, especially in the case of sessions where the
participants are known to each other.
Confidentiality (protection from disclosure to unauthorized persons)
o Desired for privacy of media streams.
o Potentially required for presentation data files.
Authorization, access control (Unauthorized users are kept out)
o Desired that access to Venues is controlled when desired.
Authentication (assurance of identity of persons)
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Required that a certain degree of authentication (perhaps just at the level of identification
of participating site) exists in order to maintain the spatial metaphor.
o Desired that multiple individuals at Access Grid nodes be able to authenticate to the
session, in order to implement finer-grained access control or to allow the credentials of
an individual give the AG Node the necessary access to protected spaces.
Auditing (permanent log kept for accountability and possible error recovery)
o Logging of the identities of participants may be desired.
Non-repudiation (originator of data can't deny it later)
o
Survivability (recovery from attack or failure)
o Needed for both corporate and academic/scientific applications.
o Prevent illegal messages or messages from unauthorized sources.
Availability (performance and access)
o Prevent connections from unauthorized clients.
o Prevent denial of service attacks.
o
-
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Application Security Requirements of
Tele-immersive Environments
July 2, 2002
Jason Leigh, Brian Corrie
spiff@evl.uic.edu Brian.Corrie@newmic.com
Scenario: A tele-immersive meeting
Description
A permanent and persistent meeting space that supports collaborative discussion, analysis, and
discovery using tele-immersion technologies such as CAVEs, and ImmersaDesks.
Assumptions
- Communication between users of the space is supported through audio, video, application, and
interaction data being exchanged.
- Data is of 3 types: bulk data (such as 3D models or data sets), communication data (such as
audio/video), state data (such as the position of an object in an environment).
- Central server keeps the most recent state of the collaboration and holds the most committed
version of the environment.
- For bulk data sets: All clients may download a version of the data to work with collaboratively.
Edits are done locally first and commits are done infrequently.
- For smaller state information, edits are done locally and then state info is synched almost
immediately with the central server for broadcast.
- Peer to peer solutions are possible but in this scenario we assume a centralized solution.
- In some cases it is important to track when an update was performed and by whom.
- Data from each user in the collaboration is typically (but not necessarily) sent to all other
participating users (ie broadcast may be selective.)
- Data may be restricted to users with specific privileges.
- Persistent data is maintained as part of the space. Persistent data typically consists of application
data, archived meeting data (to support asynchronous collaboration), and user data.
- Types of Communication Channels:
o Persistent connections- connections for delivering reliable state information
o Transient connections- connections where bulk data files are transferred. Usually
performed by opening and closing one or many TCP connections.
o Connectionless- audio and video that are transmitted via multicast or unicast UDP
- Critical to the success of the collaboration is the interactive nature of the collaboration data that is
exchanged. The overhead involved in encryption and decryption of interactive data will add
significantly to the communication latencies for that data and therefore security concerns must be
carefully balanced with performance.
There are two main types of data that exist in such an environment, persistent data and transient data.
Persistent Data
The persistent data is data that is retained for long periods of time and is the data that is critical to the
application area. Persistent data might consist of one or more data sets (possibly a large database of
data sets), user data for the users that have access to the space, and asynchronous collaboration data
that has been archived for playback and exploration by other users in the system. This data is mission
critical in nature and needs most of the security features discussed below.
Transient Data
Transient data is data that is either extracted from the persistent data or it is data that is generated to
support the collaboration. Transient data would typically consist of application, application control,
audio, video, and interaction (avatar positions, user actions, etc.) data. Transient data can be made into
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
persistent data as required. Transient data is typically used in the collaboration, and it is this data that
needs to be balanced between the performance requirements of the collaboration and the security
requirements of the application. Various levels of data encryption (ranging from no encryption through
to high levels of encryption) and their associated impact on performance need to be understood and be
able to be applied to the data streams as required by the application.
Community
This application is intended for the academic/scientific and business community where immersion and
collaboration are both critical to the success of the problem solving process.
What needs to be protected?
Business Community
- Data should only be viewable and modifiable by authorized groups or individuals.
- Audio and video must be encrypted.
Academic Community
- Data may be as sensitive as those in the business community (for example in medical applications
involving sensitive patient data). But for the most part it is ok for data to be publicly viewable.
Data should not be publically modifiable.
- Audio and video need not be encrypted.
-
For each asset (data, code, communication, etc), estimate its value in terms of cost to recover it if
lost, damaged, or compromised:
o If sensitive information is inappropriately disclosed, what regulatory penalties may
apply? What losses are anticipated in terms of intellectual property control?
o If data is lost or damaged, what are the costs associated with recovering it? If
preparations need to be made to detect such loss or damage, and allow recovery (i.e.
backups, checkpoints, etc), what are the costs to deploy and operate such recoverability
means?
o What costs are expected in terms of time and effort to reschedule and reprocess data?
What threats are expected?
-
-
Disruption
o Unauthorized connections to specific communication ports that the server normally
listens to.
o Illegal connectionless messages that the server and clients do not know how to handle
and therefore causing the server/clients to crash.
o Denial of service attacks
Privacy
o Illegal snooping of communications channels may occur.
Access- Authorized and unauthorized users may attempt to illegally read or modify the data.
Data security
o Data may become corrupted during intentional or accidental disruptions.
o Data may be intentionally or accidentally erased by external entities.
What security features are needed?
-
Integrity (messages and data can't be secretly modified)
o Needed mainly for corporate applications.
o Academic/scientific applications may need to prevent accidental modifications.
Confidentiality (protection from disclosure to unauthorized persons)
o For persistent data – for corporate users, this is needed always. For academic/scientific
users, this may only be needed for the duration of the project.
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Transient data – for corporate users, this is needed always. For sensitive meetings,
academic/scientific users will also need this.
o Confidentiality of bulk data sets may use slower encryption schemes.
o Confidentiality of transient data should use faster encryption/decryption schemes due to
the time sensitivity of data. (ie latency must be kept to a minimum)
Authorization, access control (Unauthorized users are kept out)
o Should all the collaborators know who is authorized or just the administrator- all
collaborators should know who is part of the collaboration.
Authentication (assurance of identity of persons)
o As individuals or just as a group members – in corporate applications both group and
individual authentication is needed. Individual authentication is needed to track
modifications by individuals. Group authentication is needed to allow for “show and tell”
demonstrations where data is used mainly in a read-only state. In academic/scientific
applications group authentication should suffice.
Auditing (permanent log kept for accountability and possible error recovery)
o crucial for corporate applications (ie track when someone has read or changed a piece of
data).
o In academic/scientific applications, tracking when a change was made and by whom is
useful.
Non-repudiation (originator of data can't deny it later)
o mainly important in corporate applications. Non-repudiation of what is in the audit log is
important.
Survivability (recovery from attack or failure)
o Needed for both corporate and academic/scientific applications.
o Prevent illegal messages or messages from unauthorized sources.
Availability (performance and access)
o Prevent connections from unauthorized clients.
o Prevent denial of service attacks.
o
-
-
-
Brian’s notes:
Persistent data typically requires high levels of security and relatively low levels of performance
compared to transient data. Thus there is no reason not to provide a full range of security services for
this data. These services include data integrity, confidentiality, authorization, authentication, auditing,
non-repudiation, survivability and availability. All of these services may not be necessary for each
application but there is no reason why they cannot be supported.
The transient data in a tele-immersive collaboration is time critical and therefore there is a potential
conflict between having high levels of security at the same time as having low latency interaction
between users. Authorization and authentication are two critical components to providing security to
transient data. If unauthorized users cannot get access to the collaborative space then they cannot
circumvent the security through direct access. Thus the only other security risk is passive interception
of data that is being communicated during the collaboration.
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
Application-specific Security Requirements of Advanced Collaborative Environments
Remote Visualization
Michael E. Papka, Jason Leigh
papka@mcs.anl.gov, spiff@evl.uic.edu
Description:
There are multiple scenarios for remote visualization, some of which have similarity to other
application areas such as Tele-Immersion. Presented below are 4 such scenarios- some of which
include technologies (such as the AccessGrid) whose security requirements have already been
specified in a separate document, and so will only be referenced.
Scenario 1: Data and visualization server are collocated at some remote site, users’ wants to
access the visualization server and data, and then view the results from an Access Grid node or
desktop.
Figure 1 Basic remote visualization server with access from access grid or desktop system. Data
and visualization server are collocated.
Scenario 2: Data and visualization pipeline are distributed across multiple sites, users’ wants to
access the visualization pipeline and data, and then view the results from an Access Grid node or
desktop.
Figure 2 More complicated remote visualization server with different pieces of the visualization
pipeline distributed across sites.
Scenario 3: Collaborative visualization using multiple special purpose displays with both real
video and synthetic video shared with remote users.
Figure 1 Visualization sessions shared across multiple sites using a mix of advanced display
devices, with output shared to others via Access Grid or desktop.
Assumptions
Security needed for shared sessions as mentioned in scenario 3 discussed in teleimmersion
document and security associated with all 3 scenarios on Access Grid or desktop addressed in
Access Grid document.
Community
These scenarios are intended to support work going on in the research community but is by no
means limited to that space.
What needs to be protected?
Access to datasets needs to be protected both locally (standard file permissions and remotely
access to machines), as the data is transmitted to the location where the data is converted from
raw values into images, and transmission of the images to the user. It is also possible for the
visualization pipeline to be distributed; therefore temporary datasets that are created by one
stage of the pipeline need to be protected also.
What threats are expected?
Disruption, unauthorized access, privacy, corruption of data, unauthorized creation and deletion
of data.
What Security features do you need and which of the protected items need them?
- Integrity (messages and data can't be secretly or accidentally modified)
- Confidentiality (protection from disclosure to unauthorized persons)
o Both for original data and intermediate data
o Encrypted streams are needed- some streams are latency sensitive. In general
these are streams involving realtime remote visualization and steering. Hence
latencies that are accumulated as a result of encryption and decryption should be
minimized. For playback of pre-rendered data or raw data that needs to be
distributed apriori to the collaborating sites, the streams are not latency sensitive.
- Authorization, access control (Unauthorized users are kept out)
-
o For data and access to visualization resources
Authentication (assurance of identity of persons)
o For access to data and access to visualization resources
Auditing (permanent log kept for accountability and possible error recovery)
o Most likely not a major requirement
Survivability (recovery from attack or failure)
o Most likely covered by authorization and authentication services
Availability (performance and access)
Security Requirements of
Dynamic and Asynchronous Collaborative Environments
Template Draft July 2, 2002
Deb Agarwal (DAAgarwal@lbl.gov), Markus Lorch (mlorch@vt.edu)
Scenario – An on-going or ad hoc collaboration that spans time zones and involves a
changing set of participants
Description
This scenario describes a collaboration where the participants and duration are not necessarily known in
advance and the set of participants is changing often. It also describes situations where the collaborators
are often unable to interact in real time.
An example for such a collaborative scenario is a high level grid programming and execution environment
through which collaborators can combine their grid resources (e.g. data files and executables) to create,
execute and control a shared grid meta program. This system could consist of a shared workspace within
which the meta programs are created following the visual programming approach and a set of tools that
provide the user with other collaborative services for example for communication (chat) and data transfer.
It is possible for users to collaborate synchronously by viewing and modifying the shared workspace and
interacting through a chat window at the same time or asynchronously through the sharing of saved meta
program components, whole meta programs or simply by exchanging email or voice messages.
Assumptions
There is not necessarily a persistent central authority for the collaboration.
The set of authorized collaborators is larger than the set of currently logged in collaborators. Both these
sets are changing dynamically over time.
Collaborative interactions take place using a wide variety of tools including chat, audio, shared applications,
white boards, etc.
Community
This scenario is intended to support on-going and ad hoc collaborations in the business and academic
community.
What needs to be protected?
We anticipate that this type of collaboration will have both temporary and long-term data. This data will be
divided into the data about the collaboration itself (e.g. user lists, locations, tools in use, etc), the data
produced by the collaboration (e.g. conversation archives, activity logs, etc.), and data that is the subject of
the collaboration (e.g. shared files, drawings, etc.). We expect that all of this data will need to be protected.
The minimum level of protection expected is that only users authorized to access the collaboration can read,
write, and create this data. Permission to delete the data is likely restricted to a smaller set of users
particularly in the case of data about the collaboration and produced by the collaboration. At an enhanced
level of security, a user creating any particular data could specify more restrictive access rights to that data.
This collaboration scenario will likely use a combination of secure and insecure data transmission. Ideally
this can be decided per data transmission with a settable default for the collaboration. In most
collaborations, the data most likely to need protection during transmission is data that is the subject of the
collaboration. Some collaborations will, however, want all forms of collaboration data sent securely over
the Internet.
This collaboration scenario will also likely use distributed data storage capabilities rather than centralized
servers. Data may be stored in multiple locations. In an enhanced security environment, an audit trail for
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs
each data file would need to be kept in a secure way so that different versions of the same file are
recognizable and their history, authenticity, and modifications can be identified and verified.
What threats are expected?
Similar to the AG scenario – Disruption, unauthorized access, privacy, corruption of data, unauthorized
creation and deletion of data.
What Security features do you need and which of the protected items need them?
o Integrity - Our requirements here are likely minimal. It is expected that if this is an issue
that encrypted channels will be used for transmission and data storage locations will be
secured.
o Confidentiality - Our requirements here are also likely minimal. Again, it is likely that
encrypted channels and secure data storage locations will provide an adequate solution
here. Length of time that data should remain confidential, is likely to vary by
collaboration.
o Authorization, access control – Authorization access control is required in this scenario
but the mechanisms need to allow unauthorized users some limited access to request
further access and to accommodate cases where the user does not have their normal
authorization mechanisms available but needs to participate. Each authorized
collaborator should be able determine who is authorized in the collaboration.
In order to support ad-hoc, dynamic collaboration it is important to have privilege
management mechanisms in place that allow authoritative users to assign access
privileges to new collaborators without the need for system administrator intervention.
For example the host of a specific collaboration needs to be able to manage the
collaborative environment and assign fine grained privileges to participants. Furthermore
the owner of a shared object should be able to delegate access permissions to his object to
other users directly. This provides for incremental trust relationships that require a low
amount of trust to establish a collaboration. The administrative cost associated with such
privilege management should be kept as low as possible to make dynamic and short lived
scenarios feasible. In order to support the use of fine grained access privileges adequate
enforcement mechanisms are required that can efficiently and securely make access
control decisions.
o Authentication – Ideally, the initial authentication required to join the collaboration is
minimal and that instead access rights are built based on some incremental mechanisms
that allow much of the trust to be built through interactions.
o Auditing – It is important that a permanent log be kept for accountability and possible
error recovery. It is also important to be able to distinguish the identity of the entity
taking part in a collaboration from the identity that authorized the access to the
collaboration.
o Non-repudiation – is likely not an issue.
o Survivability – In an enhanced system, it would be designed for recovery from attack or
failure. But this is likely not available in a minimal system.
o Availability – The performance and access to the collaboration are critical. The
collaboration will only function well if collaborators are able to collaborate freely and
never encounter denial of service due to failure of the security mechanisms. This is likely
unrealistic but each failure of the security system to authorize a legitimate user risks the
rejection of the collaboration itself.
Global Grid Forum Advanced Collaborative Environments Research Group
Application-specific Security Requirements of ACEs