wiki:Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Version 4 (modified by hedinger, 18 years ago) ( diff )

ORBIT Threat Analysis

The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has complete access to each and every ORBIT resource he or she needs to perform each phase of an experiment without giving each user root privileges. Each identifiable task of each phase could be a role and a user need only have the commensurate 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 project members can see all project 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 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.

Noting 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 or otherwise filter data?

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 enforced use of web access to ORBIT services (as an ORBIT policy) have any access control implications?

Are there any requirements related to version control? 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?
Note: See TracWiki for help on using the wiki.