IT1516-HSC-B.01 Application System Security Features

Responsible Office: Office of Cybersecurity

Last Review: 03/01/2025

Next Review: 03/01/2027

Contact: Chris Madeksho

Phone: 901.448.1579

Email: mmadeksh@uthsc.edu

Purpose

To require that Application Systems installed at the University of Tennessee Health Science Center (UTHSC) meet specified security features to prevent unauthorized use, access, transmission, modification, or destruction of UTHSC data or information.

Scope

All Application Systems installed and/or used in UTHSC that process, store, access or transmit UTHSC data or information.

Definitions

Application – the system, functional area, or problem to which information technology is applied. The application includes related manual procedures as well as automated procedures. Payroll, accounting, and management information systems are examples of applications.

OWASP – Open Web Application Security Project – an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the field of web application security. The Open Web Application Security Project provides free and open resources.

Responsibilities

UTHSC developers are responsible for ensuring that any custom-developed Application Systems developed and deployed by UTHSC must meet the security features listed in this Practice.

Practice

All Application Systems shall be included in an Application System Inventory and at a minimum indicate the following information:
- Name of the Application System
- Purpose of the Application System
- Data or Information Owner
- Application System Custodian
- Vendor/contractor (if applicable)
- Classification of the data that it creates, captures, stores, or processes referenced in IT0005-HSC-A-Data & System Categorization.
- Examples of types of Information:
  - Protected Health Information (PHI)
  - Personal Identifiable Information (PII)
  - Student Records and other related FERPA data
  - Credit Card Numbers
  - Other
- Recoverability objectives (after the loss of system availability, the period of time that an operation can rely on a contingency operation without detrimental effects to the customers the operation serves) in terms of:
- Recovery time objective based on business impact (IT0311-Information Technology Data Access Management and Recovery):
  - Business Impact Nominal – Data is unavailable over 2 weeks with minimal to no impact on organizational operations, organizational Assets, or individuals.
  - Business Impact Low – Data is unavailable for 72 hours to 2 weeks and it could be expected to have an adverse effect on organizational operations, organizational Assets, or individuals.
  - Business Impact High – Data is unavailable for 72 hours or less and it could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational Assets, or individuals.
  - Business Impact Critical – Data is related to control Systems that support the University, but if subverted, could be life-threatening to University Employees, students, and others using University facilities (e.g., attending athletic events).
- If server-based, unique machine name or DNS name of the server and location.
- If client-based, estimate of the number of clients and buildings where the client software is installed.
- External system dependencies – other systems not in control of the Unit that the software depends upon to operate correctly (i.e. Authentication systems, critical data feeds, etc.) and a technical support contact name for the external system.
Features for acquired or custom-developed Application Systems that must be examined in all acquired or developed software products while evaluating and testing other features, and prior to actual use in production or by users, are as follows:
1. Compatibility with Industry Security Standards
2. Does not require the use of unauthorized mechanisms for remote access to the software, such as:
  - Unencrypted transmission
  - Undocumented ports
  - Unauthorized or undocumented access accounts
3. Does not disable or circumvent standard antivirus protections, authentication, automated OS patch management or other security controls on the end user device, server, or network.
4. Does not require elevated system rights in the OS to run.
5. Third-party software must be acquired through a credible and known credible software source that has a history and reputation for distributing trouble-free and legally acquired software. A security evaluation on new Application System purchases
6. Technical support and maintenance are clearly identified and provisioned to maintain the software throughout the life of the software.
7. Version maintenance responsibility is clearly defined to ensure software continues to comply with security standards and remains compatible with an OS that is still vendor-supported with security patches.
8. Users, devices, and processes are required to authenticate.
9. Authorization is based on the least privileged principle and role-based.
10. Users, devices, and process activity are logged per IT7810-HSC-D-Logging and System Activity Review.
11. Data stored by the software on end-user devices without user intervention, knowledge, or opportunity to prevent are encrypted or otherwise protected.
12. Documented evaluation and testing for Application System components and security features.
Security features that are for Web-based Application Systems must adhere to:
1. The following Principles (see OWASP Principles for definitions):
  - Apply defense in depth (complete mediation)
  - Use a positive security model (fail safe defaults) (minimize attack surface)
  - Fail safe
  - Run with least system privilege
  - Avoid security by obscurity (open design)
  - Keep security as simple as possible to meet required security
  - Detect intrusions (compromise recording)
  - Does not trust infrastructure or external services
  - Established secure defaults
2. Countermeasures (see OWASP Principles for definitions):
  - Access Control
  - Authentication
  - Canonicalization
  - Cryptography and encryption
  - Encoding
  - Error Handling
  - Input Validation
  - Logging
  - Mechanism
  - Quotas
  - Session Management
  - Validation
3. Documented testing and results for Principles and Countermeasures listed above
A security evaluation should be performed prior to resource investment (i.e. buying a product, expending integration effort, or writing code) in new software or software services.
The recommendations generated from the security evaluation must be completed prior to use of the Application System in production, prior to use by users and prior to interaction with UTHSC data or information with a level 2 categorization unless otherwise stated in the security evaluation report.