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
- 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.
- 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.1 | System administrators establish and follow a procedure to carry out regular system backups. Example: UTBackup ( Documentation ) | ||||
| 4.1.2 | Backups verified at least monthly, either through automated verification, through customer restores, or through trial restores. Example: How to Restore Files from UTBackup | ||||
| 4.1.3 | Systems 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.1 | There 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.3 | Review and update ISORA Inventory records quarterly. | ||||
| Spacer | |||||
| 4.3. Computer Virus Protection | |||||
| 4.3.1 | Enterprise-grade Anti-virus software installed and enabled. Example: Cisco AMP | ||||
| 4.3.2 | Install 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.3 | Anti-virus and, if applicable, anti-spyware software configured to update signatures daily. | ||||
| 4.3.4 | Systems administrators maintain and keep available a description of the standard configuration of anti-virus software. | ||||
| Spacer | |||||
| 4.4. Physical Access | |||||
| 4.4.1 | Systems 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.2 | Backup 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.3 | Unattended 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.
| ||||
| 4.5.2 | Operating 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 for exigent situations that are declared by the ISO. | ||||
| 4.5.3 | Enable automatic notification of new patches if possible. | ||||
| 4.5.4 | Services, applications, and user accounts that are not being utilized are disabled or uninstalled. | ||||
| 4.5.5 | Limit 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.6 | Services 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.
| ||||
| 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.
| ||||
| 4.5.9 | Integrity checking of system accounts, group memberships, and their associated privileges enabled and tested. | ||||
| 4.5.10 | The required university warning banner is installed.
| ||||
| 4.5.11 | Whenever possible, all non-removable or (re-) writable media is configured with file systems that support access control. | ||||
| 4.5.12 | Access to non-public file system areas requires authentication. | ||||
| 4.5.13 | Enforce 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: Unix: | ||||
| 4.5.15 | Follow Minimum Security Standards for Data Stewardship for storage of data. | ||||
| Spacer | |||||
| 4.6. Security Monitoring | |||||
| 4.6.1 | If the operating system comes with a means to log activity, these controls are enabled and tested. | ||||
| 4.6.2 | Operating system and service log monitoring and analysis is performed routinely. This process is documented. | ||||
| 4.6.3 | The 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.4 | All 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:
For rare situations in which installing a Nessus Agent is not possible, configure the system for credentialed network scanning:
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:
Examples:
If your department is not using Splunk, fill out our Splunk Onboarding Form . | ||||
| 4.7.3 | Regularly 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.1 | Implement PCI DSS , HIPAA , or export controls as applicable. | ||||
| Spacer | |||||
| 4.9. Mission-critical Systems | |||||
| 4.9.1 | Implement additional controls for all mission-critical systems. | ||||
| Spacer | |||||
| 4.10. Software Applications | |||||
| 4.10.1 | Software 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
- Information Resources Use and Security Policy
- UT Austin Acceptable Use Policy
- UT Austin Data Classification Standard
- UT Austin Information Security Exception Process
This is not an all-inclusive list of policies and procedures that affect information technology resources.
Revision History
| Version | Date | New | Original |
|---|---|---|---|
| 9/29/2021 | Updated 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/2021 | In 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/2021 | Expanded requirement of Nessus Agents given recurring exigent circumstances and associated threats. | Previously required for Confidential systems and recommended for other systems. | |
| 1/1/2021 | Clarified control language to clearly reference the recommended or required nature of the control as referenced in the right hand controls legend. | ||
| 4/23/2020 | Updated vulnerability scanning position to focus more specifically on the use of Nessus Agents over credentialed scanning. | ||
| 5/29/2018 | Updated visual style; credit to Stanford's Minimum Security Standards. Added sections 4.7, 4.8, 4.9, and 4.10. | ||
| 8/24/2015 | Aligned with new data classification terms | ||
| 6/24/2013 | Reviewed and fixed broken links. | ||
| 6/19/2013 | Converted back to HTML. | ||
| Minimum Security Standards for Systems | 3/1/2011 | Converted 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/2009 | Added a reference to the Minimum Security Standards for Systems Worksheet. | ||
| 10/1/2009 | Updated visual appearance to new template. Corrected any out of date links to ensure they are pointing to the most current policy documents. | ||
| 3/19/2009 | Updated 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/2007 | Changed reference from BPM 53 to UTS 165 | "BPM 53" | |
| 4/5/2007 | Added "(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/2006 | Edited 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/2006 | Edited 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/2006 | Added 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/2006 | Changed "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
| Name | Role | Members | Date |
| Chief Information Security Officer | Approval | Cam Beasley | September 24, 2015 |