university of south florida issp-003 access control standard

University of South Florida

ISSP-003

Access Control Standard

Code: ISSP-003

Version: 3.3

Last Modified: 7/13/2020

Last Reviewed: 7/13/2020

Created and Edited by: Alex Campoe (CISO)

Approved by: Sidney Fernandes (CIO)

Confidentiality Level: Low

DocuSign Envelope ID: 601DF391-9EC2-4BBA-9040-ADB39C5EA910

7/13/2020

7/13/2020

ISSP-003 – Access Control Standard

Information Technology

2

Revision History

Version Published Author Description

2.0 6/3/2019 Campoe New formatting

Merge of SQL Update document with Change Management

Normalized use of Standard, Normal, and Emergency changes through the document

3.0 4/23/2020 Campoe Incorporated account management controls per NIST 800-53 (Rev. 4) AC-2 to existing password management standards.

Title updated to “Access Control Standard.”

Included several account management topics, including entitlement review, and process to handle multi-affiliation accounts upon termination

3.1 5/2/2020 Campoe Added detailed information on how to perform an entitlement review.

3.2 5/15/2020 Campoe Additional changes to Entitlement Review section per feedback from University Audit.

3.3 07/13/2020 Campoe Added section on Epic account authorization process




3

Table of Contents DEFINITIONS .......................................................................................................................................................... 4

USF ACCOUNTS ...................................................................................................................................................... 5

PROVISIONING ............................................................................................................................................................... 5

SPECIAL ACCOUNTS TYPES ................................................................................................................................................ 6

Service Accounts .................................................................................................................................................... 6

Privileged Accounts ............................................................................................................................................... 6

Shared Accounts .................................................................................................................................................... 6

Guest Accounts ...................................................................................................................................................... 7

DEPROVISIONING ............................................................................................................................................................ 7

IMMEDIATE DEPROVISIONING ........................................................................................................................................... 7

DEPROVISIONING OF MULTI-ROLE ACCOUNTS ...................................................................................................................... 8

AUTHENTICATION .................................................................................................................................................. 8

PASSWORD POLICY ......................................................................................................................................................... 9

AUTHORIZATION .................................................................................................................................................. 10

EPIC EPHI ACCESS AUTHORIZATION ................................................................................................................................. 10

ENTITLEMENT REVIEW ................................................................................................................................................... 11

ENFORCEMENT ..................................................................................................................................................... 11




4

ISSP-003

Access Control Standard

The University of South Florida is committed to protecting the privacy of its students, alumni, faculty,

and staff, as well as protecting the confidentiality, integrity, and availability of information essential to

the University’s mission.

Definitions

Information Technology (IT) Resources shall be interpreted to include all USF System computing and

telecommunications facilities, equipment, hardware, software, data, systems, networks, and services that are used

for the support of teaching, research, and administrative activities of the USF System.

A USF Unit consists of any College, Department, Research Center, Institute, Direct Support Organization, or other

administrative subdivisions that are connected to the University of South Florida network.

An Identity and Access Management (IAM) System is a framework of business processes, policies, and

technologies that eases the management of electronic or digital identities.

IAM encompasses the following components:

Clear identification of all unique individual with an existing relationship with the University

A set of processes and policies that associate one or more roles with each individual.

Managing the lifecycle of individuals and their roles in a system.

Supplying roles to downstream systems (known as Service Providers) to use as the basis of determining

what these individuals can do (Role-Based Access Control, RBAC).

Protecting the Personally Identifiable Information (PII) contained in the system to preserve the privacy of

the individuals.

IAM provides

Automatic User Provisioning

Reduced traffic of passwords in the network.

Password Management

Single Sign-On (SSO) and Same Sign-On

Information on affiliation for downstream Role-Based Access Control

Single location for logging and monitoring of authentication

USF’s Identity and Access Management System is the NetID System

A System of Record (SoR for short) is a system with authoritative data about users who should -- and should not --

have access to systems and applications. The most common type of SoR is a human resources (HR) application,

which can provide a current list of employees, along with employment status and possibly start and termination




5

dates. This data can be consumed by an identity and access management system to automatically create new and

deactivate existing accounts. 1

Single Sign-On (SSO) is the ability to sign-in or log into the platform once and be able to use different applications

in the platform or suite without having to enter your credentials several different times, which is undoubtedly a

benefit to the user.

Same Sign-On is the option that synchronizes user ids and passwords to the various places where authentication

might occur. The user has the same credential on all systems, but it must be entered again when moving from one

system to another. SSO is enabled using Federated Authentication protocols, where IT Resources trust

authentication coming from a central system.

Figure 1- Simplified Overview of USF IAM System

USF Accounts

Every authorized user of a USF IT Resource shall have a unique login ID. All IDs used to access a system that does

not supply a unique user identification shall have access only to specific, limited system resources. These accounts

may be created either in a central repository to which systems may federate to consume the identity and

authentication information (NetID) or locally on a system where federation is not practical or possible. Local user

accounts can be created, but USF standards for NetID and processes such as deprovisioning requirements must be

observed. The use of NetID with federated authentication is always the preferred method.

Provisioning

1 System of Record | Identity and Access Management Concepts. https://hitachi-id.com/resource/iam-concepts/system-of-record.html


https://hitachi-id.com/resource/iam-concepts/system-of-record.html



6

NetIDs are provisioned and deprovisioned according to the relationship dates provided by the Systems of Record.

For instance, accounts are automatically created and ready for use by a St. Pete employee on his first day of work

and deprovisioned according to the termination date in the GEMS HR system.

The following are the Systems of Record for the NetID system. They hold authoritative data regarding an individual

within specific roles.

Health Banner - The Banner system that contains data for individuals enrolled in the Morsani College of

Medicine and the Taneja College of Pharmacy

Banner – The system known as Banner, or “Main Campus Banner,” is the origination for all students from

Tampa, St. Pete, and Sarasota Campus, except for those already contained in Health Banner. GEMS – USF’s Implementation of PeopleSoft Human Resources System providing identity information for

all faculty and staff at USF, Tampa, St. Pete, and Sarasota.

Cyborg – Human Resources System containing all physicians, administrators, and all remaining staff

employed by USF Physician’s Group.

Innovative Education – This SoR brings in the identities for all the non-USF students attending classes

offered by USF Innovative Education that need to use USF IT Resources such as computer labs and wireless

access. Includes students in need of Continuing Education Units (CEUs) for their profession, general

Continuing Education classes, and others.

Guest Account System – This SoR holds the identity of all other users requiring access to IT Resources who

do not fit in any of the categories listed so far. They include volunteers, visiting researchers, consultants,

participants in Summer programs, and others. Details on this type of account can be found later in this

document.

Special Accounts Types

Service Accounts A service account is used when it is necessary for systems or applications to authenticate to other systems or

applications without any association to a person. These accounts should be created sparingly. Their use must be

periodically reviewed. Further, the password requirements for service accounts must be no less stringent than user

accounts. Finally, service accounts may not be used by people to authenticate aside from initial testing. Service

accounts with elevated privileges must be closely monitored for abuse.2

Privileged Accounts Certain accounts may have extra privileges related to the management of a device or application. This is often

thought of as an account type, but it is more accurately described as an account with privileged authorizations.

Administrative privilege can be added to any account type. Having at least one account with privileges is generally

unavoidable but the use of privilege should be limited and the direct use of shared accounts with privileges should

be discouraged as it lacks accountability.2 As often as possible, System Administrators should have a separate,

secondary account that is used when performing administrative activities.

Shared Accounts In certain limited situations, USF IT will approve the creation of shared accounts, accounts designated for use of

multiple people. Even in these situations, account and password management is required, and duties delegated to

2 Identity and Access Management Policy | Policies. https://www.bu.edu/policies/identity-and-access-management/


https://www.bu.edu/policies/identity-and-access-management/



7

a unique individual, usually someone who also used the shared account. This individual is responsible for the

periodic change of password upon expiration. The password in these accounts also must be changed every time

someone with knowledge of the credentials no longer has the need to access the account. Upon individual

employment termination, for instance.

Guest Accounts The Guest Account System is used to create NetIDs, and consequently grant access to IT Resources (such as an

email account, wireless access, Information System access, and others) , for individuals who have a business or

academic relationship with the University but do not have an identity in any other System of Record. By default,

Guest Accounts are automatically authorized to obtain access to:

1. An Office 365 email account in the form [email protected]

2. The ability to obtain a USF ID Card

Any additional authorization for use of other IT Resources beyond the ones listed above must be worked out

directly with the owners of the Service Provider.

Guest accounts must be requested by a USF faculty or staff with an “active” affiliation with the University

(Requestor) and approved by specially designated individuals within a department (Approvers). Usually the

Requestor and Approver will belong to the same department but in certain situations that may not be the case.

Guest accounts will expire every 6 months. Approvers will have the opportunity to renew the account prior to

expiration if the relationship between the University and the Guest is continuing. Requestors are required to notify

USF IT when the account is no longer needed, if that period is shorter than the 6 months originally granted.

Deprovisioning

Data from the System of Record dictates when accounts are created and disabled, and roles are added or removed

from an account. These roles control the authorization to access services offered by the Service Providers. Access

to services or IT Resources will be suspended, and the account deleted, when there is no longer a business or

academic need for access. The removal of the account shall be performed in a manner proportionate to the level of

risk posed by such access as determined by Human Resources in conjunction with the appropriate unit leadership,

including immediate removal of access and privileges of the account if necessary. If there is need to maintain a

certain role associated with an account past the termination of the relationship, a special request must be made to

USF IT.

Employees must remove any personal data from USF IT Resources systems prior to their last day at USF. If that is

not possible, a request must be made to the former supervisor who in turn can authorize USF IT to plan to retrieve

the personal data, provided it is still available.

Upon termination of a faculty or staff member, USF IT shall remove access to the service(s) but will keep email,

calendar, and cloud-stored files following the requirements of State and Federal law as determined by the new

records custodian. At the end of the required retention period, the files shall be purged from the system pursuant

to USF Policy.

Immediate Deprovisioning In certain situations, it is necessary to remove authorization to access IT Resources prior to or immediately upon

termination. For example, removal of roles often needs to happen while an employee is in the termination meeting

with Human Resources, especially if there is fear that the individual being terminated could affect the




8

confidentiality, integrity, or availability of the data under his responsibility. In those situations, hiring supervisors

are advised to send a request to [email protected] as soon as the outcome is determined. Often users have

multiple roles, such as staff and employee at the same time. When advised ahead of time, USF IT can research all

the roles the user has and recommends the best course of action to the supervisor. Emails to this address are only

received by a very small group of people and are kept highly confidential.

Deprovisioning of Multi-Role Accounts

At times, an individual will belong to multiple roles, as an employee taking classes (Faculty/Staff and Student Roles).

A user’s NetID is attached to the individual, not to the employee’s department. When that employee no longer

works at USF, the supervisor is responsible for obtaining agreement from the former employee to allow access to

the user’s data, if such access is desired. In certain situations, when the employee dealt with high sensitivity data,

departments may request that the data in the O365 tenant is removed before turning the account to the former

employee. GC authorization.

Authentication

Authentication occurs whenever a user attempts to access USF’s IT Resources. It is a verification that the user is

who he says he is. Verified credentials serve as a digital passport, proving a user’s identity to various systems.

Figure 2- Authentication Windows at USF

When the data held by service providers require more certainty of an individual’s identity, Multi-Factor

Authentication (MFA) is used. The term refers to the fact that users must not only “remember their password” but

also “have something.” At USF, the second factor is either provided by DUO or Microsoft Authenticator. A sample

of the DUO MFA screen is provided in Figure 3 below.


mailto:[email protected]



9

Figure 3- DUO Multi-Factor Authentication

Password Policy

All user accounts shall be subject to the password management requirements of the University. The following

settings are a mandatory baseline for all Service Provider systems at USF. Individual exceptions can be made by USF

IT based on the risk associated with the data stored and managed by the system.

Minimum password length (characters) 8

Password must meet complexity requirement Enabled

Store password using reversible encryption Disabled

Enforce password history (no. of unique passwords) 5

Maximum password age (days) 180

The minimum password length establishes the minimum size allowed for a password. The longer the password, the

harder it is for a hacker to break it. Many departments are getting away from the idea of a “password” and using

the concept of a “passphrase” instead.

When complexity requirement is enabled, passwords must

Not contain all or part of the user’s account name

Contain characters from three of the following four categories:

o English uppercase characters (A through Z)

o English lowercase characters (a through z)

o Base 10 digits (0 through 9)




10

o Non-alphanumeric characters (e.g., !, $, #, %)

Note that enabling the complexity requirement on an existing system must also be followed with an appropriate

value for the maximum password age (see below) or a domain-wide password reset requirement. Otherwise,

existing users with simple password will never be required to change their passwords.

When reversible encryption is enabled, encrypted user passwords are stored by Windows as a reversible hash,

which is essentially the same as storing the password in plaintext. This could allow any domain user to read the

password of any other domain user account, including the Administrator account.

Enforcing password history spells out the number of “old passwords” the system remembers. The user will not be

allowed to use any of these passwords when entering a new one.

The maximum password age parameter dictates how often a user will have to change his or her password. When

this limit is reached, the current password is expired, and the user is forced to choose a new password.

Authorization

Once an individual is authenticated, the Service Provider application needs to determine what level of

authorization he has in the system. Access rights to an IT Resource will be determined based on the business and

academic needs of the individual user and the value of the data to securely maintain the confidentiality and

integrity of the data.

Authorization determines a role’s level of access in the network. These items may include systems, applications, file

shares, printers, and more. For example, an accounting department employee who regularly works with payroll

software must be authorized to do such.

While authentication is simple, authorizations and their management are far more challenging. Authorizations

consist of complex sets of rules, rights, groups, and permissions explicitly configured per user account.3 Each

Service Provider determines the roles maintained by the NetID system required to grant authorization for access.

For instance, in order to access the GEMS Self Service functions an account must have the Faculty or Staff role.

In many circumstances, merely belonging to a certain role is not enough to grant access to a system. This is due to

the principle of need-to-know. For instance, not all Faculty members are advisors. Not all IT Staff members have

access to our Security Logging system. When this is the case, additional processes must be put in place to

determine and approve the access to the service.

Epic ePHI Access Authorization Epic accounts are needed for USF Physician’s Group employees to be authorized to access the TGH Epic instance.

After the employee obtains their NetID, the following must happen:

Forms must be signed by both a department leader and the requester.

For clinicians, please include certification or license numbers. Missing license numbers are a common

cause of account creation delays.

3 What is Identity and Access Management (IAM)? | Tools4ever. https://www.tools4ever.com/glossary/what-is-identity-and-access-management/


https://www.tools4ever.com/glossary/what-is-identity-and-access-management/

https://www.tools4ever.com/glossary/what-is-identity-and-access-management/



11

IRB information is required for research-related account requests.

Accounts are generally available within 3 business days after all requirements have been completed

More details about the authorization process can be found at

https://confluence.usf.edu/pages/viewpage.action?pageId=276398172#EpicAccountRequest-Epicaccountrequest .

Entitlement Review

Owners of the data housed in the Service Provider are responsible for confirming and documenting the validity of

the access level provided to every user on an annual basis. This is known as Periodic Access Reviews (PARs) or

Entitlement Review. Periodic entitlement reviews are imperative to ensure that only the right people have access

to the right data: unchecked access or infrequent permission reviews leave organizations at risk of data abuse, theft

or misuse.

When using NetID, access certifications are generally configured to occur when changes in roles or entitlements are

detected by the IAM application. For instance, access to email is authorized when a user is loaded in GEMS and

removed when GEMS indicates the individual is no longer an employee. Certain Service Providers also can look at

the user’s affiliation, striping roles when the user moves from a department to another or adding access

permissions when a student becomes an employee.

The following tasks must be performed by the system owners as part of the entitlement review:

Periodically generate list(s) of users and their assigned roles from the system.

Have users’ supervisor(s) review the list(s) to determine if users are active employees, and have an

ongoing business need for the assigned access

Ensure role definitions are available to assist supervisors with the step above.

Ensure supervisory reviews are documented and retained in accordance with all record retention

requirements (GS-1, etc.).

Frequency of reviews should be based on relative risks, not less than annually for lower-risk systems, and

at least semiannually for systems that house more critical or sensitive information.

In the event user access reviews are not practical (i.e. large number of external users), user accounts

should be set to expire at least annually thus requiring those users to be re-provisioned.

Enforcement

USF IT Resource transactions, including but not restricted to the creation of accounts, system login and logout, use

of Multi-Factor Authentication, are logged and monitored to help protect the confidentiality, integrity, and

availability of the University’s data and the privacy of our users.

All USF System students, staff, and faculty must follow this standard. Access to USF IT Resources is a privilege. All

persons and USF Units connecting to the USF network must follow USF standards, published on the USF IT website,

and USF System Policies and Regulations. Failure to comply may result in the removal of access at the discretion of

the USF IT Office of Information Security (OIS).

Individual user violations of any policy or standard published by the OIS may be subject to disciplinary or corrective

actions based upon the policies, rules, regulations, and procedures of the University of South Florida System. These

actions may include sanctions including, but not limited to, revocation of the employee or student privileges up to


https://confluence.usf.edu/pages/viewpage.action?pageId=276398172#EpicAccountRequest-Epicaccountrequest



12

and including termination of employment or expulsion. Certain violations, misuse, unauthorized access, or

disclosures of confidential information may include civil and criminal penalties.


university of south florida issp-003 access control standard

Documents