IS-1005 Identity and Access Management

Communication

Release Date: 9/12/13
Revision 1: 6/16/15
Revision 2: 2/2/16
Revision 3: 4/18/23

Table of Contents

1. Summary

This document establishes the common requirements and standards for the authentication, authorization, management, and life cycles of user and system accounts within Central New Mexico Community College (CNM) systems and applications and outlines the responsibilities of systems and applications for generating and maintaining guidelines and procedures for the administration, maintenance, and auditing of accounts and access.

2. Scope and Applicability 

This document is applicable to all systems, applications, and users within the CNM environment.  All users of CNM's information resources and systems are responsible for the protection of the College's resources; while certain roles, systems, applications, and individuals have specific additional responsibilities. 

3. Purpose

The purpose of this administrative directive is to describe:

  • the types of identities in use for systems and applications
  • how identities must be authenticated
  • how authorizations must be managed
  • how the life cycles of accounts and privileges must be maintained

4. Background

CNM is dedicated to its commitment to protect the confidentiality, integrity, accessibility, and accountability of the information and systems entrusted to the College.  Proper access control, including the use of strong authentication, authorization, and auditing techniques and technologies is of paramount importance in keeping information and systems protected.

5. Responsibilities 

5.1 End User Responsibilities

Every person with access to CNM systems is responsible for selecting strong passwords, keeping the passwords secure, and reporting any unauthorized use of accounts. Users must:

  • create passwords of adequate length and complexity commensurate with these requirements and by the practices of the systems for which their account will be used.
  • not share passwords related to any CNM system or application.
  • not use passwords related to any CNM system for non-CNM accounts.
  • not re-use passwords between accounts
  • immediately change passwords and notify the appropriate account administrator and/or the ITS Service Desk if there is any suspicion that a password has been improperly disclosed, accessed, or used by an unauthorized person.
  • use privileges associated with an account only for the purpose for which they were authorized.
  • log off or use screen-locking technologies that require authentication when leaving any device unattended.

5.2 Privileged User Responsibilities 

Every person with administrative access to CNM systems, or with access to highly sensitive data, is responsible for selecting strong passwords, keeping accounts secure, and reporting any unauthorized use of accounts. Users must:

  • create passwords of adequate length and complexity commensurate with these requirements and by the practices of the systems for which their accounts will be used.
  • not share passwords related to any CNM system or application.
  • not use passwords related to any CNM system for non-CNM accounts.
  • not use the same passwords for any other account inside or outside CNM. 
  • immediately change passwords and notify the appropriate account administrator and/or the ITS Service Desk if there is any suspicion that a password has been improperly disclosed, accessed, or used by an unauthorized person.
  • use privileges associated with an account only for the purpose for which they were authorized.
  • use privileged accounts and authorizations only when such privilege is necessary to complete a function.
  • not leave any device, system, or application to which a privileged account has been authenticated unattended for any period.
  • use multifactor authentication (MFA) for every network access session on a privileged account.

5.3 Service Account Owner Responsibilities 

Service accounts are generally controlled by Divisions or Teams within the CNM ITS Department.  Any Service Account owned by a group outside of CNM ITS must be approved by the Chief Information Security Officer (CISO) or Designee with input from various stakeholders along with a full risk assessment. Service Account Owner refers to a group or team that will have access to credentials for the Service Account.

Each service account owner that administers or bears responsibility for controlling access to accounts or resources must adopt practices and procedures consistent with these requirements to define and administer the lifecycles and/or access of all accounts and authorizations for those resources. This includes:

  • creating, adopting, and maintaining all practices, procedures, standards, and/or guidelines necessary to meet the letter and spirit of these requirements.
  • adopting the NIST Cybersecurity Framework standards for vetting and verification practices to ensure that only authorized individuals whose duties require it are given access to systems and/or applications.
  • adopting the NIST Cybersecurity Framework measures to monitor and ensure that access controls are effective at preventing unauthorized access.
  • ensure that monitoring and auditing are consistently and effectively performed.
  • ensure that unauthorized access to protected resources is effectively prevented, detected, and addressed in a timely manner.
  • periodically review accounts, roles, and rules to ensure that only authorized accounts have appropriate access to protected resources, and that those accounts have only the access necessary to perform their assigned functions.
  • periodically testing access controls (including both authentication and authorization) to ensure that they continue to be effective, properly configured, and properly administered.
  • ensure that users with accounts and/or access under the Service Account Owner’s purview are adequately educated regarding their responsibilities and associated practices, standards, and procedures.
  • ensure service accounts do not have interactive login capabilities.

5.4 Systems Responsibilities

System users are responsible for ensuring that each system that relies on or controls access to accounts or resources must adopt practices and procedures consistent with these requirements to define and administer the lifecycles and/or access of all accounts and authorizations for those resources. This includes:

  • creating, adopting, and maintaining any and all practices, procedures, standards, and/or guidelines necessary to meet the letter and spirit of these requirements.
  • adopting the NIST Cybersecurity Framework standards for vetting and verification practices to ensure that only authorized individuals whose duties require it are given access to the system.
  • adopting the NIST Cybersecurity Framework standards for monitoring and ensuring that access controls are effective at preventing unauthorized access.
  • ensure that monitoring and auditing is consistently and effectively performed.
  • ensure that unauthorized access to protected resources is effectively prevented, detected, and addressed in a timely manner.
  • periodically review accounts, roles, and access controls to ensure that only authorized accounts have appropriate access to protected resources, and that those accounts have only the access necessary to perform their assigned functions.
  • periodically testing access controls (including both authentication and authorization) to ensure that they continue to be effective, properly configured, and properly administered.
  • ensure that users with accounts and/or access administered by the system are adequately educated regarding their responsibilities and associated practices, standards, and procedures.

5.5 Application Responsibilities 

Application users are responsible for ensuring that each application that administers or bears responsibility for controlling access to accounts or resources must adopt practices and procedures consistent with these requirements to define and administer the lifecycles and/or access controls of all accounts and authorizations for those resources. This includes:

  • creating, adopting, and maintaining any and all practices, procedures, standards, and/or guidelines necessary to meet the letter and spirit of these requirements.
  • adopting the NIST Cybersecurity Framework standards for vetting and verification practices to ensure that only authorized individuals whose duties require it are given access to the application.
  • adopting NIST Cybersecurity Framework standards for monitoring and ensuring that access controls are effective at preventing unauthorized access.
  • ensure that monitoring and auditing is consistently and effectively performed.
  • ensure that unauthorized access to protected resources is effectively prevented, detected, and addressed in a timely manner.
  • periodically review accounts, roles, and access controls to ensure that only authorized accounts have appropriate access to protected resources, and that those accounts have only the access necessary to perform their assigned functions.
  • periodically testing access controls (including both authentication and authorization) to ensure that they continue to be effective, properly configured, and properly administered.
  • ensure that users with accounts and/or access administered by the application are adequately educated regarding their responsibilities and associated practices, standards, and procedures.

6. Accounts

6.1 Accounts

All accounts at CNM must be uniquely assigned to a specific individual, system, or application for access to any resource classified as Sensitive or above. 

The use of shared accounts for resources access is prohibited unless used solely for read-only access to public information unless a specific and current Exception or Exemption has been granted. 

6.2 Account Types

There are two (2) types of accounts at CNM:

  • User Accounts: User Accounts are uniquely assigned to a specific individual and used for access to resources classified as Sensitive or below.
  • Privileged Accounts: Privileged accounts are defined as those accounts with access to system administration and/or configuration; access control for resources; access to highly sensitive data (as defined in the IS – 1014 Data Classification and Handling Policy as Restricted or Regulatory); or used to administer other user accounts.

There are two types of Privileged Accounts at CNM:

  • System, user, access control, and administration (a.k.a. "Z" Accounts):
  • Accounts with access to financial, regulatory, or other systems, data, and/or applications classified as Restricted or Regulatory (a.k.a. "S" Accounts)

6.3 Account Federation 

CNM strongly prefers the use of centrally administered accounts with federated authentication. Accounts may only be created locally on a system or device where federation is not practical or possible with an exception explicitly approved by the Chief Information Security Officer (CISO) or their Designee.

6.4 Account Eligibility

To be eligible for a CNM account, an individual or group must be one of the following:

  • CNM student
  • CNM employee
  • CNM department
  • CNM organization
  • An individual (contractor, vendor, etc.) or entity approved by the Executive Director, Dean, or Functional Leader of the department under which the entity’s work is sponsored, the Chief Information Security Officer (CISO) or designee.
  • An authorized CNM guest with a CNM-issued guest identification or approved sponsorship for a CNM-sponsored event.

Contractor/Non-employee Accounts

  • All contractors, vendors, partners, and any third party must have a CNM sponsor to serve as a liaison between the non-employee and CNM. The liaison is held accountable for any usage of the third-party user account.
  • It is the CNM sponsoring manager’s responsibility to:
    • Obtain a non-disclosure agreement signed by an officer of the company/organization.
    • Oversee contractor activities.
    • Ensure that the access is withdrawn at the close of the contract or project.
  • Access given to the contractors, vendors, partners, and any third party must be approved by the Executive Director, Dean, or Functional Leader of the department under which the entity’s work is sponsored, the CISO or designee.
  • All other policies affecting user accounts apply to contractors, vendors, and third-party associates as well.

6.5 Locking and Deactivating Accounts

There are times when events, such as employment separation or a suspected violation of CNM’s policies and procedures, may necessitate the locking of a user’s account(s) to preserve and protect the integrity of CNM's systems and networks.

Employee Accounts

  • Accounts are locked upon termination of employment at CNM. It is the supervisor’s responsibility to ensure that the separation checklist is processed through ITS on the same day of the employee's separation from the College.
  • If an employee’s termination results in insufficient time to complete the separation checklist before they leave the College, Human Resources can notify ITS via e-mail to lock the employee's account. However, the separation checklist should be completed as soon as possible.
  • Upon separation from the College, an employee’s data and system files are and remain, the property of the College. No access to such information shall be granted to a separated employee unless required by law.
  • Information contained in each locked account is kept for a period of no less than thirty days. At the end of that period, the information may be retained or deleted at the College’s discretion and in accordance with state statutes and codes regarding record retention.
  • Access to information in an employee’s or separated employee’s locked account requires approval from the Human Resources Department or General Counsel.
  • Any employee whose account is locked as a result of a suspected violation of CNM policy or procedure is notified by the CISO or designee.
  • If an employee chooses to separate from the college and continues to retain the role of faculty member or student, all privileges associated with their previous position will be terminated and new roles will be assigned.

Student Accounts

  • Student accounts will remain active for a period of three terms (1 year) following the last term of attendance, after which the account will be deleted in its entirety.
  • Access to information in a student’s locked account requires approval from the Office of the Dean of Students.
  • Any student whose account is locked as a result of a suspected violation of the Information Technology Use policy is notified by the Office of the Dean of Students.

Guest Accounts

  • Guest accounts provide access to the Internet only. Community-use guest accounts are valid for one-year terms.
  • CNM-sponsored event accounts are valid for the duration of the event.

Contractor/Non-employee Accounts

  • Accounts are locked upon termination of contract with CNM. It is the CNM sponsor’s responsibility to ensure that the ITS Information Security and Compliance team has been notified of the termination. Access will be terminated on the same day of the notification.
  • Notification of the contractor’s termination is the sole responsibility of the sponsoring department.
  • Activation and deactivation dates will be granted based on the agreed upon dates in the contract/agreement. Access for these types of accounts will not exceed more than one year’s time from the initial activation date.
  • Contractors cannot have access to administrative accesses without a fully executed Non-Disclosure Agreement on file.

7. Access Control

7.1 Authentication 

Each resource must be protected according to its Data Classification (as defined in the IS- 1014 Data Classification and Handling Policy), including (but not limited to) requiring that all users, systems, or applications accessing it are authenticated. 

All authentications must be centrally logged, periodically monitored, and audited according to the accessed resource's Data Classification status. 

Authentication must be performed using a method calculated to reasonably guarantee that the entity controlling the identity used for authentication is the same entity authorized for its use. 

7.2 Authorization

Each resource must be protected according to its Data Classification (as defined in the IS- 1014 Data Classification and Handling Policy), including (but not limited to) requiring that all users, systems, or applications accessing it are authorized to access it. 

All authorizations should be centrally logged, periodically monitored, and audited according to the accessed resource's Data Classification status. 

Authentication must be performed using a method calculated to reasonably guarantee that the entity controlling the identity used for authentication is prevented from accessing the target resource for functions exceeding its authorization. 

7.3 End User Authorization

Every individual with access to CNM systems is responsible for their awareness of their authorizations and has a duty to avoid abusing their access. Users must:

  • not attempt to elevate their access by any method designed to enable them to perform functions for which they are not officially authorized.
  • not attempt to use credentials for which they have not officially been granted custody of to access functions or resources for which they are not officially authorized.
  • not share credentials in their custody with any individual, system, application, or resource without explicit prior approval from the CISO or their designee.
  • timely report any change in their authorized functions (such as through a role change or new assignment of duties) that would require less, or different access than previously granted.
  • immediately report any access they discover that is above and beyond their reasonable expectations of officially-sanctioned access.

7.4 Privileged User Authorization

Every individual with administrative access to CNM systems, or with access to highly sensitive data, is responsible for their awareness of their authorizations, and has a duty to avoid abusing their access. Users must:

  • not attempt to elevate their access by any method designed to enable them to perform functions for which they are not officially authorized.
  • not attempt to use credentials for which they have not officially been granted custody of in an attempt to access functions or resources for which they are not officially authorized.
  • not share credentials in their custody with any individual, system, application, or resource without explicit prior approval from the CISO or their designee.
  • not grant credentials and/or access to any individual, system, application, or resource that is not explicitly authorized to receive those credentials or access.
  • immediately report any evidence they encounter of an individual, system, application, or resource that is improperly using credentials or access to perform functions or gain access to resources for which they are not officially authorized.
  • timely report any change in their authorized functions (such as through a role change or new assignment of duties) that would require less, or different access than previously granted.
  • immediately report any access they discover that is above and beyond their reasonable expectations of officially sanctioned access.
  • use privileged accounts and authorizations only when such privilege is necessary to complete a function; and
  • not leave any device, system, or application to which a privileged account has been authenticated unattended for any period.

7.5 Service Account Owner Authorization

Each Service Account Owner that administers or bears responsibility for controlling access to accounts or resources must adopt practices and procedures consistent with this document to define and administer the lifecycles and/or access of all accounts and authorizations for those resources according to the Principle of Least Privilege. This includes:

  • maintaining accounts for individuals, systems, applications, and resources under the Service Account Owner’s purview with as minimal access as is required to fully perform the functions required.
  • maintaining authorizations and access for individuals, systems, applications, and resources under the Service Account Owner’s purview with as minimal access as is required to fully perform the functions required.
  • Sharing of service account credentials can only occur between the service account owner and administrators.
  • creating, adopting, and maintaining any and all practices, procedures, standards, and/or guidelines necessary to meet the letter and spirit of these requirements.
  • adopting the NIST Cybersecurity Framework standards for vetting and verification practices to ensure that only authorized individuals whose duties require it are given access to authorized resources.
  • adopting the NIST Cybersecurity Framework standards for monitoring and ensuring that access controls are effective at preventing unauthorized access.
  • ensure that monitoring and auditing is consistently and effectively performed.
  • ensure that unauthorized access to protected resources is effectively prevented, detected, and addressed in a timely manner.
  • periodically review accounts roles, and rules to ensure that only authorized accounts have appropriate access to protected resources, and that those accounts have only the access necessary to perform their assigned functions. Periodic reviews will occur annually at minimum.
  • periodically testing access controls (including both authentication and authorization) to ensure that they continue to be effective, properly configured, and properly administered. Periodic testing will occur annually at minimum.
  • ensure that users with accounts and/or access under the Service Account Owner’s purview are adequately educated regarding their responsibilities and associated practices, standards, and procedures.

7.6 Systems Authorization

Each system user that relies on or controls access to accounts or resources must adopt practices and procedures consistent with this document to define and administer the lifecycles and/or access of all accounts and authorizations for those resources. This includes:

  • not attempt to elevate its access by any method designed to enable it to perform functions for which it is not officially authorized.
  • not attempt to use credentials for which is has not officially been granted custody of to access functions or resources for which it is not officially authorized.
  • not share its credentials with any individual, system, application, or resource without explicit prior approval from the Role-Based Access Team (RBAT).
  • not grant credentials and/or access to any individual, system, application, or resource that is not explicitly authorized to receive those credentials or access.
  • timely report any change in its authorized functions (such as through a role change or new assignment of duties) that would require less, or different access than previously granted.
  • immediately report any access discovered that is above and beyond its reasonable expectations of officially sanctioned access.
  • using privileged accounts and authorizations only when such privilege is necessary to complete a function.

7.7 Application Responsibilities 

Each application user that administers or bears responsibility for controlling access to accounts or resources must adopt practices and procedures consistent with this document to define and administer the lifecycles and/or access controls of all accounts and authorizations for those resources. This includes:

  • not attempt to elevate its access by any method designed to enable it to perform functions for which it is not officially authorized.
  • not attempt to use credentials for which is has not officially been granted custody of to access functions or resources for which it is not officially authorized.
  • not share its credentials with any individual, system, application, or resource without explicit prior approval from the Role-Based Access Team (RBAT).
  • not grant credentials and/or access to any individual, system, application, or resource that is not explicitly authorized to receive those credentials or access.
  • timely report any change in its authorized functions (such as through a role change or new assignment of duties) that would require less, or different access than previously granted.
  • immediately report any access discovered that is above and beyond its reasonable expectations of officially sanctioned access.
  • using privileged accounts and authorizations only when such privilege is necessary to complete a function.

8. Exceptions

8.1 Exception Process

Exceptions to these requirements for non-system accounts must be applied for using the process defined by the Role-Based Access Team (RBAT) in CNM document IS-1018 - Banner Access Control available at IS-1018 Banner Access Control.  Exceptions for System or Service accounts must be applied for using an ITS Service Ticket to the ITS Security Team.

8.2 Exception Approvers

Exceptions to these requirements applied for in accordance with the Exception Process may be approved by the Role-Based Access Team (RBAT) at its discretion or by the CISO or Designee for System or Service accounts.

8.3 Exception Period

Any exception to these requirements at CNM must be approved for a period of not more than one year.

8.4 Extensions to Exceptions

Any exception to these requirements that has expired may be extended at the discretion of the Role-Based Access Team (RBAT), but only for good cause shown, and only for a period of one extra year.

No exception may be approved for a period of more than two years in total. If an exception is required for a period of more than two years, the requestor must apply for an Exemption, including the update to this document reflecting the Exemption.

9. Exemptions

9.1 Exemptions Defined

Exemptions to CNM policies are strongly disfavored and discouraged in all instances, but solely in limited and compelling cases, the need for Exemptions may exist.

While Exceptions are time-limited, Exemptions are permanent, and should be granted exceedingly sparingly, and only in extreme cases.

Exemptions must be tailored as narrowly as possible to ensure maximum possible compliance with these requirements, exempting the resource from only the minimum aspects of compliance necessary to accomplish the necessary functions incompatible with the enforcement of these requirements.

Compensation security controls must be put in place that accomplish the letter and spirit of this policy when exemptions are granted.

9.2 Approved Exemptions as of the Date of Publication

The following exceptions have been approved by the Role-Based Access Team (RBAT), and are exempt as follows:

  • None at this time

9.3 Exemption Process

Exemptions to these requirements for non-system accounts must be applied for using the process defined by the Role-Based Access Team (RBAT) in CNM document IS-1018, available at IS-1018 Banner Access Control. Exemptions for System or Service accounts must be applied for using an ITS Service Ticket to the ITS Security Team.

9.4 Exemption Approvers

Exemptions to these requirements applied for in accordance with the Exception Process may be approved by the CISO or designee for system accounts.

9.5 Exemption Review

Exemptions approved must be reviewed by the CISO every 12 months to verify the continued necessity for the Exemption. If the underlying justifications for Exemption have changed or ceased to exist allowing the Account, System, Application, or Service Account Owner to comply with these requirements, the Exemption must be revoked, and all requirements fully enforced.

Reference Materials

IS – 1014 Data Classification and Handling Policy

IS-1018 - Banner Access Control

NIST Cybersecurity Framework (CSF) Version 1.1