Changes between Version 20 and Version 21 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Timestamp:

Sep 20, 2006, 3:18:22 PM (18 years ago)

Author:

hedinger

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -3 +3 @@
 The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges.  The privileges needed to execute each identifiable task of each phase of each type of ORBIT experiment have been considered, and a set of roles defined to cover each of these situations using the principle of least privilege [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]].
 
-A longer term goal, also considered in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders.  Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she saw fit.  
+A longer term goal, also considered in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders.  Once a project was defined and a project leader assigned to it, that project leader would be able to add ORBIT users and add project members to his or her project and assign them roles within that project as he or she saw fit.
 
 It is expected that over the next few years there could be a thousand or more ORBIT users with many hundreds of ORBIT projects.  Many of these projects will have just a few members.  Some may have many members.  The membership of a project may well change over its lifetime.  Some members might be removed from a project intentionally, and, when that happens, access to the projects resources should no longer be granted to that former member.
 
-Implementing dynamic instead of static separation of duty will not impose overburdensome restrictions on the roles allowed for the few users on a small project.  A given member might be an Administrator on one project and just a User on two others.  Dynamic separation of duty allows a user to act in two conflicting roles on a single project at two different times.
+Implementing dynamic instead of static separation of duty should eliminate the possiblity of overburdensome restrictions on the roles allowed for the few members of a small project and on users that are members of more than one project.  A given member might be an Administrator on one project and just a User on two others.  Dynamic separation of duty allows a user to act in two conflicting roles at two different times.
 
-The use of dynamic separation of duty may diminish the care and checking needed when assigning roles, but it also strengthens the requirement to log accesses and to check those logs regularly.  Project administrators should check for project-level issues and system administrators for cross-project issues. 
+The use of dynamic separation of duty may diminish the care and eliminate any formal checking for conflicts needed when assigning roles, but it also strengthens the requirement to log accesses and to check those logs regularly.  Project administrators would check for project-level issues and system administrators for cross-project issues.
 
-Because ORBIT is designed to be operated as a service available to the research community, no one experiment should affect a future one, and each project must be protected from other projects.
+Because ORBIT is designed to be operated as a service available to the research community each project must be protected from other projects.  Experimental scripts, data and results must be private to the project.
+
+ORBIT is designed so that no one experiment should affect a future one.  This goal must not be compromised.
 
 Nothing should affect the integrity of experimental results nor any project member's ability to properly interpret those results.
 
-List of possible threats
+A list of possible threats:
  * intentional or unintentional disruption of experiments by nonproject members due to interference with ORBIT resources.
  * intentional or unintentional disruption of experiments by project members due to interference with ORBIT resources or project resources.