Information Technology Services

eRS - Logical Access Procedure

Responsible Parties
Prepared By / Document Version details / Phone Number
Wade Koeller, QA Office / Version 1 / (314) 977-1654
Effective Date: / Aug. 15, 2008 / Last Updated: / July 31, 2008
Divisions or Departments Affected: / All Facilities Using eRS
Approved By: / Approval Date:

Audience

This document applies to all employees and contractors of Saint LouisUniversity.

Responsibilities

Executive SponsorSaintLouisUniversity

Key StakeholdersSaint LouisUniversity, Saint LouisUniversity Information Systems, Database Administrators

Document OwnereRS Management

ImplementerseRS personnel and Functional Managers are responsible for ensuring all requirements in this document are implemented.

ERS Logical Access Desk Procedure

Saint LouisUniversity - Electronic Research Service

Logical Access Procedure

Table of Contents

  1. Introduction ………………………………………………………………………….3
  2. Policy ………………………………………………………………………..………3
  3. Purpose ……………………………………………………………………..……….3
  4. Scope ……………………………………………………………………….………3
  5. Roles, Responsibilities and Definitions…………………………………..………4
  6. Logical Access Flowchart – General Overview…………………………………6
  1. User Account Set Up………………………………………………………………..7
  2. Initial Account Setup…………………………………………………..……….7
  3. Password Security……………………………………………………………..7
  4. Automatic Account Lockout…………………………………………..……….8
  1. Restricted Application Access…………………………………………….……….8
  2. Eligibility for Access…………………………………………………………….8
  3. Basic Principal Investigator Access Role ……………………………………8
  4. Formal Request for Access – Additional Access Roles…………………….9
  5. Segregation of Duties………………………………………………….……….9
  6. Access Request Types...... ……….10
  7. Standard Access…………………………..………………………...... ……….11
  • ORI Staff Access …………………………………………………………11
  • Access Appeal Process …………………………………………………….12
  • Performance Standard ………………………………………………………12
  • New Implementation……………………………………………………………12
  • Emergency Access …………………………………………………………….13
  1. Changes to User Access……………………………………………………………13
  • Access Role Change …………………………………………………13
  1. Access Termination Procedures …………………………………………………..14
  1. User Resignations/Terminations………………………………………………15
  • ORI and Human Resource Notification ………………………………….15
  • Removal of Access and Account Verification …………………………….15
  • Removing ORI Staff Access …………………………………………….15
  • Emergency Terminations………………………………………………………15
  • Lock Accounts ………………………………………………………………….16
  1. Document Retention…………………………………………………………………16
  1. Monitoring…………………………………………………………………………….16
  1. Service Access and Account Inactivity Reports……………………………..17
  2. Position Change Reports………………………………………………………18
  3. Termination Reports……………………………………………………………18
  4. Documentation of Monitoring …………………………………………………19
  1. Network Operating System Logging……………………………………………….19

Appendices …………………………………………………………………………..21 - 22

I.INTRODUCTION

The overall goal of logical access is enforce and track the level of access to computer resources, preserving both data integrity and data confidentially. Several ‘General Computer Controls’ for application security are essential to achieve this goal and they are:

  • the use of a unique userid for each computer user
  • a strong password
  • proper authorization to access computer resources
  • the monitoring of userids, passwords and logical access

II.POLICY

It is the policy of Saint LouisUniversity’s Information Technology Services(ITS) department to provide all employees with system access to information resources consistent with business needs.

III.PURPOSE

The purpose of this documented process is to outline the procedure in which user access accounts are created, changed, terminated, and monitored within the eRSapplication architecture. The goal of the logical access process is to ensure standardization across all information technology systems and ensure the appropriate data owners are contacted, informed and approve each user access request. All user access requests must be documented using procedures outlined in this process. Implementation of this procedure minimizes unauthorized access to proprietary information and technology.

This procedure will be followed to request and approve access to the eRS application, create user accounts including passwords, and provide ongoing maintenance of user accounts.

  1. SCOPE

This policy applies to the eRSapplication and underlying databases.

This policy applies to students and permanent, temporary, and part-time faculty and staff, contractors, consultants, guests, and all other authorized users of any electronic communication system, including all personnel affiliated with third parties, at Saint Louis University as it relates to eRS operations or use. This policy also applies to all equipment that is owned or leased, which is used to access the eRS application.

In addition, this procedure will be utilized for user level and developer access accounts. A user

account is defined as an account which does not have the permission to install, maintain, or alter in a material way any network, application, service or workstation resource. Developer access accounts are defined as accounts which can modify, configure and install software and/or hardware for an application. Developers can typically create new features and processes within an application and update and/or access data outside the standard application interface.

  1. ROLES, RESPONSIBILITIES AND DEFINITIONS

Role / Responsibility
User /
  • Has access to or requests access to projects, programs or application data via the Process Owner or Authorized Approver.

Business Process Owner (BPO)
Also, may be referred to as Data Process Owner, Business Manager, Clinic Manager or Authorized Approver /
  • Approves access for users to specific projects, programs or application data.
  • Provides guidance to The Office of Research and Innovation relative to user access levels.
  • Identifies and provides required verifications for designated approvers and ensure these persons comprehend the significance of their role in granting access to the University’s Information Systems.

The Office of Research and Innovation (ORI):
Product Manager (may include Program Manager and Administrative Assistant) /
  • Responsible for receiving and reviewing access requests for completeness and authorized approval.
  • Grants access to the applications.
  • Ensures the security of information which users have access and that user access is properly administered and controlled.
  • Responsibility to report any potential or actual risks or incidents affecting the security of information.
  • Monitors compliance with University information security policies and procedures, making recommendations for improved security and for monitoring the occurrence of security incidents.

Quality Assurance (QA) Administrator /
  • Monitors and reviews overall logical access management process.
  • Ensure continued compliance with University information security policies and procedures; ensure logical access processes remain frozen.
  • Reviews logical access and user account reconciliation reports.
  • Provides impartial 3rd party input for user access request denial appeal process.

Definitions

  • Access Form – Abbreviated name of eRS Access Request Form
  • Business Process Owners (BPO) or Authorized Approvers – Certain person(s) of authority within a department, clinic, etc, who have been identified to eRS and University ITS as having the power to approve both user access to University applications and specifically what processes that user is allowed access. The Business Process Owners or Authorized Approvers may be Business Managers, Clinic Manager, Department Supervisors, Hiring Managers, Vice Presidents, Sponsors (in the case of guests, contractors), IT Administrators or others as designated by policy.
  • Information Security Officer– Monitors overall compliance with University information security policies and procedures, making recommendations for improved security and for monitoring the occurrence of security incidents.
  • ITS– Acronym for Saint LouisUniversity, Information Technology Services.
  • ORI – The Office of Research and Innovation
  • ORS – Office of Research Services (A department within ORI).
  • QA – Quality Assurance Office
  • Remedy – Remedy is SLU’s primary problem/request tracking system. It allows SLU ITS to track information as well as internal and external requests placed upon the organization. The information tracks various Remedy applications such as the Asset Management, Service Level Agreements, Change Request, Logical Access requests and Help Desk applications.
  • Remote Access – An encrypted channel or method is required for private access to internal computer applications and systems.
  • SLU– Acronym for Saint LouisUniversity
  • University Information Systems –Includes systems and equipment (workstations, servers, printers, telephones, switches, routers, wiring, hubs, wireless and cellular components, personal digital assistants (PDAs), and other devices and software components that access the University network) and software (applications, databases, eRS).
  • User, Username or SLUNet ID – Refers to any person accessing the University network, including, but not limited to, students, faculty, staff, contractors, clients, consultants, invited guests, and others working at the University.
  • User Account – The user identification, logon/login identification, or other system-specific means granted to a user permitting access to the University network.

VI.LOGICAL ACCESS FLOWCHART – GENERAL OVERVIEW

  1. USER ACCOUNT SETUP

A. Initial Account Setup

In order to gain access to University computer applications and infrastructure, one must have a Banner SLU netIDas established by Human Resources or in accordance with ITS Guest Account Policy and Procedures.

B. Password Security

The username assigned to a unique user name and password will be established in accordance to the following user password and security model structure:

  • Passwords must be a minimum of 8 characters in length;
  • Passwords must not be the same as the login account;
  • Temporary passwords must be changed after initial log in;
  • Passwords must be constructed using at least one of each of the following 3 character types:
  • uppercase alpha (A, B, C, D, E, etc.)
  • lowercase alpha (A, b, c, d, e, etc.)
  • numbers (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
  • Note: Special characters are not allowed.
  • Passwords will expire every 180 days and users will be required to change their password upon this expiration. ITS will run a quarterly report to monitor user account inactivity.
  • Passwords must not be easily guessed; must not be names, dictionary words, phone numbers, or birthdays;
  • Passwords must be different from the previous 12 passwords.
  • Passwords must be stored in encrypted format to prevent tampering.
  • Access of privileged users who perform administrative tasks must be restricted and properly approved.

If the application does not support the minimum structure and complexity detailed in the aforementioned guidelines, University ITS must ensure that one of the following procedures be manually implemented:

  • The password assigned must be adequately complex to insure that it is not easily guessed and the complexity of the chosen alternative must be defined and documented.
  • The legacy system must be upgraded to support the requirements of this procedure as soon as administratively possible.
  • All applications should be isolated from the main university networks or relocated to a system that supports the foregoing security password structure.

Initial and temporary user account passwords that are systemically generated will be communicated to the BPO via a secured method per best business practices. It is the BPO’s responsibility to ensure appropriate user application training and facilitating the initial password change process. The BPO should specifically instruct the user on the password change/use policy, in addition to directing them to the location of all University policies and procedures.

C. Automatic Account Lockout

ORI will enable the automatic lockout capabilities to ensure that all SLUNET IDsare temporarily suspended or locked out after three consecutive unsuccessful login attempts.

  1. RESTRICTED APPLICATION ACCESS

In order to enforce security of sensitive and confidential data and data networks, a number of SLU business applications have restricted access. It is important to ensure that users have access only to the areas required to perform their functions at the University. The process of requesting, monitoring and modifying access to key applications, involves having proper eligibility for access, proper segregation of duties analysis, formal request for access, account verification and follow proper documentation retention standards.

The remaining sections describe procedures for requesting, changing and deleting user access to the eRS application.

A. Eligibility for Access

In order to obtain access, SLU employees must have an active Banner account record in the Human Resources database and an active email account or comply with the ITS Guest Account Policy and Procedures (see Section VII - User Account Setup). Non-SLU employees must have authorized approval as discussed in the Section – Basic Principal Investigator Access Role. The BPO for each user request must confirm appropriate eligibility before approving the request for access.

It is imperative that the BPO (or other personnel responsible for the hiring process within a department/academic unit or clinic), ensure that the necessary documentation for SLU employees is submitted to Human Resources so that the Banner ID can be established in a timely manner. The BPO should verify that the Banner ID is established before submitting a request for user access to the eRS application.

B. Basic Principal Investigator Access Role

All full-time faculty and staff employed by Saint LouisUniversity, with an approved Banner ID and SLU email are eligible to have an eRS account, provided that the Faculty or Staff member is submitting a request for Funding (grant) or the Staff member is assisting in the submittal of a grant. The Office of Research Services (ORS)Administrative Staff is delegated the authority to establish these accounts and PI roles from their dashboard. TheORS Administrative Staff will make the determination on an individual basis if the person requesting an account needs additional authorization, before creating the account.Any additional authorization should be obtained in writing (i.e., email).

Others who do not meet the eligibility criteria above, including part-time employees, students, or individuals not employed by Saint LouisUniversity, must submit a written request to the Director, ORS, that includes the name and work address of the individual, and a justification for why an eRS account is needed. The request should specify what academic unit the individual is affiliated with, and the name of the individual’s supervisor in that academic unit. ORS will review the request and contact the individual with approval or denial of the request. In the case of approval, an eRS account will be created for the individual by ORS.The approval of the written request should be documented and retained.

Any individuals needing additional roles or individuals outside of these parameters (i.e. VA personnel, auditors, contractors) will require the eRS Access Security Request forms with the required approval signatures.

C. Formal Request for Access – Additional Access Roles

If additional access roles are required above and beyond the PI role, an eRS Access Request Form(hereafter referred to as Access Form) should be completed by the BPO.The BPO should generally submit the Access Form at least two days prior to the users first day at work.At a minimum, the following information should be contained and completed on the Access Security Request Form:

  • User’s full name;SLUNET ID (username), and Banner ID
  • User’s telephone number (If Assigned)
  • Job title and/or contractor name
  • Employment status (e .g., Employee, Contractor)
  • Employment (contractor/project) start and end dates
  • Department Name and Number
  • Division name and Principle Investigator (PI) name, if a collaborator
  • Additional information for non-SLU users that do not have a Banner ID includes last four digits of SSN, birthdate, address, email address)
  • Type of Request (new, edit, transfer, delete access)
  • Access rights, roles
  • Other information as necessary to identify level/type of access requested (e.g., user, power user, administrator, developer)
  • Segregation of Duties statement
  • Approval signature of the BPO(The ERS Account Role Description, as attached to the Access Form, lists the access roles and specific approvals required.)

(Note: The “start” date on the Access Formshould be included as a means to ensure access is established upon the users expected start date. The “end” date should be completed, particularly for all guests/contractors, temporary personnel and non-university users when a termination date is known or stipulated. The BPO and ORIis strongly encouraged to monitor this “end”date to ensure timely removal of user access).

The BPO should select the access to the data required for its users’ job functions. The form is located at the following:(

D. Segregation of Duties

The BPOshould determine the specific functions and responsibilities for which the individual needs access, specifically access to key Financial and Human Resources applications. The BPO must perform a segregation of duties review.

Segregation of duties prevents a single person from performing two or more incompatible functions. Failure to segregate incompatible duties, or to implement compensating controls when such separation of duties is not possible, increases the risk that errors or unauthorized actions may occur and not be detected in a timely manner.

Some examplesof incompatible duties include users having systems access enabling them to:

  • Perform billings/invoicing, receivethe corresponding payments, and record the corresponding cash receipts entries.
  • Authorize disbursements, issue corresponding disbursements, and record corresponding disbursements entries.
  • Set up a new employee, input pay rates/salary, and issue pay checks.

Some special aspects of segregation of duties apply to IT functions themselves. There should be segregation between systems development and operations, operations and data control, and data base administration and system development.

Access can be restricted to specific functions within some applications. For example, a user may be given access to prepare requisitions, but not to approve requisitions. In addition, a user may be given one of the following levels of access to some applications:

  • Modify (read/write) access: the ability to enter and update data and submit transactions or
  • Query (read-only) access: the ability only to view information without being able to enter or change data.

The Access Form includes a statement noting that the access rights being granted are appropriate for the user’s job functions and that segregation of duties has been considered. By signing/approving the Access Form, the BPO is noting that the appropriateness of the access rights and segregation of duties has been evaluated and the access is justified. As necessary, the BPO should provide any additional comments regarding the access rights and the appropriateness of the access rights to the user’s job functions.

In those instances where duties cannot be fully segregated, mitigating or compensating controls must be established and documented with the Access Form, or access rights to be granted should be adjusted. Mitigating or compensating controls are additional procedures designed to reduce the risk of errors or irregularities.

E. Access Request Types

Access granted will fall into one of the following categories:

  • Standard Access – A general new request
  • Emergency – A requirement of immediate access that does not follow the standard access procedure, where access may need to be granted beforean Access Form can be initiated.
  • New Implementation – Provides for new implementation of a product, service or function that affects multiple users. Generally the same access rights are being granted to the user group.

These access scenarios are further discussed below.