Many aspects of life at Rensselaer require additional training and testing. This may be for personal safety of the individual or others, protection of the equipment, regulatory compliance, etc.  This training may be done with online tools such as Percipio or CITI, or via more ad-hoc training programs set up by departments and staff.  A challenge remains in taking these "administrative" requirements and being able to apply them as needed and enforcing them. It may be desirable to link the compliance and training systems with the systems and processes that deliver access and apply the checks automatically.

Some recent projects allow for the deployment of normalized compliance training and credentials to be used for active enforcement of access to systems, data and places.  In addition to active control, this may also help with audit and reporting in cases where it is not desirable or possible to actually block access. All of these projects are in the process of design and immediate deployment, and provide key components to reaching "critical mass" for this project.

1. Automatic feeds of Percipio training and testing results.
2. Mapping Access Levels to normalized room data (initial data normalization in progress)
3. Shibboleth Compliance Notification project
4. CBIS Digital Transformation
5. Embedded ARTS - Mercer Lab
6. Upgrade (replacement) of Space Management System

Sources of Compliance

Training and testing may be done with online tools or via "manual" processes set up by departments and labs. For this project, our goal is to get the results into Simon "Compliance" groups. These groups can include controls over who can use, display and maintain "membership", and at the member level, we can include the date when the training was completed and the date when the training "expires".  Many compliance standards require that the person repeat the training on a regular basis, and many external system already maintain this information and may include reminder notifications.

Online Compliance Tools

Online tools such as Percipio or CITI have a department or group overseeing their operation, and these already have expiration and reminder management built in. We still have the challenge of identify WHO needs to be included.  For our automation, we want to generate a compliance report and read it into Simon, to automatically create groups for each training, and populate the membership of each group with starting and expiration dates (if applicable).  We also need to provide a configuration tool for the group that supports that tool, so they can adjust defaults, control availability of results, hide "obsolete" trainings, etc.

1. Percipio - This was used during COVID to provide a training requirement for general campus access.  This involved a manual request (online) for a report, downloading the report once available, and then loading it into Simon Groups (drag and drop the file).  Work is ongoing to automate this process so the file will be generated, transferred and processed on a daily basis, making all Percipio courses available for compliance checking.
2. CITI - This data is already being loaded into the Data Warehouse for some financial and grant compliance activity. We were able to load that file into a set of Simon Compliance groups.  This is refreshed on a daily basis.
3. Assurance Level - a future project; level of assurance deals with how "certain" we are the credentials being offered to a service, are in fact held be the person we believe to hold them.  This may require that the person present government issued ID credentials, or some other process to validate their identity. This is indicted by a set of levels. It might be possible that if an account is compromised, we might drop the level of assurance until corrective measures are completed.  
4. Financial Conflict of Interest?  No information on this yet, but someone expressed interest in controlling some application access based on this.

Manual Compliance Tools

These are typically implemented using one or more Simon groups, where the administrator adds (and removes) people as their training is completed.  Simon groups included an expiration date that will automatically remove people on that date, and also will remove people when they leave Rensselaer. History is maintained of when people are added and deleted from groups.  Groups are already used in many different cases.  Both administrators and faculty have been using these.  For compliance purposes, we already have some cases in use (there may be others)

1. HASS Workshop - There are a number of tools that require specific training and approval for use.  The HASS shop staff maintain a set of groups indicating completion of training and approval for use. When a person "taps in" at the shop, a list of completed approvals is displayed.
2. Mercer Lab - Like the HASS shop, Mercer has specialized equipment available for use.  There is a related project to add electronic interlocks that will enforce the training requirements.
3. Architecture Workshop - Is very interested in the Mercer work as well as the Percipio group feed.

Consumers of Group Data

This change, will put a "filter" between the membership in the Simon group, and its use by endpoint systems. This gives is a known set of interfaces that need to be modified in order to provide the compliance filtering we want. Groups are refreshed periodically, and this allows compliance completion to update the membership in the external systems. As most group membership checks take place outside of Simon, this gives us a limited number of places we need to add compliance checking.

1. Active Directory - These are fed from a single ORDS endpoint.  These are used by many to control access to systems, files and other resources.
2. Grouper - Similar to AD, biggest consumer is shibboleth the provides authentication for our Single Signon based services and can provide messaging ("Your training needs to be refreshed for access to this service to continue") to blocking service access entirely.
3. Banner Group Feed view - this is an Oracle view that allows Banner based applications to feed other systems with group memberships,  Currently used for some Percipio administrative groups.
4. BOX Group feed - In cases where data stored in BOX needs additional compliance training (Say some student data that requires that people seeing it have completed the FERPA training).  
5. Sympa (Mailing list) feed - an interesting question - we might want to provide three group feeds.  There may not be any automatically fed lists with compliance requirements.
   1. All members (no compliance checking)
   2. Members in Compliance
   3. Members Not in Compliance.
6. ARTS Events - Some ARTS events use group membership to determine "Access" to events.  There are also examples where at checkin, the lab monitor gets a list of equipment the person is allowed to use. This is based on group membership.
   1. Embedded ARTS events - there is an active project in the Mercer Lab to develop embedded system control (Raspberry Pi) that will check access and electrically control access either by providing power to the equipment or a control signal that will be connected the equipment controls.  We hope to have a prototype demonstration by the end of the semester.
   2. Virtual Embedded Controller - Using custom links, typically provided via QR code, people will connect to the ARTS remote check in to control a commercially available remote controlled power distribution unit.  Some development work is still required.
   3. Specific Compliance/Training ACLS - Essentially an alternate interface to the Group ACL support to allow for direct selection from the Compliance groups.
7. OnGuard access levels - many Access Levels control access to spaces that require compliance training for access.  Where we are using group membership to feed access levels, we can include the compliance  (training) check before enabling the access level. Once the person completes the training, the access level will be granted automatically.  Likewise, when their compliance "expires", their access will be revoked.  During COVID, Percipio training was required for campus access.  This is a generalization and expansion of that control.
   1. Custom tools will be made available to Public Safety so they can check a person's compliance status when they are asked ("Why doesn't my card work?")
   2. A daily (or weekly) report of access levels added and removed may be desired.
8. Simon Applications - Many Simon applications used groups to control access.  Some of these may require compliance training as well.
9. "My Access Status" - This is a new application that will allow people to check on their access requests. This will include both requests that are going through the approval workflow process, and existing access that has been approved, but is pending compliance training.  This can include both physical access (OnGuard) requests, as well as system and data access that is being protected by group membership.  This is a new tool being developed as part of the CBIS Digital transformation project.

Group Sources

Group membership can come from a number of sources, all of which can potentially be used with the Unified Compliance checking.

1. Simple Workflow Request - people can go to a web page and request access, which then goes into an approval workflow, where designated people need to approve (or reject) the access request. This is being used by the Mercer Lab.
2. Complex Workflow Request - The CBIS digital transformation project will provide an environment to provide a number of different access requests in since web site. This builds on the Simple Workflow Request.
3. Automatic Demographic based feeds.
   1. Based on course enrollment (already used for a number of access levels)
   2. Based on school affiliation or Major
   3. Based on Employment attributes (Position Group, department, title, etc)
4. Manual management via the group tool - group member administrators manual add and remove people from groups (there are bulk load options).
5. Complex groups based on group functions (AND, EXCLUDE)

Outstanding Technical Work

There are a number of technical tasks that need to be completed. In many cases, these will involve policy decisions.  These questions should become apparent as we do the implementation and will be worked out with the appropriate people at that time.

1. Online Compliance Configuration tool - Normalize compliance results
   1. CITI and Percipio modes (different sets of administrators)
   2. Training Course Specific (settings, course admins, etc)
   3. Course Admin modes
   4. Equivalent Course = more than one course that satisfies the same requirement.
   5. Exception Management
      1. Short term onboarding (you have 2 weeks to get trained, or access will be revoked)
      2. Long term exceptions - most likely for visiting/external  researchers and facility users.
2. Simon Group changes for compliance checking.  These are new fields and can be applied to any existing group as needed.
   1. List of required Compliance/Training (based on the normalized compliance groups from item 1)
   2. List of refusal groups - allows for forced blocking of access - do not have a current use case for this facility, but might be useful.
   3. Access Name, Access Description - used for the status reports and user view
   4. Enforcement Switch - allows for use in "check only" mode
   5. Private Switch - do not report on compliance or include in user status
   6. Lock switch - once set up, this would "lock" the record, preventing changes until there is intervention by a senior administrator.
   7. Group Member Changes
      1. Last Checked Date
      2. Approved/Denied status
3. Simon Group Tool changes needed
   1. Controls for new fields - likely restricted to group administrators.
   2. Include Compliance Status and outstanding required items in group member report
   3. Included upcoming compliance issues in member report
4. Simon/APEX application level training requirement.
5. Consumer Interface tests. The interfaces listed above in "Consumers of Group Data" will need to be modified to included the compliance checking where needed.
6. Public safety compliance check tool - likely a refresh of the tool used during COVID.  Multiple interfaces may be required.  This may include the daily (or weekly) change report, or that may be provided via email.
7. Request Workflow should include compliance status in the supporting information with the request - lack of compliance may not be a reason to reject a request.

Related Projects

This infrastructure (and other systems) provide a basis for additional projects that may be worth exploring.

1. Assign compliance requirements to specific spaces (rooms) and facilities.
   1. Access Levels provided access to those rooms could "inherit" the requirements
   2. People assigned to this access levels could then be checked for compliance
2. Assign Compliance requirements to chemicals, then use the chemical database (which associates chemicals with spaces) to provide additional compliance requirements for the space (and repeat steps above)
3. Assign Compliance/Training requirements to specialized equipment, use equipment inventories (were available) to identify rooms that may need additional compliance requirements.
4. Validate room occupancy training with space requirements
   1. Based on Space Management occupancy
   2. Based on HASP database
5. Create HASP database for integration with space management system
6. Feed discovered compliance requirements back into CITI and Percipio.
7. OnGuard exception detection and reporting.  There are many role based access levels (maintenance techs, environmental services, etc) in addition to emergency service roles (public safety, ambulance, Knox boxes). The first cohort may be required to have training before assignment to spaces, and the second cohort may require additional investigation and response after use of access levels.