Explore UAB

Technology Tool Governance Process

UAB IT works with partners across campus in the process to review technology tools for various purposes.

This governance process:

• Reviews available IT resources needed for successful implementation
• Helps ensure tools comply with security requirements, including federal regulations
• Helps avoid unnecessary duplication and expense
• Evaluates integrations with other technology tools

In this tool governance process, UAB IT, in consultation with strategic campus partners, provides a review that evaluates the risk associated with the above items. In most cases, the review allows the requestor to determine whether to accept any risks and move to the next step in the overall campus review process, such as contract or financial review. In rare cases, the review will determine certain risks that halt the process, such as potential violations of security regulations or duplication of core IT services.

Learn more about the technology tool governance process for each area below:

Administrative tools

Research tools

Academic tools

Submit an Item for Review

Note: Any deviations from the process will be sent to the UAB chief information officer for review and approval before the process continues.

PATCH MANAGEMENT RULE

Approved and Implemented: June 20, 2019

Reviewed/Updated: February 12, 2021

Related Policies, Procedures, and Resources

Data Protection and Security Policy

Data Access Policy

Acceptable Use Policy

Data Protection Rule

Minimum Security for Computing Devices Rule

Vulnerability Management Rule

1.0 Introduction

Patch management is a critical preventive measure designed to proactively counter the exploitation of vulnerabilities that exist within UAB systems. By taking a proactive approach to managing vulnerabilities, the University is able to reduce or eliminate the potential for exploitation and prevent the excessive time, effort, and costs that result when responding to an incident after it has occurred.

Patching may require systems to be rebooted in order for the patch to be applied. Commensurate with this, the disruption to the systems being patched should be minimized by using a preferred window of weekends.

2.0 Scope and Applicability

All UAB-owned devices as well as devices that store, process, or transmit University data must be proactively managed and patched with appropriate security updates.

3.0 Patch Management

1. Endpoints

   a. Patch management for all endpoints is centrally managed by UAB IT.

   b. All critical operating system and application patches will be installed within thirty (30) days of release from the vendor.

   c. UAB IT will prioritize centralized patching efforts in the order of (1) Windows operating systems, (2) Apple operating systems, (3) applications such as Adobe, Flash, etc.

   d. Application software vendors release security patches on a regular schedule. For centrally managed devices, applicable patches will be tested and validated by UAB IT prior to deployment to campus. Once validated UAB IT will schedule and deploy validated patches to end points on a monthly basis. UAB IT will communicate with the campus community regarding deployed security patches.

2. Servers

   a. All university-managed servers will be maintained with the latest security patches to their operating systems and applications.

   b. Each service owner is responsible for UAB servers under their control. Each UAB server must have a named service owner and system owner. When a patch is announced, an authorized system owner must document the change according to formal change management procedures. The service owner must assign a criticality rating based on their experience, the classification of the data (per UAB Data Classification Rule) contained on the server, and the level of risk to the institution in the event of compromise.

   c. All high/critical patches must be applied as soon as practically possible. This period shall not exceed thirty (30) calendar days after public release for any business critical production server.

   d. All medium criticality patches or patches for non-critical systems must be applied within sixty (60) calendar days.

   e. Any low criticality patches will be installed on a case-by-case basis. All patches should be tested on development systems before being rolled out to production, where possible.

   f. In cases where patching cannot follow the standard as outlined above, an exception request form must be completed and submitted to the UAB Chief Information Security Officer (CISO) for approval. These exception requests will only be approved for a maximum of three months and will follow the normal exception request process.

   g. All patches for vendor-maintained systems/applications that are labeled as high/critical must also be patched within thirty (30) days of the approved release from the vendor. The UAB operating unit is responsible for maintaining knowledge of these patches and ensuring that vendors comply with this standard.

3. Endpoint Procedures

   a. Installation and Validation

   i. A system reboot is required to successfully install most security patches. Until the reboot occurs, the computer will remain vulnerable to attacks which the installed patch protects against. Security updates will be deployed using regularly occurring weekend maintenance windows. UAB IT recognizes that flexibility may be needed around a system reboot to provide the university community with the option to reboot with minimal impact to productivity and operations. Because of this, exemptions will be allowed if requested, provided there is a valid business case.

   ii. There are two exemption methods that will allow users to install scheduled updates at their convenience within a pre-determined time-frame.

   Users will be provided five (5) business days to select the installation time of their choice for patching. Should the five (5) business days pass without the necessary reboot, updates will automatically install and may enforce reboots of the computer, as the updates require. In order to ensure that end points are protected, and work is not disrupted due to reboot, it is strongly recommended that users install the updates as soon as possible. When updates are available, they will appear in the system tray. This is the preferred update method if an exemption is required.

   In the event that the five (5) business exemption window for patch application could have a negative impact on academic or operating unit processes a special exemption may be granted. Users that feel this is the case may request to be temporarily exempted from the mandatory reboot process. If an exemption is granted, endpoints will still have patches deployed regularly, but it will be the end user's responsibility to install updates and reboot the machine. Updates will be presented in the same way as the first exemption option; however, the automatic install and reboot is extended to 30 days.

   iii. Out-of-Band Updates

   On occasion, a software vendor will release a critical security patch outside of their normal release cycle. The usual reason for the release of an out of band patch is the appearance of an unexpected, widespread, destructive exploit that will likely affect a large number of users. In the event of a published out-of-band patch, UAB IT will expedite the validation process. Once validated, users will have one (1) business day to install and reboot their machine to apply the patch. In the event that the deadline passes, updates will automatically install and may enforce reboots of your computer as the updates require. UAB IT will communicate with the campus community in the event of an out of band update deployment.

4. Server Procedures

   i. Installation and Validation

   A system reboot is required to successfully install most security patches. Until the reboot occurs, the server will remain vulnerable to attacks which the installed patch protects against. Security updates will be deployed using regularly scheduled weekend maintenance windows within a quarter of release, and for business critical services should be validated in a development environment first.

   ii. Out-of-Band Updates

   On occasion, a software vendor will release a critical security patch outside of their normal release cycle. The usual reason for the release of an out of band security patch is the appearance of an unexpected, widespread, destructive exploit that will likely affect a large number of users. In the event of a published out-of-band security patch, the validation process should be expedited as well as the installation and reboot of the server.

4.0 Enforcement

Each University academic and business unit is responsible for implementing, reviewing and monitoring internal policies, practices, etc. to assure compliance with this standard security rule.

The Vice President of Information Technology Office is responsible for enforcing this standard security rule.

Any device which is not updated as outlined in this standard may be removed from the UAB network, disabled, etc., as appropriate until the device can comply with this standard or an exception request be approved.

5.0 Exceptions

Exceptions may be granted in cases where security risks have mitigating controls in place to lessen the intensity from a critical to a minimal level. To request a security exception, complete the UAB Security Policy Exception request from the UAB IT Tech Help portal.

VULNERABILITY MANAGEMENT RULE

Approved and Implemented: July 1, 2017

Reviewed/Updated: June 28, 2021

Related Policies, Procedures, and Resources

Data Protection and Security Policy

Data Classification Rule

Data Protection Rule

Minimum Security for Computing Devices Rule

Patch Management Rule

1.0 Introduction

This purpose of this document is to describe the process used by University of Alabama at Birmingham Information Technology (UAB IT) in mitigating the risks from computer security vulnerabilities. This standard is intended to represent a minimum baseline for managing vulnerabilities on UAB systems pursuant to the Data Protection and Security policy. Business units may implement more strict standards. This standard may not address every requirement for remediation. Risk assessments, data classification, access control processes, and other requirements may determine that additional remediation beyond this standard is required for a particular system.

2.0 Scope and Applicability

All systems where UAB data is stored, processed, or transmitted must be regularly reviewed for vulnerabilities. Any vulnerability identified will be mitigated based on the criticality of the vulnerability, and the classification of data within the system.

3.0 Roles & Responsibilities

Chief Information Security Officer (CISO)

The CISO is the owner of the vulnerability management process. The CISO designs the process and ensures is implemented as designed. Additionally, the CISO is responsible for approving and overseeing campus use of an enterprise scanning and assessment tool. Further, the CISO has the authority to take action as needed, to ensure that all systems have vulnerabilities are remediated and that any un-remediated issues do not pose a threat to University resources.

UAB Information Security

Members of the UAB and UAB Health System Information Security teams are responsible for developing and implementing an information security program as well as the supporting data security and protection policies, standards and procedures. UAB Information Security is responsible for providing the approved enterprise vulnerability management and penetration testing service. Further UAB Information Security is responsible for providing the results of vulnerability scanning and penetration testing activities to appropriate system administrators and/or Information Security Liaisons, and validating remediation of any noted vulnerabilities.

Information Security Liaison (ISL)

Each unit or department senior manager will designate at least one ISL who will act as a liaison to the UAB Information Security team.  ISLs oversee information security responsibilities for the departments, including assisting with security awareness and security incident response.

For UAB covered entities, UAB Health System has established the Entity Security Coordinator who will act as a liaison to the UABHS Information Security Team and the Entity Privacy Coordinator who will act as a liaison to the UABHS Privacy Officer.

Data Stewards

Data Stewards have administrative control and are officially accountable for a specific information asset.  Data Stewards are:

• Responsible for assigning an appropriate classification to the information;
• Accountable for who has access to information assets; and
• Responsible for ensuring compliance with policies and regulatory requirements related to the information.

Data Custodians

Data Custodians safeguard the data on behalf of the Data Steward. UAB's Central Information Technology (IT) units shall be responsible for protecting all institutional data maintained/stored in the institutional information systems. UAB Health System Information Services (HSIS) shall be responsible for protecting all Health System data maintained/stored in the institutional information systems.

System Administrators

System Administrators are individuals within the central IT/HSIS or school/department units with day-to-day responsibility for maintaining information systems.  They are responsible for following all data security protection procedures and practices.

Data Users

Data Users are individuals authorized to access UAB data and are responsible for protecting the information assets on a daily basis through adherence to UAB policies.

4.0 Vulnerability Discovery

Vulnerabilities in computing devices across campus will be discovered by two means: vulnerability scanning and penetration testing. Vulnerability discovery may be conducted from an internal campus network, or an external perspective.

4.1 Vulnerability Scanning

All computing devices connected to the UAB network, or systems storing or processing UAB business data, are required to be scanned for vulnerabilities on a periodic basis. Vulnerability scanning will be conducted on a monthly basis as a part of normal production operation. More frequent scanning is recommended for systems storing or processing data which is classified as Sensitive or Restricted/PHI, or as required by applicable regulations or standard.

Additionally, scanning activity will occur on an as needed basis under the following circumstances:

• New service or system prior to becoming Internet-facing,
• Major change with existing information system to revalidate security controls,
• Emerging threat due to newly discovered vulnerability,
• Incident response and recovery.

4.2 Penetration Testing

Penetration testing is required for all UAB mission critical systems, all systems hosting Restricted/PHI or Sensitive data, and all Internet-facing systems on no greater than a biennial basis. Penetration testing is also required prior to the deployment of new systems and applications or following major changes, service rollouts, or system upgrades to existing systems and applications.

Penetration testing is subject to the Scope and Rules of Engagement, as defined, drafted, and agreed upon by UAB Information Security and the responsible ISL or system administrator.

Any exploitable vulnerabilities discovered during the penetration test are subject to the same remediation timelines as defined in the Vulnerability Classification Remediation Timeline.

4.3 Scanning and Mitigation

All computing devices connected to the UAB network or systems storing/processing UAB business data are required to be scanned for vulnerabilities. Vulnerability scanning will include the regular credentialed scanning of systems. Additionally, all systems used for remote access must have the vulnerability scanning agent installed.

Information Security Liaisons and/or systems administrators must correct any identified vulnerabilities according to this standard, which could include:

• Deploying available updates and/or software patches,
• Performing configuration changes which address the vulnerabilities identified,
• Removing outdated software versions as newer versions are made available.

Information Security Liaisons and/or systems administrators must request and justify all exceptions to mitigate according to this standard.

All university schools, colleges, centers and business units must develop and adhere to procedures for vulnerability management, including the regular credentialed scanning of systems. Vulnerability management procedures must also address remediating detected vulnerabilities, including timely patch and configuration management, effective change management procedures, and reporting the status of issues to the University Risk Cabinet.

UAB Information Security will be utilizing a continuous monitoring methodology for vulnerability management. This methodology of Discovery & Validation, Risk Classification & Notification, Vulnerability Remediation, and Verification of mitigation will occur in a cyclical basis. Additionally, UAB Information Security will maintain metrics to the vulnerability management program and report the status of issues to the University Risk Cabinet and other organizational leaders by unit on a quarterly basis.

5.0 Un-remediated Systems

The CISO, or delegate, shall communicate directly with Information Security Liaisons and appropriate system administrators in advance regarding any action required to give the department the opportunity to respond. This communication relies upon accurate ownership information and staff contact information being available to the CISO and UAB Enterprise Information Security. In the absence of high-risk circumstances (i.e., a critical vulnerability being actively exploited against a relevant system), the CISO shall communicate at least five days in advance of any action to be taken. In the event of large-scale, high-risk vulnerabilities, the CISO may communicate campus-wide to all Information Security Liaison (ISL), Data Custodians, System Administrators, or other mass-communication paths regarding necessary remediation actions.

High-impact actions such as blocking systems from the campus network shall require the joint approval of the Vice President of Information Technology and Chief Information Officer (CIO), and Associate Vice President and Chief Information Security Officer (or in their absence, CIO/CISO delegates) and may involve communication with appropriate unit leader.

If a system is removed from the network for non-remediated vulnerabilities, the CISO may require additional controls or a control plan prior to allowing a system back on the campus network. The CISO must consider the risk sufficiently mitigated prior to authorizing network service restoration.

The Enterprise Information Security Office will work in collaboration with internal University committees or programs to develop specific guidelines regarding un-remediated systems within the framework of this rule. These guidelines will be approved by the CISO and will balance the requirements of this rule with the potential negative impact to the mission of the University.

6.0 Vulnerability Classifications

The following classifications describe the severity levels that can be assigned to a vulnerability. UAB IT utilizes multiple commercial and open-source tools to conduct vulnerability assessments and penetration testing. Microsoft System Center Configuration Manager is used to inventory assets and patch levels within windows-based systems. These tools provide output that maps into the NIST National Vulnerability Database with Common Vulnerability Scoring System (CVSS), an open framework for communicating the characteristics and impacts of IT Vulnerabilities. Validated findings will be assessed based on the risk of the system and data classification, and will be assigned vulnerability classification as listed below.

End-of-life operating systems or applications are considered a critical vulnerability per CVSS scoring (CVSS Base Score of 10) and are not permitted for UAB business use under the Minimum Security for Computing Devices Rule. These systems must be remediated expediently as would any other urgent classified vulnerability.

Level 5: Urgent -- denotes a vulnerability through which an intruder can easily gain control at the administrator level of any affected host. This class of vulnerability poses the highest risk for a system-wide compromise of the UAB campus network.

Examples: Domain administrator account compromise of UAB Active Directory.

Level 4: Critical -- denotes a vulnerability through which an intruder could gain access to an individual host at the administrator level or could possibly access Restricted/PHI or Sensitive data stored on that host. While this class of vulnerabilities is extremely serious, the risk of a break or compromise is not as urgent as with a level 5 vulnerability.

Examples: Compromise of a server administrator account to an individual server, Internet-accessible remote code execution vulnerability of a system with Restricted/PHI Data or other sensitive data.

Level 3: Serious -- denotes a vulnerability that may allow an intruder to gain access to specific information stored on the host, including security settings. While not immediately associated with a compromise of an affected host, these vulnerabilities allow intruders to gain access to information that may be used to compromise the host in the future.

Examples: Cross-site scripting (XSS) vulnerability within a web application, malformed document which can cause an application to crash.

Level 2: Medium -- denotes a vulnerability through which intruders may be able to collect sensitive information from the host, such as the precise version of software installed. With this information, intruders can easily exploit known vulnerabilities specific to software versions.

Examples: Configuration issues with services presenting application versions in banners.

Level 1: Minimal -- denotes a vulnerability that do not pose an immediate threat to the host or the UAB campus network. These vulnerabilities refer mostly to weaknesses in a device that allow an intruder access to information that may be used in the future to compromise the host. Intruders can collect information about the host (open ports, services, etc.) and may be able use this information to find other vulnerabilities. Departments may opt to mitigate these vulnerabilities based on their network architecture or set up a timeframe for remediation based on the information stored on the device.

Examples: Open ports and services available on a particular device as identified by nmap.

Any identified vulnerabilities related to missing patches or improper configuration must be remediated within the timeframes specified below, or an exception must be in process or approved. For exception requests to be considered in process, relevant administrators must be working diligently toward approval, and Enterprise Information Security Office must have the exception request in hand. Remediation and mitigation should be prioritized based on the degree of associated severity, and the classification of data stored or processed by the system. For vulnerability remediation, administrators should perform effective testing and follow reasonable change management procedures to ensure patch installation for affected systems.

7.0 Remediation and Mitigation Descriptions

After a vulnerability is detected, and a fix is available, a timeline for remediation begins. Level 5 (Urgent) vulnerabilities of mission-critical systems or those systems holding Restricted/PHI may require activation of the UAB Incident Response process for a critical incident at the direction of the CISO.

For level 5 (Urgent) and level 4 (Critical) vulnerabilities for systems holding Restricted/PHI or Sensitive data and/or those systems designated as mission critical, exceptions to the timeline must be granted by the CISO or delegate. Any required remediation activity involving enterprise, mission critical systems must follow the UAB Enterprise Change Management process to deploy and test in an expedient manner and during agreed maintenance windows.

For all other systems, departments are responsible for managing time exceptions on a case-by-case or blanket-exception basis and may establish appropriate procedures for managing those vulnerabilities within the stated timelines. Please note that in rare instances the CISO or delegate may determine that a specific vulnerability poses unacceptable risk to other UAB systems, in which case remediation may be required on a timeline determined by the CISO or delegate.

Remediation is required within the listed periods unless a documented exception request has been submitted to Enterprise Information Security to "halt the clock," and that exception is in process and being worked diligently by relevant administrators or has been approved. CISO-approved exceptions will document the specific remediation timeline requirements for that system or document compensating controls if remediation is not feasible, not necessary, or not appropriate.

Vulnerability Remediation Timeframes

8.0 Sanctions

Due to the significant level of risk tied to Urgent issues and the danger that they pose to UAB users and resources, failure to remediate Urgent issues within one day of notification will result in network access to the offending system(s) or applications(s) being terminated until the Urgent issue has been successfully remediated. Urgent issues involving enterprise, mission-critical systems must follow UAB Enterprise Change Management process to deploy any appropriate mitigation activities during maintenance windows and is not subject to this sanction.

Any device that does not remediate vulnerabilities as outlined in this standard may be removed from the UAB network, disabled, etc., as appropriate until the device can comply with this standard or an exception request be approved.

9.0 Exceptions

Exceptions may be granted in cases where security risks have mitigating controls in place to lessen the intensity from a critical to a minimal level. To request a security exception, complete the UAB Security Policy Exception request from the UAB IT portal.

PASSWORD RULE

Approved and Implemented: January 1, 2014

Reviewed/Updated: February 12, 2021

Related Policies, Procedures, and Resources

Data Protection and Security Policy

Data Classification Rule

Data Protection Rule

1.0 Introduction

The purpose of this standard is to define password requirements for users, servers, and applications at UAB.

2.0 Scope and Applicability

This standard applies to all users and systems at UAB which utilize BlazerIDs.

3.0 Password Standard

Length: All account passwords on systems leveraging BlazerIDs will be a minimum of 15 characters and a maximum of 32 characters. Other account passwords not using BlazerIDs shall be required to request an exception.

a. System Accounts will be complex, 32 characters and have no expiration.

b. Vendor supplied, pre-configured, default passwords are forbidden.

1. Lockout: After 6 failed login attempts, accounts should be disabled and locked out for at least 30 minutes where feasible.
2. Expiration: All user account passwords shall expire annually unless authentication is protected by University provided two-factor authentication or approved biometrics. All privileged user account or administrator passwords shall expire at intervals as required by regulation (e.g., HIPAA, GLBA, etc.).
3. Password Reset after Compromise or Disclosure: Password resets will be required in situations where continued use of a password creates risk of unauthorized access to the computing account or resource.
4. History: Password / passphrase history shall be kept to prevent the previous (1) password from re-use.
5. Caching: Applications or Systems that utilize BlazerIDs shall not cache BlazerID passwords / passphrases, even if hashed or otherwise encrypted, without an approved exception. Individual devices such as smartphone, tablets, etc. are not included.
6. Complexity: Passwords shall contain at least one character from three of the following ASCII character sets: lowercase alphabetic, uppercase alphabetic, and numbers.
7. Logging: Systems shall log successful and failed logon attempts and retain such logs for a minimum of 90 calendar days.
8. Encryption: A one-way hash function wherever possible is required for storing passwords.
9. Unused Accounts: Student accounts unused for more than 180 days shall be disabled. All other accounts unused for more than 90 days shall be disabled.
10. Registration: Applications that leverage BlazerID authentication through a central mechanism/system must be registered with UAB IT.
11. Password Strength: Passwords will be checked against known bad passwords and common passwords to determine strength of the password.

4.0 Enforcement

The Office of the Vice President for Information Technology is responsible for this standard and will programmatically enforce it through the UAB IT Enterprise Identity Management (IDM) organization.