Access Management Standard

1 PURPOSEÌý

The ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û (×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û) is committed to promoting secure and appropriate access to its information and information technology resources. This Standard defines the baseline security controls designed to minimize the potential for unauthorized access to or use of information technology resources and the information they contain and to preserve and protect the confidentiality, integrity, and availability of ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information and information technology resources.

2 SCOPEÌý

This Standard applies to all administrative, academic, and business units at ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û and its component institutions. The requirements documented here apply to all information technology resources that capture, store, process, transmit, or otherwise manage institutional information.

3 STANDARDÌý

3.1 COMMUNITY MEMBER RESPONSIBILITIES

All ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members are responsible for all actions carried out using any account associated with a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resource issued for their use. As such, account holders shall take all reasonable actions to safeguard institutional information and ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources by protecting their accounts from unauthorized use and compromise, including, but not limited to, the following:

3.1.1 Completing all cybersecurity training required for their role

3.1.2 Creating passwords that comply with the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û Password Policy and maintaining the confidentiality of those passwords for all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û accounts under their controlÌý

3.1.3 Securing workstations and mobile devices by engaging the screen lock before leaving them unattended

3.1.4 Taking care not to misuse their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û accounts. Examples of misuse include, but are not limited to:

  • Using access granted to view or modify information they are not authorized to view or modify
  • Allowing anyone else to access information or resources, which includes providing access to parents, spouses, children, or any other relatives for any purpose, even to perform actions on their behalf
  • Using anyone else’s ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û account to gain access to information or resources they are not authorized to access

3.2 MANAGER RESPONSIBILITIES

Managers of ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û employees, including students, are responsible for notifying Enterprise Technology & Services (ET&S) when individuals change jobs from one part of the University System (or one of its component institutions) to another. This ensures that an access review can be completed, and modifications can be made so that each individual has access to only those information technology resources appropriate for their role(s).

3.3ÌýACCESS MANAGEMENT OVERVIEW

Access to information technology resources and the institutional information those resources capture, store, process, transmit, or otherwise manage shall be granted based on business need and the conceptÌýof least privilege. This means that ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members shall only be granted access to those information technology resources, and information required to fulfill their responsibilities.

Access to most ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û and component institution information and information technology resources requires three things. First, an identifier associated with a valid ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identity, an accepted federated identity, or an identity established for the purposes of collaboration on a specific information technology resource. Second, those with a valid identifier must be able to prove who they are through the process of authentication. Third, the authenticated identity must be authorized to access the information technology resource or information they are trying to access. This is handled through the establishment of an account or other authorizing mechanism.

3.4 IDENTITY

An identity is a set of physical and behavioral characteristics by which an individual entity is uniquely recognizable. Access to ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources is generally associated with a primary ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identity. Access may also be granted using other types of identities, including federated identities or local identities, established on a specific information technology resource (e.g., to support research collaboration). An identity is represented by one or more identifiers, most commonly a username.

To access a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resource, authorized individuals shall provide the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identifier assigned to them for the purpose of accessing that resource. Additional Information about ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identities and identifiers is provided in the Identity Management Standard

3.5Ìý´¡±«°Õ±á·¡±·°Õ±õ°ä´¡°Õ±õ°¿±·

Authentication is the process an information technology resource uses to confirm that a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member, authorized user, device, or other information technology resource is who or what it is claiming to be. Access to any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resource that captures, stores, processes, transmits, or otherwise manages institutional information that is classified as anything other than PUBLIC shall require authentication.

3.6 STANDARD AUTHENTICATION

There are three different factors that can be used to confirm that someone or something is who they claim to be:

• Something you know – a password, an answer to a secret question, or a PIN number are all examples of this kind of factor

• Something you have – an application on your phone, an electronic certificate installed on a device, or a physical key that plugs into your device are all examples of this kind of factor

• Something you are – biometrics like a fingerprint, facial recognition, or a retinal scan are all exampled of this kind of factor.

To authenticate, ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members or the devices they are using shall provide a confirmed ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identifier and the requested factors. The factor(s) provided must match the factor(s) associated with that identifier within the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û resource. Commonly used methods of authentication include username & password, biometrics, and device certificate.

Session Limits for Web Based Applications: Maximum Session Idle Time and Maximum Session Length (Token Lifetime) is based on best practices with approval from the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û Cybersecurity Committee.

3.7 MULTIFACTOR AUTHENTICATION

There are some information technology resources at ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û that require an additional level of protection to authenticate ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members. In these cases, multifactor authentication (MFA), which requires that ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members provide 2 different factors from the list above, shall be used.

3.8 CENTRAL AUTHENTICATION

Authentication services can be handled, using a central repository of identifiers and authentication factors. This type of authentication can be used to authenticate ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members across multiple information technology resources using the same identifier/authentication factor set.

A centrally managed account is created and managed in a central directory, allowing it to be used to access many information technology resources. These accounts use a single set of credentials (e.g., ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û username associated with a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identity and the password paired with that username) to access many information technology resources.

Central authentication services can provide both standard authentication and MFA, and is the mechanism used to provide single sign on (SSO) capabilities. This is the preferred method for authenticating ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members and shall be used wherever it is technically possible to do so.

3.9 LOCAL AUTHENTICATION

In some cases, information technology resources require local authentication, which means ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members need a set of credentials (e.g., username and password) that are different from a community member's centrally managed ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û credentials and that are only used to access that resource.

Local authentication uses locally managed accounts, which are created in local repositories within a specific computer, device, or application, to enable access. In cases where local authentication must be used, ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members shall not use their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û password as their authentication factor. Each information technology resource that uses a locally managed account shall have separate credentials that are only used to access that resource. Use of local application accounts must adhere to the requirements outlined in the relevant Standards.

Administrators of information technology resources that must use local authentication shall, whenever possible, utilize ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û usernames as the authentication identifier or instruct ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members to use their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û username as the authentication identifier/username for that application. Additionally, per the requirements in the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û Password Policy, application administrators shall instruct and encourage ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members not to reuse their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û password as the password in any locally authenticated information technology resource.

4.0 AUTHORIZATION

Authorization is the third element that is required when accessing ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information and information technology resources. Where identity confirmation and authentication are used to determine and confirm the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member’s identity, authorization defines what that community member can access, as well as what they can do with that access.

Authorization can occur on several different levels. A ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member can be authorized to access an information technology resource, which is usually done with an account. The account pairs credentials with a set of permissions, which are the specific instructions defining what that account is authorized to do. When a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member has an account for a resource, they are authorized to access it. For some information technology resources, this is the only level of authorization required, ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members either have access or they don’t. However, most information technology resources use multiple levels of authorization in order to ensure that each community member only has access to the information and functionality necessary. This structured authorization is called the principle of least privilege.

To ensure each ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member is only able to access what they need to, specific authorizations, also called permissions, areÌýassociated with each account. The permissions granted to an account determines what information that account can access and what functions it can perform. Permissions can also be grouped into roles which simplifies management of access for groups of ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members that need the same level of access. Roles used for authorization can be coarsegrained, like those defined in the Identity Management Standard, but they can also be finegrained or information resource specific. To demonstrate, if the information technology resource was a house, having an account, the first level of authorization, allows a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member to come through the front door but the other levels of authorization, organized by permissions or roles, determine where that community member can go, what they see, and what they can do once they are inside.

4.1 LEAST PRIVILEGE

Authorization to access ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or component institution information and information technology resources shall be based on job function, responsibilities, and/or need-to-know according to the principle of least privilege. Individual ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members, groups of ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members, and roles shall only be authorized to access the information and functionality necessary for the work to be performed or access needed, and no more.

4.2 ACCESS PROVISIONING

Any information technology resource that captures, stores, processes, transmits, or otherwise manages PROTECTED, or RESTRICTED, information per the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û Information Classification Policy shall have documented access management procedures that meet the minimum requirements outlined in this Standard. Gaining access to information and information technology resources is done is several ways, as outlined below.

4.2.1 Birthright Access

There is a level of role-based access provided to all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members as soon as their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û credentials are established. This is called birthright access. Birthright access is coarse-grained role-based, which means it differs based on the active roles associated with the community member’s primary identity – an employee’s birthright access is different than the birthright access for students. Birthright access changes when the active coarse-grained roles change, ensuring that birthright access also follows the principle of least privilege.

Cybersecurity Ops, Engineering, & IAM, in collaboration with the necessary Business Application and/or Technology Service Owners, is responsible for defining the appropriate access for each established U

SNH coarse-grained role. This team is also responsible for the processes, procedures, and tools required toÌýprovision, deprovision, and modify access for all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û coarse-grained roles. Birthright access authorization within each individual application is the responsibility of the Business Application and/or Technology Service Owners, of that application.

4.2.2 Fine-Grained Role Based Access

Fine-grained role-based access builds upon Birthright Access, granting access based on user characteristics or attributes. Examples of these attributes are which college a community member belongs to, which class a student is taking, or the department where a community member works.

4.2.3 Request/Approval Access

Access to some ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information and information technology resources cannot be granted at the coarse-grained or fine-grained role level. In these cases, access is granted on a request/approval basis. To gain access to these ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources and the information those resources support, an individual request for that ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member shall be made using the designated ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or institutional process for that resource.

4.2.4 Privileged Access

There are also circumstances where a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member needs an authorization level that allows them to modify the information technology resource itself or the information captured, stored, processed, transmitted, or otherwise managed by that resource, rather than simply utilizing it. This level of authorization is called privileged access. Definitions, requirements, and security access controls related to this type of authorization are documented in the Privileged Access Management Standard.

4.2.5 Sponsored Access

Access to most ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources requires that a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member have a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û identity AND an active coarse-grained role. When there is a need to provide access to an individual who lacks an active, coarse-grained role (e.g., to provide access for a contractor or vendor), that access shall be authorized under the Sponsored Use program. Definitions and information about Sponsored Use and sponsored access are documented in the Sponsored/Guest Access Management Standard.

4.3 ACCESS MANAGEMENT RESPONSIBILITIES

All administrative, academic, and business units engaged in provisioning, modifying, deprovisioning, and/or managing access shall develop processes and procedures, and implement tools to enable those processes and procedures, that meet the requirements defined below.

4.3.1 Birthright Access

• Requests to add a new information technology resource authorization to birthright access shall be sent to Cybersecurity Ops, Engineering, & IAM

• This team, with the oversight of the Chief Information Security Officer (CISO), has the authority to add authorizations to birthright access and to remove them

• Any request to add an authorization for an information technology resource or resources to the birthright access for a coarse-grained role shall include documentation that explicitly lists the authorizations included for all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members within a coarse-grained role or across coarse-grained roles, as appropriate o For example, adding something like the learning management system to birthright access for Faculty would require a detailed explanation of what information and functionality within the learning management system each faculty member is automatically authorized to access

• This documentation shall be included in the access management processes and procedures for that information technology resource and reviewed, annually, as part of the mandatory annual review of access management documentation

4.3.2 Fine-Grained Role Access

• Requests to add a new information technology resource authorization using fine-grained roles shall be sent to Cybersecurity Ops, Engineering, & IAM

• This team has the authority to add authorizations to fine-grained role-based access and to remove them

• Any request to add an authorization for an information technology resource or resources using fine-grained role-based access shall include documentation that explicitly lists the authorizations included for each fine-grained role

• This documentation shall be included in the access management processes and procedures for that information technology resource and reviewed, annually, as part of the mandatory annual review of access management documentation

4.3.3 Access Request and Approval

• There shall be a defined method for ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members to request access, notify administrators of a change to access, and request access be removed for each information technology resource that requires authorization

• There shall be an approval process that involves either the service owner of that resource or the data stewards (or their designee) for the information contained on it or accessed through it

• Use of central authentication shall be pursued whenever possibleÌýUse of role-based authorization schemes over individual authorizations shall be pursued whenever possible

• Access shall be granted at the most granular authorization level possible

• Access shall not be granted to any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or component institution information or information technology resource until the required approvals are complete

• An audit trail that contains the details of the request and that documents all required approvals shall be preserved as outlined in the Access Management Audit section of this Standard

• Account approvals shall be retained until the next access audit, as defined below, is performed for that resource

4.3.4 Modifications to Access

When formal notification of a requirement to modify a community member's access is received, modification will be made first by resetting that user's access to only provide Birthright Access based on coarse-grained role and any appropriate fine-grained role-based access. This process may involve a review of existing access to determine the optimal approach to ensuring appropriate access is maintained. Any access based on a request/approval process will need to be reauthorized per the regular process. Deprovisioning Access Loss of a specific coarse-grained role and/or attributes that enable fine-grained role-based access shall result in deprovisioning of any access automatically granted based on those roles. Deprovisioning requirements for request/approval-based access are defined in the Accounts Management Standard.

4.4 PHYSICAL ACCESS TO ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û INFORMATION AND INFORMATION TECHNOLOGY RESOURCES

Physical access to ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources used to capture, store, process, transmit, or otherwise manage institutional information classified other than PUBLIC shall be limited to ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members who have a need to access them as determined by job responsibilities. Access to the facilities where those resources reside shall be restricted according to the requirements provided in the Physical Information Technology Asset Access and Management Standard and the Data Center Facility Security, Access, and Use Standard.

4.5ÌýCOMPROMISED ACCESS

Access to ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information and information technology resources is considered compromised when there is reason to suspect that an unauthorized party or parties has obtained the necessary credentials to access any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û information technology resources the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member is authorized to access. Upon identification of a compromised account, all centrally managed access authorizations shallÌýbe secured until the identity of the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member can be confirmed and the password associated with their ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û username can be changed. Securing a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member’s access temporarily blocks the ability to use that access for any information technology resources that use centrally managed accounts for access.

4.6 LOCAL APPLICATION DEVELOPMENT

Applications that are developed by ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members for use at ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or its component institutions shall be designed to support the requirements provided in this Standard as well as those defined in the System Acquisition, Development, and Maintenance Lifecycle Standard.

4.7 SPECIAL ACCESS MANAGEMENT CONSIDERATIONS

Emeriti Faculty Access for faculty members who have been granted emeritus status by a University President shall be retained to the level appropriate with their contributions and status for the duration of their lives. As with all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û access, access granted to Emeriti is intended only for use by the individual with Emeritus status. ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û credentials used to access ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û resources cannot be shared with or used by any other individual.

4.7.1 Revocation of Access

Human Resources (×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or institutional), Cybersecurity & Networking (CS&N), and the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û General Counsel’s Office (GCO) are authorized to revoke access temporarily or permanently to ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û and institutional information and information technology resources, including Birthright Access authorization.

In circumstances where this is warranted, a confidential request will be submitted in writing to CS&N. Requests from Human Resources and the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û GCO do not require additional approval.

Requests initiating within CS&N require approval by a member of the CS&N management team (CISO and Direct Reports). Documentation of the request, and where required, any approvals, shall be stored confidentially according to procedures defined by Cybersecurity Ops, Engineering, & IAM, which is part of CS&N.

4.8 ACCESS MANAGEMENT AUDITING

4.8.1 Annual Access Audit

The Technology Service Owner or Business Application Owner of each information technology resource that requires authorization/accounts is responsible for conducting an annual audit of all access to that resource. The purpose of this audit is to confirm that all ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members who have access to the resource, should have access to the resource and that the access each ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member has is appropriate for that ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member. Timing of these audits should consider academic or administrative calendar implications (e.g., R+30) and should be done around the same time each year.

An access audit report, which shall include the identities of each authorized ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member and a description of their authorizations, shall be created during this audit. Senior management of the administrative, academic, or business unit responsible for managing that access shall sign-off on the finalized access audit report. This sign-off confirms that the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community members and authorization levels listed on the report have been confirmed and are appropriate and valid based on the ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member’s job function and the organization’s business needs. This report, along with a list of the identity and authorizations for any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member whose access was deemed inappropriate as a result of this audit shall be provided to Cybersecurity Ops, Engineering, & IAM for review and audit tracking. Cybersecurity Ops, Engineering, & IAM is responsible for reviewing all inappropriate access lists resulting from access management audits and determining if any additional investigation is required.

Cybersecurity Ops, Engineering, & IAM is also responsible for maintaining records related to these access management audits for a period of 18 months.

4.8.2 Access Management Processes and Procedures Assessment and Audit

At the discretion of the CISO, the access management processes and procedures used by any unit at any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û institution can be assessed by Cybersecurity Governance, Risk, & Compliance (GRC) to ensure that those processes and procedures include all required security controls.

This assessment shall also confirm that all aspects of those processes and procedures are being followed as documented and that an appropriate audit trail is being maintained, including, but not limited to the following:

  • A documented request for every account that is manually created • A documented approval and justification for each account request that requires approval
  • Confirmation that every account is held by a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member who is still at the institution
  • Confirmation that every account is held by a ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û community member with an appropriate coarse-grained role for the access provided
  • Confirmation that the account holder’s job function still requires the granted access

Additionally, ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û Internal Audit may perform informal or formal access management audits, as needed, on any ×î¿ì¿ª½±Ö±²¥½ÁÖé½á¹û or component institution information technology resource. Situations that are not covered by this Standard or where there is question about whether an employee's account or access rights should be changed or terminated shall be brought to the attention of the CISO for guidance.

DOCUMENT HISTORYÌý

  • Approved by: CHIEF INFORMATION SECURITY OFFCER, T NUDD, 18ÌýAUG 2021 V1 CYBERSECURITY POLICY & STANDARD WORKING GROUP, 13 AUG 2020, V0.2
  • Reviewed by:ÌýCHIEF INFORMATION SECURITY OFFICER, T NUDD, 18 AUG 2021 V1 CYBERSECURITY POLICY & STANDARD WORKING GROUP, 13 AUG 2020, V0.2
  • Revision History:ÌýREVISED PER CYBERSECURITY POLICY & STANDARD WORKING GROUP REVIEW, 12 AUG 2020
    • V0.2 REVIEW DRAFT FINALIZED, 06 MARCH 2023
    • V0.3 REVISED PER CYBERSECURITY COMMITTEE, 09 NOVEMBER 2023
    • REVISED FORMATTING, K SWEENEY, 30 MAY 2024