Skip to main content
uta
uta

Minimum Security for Application Development and Management

Contents

  I. Purpose
  II. Scope
  III. Audience
  IV. Requirements
  V. Roles and Responsibilites
  VI. Non-Compliance and Exceptions
  VII. Related Policies, Procedrues, Best Practices and Applicable Laws
  VIII. Updates and Modifications to this Guideline
  IX. Revisions

I. Purpose

Web or mobile applications (“applications”) that are developed or purchased are Information Resources that support The University of Texas at Arlington’s (UTA) mission. As with all software, certain imperfections in design, coding, implementation or architecture can lend these applications vulnerable to attacks that may originate from both UTA and non-UTA networks. Successful attacks may lead to the unauthorized exposure, modification or deletion of information.

The purpose of this document is to provide application owners and developers baseline requirements and guidelines for developing or administering applications on behalf UTA.

II. Scope

These standards and guidelines apply to all University applications that are implemented by or on behalf of UTA for administrative, instructional, research or other purposes that support UTA's mission. All employees, including student employees, contractors and/or volunteers developing applications on or behalf the institution are expected to adhere to these standards.

III. Audience

All faculty, staff, student employees, contractors, and vendors developing or administering applications designed to handle or manage Confidential or Controlled UTA data.

IV. Requirements

The following are minimum administrative and technical requirements for all applications, whether developed by UTA or acquired. Exceptions to these requirements may be granted by the Information Security Office where compensating controls are in place. Owners are encouraged to exceed the requirements based on prevailing best practices and identified threats that might exploit residual risks to obtain unauthorized access.

#

 Requirement

Confidential/
Mission Critical

Controlled

Public

4.1

All applications must be registered with the Information Security Office and must be classified following UTA’s established data classification standard.

Required

Required

Required

4.2

Applications must not store or display Confidential data that has been specifically restricted by law or policy (for example, Social Security Numbers, Protected Health Information, or Credit Card data) unless approval has been received from the Dean or Vice President, Chief Information Officer and Chief Information Security Officer.

Required

N/A

N/A

4.3

All confidential information must be encrypted in transmission. If approved for storage, Social Security Numbers, Credit Card and certain Protected Health Information, must be encrypted at rest (i.e. in a database or on the file system) and encrypted in transmission.

Required

Recommended

Recommended

4.4

Each application owner must establish access control procedures that includes timely user provisioning/onboarding and termination/off-boarding based on the users need-to-know. Information must be restricted following least privilege principles. 

Required

Required

Recommended

4.5

Web applications shall conform to established UTA standards for hosted location, server certificate validity, appropriate URL naming and branding, the combination of which provides users with visual and technical cues to indicate website legitimacy.

Required

Required

Recommended

4.6

An approved warning banner must be displayed on the logon screen or interface in use by the application.

Required

Required

Recommended

4.7

Where possible, applications processing non-public university data must properly authenticate users using NetID credentials through centrally managed authentication systems, specifically UTA Active Directory, LDAP or Shibboleth.

Required

Required

Recommended

4.8

Where it is not possible to use central authentication systems (described above), the Information Security Office must approve alternative methods that provide assurance that: (1) the identity of the user is positively identified in an accepted system of record (e.g. Student Information System or Human Capital Management or other authoritative system); (2) passwords conform to institutional standards for minimum length, complexity, expiry, lock-outs, etc; (3) passwords are stored as one-way salted hash (e.g. SHA 256) (4) the salt value must be kept secure; (5) users must be instructed to not assign the same password for the application as they have for NetID.

Required

Required

Recommended

4.9

Passwords submitted by users on logon screens must not be stored in any form (e.g. in memory, cookies, databases, etc.) outside the authoritative authentication system (e.g. UTA Active Directory, Shibboleth or LDAP). Specifically, capturing NetID passwords by the application is specifically prohibited.

Required

Required

Required

4.10

Implement two factor authentication on internet facing web applications containing confidential information following established standards for protecting against stolen authentication credentials.

Required

Recommended

Recommended

4.11

Implement CAPTCHA following established standards for protecting against automated brute force attacks that result in password theft, account lock-outs, unauthorized access or data corruption. (For example, prompt for CAPTCHA if there is risk that a malicious automated process may cause an account lock-out after multiple attempts within a set period).

Recommended

Recommended

Recommended

4.12

Ensure applications validate input properly and restrictively, allowing only those types of input that are known to be correct. Examples include, but are not limited to, such possibilities as cross-site scripting, buffer overflow errors, and injection flaws. See http://www.owasp.org/ for more information and examples.

Required

Required

Required

4.13

Ensure applications execute proper error handling so that errors will not provide detailed system information, deny service, impair security mechanisms, or crash the system. See http://www.owasp.org/ for more information and examples. Disable debugging messages on production systems, instead enable it on restricted pre-production or test systems.

Required

Required

Required

4.14

Establish authorizations for applications by affiliation, membership, or employment, rather than by individual, where the principles of least-privilege and need-to-know are not violated.

Recommended

Recommended

Recommended

4.15

If individual authorizations are used (e.g. for affiliates, guests), these should expire and require renewal on a periodic (at least annually) basis.

Required

Required

Recommended

4.16

Provide automated review of authorizations where possible. Use central authorization tools where possible, and if additional functionality is needed, coordinate development with OIT.

Required

Recommended

Recommended

4.17

Ensure applications make use of secure storage for university data in accordance with the provisions of the Minimum Security Standards for Systems.

Required

Required

Recommended

4.18

Services or applications running on systems manipulating Confidential data should implement secure (that is, encrypted) communications as required by confidentiality and integrity needs.

Required

Recommended

Recommended

4.19

Implement the use of application access (web server and user access) logs. To the extent practical, copy of logs must be sent to centralized logging (e.g. OIT managed Splunk). When logging access to university data, store logs of all users and times of access for at least 30 days.

Required

Required

Recommended

4.20

Conduct code-level security reviews with professionally trained individuals for all new or significantly modified applications; particularly, those that affect the collection, use, and/or display of Confidential data, documenting the actions that were taken.

Required

Recommended

Recommended

4.21

Complete an initial vulnerability and security assessment of Internet facing mobile and web applications. Complete on-going vulnerability scans where significant changes are made to an application that might change its security posture.

Required

Recommended

Recommended

4.22

Implement and maintain a change management procedure for changes to applications to ensure that the security of the application has not inadvertently been reduced; incorporate testing, release management and production control. Complete vulnerability assessments, especially where significant code changes are made that might affect the security of the application. Ensure that lower instances such as pre-prod, UAT, Test, Development are utilized in preparation for change management and each of those systems is sufficiently restricted and protected.

Required

Recommended

Recommended

4.23

Ensure that obsolete applications, or portions of applications, including underlying infrastructure and databases are removed from service; sufficiently restrict access to the entire application during the decommissioning process.

Required

Required

Required

4.24

Third parties, for example, vendors, providing software and/or receiving university data must enter into written agreements with the university to secure systems and data according to standards established by UTA, including the requirements in this standard.

Required

Required

Required

4.25

Owners must ensure that web applications are hosted on servers that are approved by the Office of Information Technology and the Information Security Office.

Required

Required

Recommended

4.26

Maintain an up-to-date architectural diagram of the application to include all tiers (mobile, web, application tier, database tier) in relation to network security (firewalls, intrusion prevention and detection systems, etc.)

Required

Recommended

Recommended

4.27

Maintain an up-to-date data flow diagram of the application in relation to data collection, storage, manipulation, extract-transform-load (ETL), archiving, etc.

Required

Recommended

Recommended

4.28

Maintain an up-to-date disaster recovery and business continuity plan that follows a business impact assessment. Establish acceptable mean-time-to-recovery (MTTR), recovery time objectives (RTO) and recovery point objectives (RPO). Establish high availability configurations for mission critical systems and supporting infrastructure.

Required

Recommended

Recommended

4.29

Ensure that web applications are adequately protected by technical controls such as centrally managed and monitored stateful and web firewalls, intrusion prevention, intrusion detection, etc.

Required

Recommended

Recommended


V. Roles and Responsibilities

A. Application Owner
Each web application must have an Owner (e.g. vice president, dean, department head, researcher, faculty, etc.) who is responsible justifying its development or procurement, and its continued existence.  It is the responsibility of all Owners to secure the data under their management or control following best practices information security as well as conform to all policies and standards established by UTA and UT System, and to follow relevant regulations established by the State of Texas and the Federal government. If an Owner leaves the institution or is no longer responsible for the web application, the department head, Dean or VP assumes Ownership. The Owner responsibilities are outlined below:

1. Registering and classifying the application with the Information Security Office.

2. Ensuring that the storage of all confidential information, such as SSN, is justified.

3. Ensuring that the application at all tiers (e.g. web, application, database, operating system) is secured, based on risk and classification, following industry best practices or those established by the Information Security Office.

4. Ensuring adequate documentation exists in support of the administrative, technical and physical controls for an application that collects or processes Confidential Information. Consistent with Texas House Bill 8 documentation must include the following:

i. An up-to-date architectural diagram of the application to include all tiers (web, application tier, database tier) in relation to network security (firewalls, intrusion prevention and detection systems, etc.) ;

ii. Details on an authentication mechanism such as Shibboleth or ADFS that is supported by UTA’s Identity and Access Management System;

iii. How access control is administratively and technically implemented to limit data access to authorized users;

iv. The technical and administrative protocols and procedures governing application and system administrator access;

v. The schedule of network and application vulnerability scans and penetration tests; and 

vi. Results of vulnerability scans and penetration tests, and disposition of any identified risks.

5. Appointing qualified Custodian(s) (e.g. developers, system and database administrators) to implement required security in accordance with this standard.

6. Ensuring that Custodians have received appropriate training and that they understand the technical requirements needed to create and maintain secure web applications.

7. Approving any direct access to the data (including that of the database administrator) and ensuring that the data is interpreted and used consistently with UTA’s data management policies and standards.

8. Verifying that the database users (including database administrators) will not make any unauthorized copies of the data and not use the data for unauthorized purposes.

9. Ensuring that appropriate separation of duties occurs to prevent fraud or unauthorized changes to mission critical data, financial transactions, research data, or any data whose loss of integrity might negatively impact the operations or reputation of UTA.

10. On a monthly basis, reviewing all web application access and remove individuals who are no longer authorized.

11. All non-production systems are appropriately restricted to permit access to the developers and system administrators only.

12. Cooperate with incident response and management teams in a timely manner, including providing access to systems, logs, etc.

13. All data in non-production or lower systems is appropriately scrubbed for confidential information.

14. Serves in the Custodian role if one is not appointed.

15. At the application end-of-life, complete decommissioning of the application, including removing associated databases and infrastructure.

B. Application Developer

An application developer is a custodian appointed by the Owner to create, update or enhance a UTA owned or controlled web application. Application Developers are responsible for ensuring that:

1. Best practices for securing web applications are understood and implemented.

2. The application conforms to established UTA standards for hosted location, server certificate validity, appropriate URL naming and branding to provide users with visual and technical cues to indicate legitimacy.

3. That certain confidential information, such as SSN, if stored, is encrypted.

4. All coding is done on development servers.

5. All testing is done on test servers.

6. All data in non-production or lower systems is appropriately scrubbed for confidential information.

7. All non-production systems are appropriately restricted to permit access to the developers and system administrators only.

8. Static code review and dynamic vulnerability testing occurs prior to moving code into production.

9. Version control and roll back plans are incorporated into change management for applications containing confidential information.

10. All service accounts (e.g. database accounts) are kept secure at all times and changed at least once a year or when a person with knowledge of the password no longer has a need to know.

11. The web application code is updated as needed to accommodate security updates to the libraries, frameworks, operating system, database server, or any other component that supports the application.

12. Work cooperatively with the Owner, Database Administrator and System Administrator to ensure that the entire information system is protected.

C. Database Administrator

A database administrator is a custodian appointed by the Owner to provide storage for structured data. The database administrator is responsible for ensuring:

1. Each database has an assigned Owner.

2. Each application has a unique database, unique password and is logically separated from other database.

3. Access to the supporting database for a web application is sufficiently restricted to the authorized service account and authorized users with direct access.

4. The supporting database server for a web application is sufficiently protected and hardened against unauthorized access.

5. Direct access to the database server and databases held within are approved by the Owner.

6. On a monthly basis, database user accounts reviews occur and individuals who are no longer authorized are removed.

7. The availability and performance of the database server meets Owner requirements.

8. The database server is patched for security vulnerabilities in a timely manner.

9. That backups are occurring in accordance with the Owners expectations of recovery time objectives and recovery point objectives.

10. On an annual basis, reviews the inventory of databases and ensures each is still in production

11. That databases that have no owner or production use are decommissioned following appropriate records retention policies.

12. Work cooperatively with the Owner, Application Developer and System Administrator to ensure that the entire information system is protected.

D. System Administrator

A system administrator is a custodian appointed by the Owner to provide operating systems and infrastructure supporting web applications and databases. The system administrator is responsible for ensuring:

1. That each server in a system (production and lower instances) supporting an application has an Owner.

2. The supporting operating systems for web applications and database servers are sufficiently hardened and protected to prevent unauthorized access.

3. The availability and performance of the servers meet Owner requirements.

4. Ensures direct access to the servers is approved by the Owner.

5. The supporting operating systems and web servers are patched for security vulnerabilities in a timely manner following Change Management procedures.

6. That backups are occurring in accordance with the Owners expectations of recovery time objectives and recovery point objectives

7. On a monthly basis, reviews any operating system user accounts and removes individuals who are no longer authorized

8. That each system environment is logically separated to ensure that a compromise in a lower tier or environment does not propagate to a production environment

9. That each process (e.g. web server, application server, data base server, etc. is running with the least privilege required on the system for the application to be functional. Avoid running applications with “administrator” or “root” level privileges.

10. On an annual basis, reviews the inventory of servers and ensures each is still in production

11. Servers that have no owner are decommissioned following appropriate records retention policies.

12. Work is done cooperatively with the Owner, Application Developer and Database Administrator to ensure that the entire information system is protected.



VI. Non-Compliance and Exceptions

Employees and contractors are required to comply with applicable UT System and UTA rules and regulations, as well as with applicable federal and state laws and regulations.

1. Non-compliance with this standard may result in revocation of developer or administrator access, notification to supervisors, and reporting to the Office of Internal Audit and/or the Office of Compliance.

2. Minimum standards that cannot be met must have an approved exception from the Information Security Office.

3. A website that is compromised or otherwise deemed unsafe by the CISO or CIO will be blocked from direct internet or campus access. Notification shall be sent to the Owner when this occurs.

4. Any costs incurred by the Information Security Office will be recovered from the Owner if these costs are directly related to investigations into a server compromise or to any additional monitoring or controls related unresolved vulnerabilities. Notification shall be sent to the Owner when this occurs.


VII. Related Policies, Procedures, Best Practices and Applicable Laws

An inventory of related policies and procedures can be found at: https://www.uta.edu/security/policy/index

VIII. Updates and Modifications to this Standard

This standard will be modified as necessary to address changes in technology and related risks, and is intended to complement, and does not supersede, relevant UT System or UT Arlington policies and procedures governing the security of mobile devices. In the absence of specific policies, policy statements found in this document will stand as provisional until such time that it is incorporated into a HOP policy or procedure. Significant changes to this guideline will be announced to Information Security Administrators and/or in the MavWire.

IX. Revisions

Version Date Changes
1.0 9/10/2018 Initial Publication