South Plains College

Information Services (SPC-IS)

Account Management and Access Control Standard: I-D(a)

Purpose and Benefits

This Standard establishes the rules, processes, and controls for creating, maintaining, and managing account credentials to access SPC’s applications and resources, protecting SPC systems and data.

Scope

This Standard covers access to all systems developed by or on behalf of SPC that require authenticated access. This includes all development, testing, quality assurance, production, and other ad hoc systems.

Information Statement

Account management and access control include requesting, creating, issuing, modifying, and disabling user account credentials; enabling and disabling access to resources and applications; establishing conditions for group and role membership; tracking accounts and their respective access authorizations; and managing these functions.

Account Management/Access Control Roles

Account management and access control require the Information Owner and Account Administrator roles to be defined and assigned for each resource and application per the Data Classification and Security Planning Policy: I-B. The SPC ISO office documents and maintains a listing of authorized users in these roles. The associated tasks and responsibilities for each role are described below.

Information Owner Responsibilities

Information owners are people at the managerial level who are responsible for the following:

Delegate account administrators (e.g., Director of Enterprise Applications, System Administrator, Network Administrator) to ensure the appropriate level of information access is provided.
Defining roles and groups and the corresponding level of access to resources for that role or group.
Determining who should have access.
Determining the identity assurance level for the application or data (e.g., MFA).

Annually review that accounts and access controls are commensurate with overall business function and that the associated rights have been adequately assigned adhering to the principle of least privilege.
Requiring business units with access to protected resources to notify the SPC Information Security Officer (ISO) or designated security representative when individual access requirements change, or accounts are no longer required and notify Human Resources when users leave SPC.

Account Administrator Responsibilities

Account administrators maintain accounts. They are the delegated custodians of protected data. Account Administrators are responsible for the following:

Maintain appropriate levels of communication with the information owners to determine the level or degree of access granted to an individual.
Determine the technical specifications needed to set access privileges.
Delegate account management functions such as password resets to the help desk.
Create and maintain procedures and scripts used in managing accounts.
Maintain any necessary information supporting account administration activities, including information owner requests and approvals.
Enroll new users.
Enable/disable user accounts.
Create and maintain user roles and groups.
Assign rights and privileges to a user or group.
Collect data to review user accounts and their associated rights periodically.
Assign new authentication credentials (e.g., password resets).

Account Types

Account types include Individual, Privileged, Service, Shared, Default Non-Privileged (e.g., Guest, Anonymous), Emergency, and Temporary:

Individual Accounts: An individual account is a unique account issued to a single user. The account enables the user to authenticate to systems with digital credentials. After a user is authenticated, the user is authorized or denied access to the system based on the permissions assigned directly or indirectly to that user.
Privileged Accounts: A privileged account is an account that provides increased access and requires additional authorization. Examples include a network, system, or security administrator account. A privileged account may only be provided to members of the workforce who require it to accomplish their job duties. The use of privileged accounts must be compliant with the principle of least privilege. Access will be restricted to only those programs or processes specifically needed to perform authorized business tasks and no more. There are two privileged account types - Administrative Accounts and Default Accounts.
Administrative Accounts: An account given to a user that allows the right to modify the operating system and platform settings or enable modifications to other accounts. These accounts must:
- be at an Identity Assurance Level commensurate with the protected resources they access.
- be internally identifiable as an administrative account per a standardized naming convention.
- be revoked under organizational requirements.
Default Privileged Accounts: Default privileged accounts (e.g., root, Administrator) are provided with a particular system and cannot be removed without affecting the system's functionality. Default privileged accounts must:
- be disabled if not in use or renamed if technically possible.
- It can only be used for initial installation or as a service account. When technically feasible, alerts must be issued to the appropriate personnel when an attempt is made to log in with the account for access.
- Do not use the initial default password provided by the system.
- have a password known or accessible by at least two individuals within the SE if anyone knows the password. As such, restrictions for shared accounts, outlined below, must be followed.
Service Accounts: A service account is not intended to be given to a user but is provided for a process. It is to be used in situations such as to allow a system to run jobs and services independent of user interaction. Service accounts must:
- An assigned owner is responsible for documenting and managing the account.
- be restricted to specific devices and hours when possible.
- never be used interactively by a user for any purpose other than the initial system installation or if required for system troubleshooting or maintenance. Wherever technically feasible, administrators should leverage “switch user” (SU) or “run as” to execute processes as service accounts.
- never be for any purpose beyond their initial scope.
- be internally identifiable as a service account per a standardized naming convention.
- not allow its password to be reset according to any standardized or forced schedule. However, should an employee with knowledge of said password leave the entity, that password must be changed immediately.
- have a password known or accessible by at least two individuals within the entity if anyone knows the password. As such, restrictions for shared accounts, outlined below, must be followed.
Shared Accounts: A shared account is any account where more than one person knows the password and uses the same authentication credential. Sharing accounts is only allowed when a system or business limitation prevents using individual accounts. These cases must be documented by the information owner and reviewed by the Information Security Officer (ISO) or designated security representative. Additional compensatory controls must be implemented to confirm accountability is maintained. Shared accounts must:
- have the authentication credentials reset when any of its users no longer need access.
- be restricted to specific devices and hours when possible.
- Where technically feasible, have its users log on to the system with their Individual Accounts and “switch user” (SU) or “run as” the shared account.
- have strictly limited permissions and access only to the system(s) required.
Default Non-Privileged Accounts: The default non-privileged account (guest or anonymous user) is an account for people who do not have individual accounts. An example of where this might be necessary is on a public Wi-Fi network. This account type must:
- be disabled until necessary.
- have limited rights and permissions.
- only be allowed after a risk assessment
- have compensatory controls that include restricted network access.
- be assigned a password that the user cannot change, but that is changed monthly, at a minimum, by an administrator.
- not allow the account to be assigned for delegation by another account.
- have a log maintained of users to whom the password is given.
Emergency Accounts: Emergency Accounts are intended for short-term use and include restrictions on creation, point of origin, and usage (i.e., time of day, day of week). SEs may establish emergency accounts in response to crises and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency accounts must be automatically disabled after 24 hours.
Temporary Accounts: Temporary accounts are intended for short-term use and include restrictions on creation, point of origin, usage (i.e., time of day, day of week), and must have start and stop dates. SPC may establish temporary accounts as a part of standard account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation, such as for vendors, manufacturers, etc. These accounts must have strictly limited permissions and access only to the systems required.

Account Management and Access Control Functions

Automated mechanisms must be employed to monitor account use and management. These mechanisms must allow for usage monitoring and notification of atypical account usage. Thresholds for alerting should be set based on the system's criticality or account assurance level.

Staff in the appropriate account management/access control role(s) must be notified when account management activities occur, such as when accounts are no longer required, users are terminated or transferred, or system usage or need-to-know changes. This should be automated where technically possible.

Systems must have automated access control policies that enforce approved authorizations for information and system resources. These policies could be identity, role, or attribute-based.

By default, no one has access unless authorized.

A system's Identity Assurance Level (IAL) determines the degree of certainty required when proofing a user's identity. The following table describes the level of confidence associated with each IAL.

Identity Assurance Level	Description
1	Low or no confidence in the asserted identity’s validity
2	Confidence in the asserted identity’s validity
3	High confidence in the asserted identity’s validity

Table 1 reflects the standards for account management at each assurance level.

Table 1 – Account Management Standards per Identity Assurance Level

	Identity Assurance Levels
Category	1	2^.	2
Account disabled automatically after x days of inactivity	1096	90	90
Send notification x days before the account is disabled	30	30	14
Account locked after x number of consecutive failed login attempts	10	5	3
Account creation requires an authoritative attribute that ties the user to their account. This could be an employee ID, driver’s license ID, tax ID, or unique individual email address.	No	Yes	Yes
Email notifications will be sent to the user for the following events: · Authentication credential change (password) · Account disabled due to invalid attempts. · Forgotten User Identification (UID) issued. · Account attribute change (e.g., name change) · Account re-activation	If known	Yes	Yes
Self-service functionality allowed	Yes	Yes	No

For all Assurance Levels, the following must be adhered to.

Creating New Accounts: To create an account, a valid access authorization based on an approved business justification must be obtained, and a request must be made to create the account.
Modifying Account Attributes (e.g., changing users’ names, demographics, etc.): Modifications must be made only by the authenticated user or an authorized account manager.
Enabling Access: Access is granted, based on the principle of least privilege, with valid access authorization.
Modifying Access: Access modifications must include valid authorization. When there is a position change (not including separation), access is immediately reviewed and removed when no longer needed.
Disabling Accounts/Removing Access:

Event/Risk Based (Administrative Disable): When an account poses or has the potential to pose a significant risk, the account is disabled, or access attributes are removed upon discovery of the risk. Close coordination between the information owners, account managers/administrators, legal, incident response stakeholders, and human resource managers is essential for the timely execution of removing or restricting user access. Significant risks may include a disgruntled employee or one who has been identified as a potential risk. Users posing a substantial risk to organizations include individuals for whom reliable evidence or intelligence indicates either the intention to use authorized access to information systems to cause harm or through whom adversaries will cause damage. Harm includes potential adverse impacts to organizational operations and assets, individuals, and other organizations. An account identifier is required to identify these accounts and prevent inappropriate re-enabling of the account/access. Re-enabling the account requires explicit SPC approval, so self-service mechanisms may not be used to re-enable the account.
De-provisioning Upon Separation: All user accounts (including privileged) must be disabled immediately upon separation. Credentials must be revoked in accordance with organizational requirements, and access attributes must be removed. Self-service mechanisms may not be used to re-enable the account.
Inactivity Disable: When an account is disabled due to inactivity, access attributes may remain unchanged if the information owner deems it appropriate.
Reviewing Accounts and Access:
- Information owners must review all accounts annually (minimally) to determine if they are still needed.
- Access to privileged accounts must be reviewed every six months (minimally) to determine whether they are still needed.
- Information owners must review account authorizations and user access assignments annually (minimally) to determine if all access is still needed.
- Accounts or records of the account must be archived after five years of inactivity or after specific audit purposes are met.
Unlocking User Accounts: Before an administrator or user support agent can unlock a user's account, the user must be validated using Personally Identifiable Information.
- Secure Log-on Procedures: Where technically feasible, access must be controlled by secure log-on procedures as follows:
- Must not display password or PIN being entered.
- Must comply with the Multi-Factor Authentication Policy I-D(d)

Security Logs must display the following information on completion of a successful log-on:

- Date and time of the previous successful log-on and
- Details of any unsuccessful log-on attempts since the last successful log-on.
Session Inactivity Lock: Sessions must be locked after a maximum inactivity period of 15 minutes. Session inactivity locks are temporary actions taken when users stop work and move away from their immediate vicinity but do not want to log out because of their absences' temporary nature. Users must re-authenticate to unlock the session.
Connection Time-out: Sessions must be automatically terminated after 18 hours or after “pre-defined” conditions such as targeted responses to certain incidents.
Logging/Auditing/Monitoring: All account activity must be logged and audited following the Security Logging Standard. The ability to modify or delete audit records must be limited to a subset of privileged accounts. Any modification to access attributes must be recorded and traceable to a single individual.

Wireless Access
SPC must establish usage restrictions, configuration/connection requirements, and implementation guidance for wireless access. Prior to allowing connections to the wireless network, authorization of wireless access must be approved. SPC must ensure that the access control system protects wireless access to information systems using authentication of users and devices and encryption, ensure that Guest wireless connection restricts access to the internet only, and that no internal systems are available when using Guest Wireless.

Access Control for Mobile Devices

SPC must establish usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices and authorize the connection of mobile devices to organizational information systems.

Use Of External Information Systems

SPC will establish terms and conditions consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:

Access the information system from external information systems.
Process, store, or transmit organization-controlled information using external information systems.

SPC will permit authorized individuals to use an external information system to access the information system or to process, store, or transmit SPC-controlled information only when SPC:

Verifies the implementation of required security controls on the external system as specified in the SPC’s information security policy and security plan.
Retains approved information system connection or processing agreements with the organizational entity hosting the external information system.

Information Sharing

SPC will Facilitate information sharing by enabling authorized users to determine whether access authorizations assigned to the sharing partner match the information's access restrictions. SPC will employ system administrative and data owner support to assist users in making information-sharing/collaboration decisions.

Publicly Accessible Content

SPC will designate authorized individuals to post information on a publicly accessible system. Authorized individuals must be trained to ensure that publicly accessible information does not contain nonpublic information. The data owner must review the proposed content before posting it onto the publicly accessible information system to ensure that nonpublic information is not included. The data owner must review the content on the publicly accessible information system for nonpublic information monthly and remove such information if discovered.

Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards, which may be amended at any time.

If compliance with this standard is not feasible or technically possible, or if deviation from this standard is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

Policy and Procedure Manual

Account Management and Access Control Standard: I-D(a)

Purpose and Benefits

Scope

Information Statement

Compliance

Related Documents:

ExpandExpand Quick Links

.st0{fill:#00355A;} .st1{fill:none;} .st2{fill:#F58426;}

Policy and Procedure Manual

Account Management and Access Control Standard: I-D(a)

Purpose and Benefits

Scope

Information Statement

Compliance

Related Documents:

ExpandExpand Quick Links