Loading...

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.1 System administrators should establish and follow a procedure to carry out regular system backups.
Example: UTBackup (Documentation)
Task for Confidential Data
4.1.2 Backups must be verified at least monthly, either through automated verification, through customer restores, or through trial restores.
Example: How to Restore Files from UTBackup
Task for Confidential Data
4.1.3 Systems administrators must maintain documented restoration procedures for systems and the data on those systems.
Example: How to Restore Files from UTBackup
Task for Confidential Data
Spacer
4.2. Change Management
4.2.1 There must be a change management process for systems configuration. This process must be documented.
Example: Change Management Documentation
Task for Confidential Data
4.2.2 System changes should be evaluated prior to being applied in a production environment. Patches must be 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 should be communicated to the service subscriber or data customer, along with possible changes in the environment due to the patch.
Task for Confidential Data
4.2.3 Review and update IoTron records quarterly. Task for Public Data for Controlled Data for Confidential Data
Spacer
4.3. Computer Virus Protection
4.3.1 Anti-virus software must be installed and enabled.
Example: Cisco AMP
  for Public Data for Controlled Data for Confidential Data
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, installing and enabling anti-spyware software is required.
Example: Cisco AMP
 
4.3.3 Anti-virus and, if applicable, anti-spyware software should be configured to update signatures daily.   for Public Data for Controlled Data for Confidential Data
4.3.4 Systems administrators should maintain and keep available a description of the standard configuration of anti-virus software. Task for Confidential Data
Spacer
4.4. Physical Access
4.4.1 Systems acting as servers must be 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, must be physically secured if left unattended.   for Confidential Data
4.4.2 Backup media must be secured from unauthorized physical access. If the backup media is stored off-site, it must be encrypted or have a documented process to prevent unauthorized access.   for Confidential Data
Spacer
4.5. System Hardening
4.5.1 Systems must be 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.
  for Confidential Data
4.5.2 Operating system and application services security patches should be 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. Task for Public Data for Controlled Data for Confidential Data
4.5.3 Enable automatic notification of new patches if possible.   for Public Data for Controlled Data for Confidential Data
4.5.4 Services, applications, and user accounts that are not being utilized should be disabled or uninstalled.   for Confidential Data
4.5.5 Limit connections to services to only the authorized users of the service.
Examples: A configured host-based firewall is required for all systems handling Confidential data.
Software firewalls, hardware firewalls, and service configuration for all other systems.
  for Confidential Data
4.5.6 Services or applications running on systems manipulating Confidential data should implement encrypted communications as required by confidentiality and integrity needs. (See Data Encryption Guidelines.)   for Confidential Data
4.5.7 Systems will 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:
  for Confidential Data
4.5.8 If the operating system supports it, integrity checking of critical operating system files should be enabled and tested. Third-party tools may also be used to implement this.
Examples:
Task for Confidential Data
4.5.9 Integrity checking of system accounts, group memberships, and their associated privileges should be enabled and tested. Task for Confidential Data
4.5.10 The required university warning banner should be installed.
Examples:
  for Confidential Data
4.5.11 Whenever possible, all non-removable or (re-) writable media must be configured with file systems that support access control.   for Confidential Data
4.5.12 Access to non-public file system areas must require authentication.   for Public Data for Controlled Data for Confidential Data
4.5.13 Enforce password complexity requirements per the IRUSP.   for Public Data for Controlled Data for Confidential Data
4.5.14 Apply the principle of least privilege to user, admin, and system accounts. Administrative accounts must not be used as a primary user account or for non-administrative purposes.
Examples:
Windows: Unix:
  for Confidential Data
4.5.15 Follow Minimum Security Standards for Data Stewardship for storage of data. Task for Public Data for Controlled Data for Confidential Data
Spacer
4.6. Security Monitoring
4.6.1 If the operating system comes with a means to log activity, enabling and testing of those controls is required. Task for Confidential Data
4.6.2 Operating system and service log monitoring and analysis should be performed routinely. This process should be documented. Task for Confidential Data
4.6.3 The systems administrator must follow a documented backup strategy for security logs (for example, account management, access control, data integrity, etc.). Security logs should retain 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.
Task for Confidential Data
4.6.4 All administrator or root access must be logged. Task for Confidential Data
Spacer
4.7. Vulnerability Management
4.7.1 Add credentials for ISO scanning on the system:   for Confidential Data
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.
Task for Confidential Data
4.7.3 Fill out the ISOProbe Intake Form. Task for Confidential Data
4.7.4 Review your monthly SelfScan Report. Remediate vulnerabilities with published exploits () or malware kits () within 14 days of discovery and other vulnerabilities within 90 days. Task for Confidential Data
Spacer
4.8. Regulated Data Security Controls
4.8.1 Implement PCI DSSHIPAA, or export controls as applicable.       for Confidential Data
Spacer
4.9. Mission-critical Systems
4.9.1 Implement additional controls for all mission-critical systems.       for Confidential Data
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.       for Confidential Data

Security Review for New Security Software and Appliances

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, an Exception Process must be initiated that includes reporting the non-compliance to the Information Security Office, along with a plan for risk assessment and management. (See Security Exception Report.) 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

Version Date New Original
  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