Control Access to Data

Overview

The University of Oklahoma and University community members require reliable and continuous access to data to support the University’s teaching, research and service mission. The University’s data is a valuable resource and asset that must be maintained and protected as such. In addition, the privacy of University community members must be protected to the greatest possible extent.  The purpose of recommending these best practices on data access control is to help ensure the protection of the University’s data resources from accidental or intentional unauthorized access, damage, alteration or disclosure while preserving authorized users’ ability to access and use data as needed to perform their job functions. The purpose is also to support compliance initiatives regarding FERPA, HIPAA, the Gramm Leach Bliley Act and other privacy and security requirements and best practices that address data access controls.

Step One: Understand Responsibilities

Anyone who create access accounts for applications, networks, or systems are required to manage the accounts in accordance with these general access controls.

1. All access must be reviewed and approved by the Data Owner or Data Steward before being granted permissions to access a system or data. 
2. Account passwords must meet the OU Password Policy’s complexity requirements.
3. The password initialization and reset process must be a one-time use, auto-generated random password (sent separately from the username if sent in plain text) that may only be used for systems that require an immediate password change by the user.
4. Accounts must lock after 10 failed login attempts.
5. Sessions or applications must lock or logout after four hours of inactivity.
6. Systems and applications must be configured to display an approved system use notification, banner, or warning.
7. Access control permissions for all non-public data or systems must default to no access, which blocks access by unauthorized users. 
8. Systems must log all successful and unsuccessful login attempts.
9. Authentication logs must be sent to a central log repository that can be monitored by staff. System log monitoring must send alerts to system administrators if the maximum number of login attempts is reached.
10. Passwords must be changed when there is indication of possible system or account compromise. If an account owner is unresponsive the account may be disabled.

Step Two: Schedule a Consultation

Using local authentication increases the risk of users selecting easy-to-guess passwords and storing them in places where they can be easily stolen because users are expected to manage multiple usernames and passwords. Centralized authentication services replaces multiple usernames and passwords with one set of OU credentials to access resources securely. By minimizing the passwords available to be pilfered, centralized authentication decreases the risk of a security breach. 

Request a Security Engineering Consultation to discuss your environment with an OU IT SSO subject matter expert.  OU IT can help you select the best option for your system or project.  OU IT offers several options to implement centralized authentication:

• Active Directory:  Domain-join all servers, workstations, and laptops.
• PingID SSO:  PingID SSO allows a user to sign on with one set of credentials and gain access to multiple applications and services.  PingID SSO can be used with or without Multi-Factor Authentication.
• InCommon Federated Authentication (GLUU Shibboleth):  Federated authentication provides secure single-sign-on access to cloud and local services, and global collaboration tools to connect users across educational institutions, research organization, and commercial resource providers.  Federated Authentication does not provide Multi-Factor Authentication yet.
• Active Directory Federated Services (ADFS):  ADFS is a software component developed by Microsoft and can run on Windows Server operating systems to provide users with minimal sign-on access to systems and applications located across organizational boundaries.  ADFS does not provide Multi-Factor Authentication yet.
• Azure Active Directory SSO:  
• Lightweight Directory Access Protocol (LDAP):  

Step Three: Implement Separation of Duties

Asset Administrators must configure systems to support the separation of duties.

1. Development staff should not have access to production data, unless specifically authorized by the Data Owner to repair a limited number of records.
2. Development staff should not access system level technology or database management systems.
3. End users should not have access to production data except through the features and functions of the administrative applications; in particular, they should not have the ability to bypass or circumvent the applications’ validation and audit procedures.
4. Functional users should not access or modify application code.
5. Systems programmers should not access application code.
6. Accounts should be approved by the data owner and subsequently created by a separate, independent system security administrator.
7. Access to system logs and system audits should be limited to system security analysts, and all such access should be reviewed by IT management.
8. Access to firewalls and other network security systems should be limited to the network security analysts, and all such access should be reviewed by IT management.

Step Four:  Document Access Control Procedures

Document your procedures using the OU IT Access Control Runbook and make sure the procedures describe the process used, including any paper or electronic forms, to request new, modified, or terminated access to the system.  You may also add a workflow diagram to this document.  Review this procedure every year for accuracy.

Data Stewards are responsible for authorizing access and monitoring appropriate use. 

1. Access Control Policies and Procedures, for Category A data or systems, must be documented using the OU HIPAA HCC Program and Procedures – HCC Review of Access to ePHI Systems Procedures.
2. Access Control Policies and Procedures, for all other data or systems, must be documented.  A template is available from OU IT Governance, Risk, and Compliance, if needed.  At a minimum, these procedures must include:
   • The levels of access to data or systems available.
   • Procedures for authorization and approval to grant  new access, modify access, and delete access requests, in accordance with the departmental Role-Based Access strategy or to only those with a “need to know”.
   • Procedures for tracking access requests of any type (new, modify, delete).
   • Procedures and assigned roles/responsibilities for reviewing access levels, at least annually, and more frequent, as necessary.

Step Five: Access Reviews

Data Owners and Stewards must control and monitor access to data within their scope of responsibility and through the use of appropriate administrative, physical, and technical safeguards. 

1. User access must be reviewed, at least annually, when major changes occur, and modified or revoked upon a change in status with the University.  These reviews must include access to all component of a system (e.g., application, database, operating system, etc.).
2. Administrator privileges assigned to individuals must be reviewed, at least every 90 days, and modified or revoked upon a change in status with the University. 
3. The results of user access reviews must be approved by the Data Owner or Steward.