ORBIT Threat Analysis

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. Each identifiable task of each phase of each type of experiment could be a role, and a user need only have the certain privileges when acting in a given role.

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.

It is assumed that all members of a given project can see all of that project's scripts, programs and data, but not all scripts, programs and data belonging to each member of the project.

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.
• unintended read access to a user's or a project's experimental scripts or locally developed components or data results by other users or projects.
• intentional or unintentional modification or deletion of a user's or a project's scripts or own components or data results by nonproject members.
• unauthorized access to ORBIT system code, esp., device driver source or controller scripts.

Nothing should affect the integrity of experimental results nor any project member's ability to properly interpret those results.

Who (what role on the project) is allowed to change data, i.e., remove outliers, otherwise filter data, or delete data sets?

Is it possible that user- or project-developed components may have hidden dependencies on its own or other component's history?

Does the full support of real-time measurement require dedication of some resources above and beyond normal experiments, e.g., impairing other's access?

Does the preferred use of web access to ORBIT services (as an ORBIT policy) have any access control implications?

Are there any requirements related to version control? Is it safe to assume that each project will keep track of it?

Are there any other threats that might require the use of RBAC with ORBIT?

How are each of these goals affected by or depend upon

• Separation of Duty (SoD),
• the Principle of Least Privilege, and
• Timely Revocation of Trust?