SC-003.02 – Application System Security Features

Responsible Office: Office of Cybersecurity

Last Review: 04/15/2020

Next Review: 04/15/2022

Contact: Chris Madeksho

Phone: 901.448.1579



To require that Application Systems installed in UTHSC meet specified security features to prevent unauthorized use, access, transmission, modification, or destruction of UTHSC data or information.


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


  1. All Application Systems shall be included in an Application System Inventory and at a minimum indicate the following information:
    1. Name of the Application System
    2. Purpose of the Application System
    3. Data or Information Owner
    4. Application System Custodian
    5. Vendor/contractor (if applicable)
    6. Classification of the information that it creates, captures, stores or processes
    7. Type of Information:
      • Protected Health Information (PHI)
      • Personal Identifiable Information (PII)
      • Student Records
      • Credit Card Numbers
      • Other
    8. Recoverability objectives (after 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:
    9. Recovery time objective:
      • 0-24 hours
      • 0-72 hours
      • 0-120 hours
      • As resources are available
    10. If server based, unique machine name or DNS name of the server and location.
    11. If client based, estimate of the number of clients and buildings where the client software is installed.
    12. 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.
  2. 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.
    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 Standard-InfoSec-SC-004-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.
  3. 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
  4. 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.
  5. 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 classification rating of 3 in any area unless otherwise stated in the security evaluation report.


  1. SC-003-Application System Security
  2. AU-002-Logging and System Activity Review
  3. GP-002-Data & System Classification
  4. Open Web Application Security Project

SC-003.02 – Application System Security Features
Version: 5 // Effective: 03/20/2016
PDF icon Downloadable PDF

Related Procedures: