Overview

These minimum standards serve as a supplement to the Information Resources Use and Security Policy (IRUSP). Adherence to the standards will increase the security of systems and help safeguard university information technology resources. These minimum standards exist in addition to all other university policies and federal and state regulations governing the protection of the university's data. 

These standards apply to all devices, physical or virtual, connected to the university networks through a physical, wireless, or VPN connection where data is classified as Confidential, Controlled, or Published.

Compliance with these requirements does not imply a completely secure system. Instead, these requirements should be integrated into a comprehensive system security plan, based on what data your systems store and process.

Minimum Standards

This section lists the minimum standards to be applied and enabled in Published, Controlled, and Confidential data systems that are connected to the university network. Standards for Confidential are generally required.
 
If products are not available from reputable commercial or reliable open source communities for a specific requirement, then the specific requirement is waived until an appropriate solution is available. In such cases a security exception report must be filed.
 
IT Owners and IT Custodians, lead researchers, and/or systems administrators are expected to use their professional judgment in managing risks to the information and systems they use and/or support. All security controls should be proportional to the confidentiality, integrity, and availability requirements of the data processed by the system.
  1. Determine the risk level by reviewing the data types and selecting the highest applicable risk designation across all. For example, a system storing Published data but utilized to access an application accessing Confidential data is designated as a Confidential system.
  2. Follow the minimum security standards below to protect your systems.

: A recurring task; this should be automated when possible

: Recommended

: Required

 
 
#What to do
Recurring?
Published
Controlled
Confidential
4.1. Backups
4.1.1System administrators establish and follow a procedure to carry out regular system backups.
Example: UTBackup ( Documentation )
4.1.2Backups verified at least monthly, either through automated verification, through customer restores, or through trial restores.
Example: How to Restore Files from UTBackup
4.1.3Systems administrators maintain documented restoration procedures for systems and the data on those systems.
Example: How to Restore Files from UTBackup
Spacer
4.2. Change Management
4.2.1There is a change management process for systems configuration. This process must be documented.
Example: Change Management Documentation
4.2.2

System changes evaluated prior to being applied in a production environment. Patches tested prior to installation in the production environment if a test environment is available.

 
If a test environment is not available, the lack of patch testing is communicated to the service subscriber or data customer, along with possible changes in the environment due to the patch.
4.2.3Review and update ISORA Inventory records quarterly.
Spacer
4.3. Computer Virus Protection
4.3.1Enterprise-grade Anti-virus software installed and enabled.
Example: Cisco AMP
 
4.3.2Install and enable anti-spyware software. If the machine is used by administrators to browse Web sites not specifically related to the administration of the machine, which is not recommended, install and enable anti-spyware software.
Example: Cisco AMP
 
4.3.3Anti-virus and, if applicable, anti-spyware software configured to update signatures daily. 
4.3.4Systems administrators maintain and keep available a description of the standard configuration of anti-virus software.
Spacer
4.4. Physical Access
4.4.1Systems acting as servers physically located in one of the two authorized University Data Centers, or, with an approved exception request , a physically secured area with restricted access. All other systems, including portable devices, physically secured if left unattended. 
4.4.2Backup media secured from unauthorized physical access. If the backup media is stored off-site, it must encrypted or have a documented process to prevent unauthorized access. 
4.4.3Unattended computing devices are secured from unauthorized access using a combination of physical and logical security controls commensurate with associated risks. Physical security controls include barriers such as locked doors or security cables. Logical security controls include screen saver passwords and automatic session time-outs that are set to activate after 15-minutes of inactivity. 
Spacer
4.5. System Hardening
4.5.1

Systems are set up in a protected network environment or by using a method that assures the system is not accessible via a potentially hostile network until it is secured.
Example:

  • Keep the host offline until you have your firewall configured to block inbound traffic by default, and restrict remote access services (VNC, RDP, etc.) to authorized campus-only networks and the campus VPN, or
  • Connect the host to a network protected by a SOHO firewall or router configured to block inbound traffic by default, and restrict remote access services (VNC, RDP, etc.) to authorized campus-only networks and the campus VPN.
 
4.5.2Operating system and application services security patches are installed expediently (e.g., 30-days) and in a manner consistent with change management procedures. Products that no longer receive security updates from the vendor (e.g., unsupported) are not authorized. All new servers should be designed with the appropriate level of resiliency to accommodate rapid patching. All existing servers much have documented procedures in place to ensure that out of band patching can be completed in 1-3 days exigent situations that are declared by the ISO.
4.5.3Enable automatic notification of new patches if possible. 
4.5.4Services, applications, and user accounts that are not being utilized are disabled or uninstalled. 
4.5.5Limit connections to services to only the authorized users of the service.
Examples: A configured host-based firewall is set for all systems handling Confidential data.
Software firewalls, hardware firewalls, and service configuration for all other systems.
 
4.5.6Services or applications running on systems manipulating Systems with confidential data implement encrypted communications as required by confidentiality and integrity needs. (See Data Encryption Guidelines .) 
4.5.7

Systems provide secure storage for Confidential data. Security can be provided by means such as, but not limited to, encryption (see Data Encryption Guidelines ), access controls, file system audits, physically securing the storage media, or any combination thereof as deemed appropriate.
Examples:

 
4.5.8

If the operating system supports it, integrity checking of critical operating system files is enabled and tested. Third-party tools may also be used to implement this control.
Examples:

4.5.9Integrity checking of system accounts, group memberships, and their associated privileges enabled and tested.
4.5.10

The required university warning banner is installed.
Examples:

 
4.5.11Whenever possible, all non-removable or (re-) writable media is configured with file systems that support access control. 
4.5.12Access to non-public file system areas requires authentication. 
4.5.13Enforce password complexity requirements per the IRUSP . 
4.5.14

Apply the principle of least privilege to user, admin, and system accounts.

A user's primary account should not have administrative privileges. Accounts with administrative privileges should not be used for non-administrative purposes. Accounts using UT EID authentication should not be granted administrative privileges unless the system is capable of requiring multi-factor authentication each time administrative access is invoked.

Examples:
Windows:

Unix:

 
4.5.15Follow Minimum Security Standards for Data Stewardship for storage of data.
Spacer
4.6. Security Monitoring
4.6.1If the operating system comes with a means to log activity, these controls are enabled and tested.
4.6.2Operating system and service log monitoring and analysis is performed routinely. This process is documented.
4.6.3The systems administrator follows a documented backup strategy for security logs (for example, account management, access control, data integrity, etc.). Security logs are retained at least 14 days of relevant log information (data retention requirements for specific data should be considered).
Note: This is required for all servers, regardless of data classification.
Example: Forward logs to Splunk . If your department is not using Splunk, fill out our Splunk Onboarding Form .
4.6.4All administrator or root access is logged.
Spacer
4.7. Vulnerability Management
4.7.1

Configure vulnerability scanning using Nessus Agents, and make sure that neither host-based nor network firewalls block access to the ISO’s vulnerability scanners:

  • Install and link a Nessus Agent on your Linux, Windows, or macOS system; see https://security.utexas.edu/nessus-agents.
  • Ensure that network- and host-based firewalls allow incoming traffic from 146.6.161.0/25.

For rare situations in which installing a Nessus Agent is not possible, configure the system for credentialed network scanning:

  • Add the ISO65 SSH key as an administrative user on your Linux or macOS system.
  • Add the ISO65 Active Directory user to the Administrators group on your Windows system.
  • Ensure that network- and host-based firewalls allow incoming traffic from 146.6.161.0/25.

NOTE: Agents are not required for appliances or non-standard embedded devices that don't natively support them.  These situations would not require an exception to be documented.

 

4.7.2

Share patch logs with the ISO via Splunk that include:

  1. When the patch was available for download
  2. When it was applied
  3. When the host was rebooted if the patch required a reboot
  4. (Optional but preferred) What CVE the patch is addressing

Examples:

If your department is not using Splunk, fill out our Splunk Onboarding Form .

4.7.3Regularly review vulnerability scan findings for your systems in Splunk. Remediate vulnerabilities with published exploits or malware kits within 14 days of discovery, and remediate other significant vulnerabilities within 30 days. If a vulnerability cannot be remediated, file a Security Exception Request.
Spacer
4.8. Regulated Data Security Controls
4.8.1Implement  PCI DSS HIPAA , or  export  controls as applicable.   
Spacer
4.9. Mission-critical Systems
4.9.1Implement additional controls for all mission-critical systems.   
Spacer
4.10. Software Applications
4.10.1Software applications designed to handle or manage university data that are being developed or administered by faculty, staff, student employees, contractors, and vendors must implement additional controls .   

New Security Software/Appliance Review

Departments evaluating the implementation of new security software or appliances, involving Confidential data, should request a security review by sending a written description of the proposed implementation to the Information Security Office prior to selecting vendors or products. Security reviews tend to be informal and can often be performed quickly, while ensuring that best practices are being considered.

Non-Compliance and Exceptions

For all system administrators—if any of the minimum standards contained within this document cannot be met on systems manipulating Controlled or Confidential data that you support, you must submit a Security Exception Report that includes reporting the non-compliance to the Information Security Office, along with a plan for risk assessment and management. Non-compliance with these standards may result in revocation of system or network access, notification of supervisors, and reporting to the Office of Internal Audit.

University of Texas at Austin employees are required to comply with both institutional rules and regulations and applicable UT System rules and regulations. In addition to university and System rules and regulations, University of Texas at Austin employees are required to comply with state laws and regulations.

Related Policies and Regulations

The policies and practices listed here inform the system hardening procedures described in this document and with which you should be familiar.

This is not an all-inclusive list of policies and procedures that affect information technology resources.

Revision History

VersionDateNewOriginal
 9/29/2021Updated 4.5.14 to clarify that UT EID-authenticated accounts should generally not have administrative privileges."Administrative accounts are not to be used as a primary user account or for non-administrative purposes."
 11/17/2021In response to an internal audit, 4.5.2 was modified to speak specifically to the need for systems to be designed to accommodate rapid patching in exigent situations. 
 7/14/2021Expanded requirement of Nessus Agents given recurring exigent circumstances and associated threats.Previously required for Confidential systems and recommended for other systems.
 1/1/2021Clarified control language to clearly reference the recommended or required nature of the control as referenced in the right hand controls legend. 
 4/23/2020Updated vulnerability scanning position to focus more specifically on the use of Nessus Agents over credentialed scanning. 
 5/29/2018Updated visual style; credit to Stanford's Minimum Security Standards. Added sections 4.7, 4.8, 4.9, and 4.10. 
 8/24/2015Aligned with new data classification terms 
 6/24/2013Reviewed and fixed broken links. 
 6/19/2013Converted back to HTML. 
Minimum Security Standards for Systems3/1/2011Converted web page to PDF. Updated numbering in tables to Level 3 numbers (4.4.1, 4.4.2, etc).
Tables were originally numbered 4.1, 4.2, etc.
 10/14/2009Added a reference to the Minimum Security Standards for Systems Worksheet. 
 10/1/2009Updated visual appearance to new template. Corrected any out of date links to ensure they are pointing to the most current policy documents. 
 3/19/2009Updated section 3.2 to improve the clarity of the standard.
"Anti-spyware software must be installed and enabled if the machine is used by administrators to browse Web sites not specifical}}ly related to the administration of the machine. In addition, anti-spyware software must be installed if users are able to install software. "
 9/14/2007Changed reference from BPM 53 to UTS 165
"BPM 53"
 4/5/2007Added "(See Data Encryption Guidelines.)" to System Hardening standards 5.6 and 5.7.
No reference previously.
 3/6/2007
Changed Section I, first sentence to read "These minimum standards serve as a supplement to the IT Security Operations Manual, which was drafted in response to Texas Administrative Code 202 and UT System BPM 53."
 
Added "This minimum standard exists in addition to all other university policies and federal and state regulations governing the protection of the university's data." to the end of the same paragraph.
 
Also revised all references to "standard" to read "standards."
"This minimum standard serves as a supplement to the IT Security Operations Manual, The University of Texas at Austin's implementation of UT-System BPM 53."
 12/02/2006
Added practice 5.14:
 
"Apply the principle of least privilege to user, administrator, and system accounts."
 
Cat I: Required; Cat II/III: Recommended
New
 11/02/2006Edited Practice 5.7 to say "Systems will provide secure storage for Category-I data as required by confidentiality, integrity, and availability needs. Security can be provided by means such as, but not limited to, encryption, access controls, file system audits, physically securing the storage media, or any combination thereof as deemed appropriate."
Systems will provide secure (that is, encrypted) storage for Category I data as required by confidentiality and integrity needs.
 10/20/2006Edited Practice 5.6 to say "Services or applications running on systems manipulating Category I data should implement secure (that is, encrypted) communications as required by confidentiality and integrity needs."
"Services or applications running on systems manipulating Category I data should implement secure (that is, encrypted) communications to ensure Category I data does not traverse the Internet in clear text."
 10/20/2006Added Practice 5.13, "Strong password requirements shall be enabled, as technology permits, based on the category of data the account is allowed to access." Required for all data categories.
New
 7/11/2006
Changed title to "Minimum Security Standards for Systems" in this and all documents referencing the title. The phrase "Associated with Category I,II, or III Data" relates to all IT Security policies, and the change will make it easier to incorporate "Minimum Security Standards" documents for other IT resource types.
 
Added links to appropriate definitions in the ISO Technical and Security Glossary.
 
Added Change Log for transparency.
"Minimum Security Standards for Systems Associated with Category I, II, or III Data."
 7/11/2006
Added the Exception Reporting Process to this sentence...
 
"If products are not available from reputable commercial or reliable open source communities for a specific requirement, then the specific requirement is waived until an appropriate solution is available. In such cases a security exception report shall be filed.
"If products are not available from reputable commercial or reliable open source communities for a specific requirement, then the specific requirement is waived until an appropriate solution is available."
 7/11/2006Changed "Primary Investigators" to "Lead Researchers," per BPM-75 language.
"IT owners and custodians, Primary Invesigators (PIs), and/or systems administrators are expected to use their professional judgment in managing risks to the information and systems they use and/or support."

Approvals

NameRoleMembersDate
Chief Information Security Officer  ApprovalCam BeasleySeptember 24, 2015