Logical Access Security Procedure

Effective Date: September 1, 2025
Revised Date: September 22, 2025

1. Purpose

This procedure establishes standards for account creation, management, and information system management across all systems and accounts within the university. It is designed to align with guidance from the National Institute of Standards and Technology (NIST), Arkansas Legislative Audit, and the Criminal Justice Information Services (CJIS) Security policy, while incorporating operational considerations specific to our user environment.

2. Scope

This procedure applies to all users, including employees, students, contractors, and vendors who access any information system, application, or service under the control of the Arkansas State University Jonesboro campus. Any mention of specific teams, user groups, management groups, or leadership teams will only be applicable to their Jonesboro campus counterpart unless explicitly stated otherwise.

3. Definitions

This section of the procedure serves to assign clear ownership of the necessary components for management and implementation of the logical access security procedure.

Chief Information Officer (CIO): Responsible for establishing and coordinating the campus’ information systems management strategy, ensuring alignment with organizational objectives and regulatory requirements.
ITS Security Team: Responsible for monitoring the campus’ digital infrastructure for both internal and external threats and verification of compliance with organizational objectives and regulatory requirements. This includes the investigation and response of reported or identified security incidents and maintenance of monitoring tools.
ITS Systems Team: Responsible for the campus’ domain-level system administration. Responsible for designing, documenting, maintaining, and overseeing enterprise infrastructure, system configurations, and access to control frameworks. This includes the active management and documentation of all information system accounts. This team establishes the standards and procedures to which endpoint-level support activities must adhere.
ITS Hardware Team: Responsible for the campus’ endpoint-level system administration. Endpoint-level administration will maintain infrastructure in alignment with the standards and procedures designed by the ITS Systems Team.
Department of Human Resources: Responsible for conveying employee employment status to those responsible for organization-level system administration.
Office of the Registrar: Responsible for conveying student registration status to those responsible for organization-level system administration.

4. Procedure Exceptions

The Chief Information Officer for the Jonesboro Campus is authorized to review and approve exceptions to this procedure when organizational needs justify a deviation, and the associated risks are deemed acceptable. All exceptions must be documented, including a defined scope, a scheduled review date, and incorporate compensating controls when appropriate. The CIO may delegate this authority as necessary but retains overall accountability for exception management and review.

5. Passphrase Requirements

This section of the procedure serves to establish four account security levels and outline their respective passphrase requirements. These account security levels serve to accommodate varying account passphrase requirements based on the sensitivity of systems accessed. Universal account passphrase requirements apply to all security levels unless specified otherwise. This section also outlines requirements for local account passphrases but does not place them at a specific security level as their use outside of emergencies is strongly discouraged.

Passphrase settings are not considered enforced unless systematically required.

Universal Account Passphrase Requirements
1. Prohibited Passphrases:
  Passphrases must not appear on known compromised passphrase lists or commonly used passphrase databases. Passphrases will be screened against such lists during passphrase creation and change. A mechanism will be used to detect user passphrases that become compromised after being selected by the user.
2. Passphrase Reuse
  (i) A user’s passphrase cannot match their last 24 set passphrases within the campus’ information systems.
  
  (ii) Users must create unique passphrases for each individual system to which they are given access.
  (iii) Reuse of personal account passphrases for business purposes is strictly prohibited.
3. New User Passphrases
  Users will be required to change their initially assigned passphrase.
4. Multi-Factor Authentication (MFA)
  Users will be required to authenticate using a multi-factor solution during their first authentication of the day for each individual resource. This authentication will be valid for a period of 4 hours. Security Level 3 and 4 accounts are excluded from this universal requirement and will instead follow a stricter requirement as outlined in their section.
5. Alternative Authentication Solutions
  
  Other technologies for user identification and authentication, such as biometrics (e.g., fingerprint verification, signature verification) and use of hardware tokens (e.g., smart cards) will be considered and made available for users, if appropriate. Security Level 3 and 4 accounts are excluded from this universal requirement and will instead follow a stricter requirement as outlined in their section.
6. Duplicated Passphrases
  
  All user passphrases will be unique and cannot match the passphrase of another account in the campus’ information system. This includes any additional account a user may have (such as an administrator account) but excludes accounts synced to the same passphrase using passphrase synchronization at the domain level.
Security Level 1 Accounts
1. Passphrase Length
  
  Account passphrases must be a minimum of 15 characters in length.
2. Passphrase Complexity
  
  Passphrases must include at least one uppercase letter, one lowercase letter, one number, and one special character. Users are strongly discouraged from using repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
3. Passphrase Rotation
  
  Account passphrases will expire after a period of 365 days. This expiration will force the user to set a new account passphrase on their next login attempt.
4. Account Lockout Threshold
  
  Accounts will be temporarily disabled for 15 minutes after five (5) consecutive failed attempts within a 15-minute period. At the end of this 15-minute lockout the user's account will automatically unlock, and the process will restart. Passive authentication attempts are excluded from this requirement.
Security Level 2 Accounts
1. Passphrase Length
  
  Account passphrases must be a minimum of 20 characters in length.
2. Passphrase Complexity
  
  Users are strongly discouraged from using repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
  
  No other complexity requirements are imposed.
3. Passphrase Rotation
  
  Account passphrases will expire after a period of 365 days. This expiration will force the user to set a new account passphrase on their next login attempt.
4. Account Lockout Threshold
  
  Accounts will lock after 5 consecutive invalid logon attempts by a user during a 15-minute period. This account will stay locked until an A-State representative releases the account. Passive authentication attempts are excluded from this requirement.
Security Level 3 Accounts
1. Passphrase Length
  
  Account passphrases must be a minimum of 20 characters in length.
2. Passphrase Complexity
  
  Users are strongly discouraged from using repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
  
  No other complexity requirements are imposed.
3. Passphrase Rotation
  
  Account passphrases will expire after a period of 365 days. This expiration will force the user to set a new account passphrase on their next login attempt.
4. Account Lockout Threshold
  
  Accounts will lock after 5 consecutive invalid logon attempts by a user during a 15-minute period. This account will stay locked until an AState representative releases the account. Passive authentication attempts are excluded from this requirement.
5. Enhanced MFA Requirements
  
  Users will be required to authenticate using a multi-factor solution upon each account authentication.
6. Endpoint Configuration
  Endpoints will be configured to block security level 3 accounts from directly accessing them. Instead, security level 3 accounts will be required to access an endpoint using their security level 2 account and then elevate their access using system specific solutions (such as Sudo on Linux or RunAs on Windows).
Security Level 4 Accounts
1. Passphrase Length
  
  Account passphrases must be a minimum of 30 characters in length.
2. Passphrase Complexity
  
  Account passphrases must be sufficiently complex and resistant to brute-force or dictionary attacks. Use of randomly generated passphrases is required.
3. Passphrase Rotation
  
  Account passphrases will expire after a period of 730-days. If an employee who has accessed a security level 4 account leaves the organization, this passphrase will be reset.
4. Account Lockout Threshold
  
  Security level 4 account information will be stored in a single passphrase management system. Access to passphrases in this system by administrators must be logged with access logs retained for a minimum of three years.
5. Early Passphrase Rotation
  
  When an employee who has accessed a service account leaves the organization, that security level 4 account passphrase must be reset within 12 hours of the employees account being disabled. A passphrase reset of this nature will be considered an emergency priority for change management purposes.
Local Account Passphrase Requirements:
1. Technician Generated Accounts
  1. Local user or administrator accounts created by either domain-level administrators or endpoint-level administrators for specific use cases will have their passphrases changed every 60 days. Passphrase age will be tracked within an EDR when available to ensure compliance.
  2. Account passphrases will be a minimum of 15 characters with at least one uppercase letter, one lowercase letter, one number, and one special character.
  3. Local user or administrator accounts created by either domain-level administrators or endpoint-level administrators for specific use cases on domain joined endpoints will not be accessible by standard users without written approval by the CIO.
  4. Local user or administrator accounts, other than a system generated default administrator account, will not be permitted on endpoints in areas such as the University Police Department, Information Technology Services department, the University Data Center, and any other area containing controlled unclassified information (CUI) to increase data security.
2. Default Administrator Accounts
  1. Local Administrator Passphrase Solution (LAPS) will be utilized for the generation and management of all default local administrator accounts. These accounts should not be accessed unless a severe technical issue prohibits the use of a domain administrator account. Upon use this passphrase will then be regenerated.

Account Classification Matrix

Security Level 1 Accounts	Security Level 2 Accounts	Security Level 3 Accounts	Security Level 4 Accounts
Student Accounts	System Administrator Security Level 1 Accounts	System Administrator Accounts	Service Accounts
Faculty Accounts	CJIS User Accounts
Staff Accounts
CUI Accounts

6. Passphrase Enforcement and Monitoring Mechanisms

This section of the procedure outlines mechanisms available to the Arkansas State University Jonesboro campus for passphrase management and enforcement. It serves to offer direct solutions to the requirements outlined in section three of this procedure.

Passphrase Procedure Enforcement
1. Utilize Fine-Grained Passphrase Policies (FGPP)
  
  FGPP allows system administrators to apply different passphrases and lockout settings to separate user groups. This approach will allow for more granular control of users' passphrase requirements. This work will be completed by a Domain-level System Administrator. This requirement will be applied to all GPO’s and to all university owned endpoints.
2. Enable Passphrase Complexity & Length Requirements
  
  Alternatively, passphrase complexity and length can be set via group procedure to ensure each user group is meeting their unique requirements. This work will be completed by a Domain-level System Administrator. This requirement will be applied to all GPO’s and to all university owned endpoints.
Enable Breached Passphrase Detection
1. Entra Passphrase Protection for Active Directory (AD)
  Configuration of Entra Passphrase Protection for both on-premises and cloud-based accounts will allow for global and custom banned passphrase lists to be utilized during user passphrase changes. This prevents users from setting a compromised or weak known passphrase that a secondary system would then detect and correct, limiting user frustration during the process. This work will be completed by a Domain-level System Administrator. This requirement will be applied to all GPO’s and to all university owned endpoints.
Enable CrowdStrike Passphrase Detection Workflows
1. CrowdStrike Compromised Passphrase Workflows
  Access to CrowdStrike's Identity Protection module allows for custom workflows to be deployed in our environment. CrowdStrike compares the hash of our users' passphrases against the hash of passphrases found in their datasets. The Identity Protection module already flags user accounts with compromised or duplicate passphrases. We can then enable an automated workflow that sends an email to users with this “flag” notifying them of the compromised passphrase and forcing a passphrase change on their next login. This work will be completed by a Security Team Member.
Layering Security Resources
1. Customized Approach
  
  The ideal approach for passphrase security in our environment will be to layer available resources. Passphrase policies increasing the minimum length and complexity for specific user groups as outlined in section 3 will minimize the ability for dictionary attacks or brute force attacks. Microsoft’s Entra Passphrase Protection ensures that users setting up a new passphrase are not using an already compromised passphrase or one from a banned passphrase list. Finally, passphrases that become compromised or are duplicated after being set will be detected and reset automatically using CrowdStrike’s automated workflows.

7. Account Management Requirements

This section of the procedure will serve to outline operational account control requirements to ensure user accounts are handled appropriately from their creation to their deletion. The lifecycle of each account type may vary depending on the criticality of resources accessed, but standardized procedures will limit organizational risk over time.

All user accounts must be uniquely identifiable using the assigned username.
All user accounts will follow a defined and documented naming scheme.
Shared accounts are not permitted for access to Arkansas State University – Jonesboro information systems. Though “shared” by administrators, Service Accounts are not considered shared accounts for the purposes of this requirement.
Non-organizational user accounts, such as temporary or guest accounts, are not permitted for access to Arkansas State University – Jonesboro information systems.
Any non-organizational user access must be granted through the existing sponsored account process.
All user accounts must have a passphrase that complies with the requirements in their respective security level as outlined in section three of the logical security access procedure.
Concurrent connections may be limited for technical or security reasons.
All non-administrator user accounts must be disabled at 5:00 P.M. upon the date of their last scheduled day of work as listed in the termination workflow.
Any account accessed by a terminated user that must persist past their termination (ex. Service Accounts) will be reset within 12 hours of their account being disabled.
All endpoint-level and domain-level administrator accounts must be disabled at 12:00 P.M. upon the date of their last scheduled day of work as listed in the termination workflow. Users will be allowed to continue access to information systems via their standard user account.
All user accounts meeting immediate or retroactive termination criteria will have their account immediately disabled. This disablement will occur for both standard and administrative user accounts.
All service accounts will be thoroughly documented by the domain-level systems administrator, with purpose and any automated tasks executed defined. While a service account's purpose may evolve over time, it is the responsibility of the domain-level system administrator to review this on a regular basis and update the documentation in alignment with active account management.
Arkansas State University Jonesboro information system accounts will be created so that they enforce the most restrictive set of rights, privileges, or accesses required for the performance of tasks associated with their assigned job duties.
Information system accounts with rights, privileges, or accesses extending into the administrative management of endpoints, information systems, or other restricted resources will result in an administrative account being created for the user. This administrative account will exist solely for the completion of assigned job duties extending beyond that of a standard user account.
All information system accounts will be actively managed. Active management includes the acts of establishing, documenting, activating, modifying, disabling, and removing accounts from Arkansas State University Jonesboro information systems. This work will be completed by a domain-level system administrator.
Information system accounts are to be reviewed by domain-level system administrators on a monthly basis to identify inactive accounts. These accounts will be broken into two groups based on their owner’s status:
- Student Accounts: If a student account is found to be inactive for a period of 365 days, the owner of the account and the registration office will be notified of pending disablement. If neither group indicates the student is actively enrolled or will be enrolled in the following term and the account remains inactive for an additional period of 30 days, the account will be manually disabled. After an additional 30 days the account will be permanently deleted.
- All Other User Accounts: If any non-student or non-service account is found to be inactive for a period of 30 days, the owner of the account, the manager of the owner of the account, and Human Resources will be notified of the pending disablement. If no group indicates that the owner of the account will return and the account remains inactive for an additional period of 15 days, the account will be manually disabled. After an additional 90 days the account will be permanently deleted.
- 9-Month Faculty Considerations: Accounts of users on a 9-month contract will naturally end up being marked as “inactive” during the 30-day period outlined above. These accounts will be prevented from being disabled or deleted during the pending disablement notification by either Human Resources or Manager notification to the systems administrator.
Information system accounts are to be reviewed by domain-level system administrators to verify access is still relevant to their assigned duties.
- Review will include verification of:
  - Continued business justification for access.
  - Confirmation of appropriate role-based group membership.
- Any access that is no longer justified must be revoked within 1 business day of the review.
- Review will be conducted in alignment with the following schedule:
  - Security Level 1 and 2 accounts will be reviewed quarterly.
  - Security Level 3 and 4 accounts will be reviewed monthly.
Develop and implement a mechanism for information system account access to be reviewed outside of the monthly review schedule if employee roles are updated.
An independent audit review may be performed to ensure information system accounts are properly managed.

8. Account Management Mechanisms

AI use must comply with relevant regulations, including but not limited to:

FERPA (Family Educational Rights and Privacy Act)
GLBA (Gramm-Leach-Bliley Act)
HIPAA (Health Insurance Portability and Accountability Act)
Other applicable federal, state, or international laws such as:
- UK Data Protection Act 2018
- EU GDPR
- EU AI Act
- China’s Personal Information Protection Law

Legal questions should be directed to the ASU System General Counsel’s Office.

9. Prohibited Uses of AI

The following are not permitted:

Using AI for academic dishonesty (e.g., cheating or plagiarism)
Collecting or using personal data without authorization
Discriminatory or biased use of AI
AI surveillance without approval from A-State IT Security and Legal departments

10. Use of AI Assistant Guidelines

10.1 Overview

AI assistants, such as those integrated into Microsoft Teams or Zoom, can provide valuable support in meetings by generating summaries, action items, and transcripts. However, they are not appropriate for all settings and should only be used in meetings where their presence aligns with meeting objectives, privacy expectations, and institutional policy.

10.2 Risks to Consider

Privacy Concerns – AI assistants record and process meeting content, which may include sensitive or confidential information.
Data Security – Content may be stored in third-party systems depending on the AI service provider, potentially outside the institution’s control.
Compliance – Certain discussions (e.g., FERPA-, HIPAA-, or CJIS-protected data) must not be recorded or processed by AI assistants.
Informed Consent – All participants should understand and agree to AI assistant use prior to recording or summarizing a meeting.
Legal Considerations – Recorded discussions and summaries/transcripts may be subject to legal discovery in future litigation.

10.3 Guidance for Approved Use of AI Assistants

AI assistants should never be enabled by default in recurring meetings or meeting templates.
AI assistants may be used in Microsoft Teams meetings only when all participants provide explicit consent at the start of the meeting.
The meeting organizer is responsible for announcing the AI assistant’s presence and its intended function (e.g., transcription, note-taking, summarization).
Avoid enabling AI assistants in meetings that include confidential, legally protected, or sensitive data.
Store and share AI-generated notes only in secure, approved A-State storage platforms (e.g., Microsoft OneDrive, SharePoint) and should only be shared with individuals who were part of the meeting.

10.4 General Guidance on Preventing AI Assistants from Joining Meetings

In Microsoft Teams, review and adjust meeting options before the session to ensure that AI assistants are not automatically admitted.
Disable transcription, recording, or meeting summarization features unless explicitly needed and approved.
If an AI assistant joins unexpectedly, the meeting organizer should remove it immediately and verify settings before proceeding.

11. Compliance and Enforcement

Misuse of AI may result in disciplinary action per A-State's employee and student handbooks. The university may review AI usage to ensure institutional compliance, especially for licensed tools.

12. Review and Updates

These guidelines will be reviewed as AI technologies and regulations evolve. The IT Security Panel will monitor compliance and propose updates when necessary.

13. Contact Information

Security Inquiries: security@astate.edu
Academic AI Use Questions:
Madeline Ragland, Assistant Vice Provost for Academic Student Services
mprestidge@astate.edu

14. Approved AI Platforms

See Appendix I for A-State-approved AI platforms. All other tools must go through the standard Software Purchase Request process, including submission of a VPAT and HECVAT or ITS Security Questionnaire.

Use of OpenAI platforms such as ChatGPT or DALL·E is discouraged unless a Business Associate Agreement (BAA) is obtained.

Appendix I – Approved AI Platforms

The following AI tools meet A-State's compliance and data protection standards:

Microsoft Copilot (Strongly Recommended)
- Fully compliant with FERPA and HIPAA
Claude Pro (Anthropic)
OtterAI

While Microsoft Copilot is preferred due to its robust compliance standards, other listed tools are acceptable for use. OpenAI platforms (e.g., ChatGPT, DALL·E) are generally discouraged unless approved through a BAA.