This wiki site will be offline Weds, July 6th, 2022, from 5:30-8:30 PM CDT in order to upgrade Confluence
Skip to end of metadata
Go to start of metadata

Document Name: NCSA CUI Access Control Standard
Version: 1.0
Accountable: Alex Withers
Authors: Margaret Johnson

Reviewed: N/A
Approved: Dec 16, 2021 by IIB

Purpose

This document specifies the procedures for granting, revoking and auditing access control to systems processing or storing CUI (Controlled Unclassified Information).

Scope

These processes apply only to staff in the NCSA Staff with ACHE Access. NCSA customers are responsible for authorization decisions of their own staff and can manage their access control groups directly. A Principal Investigator (PI) is responsible for authorization decisions for their project teams and can modify group credentials directly. Regardless of the approval process, NCSA will record the access changes made by customers or PIs to ACHE resources through its authorization framework.

Procedures

NCSA will track approvals and changes made to access groups, keeping records for 6 years or from the inception of the program. Each step of the following workflows is approved by a member of the NCSA Staff with ACHE Access while logged in with their personal credentials, and each approval sends emails to the approver and other relevant parties.

Alerts are sent to the Security Office and CISO anytime there are direct modifications to the group management system that were not triggered by the approval workflow engine. Such legitimate changes are checked for by automated systems at least daily.

Authorization

NCSA staff must be within the NCSA Staff with ACHE Access to make a valid request to be added to a system access group for system processing or storing CUI. Being in the NCSA Staff with ACHE Access itself does NOT grant any access, which must instead be requested by the staff member via the following process.

  1. Staff member submits request for access with the stated reason for the request. This request contains the requested access group name. 
  2. Staff member's manager approves or rejects the request.
  3. Approved request proceeds to the CISO who considers the staff member's role and reason for the request. They also verify that the person has taken approved CUI training (N.b., CUI training requirements are still TBD).
  4. If approved and they are in the NCSA Staff with ACHE Access group, they are added to the requested group(s).
  5. Emails are sent to the staff member, their manager and the CISO.

Deauthorization

Deauthorization can happen automatically or by request. For example, being removed from the staff group upon leaving the NCSA will automatically remove one from the NCSA Staff with ACHE Access and by consequence from any access group for systems with CUI. Therefore, even if a person leaves NCSA and has another legitimate reason for access in another unit, they will have to be reapproved by a PI in that unit to be added to the necessary group(s) for their project. The security office can also disable credentials and remove anyone from any group at anytime, though an alert will be sent to them and the CISO.

Employees, their managers, and the CISO can request de-authorization as well via the following workflow.

  1. Employee requests removal with justification and the access control groups they need to be removed from. (Optional: Can start with their manager)
  2. Request is received by (or starts with) the employee's manager who approves the request or fills in the same details if they start the request. (Optional: Can start with the CISO).
  3. The CISO either receives the request or starts a new one specifying the person and which groups they are to be removed from.
  4. If approved, the person is removed from the access control groups.
  5. Emails are sent to the staff member, their manager and the CISO.

Audits

All NCSA group owners are required to review group membership annually and approve or modify it. This includes customers and their point of contact and PIs at the University. Access control groups that provide access to systems with CUI are owned by the CISO who must do the same, or the group is suspended automatically.

  • No labels