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 ISORA Inventory 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

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.
  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 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. Task for Confidential Data
Spacer
4.8. Regulated Data Security Controls
4.8.1 Implement  PCI DSS HIPAA , 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

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

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

Overview

1. Purpose

These minimum standards serve as a supplement to the Information Resources Use and Security Policy, which was drafted in response to Texas Administrative Code 202 and UT System UTS-165. It specifically applies to Mission Critical Information Resources as defined in the UT Austin Information Resources Use and Security Policy, which states:

Mission Critical Information Resources - Information Resources defined to be essential to U.T. Austin’s ability to meet its instructional, research, patient care, or public service missions. The loss of these resources or inability to restore them in a timely fashion would result in the failure of U. T. Austin’s operations, inability to comply with regulations or legal obligations, negative legal or financial impact, or endanger the health and safety of faculty, students, staff, and patients. Mission Critical Information Resources include but are not limited to:

  • Information Systems managing Confidential Data;
  • Common Use Infrastructures;
  • Core Network and Data Center Infrastructure;
  • Identity and Access Management Systems, such as single-sign-on or other applications required to enable access to other critical systems;
  • Administrative systems (e.g., HR, Finance, Payroll, Credit Card Data Environments (CDE), student/patient enrollment and billing, etc.);
  • Student information systems;
  • Patient care and life-support systems, etc.

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.

Compliance with these requirements does not imply a completely secure system. Instead, these requirements should be integrated into a comprehensive security plan for the system or service.

2. Scope

These standards apply to all components associated with Mission Critical Information Resources; servers, applications, middle-ware, databases, network management, workstations, gateways, etc.

3. Audience

All university staff associated with managing or supporting Mission Critical Information Resources. Ensuring security controls are appropriately applied is the responsibility of the several involved parties, namely:

4. Minimum Standards

This section lists the minimum standards to be applied and enabled for Mission Critical Information Resources.
 
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 and approved.
 
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.
Follow the minimum security standards below to protect your systems.
: A recurring task; this should be automated when possible


 
# Standard
Recurring?
4.1. Backups
4.1.1 System administrators (or service owners) must establish and follow a procedure to carry out regular system backups.  
4.1.2 Backups must be verified at least monthly, either through automated verification, through customer restores, or through trial restores.
4.1.3 Systems administrators must maintain documented restoration procedures for systems and the data on those systems.
 
4.2. Change Management
4.2.1 There must be a change management process for system/service management.
This process must be documented.
Example: ITS Systems Change Management Documentation
4.2.2 There must be a test environment for evaluating system changes and updates, and for conducting potentially destructive security assessments, as technology permits. If technology does not permit, a security exception must be submitted. Patches must be tested prior to installation in the production environment.
4.2.3 The Information Security Office must be engaged when a significant or material system or application change is planned for implementation to determine what sort of, if any, security review is needed. The respective change committee for the system, application, or service will determine when a change is significant or material (e.g., the attack surface for the service changes, established controls are removed or impossible to maintain).
 
4.3. Computer Virus Protection
4.3.1 Malware protection software must be installed and enabled, as technology permits. If technology does not permit, a security exception must be submitted.
NOTE: Cisco AMP is the current campus standard, but other managed clients are suitable as well.
 
4.3.2 Malware protection software must be configured to update signatures at least daily.
 
4.4. Documentation
4.4.1 There must be documentation and/or runbooks for fundamental functions or procedures (e.g., applying system/service updates, firewall maintenance, installation of new software, patch verification and compliance audits, log review and alert configuration).
Given the complexity of systems or services, it may be necessary for documentation to span multiple teams or groups.
 
4.5. Physical Access
4.5.1 Systems must be physically secured in University Data Centers or in physical or virtual facilities approved by the Information Security Office.  
4.5.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.  
 
4.6. System Hardening
4.6.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.
Examples:
  • 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.6.2 Operating system and application services security patches must be applied within 30-days of being made generally available and in a manner consistent with change management procedures. Exceptionally high-risk infrastructure (e.g., domain controllers) should apply security patches within 7-days of being made generally available. Systems running operating systems or services that no longer receive security updates from the vendor (e.g., unsupported) are not authorized and will be isolated on the network until they can be remediated.
4.6.3 If automatic notification of new patches is available, that option must be enabled.  
4.6.4 Services, applications, and service accounts that are no longer being utilized must be assessed every 90-days and disabled or uninstalled.
4.6.5 Methods must be enabled to limit connections to services running on the system to only the authorized users of the service and to the minimum set of networks (e.g., local management networks and VPN groups). In addition to other solutions that may be used (e.g., hardware firewalls, network segmentation, etc.), host-based firewalls must be configured in accordance with this requirement. The campus at large should be considered a hostile network and appropriate protections should be enabled for that address space.  
4.6.6 Services or applications running on systems manipulating Confidential data must implement encrypted communications as required by confidentiality and integrity needs. (See Data Encryption Guidelines.)  
4.6.7 Systems must provide secure storage for Confidential data as required by confidentiality, integrity, and availability needs. 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.6.8 Integrity checking of critical operating system files must be enabled and tested, as technology permits. If technology does not permit, a security exception must be submitted.
Examples:
4.6.9 Integrity checking of system accounts, group memberships, and their associated privileges must be enabled and tested.
4.6.10 The required university warning banner must be installed on all end-user accessible services as the system allows.
Examples:
 
4.6.11 Whenever possible, all non-removable or (rewritable) media must be configured with file systems that support access control.  
4.6.12 Access to non-public file system areas must require authentication.  
4.6.13 Strong password requirements must be enabled that comply with IRUSP Standard 15.  
4.6.14 Accounts of individuals (e.g., end-users or administrators) who have had their status, roles, or affiliations with university change must be automatically updated in real-time to reflect their current status.
4.6.15 All administrator passwords must be rotated on a 90-day basis. All administrator accounts must be associated with a named system administrator and should ideally not be that individual’s standard EID and password, where possible. All administrator accounts must be reviewed at least 90-days to ensure their current state is correct.
4.6.16 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:
 
4.6.17 All administrative access to systems must leverage multi-factor authentication regardless of where the access is initiated (e.g., to prevent pivoting attacks that originate from elsewhere on campus) as technology permits. If necessary, use of the campus VPN service can be leveraged for on-campus services to ensure multi-factor authentication. Cloud-based services may be required to leverage alternative multi-factor authentication options.  
4.6.18 If an ISO hardening checklist exists for the operating system or service, it must be followed. For any sections that cannot be implemented, a security exception request must be submitted. If an ISO hardening checklist is not available, but a benchmark from the Center for Internet Security (CIS) is, the CIS benchmark must be followed to the degree that the controls are possible and reasonable for the infrastructure.  
 
4.7. Security Monitoring
4.7.1 All systems and applications must maintain a means to log access and usage. System administrators (or service owners) must ensure services are configured to log an appropriate level of detail so that appropriate security monitoring is possible; at a minimum and as technology permits, all changes, edits, logins, administrative activities, and accesses of Confidential data must be logged and tied to an account and a timestamp. All administrative access must be logged.
4.7.2 All service and operating system authentication logs must be forwarded to the ISO managed Splunk service. If your department is not using Splunk, fill out our Splunk Onboarding Form.
4.7.3 Any logs not forwarded to a managed Splunk service must be retained for a minimum of 14 days and must be made available to the ISO upon request.
4.7.4 System administrators (or service owners) must routinely perform system and service log monitoring (e.g., to ensure updates are being applied as expected and that no atypical usage is occuring. System administrators (or service owners) are encouraged to develop automated reports and alerts with in the Information Security Office’s logging infrastructure to further streamline this process. This process must be documented. Services that stop sending logs may be quarantined in cases where security is paramount (e.g. authentication, VPN, etc) to ensure against unauthorized access or misuse.
4.7.5 Systems administrators must follow a documented backup strategy for security logs (for example, account management, access control, data integrity, etc.). Local security logs must retain at least 14 days of relevant log information (consider data retention requirements for specific data).
 
4.8. Resilient Infrastructure
4.8.1 All systems and applications must be architected in a resilient manner, such that high availability is in place. Services must be designed to be patched and updated without inordinately impacting the operational state of the service. Services must be designed to tolerate routine network and hardware maintenance without inordinately impacting the operational state of the service.  
4.8.2 Enterprise-wide authentication services must be designed and managed to be resilient in the event a campus-wide power or network outage occurs (e.g., to ensure cloud-based campus services are still operational).
 
4.9. Staffing and Training
4.9.1 All systems and applications must be operated by system administrators (or service owners) that are professionally trained according to IRUSP Standard 18.
4.9.2 Systems and applications must have sufficient resources assigned to maintain, patch, monitor and provide customer support.
4.9.3 All remote configuration, management, administration, etc. of mission critical services and systems must be conducted from University issued and managed computing devices. Any devices issued by the University for this purpose may only be used by the person to whom the device was issued and other authorized University staff (e.g. managed systems support staff). Incidental use of these devices does not extend to family or friends.  

5. New Security Software/Appliance Review

Departments evaluating the implementation of new Mission Critical Information Resources must undergo a security review by sending a written description of the proposed implementation to the Information Security Office prior to implementing in a production capacity.

6. Non-Compliance and Exceptions

For all system administrators—if any of the minimum standards contained within this document cannot be met, 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.

7. 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.

8. Revision History

Version Date New Original
1.1 6/12/2018 Updated visual style; credit to Stanford's Minimum Security Standards. Added examples from Minimum Security Standards for Systems where appropriate for ease of use by readers. Added hyperlinks where appropriate for ease of use.  
1.0 5/20/2018 Initital publication  

9. Approvals

Name Role Members Date
Chief Information Security Officer   Approval Cam Beasley May 20, 2018

Overview

1. Purpose

This minimum standard serves as a supplement to the Information Resources Use and Security Policy, which was drafted in response to Texas Administrative Code 202 and UT System UTS-165. Adherence to the standard will increase the security of applications and help safeguard university information technology resources.
 
Compliance with these requirements does not imply a completely secure application or system. Instead, these requirements should be integrated into a comprehensive system security plan.
 

2. SCOPE

This standard applies to all software applications that are being developed or administered by the audience referenced in Section III and that are running on devices, physical or virtual, where university data are classified as Category I, II, or III (see Data Classification Standard).
 

3. Audience

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

4. Minimum Standard

This section lists the minimum standards that should be applied to the development and administration of applications working with Confidential, Controlled, or -Published. Standards for Confidential are generally required.
 
If a solution is not available for a specific requirement, then the specific requirement can be waived by the ISO until an appropriate solution is made available. In such cases a security exception shall be filed (see part V below). IT owners and custodians, data stewards, lead researchers, system administrators, and application developers are expected to use their professional judgment in managing risks to the information, systems and applications 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.
 
 
: A recurring task; this should be automated when possible
: Recommended
: Required
4.1.
# Practice Confidential Controlled & Published
4.1.1 Classify the university data handled or managed by the application (see Data Classification Standard). for Confidential Data for Confidential Data
4.1.2
Prominently display a Confidential Record banner to the screen or interface in use by the application, depending on the type of data being accessed (for example, FERPA, HIPAA, etc.). Do not 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 permitted by University Compliance Services.
for Confidential Data
4.1.3
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.
for Confidential Data
4.1.4 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. for Confidential Data
4.1.5 Ensure applications processing data properly authenticate users through central authentication systems, specifically: Enterprise Authentication, UTLogin, Austin Active Directory, or UT
Shibboleth.
4.1.6 Establish authorizations for applications by affiliation, membership, or employment, rather than by individual.
4.1.7 If individual authorizations are used, these should expire and require renewal on a periodic (at least annually) basis. for Confidential Data
4.1.8 Provide automated review of authorizations where possible.
4.1.9 Use central authorization tools where possible, and if additional functionality is needed, coordinate development with Information Technology Services (ITS).
4.1.10 Ensure applications make use of secure storage for university data, in accordance with the provisions of the Minimum Security Standards for Systems, consulting with system administrators where needed. for Confidential Data
4.1.11 Services or applications running on systems manipulating Confidential data should implement secure (that is, encrypted) communications as required by confidentiality and integrity needs. for Confidential Data
4.1.12 Implement the use of application logs to the extent practical, given the limitations of certain systems to store large amounts of log data. When logging access to university data, store logs of all users and times of access for at least 90 days. for Confidential Data
4.1.13
Conduct code-level security reviews with professionally trained peers 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.
for Confidential Data
4.1.14 Ensure the Information Security Office has completed application security assessment for Internet-facing applications and sites. Requests can be submitted via the following form. for Confidential Data
4.1.15 Ensure that obsolete or unsupported applications, or related components, are removed or are otherwise updated within 30-days of becoming unsupported. Additionally, as of 2010-July-02, no new WebAgent application development is permitted unless explicitly approved as an exception by the Information Security Office. for Confidential Data for Confidential Data
4.1.16 Implement and maintain a change management process for changes to existing software applications. for Confidential Data
4.1.17 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 the provisions of section 22 of the UT Austin Information Resources Use and Security Policy. for Confidential Data

 

 
4.2.
# Practice Confidential Controlled & Published
4.2.1 Maintain a full inventory of all applications and Vendor-managed services. Applications and/or Vendor managed services must be registered and assessed in the Information Security Office's risk management tool (ISORA). Applications can be added to the department's application inventory in ISORA, which will then trigger an assessment to be completed by the IT support staff. Vendor managed services can be added to the department's vendor inventory in ISORA, which will then allow the department to assign an assessment to the vendor they are working with. These must be maintained annually. for Confidential Data
4.2.2 Document clear rules and processes for vetting and granting authorizations. for Confidential Data
4.2.3 On at least a monthly basis, review and remove all authorizations for individuals who have left the university, transferred to another department, or assumed new job duties within the department. for Confidential Data

5. Non-Compliance and Exceptions

For all application developers and administrators – if any of the minimum standards contained within this document cannot be met for applications manipulating Confidential or Controlled 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 this standard may result in revocation of developer or administrator access, notification of supervisors, and reporting to the Office of Internal Audit and/or the Office of Compliance.
 
Employees of The University of Texas at Austin 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.
 

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

The policies and practices listed here inform the application development and administration practices described in this document. You should be familiar with these documents. (This is not a complete list of policies and procedures that affect IT resources.)
 
 
 
 
 
 
 

7. Revision History

 
Revision History
Version Date New Original
  09/19/2019 Adjusted 4.1.5 to identify new Enterprise Authentication service.  
  08/29/2017 Made slight adjustments to require pentests for applications processing Confidential data per recent requirements from HB8 (85th Legislature).
Originally recommended pentests.
  11/19/2014 4.1.16 was missing. It numbered from 4.1.15 to 4.1.17 and 4.1.18.
Changed 4.1.17 to 4.1.16 and 4.1.18 to 4.1.17.
  06/24/2013 Reviewed and fixed broken links. Changed "Office of Institutional Compliance" to University Compliance Services
University Compliance Services
  06/19/2013 Converted from PDF to HTML  
Minimum Security Standards for Application Development and Administration 10/12/2012 On July 02, 2010, the Business Services Committee (BSC), part of the campus-wide IT governance structure (http://www.utexas.edu/cio/itgovernance) endorsed the Chief Information Security Officer's proposal for the university to place a moratorium on all new WebAgent application development. The BSC reserved the right to approve exceptions to this rule, if needed.  
  2/28/2011 Converted web page to PDF
No changes
  7/22/2010 On July 02, 2010, the Business Services Committee (BSC), part of the campus-wide IT governance structure (http://www.utexas.edu/cio/itgovernance) endorsed the Chief Information Security Officer's proposal for the university to standardize on one enterprise method for inventorying applications -by using the ISO's Application Registry. The Application Registry has been in production for some time and is widely used, but this change will eliminate confusion in the development community. This change will be made effective immediately and will be communicated to the campus IT development community.
Maintain a full inventory of all applications with descriptions of authentication and authorization systems, along with the data classification and level of criticality for each application. Ensure a custodian(s) is assigned to each application.
  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.  
  6/20/2008 Added link to University Login Banner page.
No link.
  9/14/2007
Added this Change Log.
 
Changed reference in section I. Purpose and References sections to UTS-165. Removed reference to BPM 66 (consolidated into UTS 165).
"BPM 53"
 

8. Approvals

 
Approvals
Name Role Members Date
Chief Information Security Officer   Approval Cam Beasley 09/19/2019
 

Overview

1. Purpose

These minimum standards serve as a supplement to the Information Resources Use and Security Policy, specifically for devices that are used to work with HIPAA protected data. 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.

Compliance with these requirements does not imply a completely secure system. Instead, these requirements should be integrated into a comprehensive system security plan.

2. Scope

These standards apply to all devices, physical or virtual, that are used to process, view, modify, store, or otherwise interact with any data that is classified as Protected Health Information (PHI).

3. Audience

All persons with access to any computing device that falls within the scope defined in the previous section of this document.

Minimum Standards

Note that the implementation specifications provided in the Security and Privacy rules may be addressable or required. Some standards do not have any implementation specifications. These standards are just the minimum for HIPAA compliance. In some cases, additional controls may be necessary to comply with university policy. All devices must also meet the Minimum Security Standards for Systems.

Administrative Safeguards

Security Management
Standard: Security Management §164.308 (a)(1)
Implement policies and procedures to prevent, detect, contain, and correct security violations.
Security Management
Implementation Specification
Type
Reference
Risk analysis: Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held. UT note: This assessment is required annually per university policy. The Information Security Office may be able to conduct the assessment, depending upon the size and scope of the covered environment.
Required
§164.308 (a)(1)(ii)(A)
Risk management: Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.
These measures must, at a minimum:
  • protect against any reasonably anticipated threat or hazard to the security or integrity of such information,
  • ensure compliance by employees, and
  • protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under Subpart E of the HIPAA Privacy Rule.
Required
§164.308 (a)(1)(ii)(B)
Sanction policy: Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures.
Required
§164.308 (a)(1)(ii)(C)
Information system activity review: Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. UT note:Splunk might be useful for log aggregation, searching, and custom activity alerts, and is available free of charge to campus.
Required
§164.308 (a)(1)(ii)(D)
 
Assign Security Responsibility
Standard: Assign Security Responsibility §164.308 (a)(2)
Identify the security official who is responsible for the development and implementation of required policies and procedures.
Implementation Specification
Type
Reference
N/A
 
 
 
Workforce Security
Standard: Workforce Security §164.308 (a)(3)
Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under §164.308 (a)(4), and to prevent those workforce members who do not have access under §164.308 (a)(4) of the HIPAA Security Rule from obtaining access to electronic protected health information.
Workforce Security
Implementation Specification
Type
Reference
Authorization and/or supervision: Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
Addressable
§164.308 (a)(3)(ii)(A)
Workforce clearance procedure: Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
Addressable
§164.308 (a)(3)(ii)(B)
Termination procedures: Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in §164.308 (a)(3)(ii)(B).
Addressable
§164.308 (a)(3)(ii)(C)
 
Information Access Management
Standard: Information Access Management §164.308 (a)(4)
Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of Subpart E of the HIPAA Privacy Rule.
Information Access Management
Implementation Specification
Type
Reference
Access authorization: Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
Addressable
§164.308 (a)(4)(ii)(B)
Access establishment and modification: Implement policies and procedures that, based upon access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.
Addressable
§164.308 (a)(4)(ii)(C)
 
Security Awareness and Training
Standard: Security Awareness and Training §164.308 (a)(5)
Implement a security awareness and training program for all members of its workforce (including management).
Security Awareness and Training
Implementation Specification
Type
Reference
Implement a security awareness and training program that, at a minimum, covers:
  • procedures for creating, changing and safeguarding passwords;
  • periodic security updates;
  • procedures for protecting against, detecting, and reporting malicious software; and
  • procedures for monitoring login attempts and reporting discrepancies.
Addressable
§164.308 (a)(5)(ii)(A-D)
 
Security Incident Procedures
Standard: Security Incident Procedures §164.308 (a)(6)
Implement policies and procedures to address security incidents.
Security Incident Procedures
Implementation Specification
Type
Reference
Response and Reporting: Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes. UT note: All incidents must be reported immediately to the Information Security Office (abuse@utexas.edu).
Required
§164.308 (a)(6)(ii)(A)
 
Contingency Plan
Standard: Contingency Plan §164.308 (a)(7)
Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.
Contingency Plan
Implementation Specification
Type
Reference
Data backup plan: Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information. UT note: An cloud-based CrashPlan service is available to staff, faculty, and departments. When combined with a user-managed encryption key, this service can be used with HIPAA data.
Required
§164.308 (a)(7)(ii)(A)
Disaster recovery plan: Establish (and implement as needed) procedures to restore any loss of data.
Required
§164.308 (a)(7)(ii)(B)
Emergency mode operation plan: Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode. UT note: The Information Security Office provides a disaster recovery planning service, UT Ready, and business impact analysis templates for business continuity and disaster recovery documentation/planning.
Required
§164.308 (a)(7)(ii)(C)
Testing and revision procedures: Implement procedures for periodic testing and revision of contingency plans.
Addressable
§164.308 (a)(7)(ii)(D)
Applications and data criticality analysis: Assess the relative criticality of specific applications and data in support of other contingency plan components. UT note: Applications and/or Vendor managed services must be registered and assessed in the Information Security Office's risk management tool (ISORA). Applications can be added to the department's application inventory in ISORA, which will then trigger an assessment to be completed by the IT support staff. Vendor managed services can be added to teh department's vendor inventory in ISORA, which will then allow the department to assign an assessment to the vendor they are working with. These must be maintained annually.
Addressable
§164.308 (a)(7)(ii)(E)
 
Evaluation
 
Standard: Evaluation §164.308 (a)(8)
Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which the security policies and procedures meet the requirements of §164.308 (a).
Evaluation
Implementation Specification
Type
Reference
N/A
 
 
 
Business Associate Contracts and Other Arrangements
 
Standard: Business Associate Contracts and Other Arrangements §164.308 (b)(1)
A covered entity, in accordance with §164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314 (a) that the business associate will appropriately safeguard the information.
Business Associate Contracts and Other Arrangements
Implementation Specification
Type
Reference
Written contract or other arrangement: Document the satisfactory assurances required through a written contract or other arrangement with the business associate that meets the applicable requirements of §164.314 (a).
Required
§164.308 (b)(4)

Physical Safeguards

Facility Access Controls
Standard: Facility Access Controls {{§164.310 (a)}}
Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed.
Facility Access Controls
Implementation Specification
Type
Reference
Contingency operations: Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.
Addressable
§164.310 (a)(2)(i)
Facility security plan: Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.
Addressable
§164.310 (a)(2)(ii)
Access control and validation procedures: Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.
Addressable
§164.310 (a)(2)(iii)
Maintenance records: Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks).
Addressable
§164.310 (a)(2)(iv)
 
Workstation Use
Standard: Workstation Use {{§164.310 (b)}}
Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information.
Workstation Use
Implementation Specification
Type
Reference
N/A
 
 
 
Workstation Security
Standard: Workstation Security {{§164.310 (c)}}
Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.
Workstation Security
Implementation Specification
Type
Reference
N/A
 
 
 
Device and Media Controls
Standard: Device and Media Controls {{§164.310 (d)}}
Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility.
Device and Media Controls 
Implementation Specification
Type
Reference
Disposal: Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored.
Required
§164.310 (d)(2)(i)
Media re-use: Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.
Required
§164.310 (d)(2)(ii)
Accountability: Maintain a record of the movements of hardware and electronic media and any person responsible therefore.
Addressable
§164.310 (d)(2)(iii)
Data backup and storage: Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.
Addressable
§164.310 (d)(2)(iv)

Technical Safeguards

Access Control
Standard: Access Control {{§164.312 (a)}}
Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in §164.308(a)(4).
Access Control
Implementation Specification
Type
Reference
Unique user identification: Assign a unique name and/or number for identifying and tracking user identity. {{UT note: University-issued EIDs may be used for this purpose.}}
Required
§164.312 (a)(2)(i)
Emergency access procedure: Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
Required
§164.312 (a)(2)(ii)
Automatic logoff: Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
Addressable
§164.312 (a)(2)(iii)
Encryption and decryption: Implement a mechanism to encrypt and decrypt electronic protected health information. {{UT note: Only encryption methods/products listed at Approved Encryption Methods ar compliant with policy. The use of any other encryption methods/products not listed is only permissible with an approved Exception to Policy Request. All devices used to store confidential (Category I) university data must be encrypted using an approved method.}}
Addressable
§164.312 (a)(2)(iv)
 
Audit Controls
Standard: Audit Controls {{§164.312 (b)}}
Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
Audit Controls
Implementation Specification
Type
Reference
N/A
 
 
 
Integrity
Standard: Integrity {{§164.312 (c)}}
Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
Integrity
Implementation Specification
Type
Reference
Mechanism to authenticate electronic protected health information: Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
Addressable
§164.312 (c)(2)
 
Person or Entity Authentication
Standard: Person or Entity Authentication {{§164.312 (d)}}
Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
Person or Entity Authentication
Implementation Specification
Type
Reference
N/A
 
 
 
Transmission Security
Standard: Transmission Security {{§164.312 (e)}}
Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
Transmission Security
Implementation Specification
Type
Reference
Integrity controls: Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
Addressable
 
Encryption: Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. {{UT note: Section 11.5.2 of the Information Resources Use and Security Policy mandates that all confidential (Category I) university data be encrypted in transmission over a network. Exceptions are only permissible with an approved Exception to Policy Request.}}
Required by
university policy
 

Policies and Procedures; Documentation Requirements

Policies and Procedures
Standard: Policies and Procedures {{§164.316 (a)}}
Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in §164.306 (b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.
Policies and Procedures
Implementation Specification
Type
Reference
N/A
 
 
 
Documentation
Standard: Documentation {{§164.316 (b)(1)}}
(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and
(ii) If an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.
Documentation
Implementation Specification
Type
Reference
Time limit: Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. {{UT note: Records should not be kept longer than is required. When no longer required, records must be destroyed or erased in a secure manner.}}
Required
§164.316 (b)(2)(i)
Availability: Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.
Required
§164.316 (b)(2)(ii)
Updates: Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.
Required
§164.316 (b)(2)(iii)
 

UT Specific Policy Requirements for Category I Systems

Backups
Standard: Backups {{MSS 4.1}}
Backups
Implementation Specification
Type
Reference
Backups must be verified at least monthly, either through automated verification, through customer restores, or through trial restores.
Required
MSS 4.1.2
 
Change Management
Standard: Change Management {{MSS 4.2}}
Change Management
Implementation Specification
Type
Reference
There must be a change control process for systems configuration. This process must be documented.
Required
MSS 4.2.1
System changes should be evaluated prior to being applied in a production environment.
Required
MSS 4.2.2
Patches must be tested prior to installation in the production environment if a test environment is available.
Addressable
MSS 4.2.3
 
Computer Virus Prevention
Standard: Computer Virus Prevention {{MSS 4.3}}
Computer Virus Prevention
Implementation Specification
Type
Reference
Anti-virus software must be installed and enabled.
Required
MSS 4.3.1
Install and enable anti-spyware software. Installing and enabling anti-spyware software is required if the machine is used by administrators to browse Web sites not specifically related to the administration of the machine.
Addressable
MSS 4.3.2
Anti-virus and, if applicable, anti-spyware software should be configured to update signatures at least daily.
Required
MSS 4.3.3
Systems administrators should maintain and keep available a description of the standard configuration of anti-virus software.
Required
MSS 4.3.4
 
System Hardening
Standard: System Hardening {{MSS 4.5}}
System Hardening
Implementation Specification
Type
Reference
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.
Required
MSS 4.5.1
Operating system and application services security patches should be installed expediently and in a manner consistent with change management procedures.
Required
MSS 4.5.2
If automatic notification of new patches is available, that option should be enabled.
Required
MSS 4.5.3
Services, applications, and user accounts that are not being utilized should be disabled or uninstalled.
Required
MSS 4.5.4
Methods should be enabled to limit connections to services running on the host to only the authorized users of the service. Software firewalls, hardware firewalls, and service configuration are a few of the methods that may be employed.
Required
MSS 4.5.5
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.
Required
MSS 4.5.8
Integrity checking of system accounts, group memberships, and their associated privileges should be enabled and tested.
Required
MSS 4.5.9
The required university warning banner should be installed.
Required
MSS 4.5.10
Whenever possible, all non-removable or (re-) writable media must be configured with file systems that support access control.
Required
MSS 4.5.11
Strong password requirements will be enabled. Passwords must comply with section 15.2.2.3 of the Information Resources Use and Security Policy.
Required
MSS 4.5.13
Apply the principle of least privilege to user, administrator, and system accounts.
Required
MSS 4.5.14
 
Security Monitoring
Standard: Security Monitoring {{MSS 4.6}}
Security Monitoring
Implementation Specification
Type
Reference
If the operating system comes with a means to log activity, enabling and testing of those controls is required.
Required
MSS 4.6.1
Operating system and service log monitoring and analysis should be performed routinely. This process should be documented. 
Required
MSS 4.6.2
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).
Required
MSS 4.6.3
All administrator or root access must be logged. 
Required
MSS 4.6.4

Security Review for New Software and Appliances

Departments evaluating the implementation of new software or appliances involving HIPAA protected 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.

Non-Compliance and Exceptions

If any of the minimum standards contained within this document cannot be met on systems manipulating HIPAA protected data, 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 UT Austin Policies, Procedures, Best Practices and Applicable Laws

Definitions

Health Information
Health information means any information, including genetic information, whether oral or recorded in any form or medium, that:
  1. Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and
  2. Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.
Individually Identifiable Health Information
Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and:
  1. Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and
  2. Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and
    1. That identifies the individual; or
    2. With respect to which there is a reasonable basis to believe the information can be used to identify the individual.
Protected Health Information (PHI)
Protected health information means individually identifiable health information:
  1. Except as provided in paragraph (2) of this definition, that is:
    1. Transmitted by electronic media;
    2. Maintained in electronic media; or
    3. Transmitted or maintained in any other form or medium.
  2. Protected health information excludes individually identifiable health information:
    1. In education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g;
    2. In records described at 20 U.S.C. 1232g(a)(4)(B)(iv);
    3. In employment records held by a covered entity in its role as employer; and
    4. Regarding a person who has been deceased for more than 50 years.
'Addressable
When a standard adopted in §164.308 (Administrative safeguards), §164.310 (Physical safeguards), §164.312 (Technical safeguards), §164.314 (Organizational requirements), or §164.316 (Policies and procedures and documentation requirements) includes addressable implementation specifications, a covered entity must:
  1. Assess whether each implementation specification is a reasonable and appropriate safeguard in its environment when analyzed with reference to the likely contribution to protecting the entity’s electronic protected health information; and
  2. As applicable to the entity
    1. Implement the implementation specification if reasonable and appropriate; or
    2. If implementing the implementation specification is not reasonable and appropriate:
      1. Document why it would not be reasonable and appropriate to implement the implementation specification; and
      2. Implement an equivalent alternative measure if reasonable and appropriate.
'Required
When a standard adopted in §164.308 (Administrative safeguards), §164.310 (Physical safeguards), §164.312 (Technical safeguards), §164.314 (Organizational requirements), or §164.316 (Policies and procedures and documentation requirements) includes required implementation specifications, a covered entity must implement the implementation specifications.

Overview

1. Purpose

U. T. Austin is committed to maintaining the security of customer information, including payment cardholder information such as payment card account number, payment cardholder name, expiration date, and payment cardholder verification number. To uphold this commitment, U. T. Austin follows the best practices for protecting payment card information as defined by the Payment Card Industry Security Standards Council, including information in computer systems which process, store, and transmit payment card information. U. T. Austin must adhere to these standards to limit its liability and to continue to process payments using payment cards.
 

2. SCOPE

The PCI Data Security Standard impacts all U. T. Austin computers and electronic devices involved in processing payment card information.PCI compliance is required of all eCommerce merchants that store, process or transmit credit cards, use equipment with external facing IP addresses, and all other payment channels including manual processing techniques such as, but not limited to, point-of-sale terminals and cash registers.

3. Standards

To meet the Payment Card Industry requirements, the Information Security Office requires the following actions be taken:
 
1. All Merchant accounts must be obtained through and registered with U. T. Austin Cash Management Services.
 
2. All Merchants must utilize the U. T. Austin central processing services, What I Owe and/or TXShop, for their payment card processing needs, unless the university Executive Compliance Committee (or its designate) has approved an exception. When an exception has been granted, the university merchant remains responsible for ensuring the vendor providing payment card processing services is PCI compliant. The university merchant will coordinate proof of compliance with U. T. Austin Cash Management Services.
 
3. If utilizing the central processing services, merchants shall not transmit or store cardholder data outside the centralized system.
 
4. All systems processing payment card information must be registered with the UTnet Utilities (your local Technical Support Coordinator(s) 'TSC' can assist you). An appropriate description for these devices must be provided in the description field and the priority should be set as 'Critical'. The merchant manager should be included as an additional Security Custodian.
 
5. All systems processing payment card information must comply with the Category-I requirements specified in the U. T. Austin Minimum Security Standards for Systems. Server administrators should also refer to the Server Hardening Checklists.
 
6. All applications processing payment card information must comply with the U. T. Austin Minimum Security Standards for Application Development and Administration.
 
7. All payment card business and data handling processes must comply with the U. T. Austin Minimum Security Standards for Data Stewardship.
 
8. All eCommerce merchants processing less than 20,000 payment card transactions per year, and all non-eCommerce merchants, are considered Level-4 Merchants by PCI Standards. UT Austin Cash Management will determine PCI Level. All eCommerce systems associated with the Level-4 Merchant's processes shall undergo quarterly vulnerability scans, which will be conducted by the Information Security Office. Local IT support staff are expected to review the vulnerability scan results and remediate or take steps to mitigate the risk. The local IT support staff will note with the Information Security Office if a particular vulnerability is identified as a false positive or the risk has been mitigated in other ways.
 
9. All eCommerce merchants processing 20,000 to 150,000 payment card transactions per year per card type are considered Level-3 Merchants by PCI Standards. If Visa transactions are less than 20,000 and MasterCard transactions are less than 20,000 then merchant is still considered Level 4. However, separate merchants processing under the same infrastructure will be combined to determine PCI Level. UT Austin Cash Management will determine PCI Level. All systems associated the Level-3 Merchant's processes shall undergo periodic vulnerability scans by the Information Security Office. Additionally, all systems associated with the Level-3 Merchant's processes shall undergo at least quarterly vulnerability scans conducted by an approved PCI vendor. The Level-3 Merchant shall be responsible for paying for these services and will coordinate all activities with U. T. Austin Cash Management Services and the Information Security Office.
 
10. All Level-3 and Level-4 Merchants shall annually complete a PCI Self-Assessment Questionnaire. All responses shall be coordinated with U. T. Austin Cash Management Services and the Information Security Office.
 
11. All systems processing payment card information must use fixed IP addresses. Access to these systems should be appropriately restricted.
 
12. Using any wireless connectivity for payment card processing is not authorized unless purchased from Global Payments Inc through UT Austin Cash Management. Merchants that must use wireless must file an exception via the U. T. Austin Exception Reporting Process and must adhere to PCI best practices regarding such use.
 
13. In addition to the U. T. Austin Minimum Security Standards for Systems, all Web servers providing payment card processing services must utilize the strongest transmission encryption possible (e.g., enable TLSv1.1).
 
14. All portable devices processing payment card information (e.g., laptops, external hard drives, flash drives, CD-ROMs, DVDs) and any desktops located in physically insecure environments must implement disk encryption software. Encryption credentials must be properly escrowed, preferably using a central escrow authority, if there is a need for data retention or recovery.
 
15. Merchants using manual payment card processing techniques, such as point-of-sale and other credit card processing equipment, must abide by the Office of Accounting 6.4 Handbook of Business Procedures.
 
16. The university merchant is also responsible for ensuring any credit card equipment purchased from vendors other than the university's credit card processor (i.e., Global Payments Inc) is PCI compliant. The university merchant will coordinate proof of compliance with U. T. Austin Cash Management Services.
 

4. Additional Resources

5. Revision History

 
Revision History
Version Date New Original
  7/15/2017 Updates to minor terms and concepts.  No material changes.  

 

6/24/2013 Reviewed and fixed broken links
No changes.
  6/19/2013 Converted back to HTML
No changes.
Minimum Security Standards for Merchant Payment Card Processing 3/1/2011 Converted web page to PDF
No changes.
  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.  
  11/13/2007 Added link to exception process.
Unlinked.
  8/8/2007 Posting Date.  

6. Approvals

 
Approvals
Name Role Members Date
Chief Information Security Officer   Approval Cam Beasley 07/15/2017

Overview

1. Purpose

This minimum standard serves as a supplement to the Information Resources Use and Security Policy, which was drafted in response to Texas Administrative Code 202 and UT System UTS-165. Adherence to the standard will improve confidentiality and integrity of university data.
 
The objective of this standard is to facilitate the identification, management, communications and training requirements to promote prudent stewardship of university data. This minimum standard exists in addition to all other university policies and federal and state regulations governing the protection of the university's data.
 
Compliance with these requirements does not imply that data will be completely secure. Instead, these requirements should be integrated into a comprehensive information security plan.
 

2. SCOPE

This standard applies to the handling of university data that are classified as Confidential, Controlled, or Published (see Data Classification Standard).
 

3. Audience

All faculty, staff, student employees, contractors, and vendors working with University of Texas at Austin data or information resources.
 

4. Minimum Standard

The university requires all data stewards and data custodians to manage, access, and utilize university data in a manner consistent with the university's need for confidentiality, integrity, and availability.
 
Each College, School, or Unit (CSU) handling university data shall develop, maintain, and execute a data stewardship plan comprised of clear and consistent procedures describing how the respective area manages the handling, access, and protection of university data. Each data stewardship plan for university data shall include the following components:
 
 
 
: A recurring task; this should be automated when possible
: Recommended
: Required
4.2
# Action Confidential Controlled Published
4.2.1 Labeling documents
Certain documents must be labeled as "Confidential" regardless of internal or external use.
 
Documents approved for distribution should be labeled accordingly.
Certain documents may be labeled as "Confidential" regardless of internal or external use. 
 
Documents approved for distribution should be labeled accordingly.
4.2.2 Duplicating documents
Receiver of document containing Confidential information must not further distribute without permission of respective CSU or data steward. Please see records management practices for more details about creating and managing copies of records.
4.2.3 Mailing documents via campus mail The envelope is labeled as "Confidential"
4.2.4 Mailing documents via external mail carriers No classification marking on external envelope required; Confirmation of receipt is required as legally mandated.
4.2.5 Disposing of documents
Adhere to retention schedules . Employ the services of the preferred vendor for records management and destruction.
Adhere to retention schedules . Physical destruction beyond ability to recover (e.g. office cross-cut shredder).
4.2.6 Storing of documents Stored in a secured location when not in use. Stored out of sight when not in use.
4.2.7 Granting permission to view information
Read access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate.
Read access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate.
4.2.8 Reviewing data classifications for data under CSU and Data Stewards' management Review annually Review annually Review annually

 

 
4.3
# Action Confidential Controlled Published
4.3.1 Storing data on fixed media with access controls . No encryption required. It is highly recommended that some credit card and/or bank account information be encrypted if it must be stored. (Refer to the Data Encryption Guidelines for information about encryption.) Sensitive credit card authentication data should not be stored at all.
4.3.2 Storing data on fixed media without access controls and accessible via the network Not permitted. Not advised. If Controlled data must be stored via this media, it should be encrypted (see Data Encryption Guidelines ) or isolated in such a manner that ensures confidentiality, integrity, and/or availability.
4.3.3
Storing data on fixed media without access controls, but not accessible via the network
Devices must be stored in a physically secured location at all times. Devices must be stored in a physically secured location when not in use.
4.3.4 Storing data on removable media or portable devices It is required that Confidential data be encrypted when stored on such media or devices (see Information Resources Use and Security Policy (IRUSP)  11.3.4). Such media or devices must be stored in secured location when not in use. It is recommended that Controlled data be encrypted when stored on such media or devices. Such media or devices must be stored in secured location when not in use.
4.3.5 Granting permission to view data (including duplication) Read access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate. Read access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate.
4.3.6 Granting permission to create or modify data Create / Modify access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate. Create / Modify access is restricted using various access control methods and is based on roles, classes, entitlements, or affiliations defined by respective Data Steward, or their designate.
4.3.7 Granting permission to delete data Deletions are restricted using various access control methods and are based on roles, classes, entitlements, or affiliations defined by respective Data Steward or their designate. Also adhere to records management requirements for deleting data . Deletions are restricted using various access control methods and are based on roles, classes, entitlements, or affiliations defined by respective Data Steward or their designate.
4.3.8 Preventing data disclosure to unauthorized requestors (e.g., social engineering) Consider what is being requested and who is requesting it. If the requestor's credentials or authenticity cannot be 100% assured, do not disclose any information. Escalate the situation to a supervisor, or to the Information Security Office. Consider what is being requested and who is requesting it. If the requestor's credentials or authenticity cannot be 100% assured, do not disclose any information. Escalate the situation to a supervisor, or to the Information Security Office.
4.3.9
Preventing unauthorized viewing or eavesdropping of data (e.g., shoulder surfing)
Implement privacy screens on monitors that are in high-traffic areas. Be aware of any unauthorized individuals or loiterers. Implement privacy screens on monitors that are in high-traffic areas. Be aware of any unauthorized individuals or loiterers.
4.3.10 Printing hard copy report of data Unattended printing permitted only if physical access controls are used to prevent unauthorized viewing. Unattended printing permitted only if physical access controls are used to prevent unauthorized viewing.
4.3.11 Labeling data at the internal application or screen level If information has been specifically restricted (e.g. about a user), it should be clearly displayed to the viewer upon request of such restricted information.
4.3.12 Disposing of surplus physical electronic media device (e.g. disks, hard drives, CDs, etc) Media must be securely destroyed using university-approved methods . Media should be wiped or degaussed beyond the ability to recover data. It is advised that media be destroyed using the Confidential destruction processes
4.3.13 Disposing of data (e.g., legacy data, unneeded data, etc) Adhere to retention schedules . Manually or automatically attempt to verify Confidential data has been removed (e.g., SENF ). Adhere to retention schedules . Manually or automatically attempt to verify Controlled data has been removed.
4.3.14 Auditing access activity Log all necessary access attempts defined by policy or business requirements; System Custodians shall review all access violation attempts and notify Data Steward and/or Information Security Office of any suspicious or abnormal activity. Log all violation attempts; System Custodian reviews as appropriate.
4.3.15 Retaining information access report logs Retain logs for at least 14 days. Existing record retention schedules are authoritative. Retain logs for at least 14 days. Existing record retention schedules are authoritative.
4.3.16 Reviewing data classifications for data under CSU and Data Stewards' management Review annually Review annually Review annually
 
 
4.4
# Action Confidential Controlled Published
4.4.1 Transmitting information via fax Machine must have limited access such that only those authorized can view. Otherwise, recipient must first agree that an authorized person will be present when the material is received. Machine must have limited access such that only those authorized can view. Otherwise, recipient must first agree that an authorized person will be present when the material is received.
4.4.2 Transmitting information via voice mail Confidential data must not be provided in a voice mail message. Instead, request a call back.
4.4.3 Transmitting information via wired, wireless, or cellular network Encryption required (e.g. SSL, SSH, IPSEC, etc). If no secure transmission option is available, data must be encrypted prior to transmission. Encryption suggested
4.4.4 Transmitting information via other network protocols (e.g. e-mail, file transfers, telnet sessions, web applications, network printing) Encryption required (e.g. SSL, SSH, IPSEC, etc). If no secure transmission option is available, data must be encrypted prior to transmission. Encryption suggested. Access controls required.
4.4.5 Reviewing data classifications for data under CSU and Data Stewards' management
Review annually
Review annually
Review annually
 

5. Responsibility

5.1. Colleges, Schools, Units (CSUs)
 
5.1.1. CSUs, relying on the university's Data Classification Standard and the Minimum Security Standards for Data Stewardship, shall develop, maintain, and execute a data stewardship plan comprised of clear and consistent procedures describing how the respective functional areas and their reporting units manage the handling, access, and protection of university data.
 
5.1.2. CSUs must be able to clearly demonstrate effective employee awareness efforts as they relate to respective business practices involving university data.
 
5.2. Data Stewards
 
5.2.1. Data Stewards shall ensure that steps are taken to protect the data in accordance with respective policies, guidelines, and procedures are being properly implemented.
 
5.2.2. Data Stewards may delegate the implementation of the university polices, guidelines, and procedures (for example, system administration) to professionally trained campus or departmental IT owners and/or custodians.
 
5.3. Data Custodians
 
5.3.1. All university employees handling university data are considered Data Custodians for any data in their possession regardless of where the data may be stored.
 
5.3.2. Data Custodians should review and understand the university's Data Classification Standard and the responsibilities associated with viewing and handling university data they have been authorized to access. Any related questions should be directed to their respective supervisor and/or to the Information Security Office (security@utexas.edu).
 
5.3.3. Data Custodians should refer to the Minimum Security Standards for Data Stewardship, or their respective area or unit's specific data handling procedures, if there are any questions about how a piece of data should be handled.
 
5.3.4. Data Custodians are responsible for any unauthorized disclosure or exposure of data while the data is in their possession.
 
5.3.5. All university employees handling university data should avoid accessing, manipulating, or changing university data without the authorization of their supervisor or if is not required to fulfill assigned university duties. Such misuse includes, but is not limited to, the following examples:
 
5.3.5.1. Changing data about yourself or others for other than usual business purposes.
 
5.3.5.2. Using information, even if authorized to access it, to support actions by which individuals might profit (e.g., salary changes, grade changes, appointment changes.)
 
5.3.5.3. Disclosing information about individuals without prior supervisor authorization.
 
5.3.5.4. Monitoring the pattern of salary raises of others; determining the source and/or destination of telephone calls or Internet usage; patterns of personal location; exploring race and ethnicity indicators; querying student grades.
 
5.3.5.5. Circumventing the assigned levels of data access given to other users by providing access or data sets that are broader than those available via normal approved levels of access.
 
5.3.5.6. Facilitating another's illegal access to or compromise of the university's information resources by sharing account passwords or other information.
 
5.3.5.7. Violating university policies or federal, state, or local laws in accessing, manipulating, or disclosing university data.
 

6. Non-Compliance and Exceptions

For all CSUs and Data Stewards—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.
 
For all university employees — non-compliance with this standard may result in revocation of system or network access, notification of supervisors, and/or reporting to the Offices of Internal Audit and Institutional Compliance.
 
All 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 federal and state laws and regulations.
 

7. Related UT Austin Policies, Procedures, Best Practices, and Applicable Laws

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.)
 
 
 
 
 
 
 
 

8. Sources

Portions adapted from "Security Requirements for Handling Information"
(http://www.itap.purdue.edu/security/procedures/dataHandling.cfm), with permission from Purdue University, West Lafayette, Indiana 47907.
 
Portions adapted from "Cornell University Policy: Data Stewardship and Custodianship" (http://www.dfa.cornell.edu/treasurer/policyoffice/policies/volumes/governance/data.cfm), with permission from Cornell University, Ithaca, New York 14853.
 

9. Revision History

 
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 updated Data Classification Standard  
  6/24/2013 Reviewed and fixed broken links. Dropped recursive link back to this document in references.
 
  6/19/2013 Converted back to HTML
No changes
Minimum Security Standards for Data Stewardship 2/28/2011 Converted from PDF to HTML
No changes
  05/03/2010
Updated information in Data Stewardship Standard Sec 3.4
 
Under Cat-I column, removed "(see Data Encryption Guidelines)" and replaced with "(see Information Resources Use and Security Policy (IRUSP))."
 
Under Cat-II column, replaced "Category-I" with "Category-II data"
"(see Data Encryption Guidelines)"
 
"Category-I"
  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.  
  9/14/2007
Changed references from BPM 53 to UTS-165
 
In Section IV. References, removed "Draft" designation from the Data Stewardship and Application Development Standards
 
Corrected typo in standard 3.4. Changed "removal" to "removable"
"BPM 53"
 
"(Draft)"
 
"Storing data on removal media or portable device"
  9/8/2007 Corrected typo in standard 4.1. Changed "than" to "that."
"Machine must have limited access such that only those authorized can view. Otherwise, recipient must first agree than an authorized person will be present when the material is received."
  5/30/2007 Section IV, changed "printed digital data" to "printed data" to remove confusion.
"Specific procedures addressing the handling of printed digital data, including but not limited to:"

8. Approvals

 
Approvals
Name Role Members Date
Chief Information Security Officer   Approval Cam Beasley 8/24/2015

Infrastructure-as-a-Service (IaaS) and Containerized Solutions

Applicability: The minimum security standards found here apply to IaaS managed services — virtual servers that are designed to be ephemeral — and containerized solutions.

 
Standards What to do
Low Risk
Moderate Risk
High Risk
Platform Selection Review the ISO's Local and Cloud Services Decision Matrix  for Public Data for Controlled Data for Confidential Data
Operational Practices Review the guidance from Vendors and 3rd Party controls and compliance for Public Data for Controlled Data for Confidential Data
System Architecture Review the guidance from and Risks of Cloud Services for Public Data for Controlled Data for Confidential Data
Account Management Ensure that you are adhering to these standards related to the creation of cloud accounts and leverage centrally managed cloud options as much as possible. for Public Data for Controlled Data for Confidential Data
Patching and Application Lifecycle
  1. Apply high severity security patches within seven days of release.
  2. Apply all other security patches within 30 days.
  3. Use a supported operating system and application version.
  4. Use machine images only from trusted sources.

Additional Elaboration:

  • Managed Services — For managed services like Amazon RDS or Google Cloud SQL, define a maintenance window that meets the standard.
  • Ephemeral Servers and Containers — If using an automated system to build fully patched machine images, ensure that the patched image, or container base layer, is in use in your environment within the window of time specified in the Minumum Security Standard.
for Public Data for Controlled Data for Confidential Data
Vulnerability Management

Leverage the UTISO Managed Vulnerability Scanning Service (with Nessus Agents) to ensure that all critical vulnerabilities are remediated within seven days of discovery, and moderate/important vulnerabilities within 30 days.

Systems should also log data to the Managed Splunk Service with analysts regularly reviewing these logs.

For high risk services, UTISO can make additional security monitoring agents available. Please contact us directly about this option (security@utexas.edu).

Additional Elaboration:

  • Managed Services — UTISO scanning may be omitted on infrastructure provider managed services, however if the platform provides a native vulnerability detection capability, it should be implemented.
  • Ephemeral Servers — Build machine images that contain the Nessus Agent, or bootstrap the installation and configuration of the Nessus Agent using the management tools specific to your implementation.
  • Containerized Solutions — Run a Nessus Agent scan on the network where the container runs.
for Public Data for Controlled Data for Confidential Data
Inventory and Asset Classification

Maintain an inventory of deployed resources as well as the risk classification and service owner of those resource in ISORA.

Additional Elaboration:

  • Ephemeral Servers — Systems designed for a lifespan no greater than 7 days (commonly those in autoscaling worker groups) should be inventoried as a single application.
  • Managed Services — Infrastructure managed services like Amazon RDS or Google Cloud SQL should be inventoried as applications.
for Public Data for Controlled Data for Confidential Data
Container Registries As more applications move to container-based microservices, those container images need to be stored in a common set of repositories (as much as possible) to help ensure that a container registry security strategy can be carried out. 
This involves scanning the container images for vulnerabilities, auditing image lifespan and outdated packages, etc.  If containers are leveraging the centrally managed registries on campus the ISO will be positioned to scan those for security deficiencies and system admins will be able to more easily assess package gaps, etc. 
Please consult with ITS as to which container registry is right for your use case (help@its.utexas.edu).
for Public Data for Controlled Data for Confidential Data
Firewall Use the native tools and design patterns of your platform to ensure that only the minimum necessary network communication is permitted through virtual network devices such as VPCs, load balancers, and the like. This includes access to managed services such as hosted database platforms. for Public Data for Controlled Data for Confidential Data
Credential and Key Management
  1. Where possible, integrate with UT Austin authentication for all cloud administration consoles.
  2. Abide by UT's  password rules
  3. Review administrative accounts and privileges quarterly.
  4. API keys:
    1. Minimize their generation.
    2. Grant minimum necessary privileges.
    3. Rotate at least annually.
    4. Do not hardcode.
  5. Do not share credentials.
  6. Leverage Stache for management of these (note: Stache offers an API to facilitate this).
for Public Data for Controlled Data for Confidential Data
Two-Step Authentication Enforce two-factor authentication for all interactive user and administrator logins. UT provided Duo two-factor authentication is recommended, but other two-factor options may be acceptable.   for Controlled Data for Confidential Data
Logging and Alerting
  1. Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed.
  2. Forward logs to the UTISO Managed Splunk Service.

Additional Elaboration:

  • Administrative Activity Logs —  Log user actions and API calls that create or modify the configuration or metadata of a resource, service or project.
  • Data Access Logs — Log user actions and API calls that create, modify, or read high-risk Confidential data managed by a service. One example would be to enable data access logs on AWS S3 buckets containing high-risk Confidential Data.
  for Controlled Data for Confidential Data
Intrusion Detection

In most situations involving lower risk university data robust system logging paired with system management insights can be all that is needed.  In situations where higher risk Confidential university data is in scope specific network security monitoring may be required. Please consult with the Information Security Office if your implementation is handling Confidential and you are needing to tie into our intrusion detection services for cloud implementations.  Reach us at (security@utexas.edu).

    for Confidential Data
Backups
  1. Backup application data at least weekly.
  2. Encrypt backup data in transit and at rest.
  3. Store backups in independent cloud accounts.
  for Controlled Data for Confidential Data
Encryption
  1. Enable transport layer encryption for all communications external to the private cloud environment.
  2. Use TLS 1.1 or higher.
  3. Use encryption at rest if available.
  for Controlled Data for Confidential Data
Data Centers Prefer US based data center locations.   for Controlled Data for Confidential Data
Privileged Access Workstation (PAW)

Cloud administration consoles should only be accessed through a PAW when logging in with an administrative account.

Administrative accounts are defined as:

  • Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes.
  • Accounts with the ability to override or change security control
    for Confidential Data
Security, Privacy, and Legal Review Prior to implementation, ensure that your assets are accounted for in ISORA's inventory and that risk management details are provided​     for Confidential Data
Regulated Data Security Controls
  1. Adhere to applicable regulations: PCI, HIPAA/HITECH, NIST 800-171, GDPR, etc.
  2. For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used.
    for Confidential Data

Credit where credit is due: Thanks to Stanford's ISO for the content!

Minimum Security Standards: Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS)

 
Standards What to do
Low Risk
Moderate Risk
High Risk
Product Selection Review the ISO's Local and Cloud Services Decision Matrix for Public Data for Controlled Data for Confidential Data
Pre-implementation Planning

Review the ISO's Risks of Cloud Services.

for Public Data for Controlled Data for Confidential Data
Inventory and Asset Classification
  1. List the product in the department's ISORA Inventory.
  2. Ensure the inventory is updated quarterly and reflects accurate data classification and service ownership.
for Public Data for Controlled Data for Confidential Data
Credential and Key Management
  1. Integrate with UT's SSO services, preferably SAML.
  2. Review administrative accounts and privileges quarterly.
  3. Adhere to the University of Texas password complexity rules if not integrated with a UT SSO service.
  4. API keys:
    1. Minimize their generation.
    2. Grant minimum necessary privileges.
    3. Rotate at least annually.
    4. Do not hardcode.
  5. Do not share credentials.
  6. Use Stache and Stache's API to help with this.
for Public Data for Controlled Data for Confidential Data
Encryption
  1. Enable transport layer encryption TLS 1.1 or higher.
  2. Use encryption of data at rest if available.
for Public Data for Controlled Data for Confidential Data
Two-Step Authentification

If user login is not able to be integrated with UT Austin SSO, enable two-factor authentication if offered by the solution.

for Controlled Data for Confidential Data
Logging and Auditing
  1. Enable any available application logging that would assist in a forensic investigation in the event of a compromise. Seek vendor or ISO guidance as needed.
  2. Contractually ensure that the provider can export logs at the request of UT Austin within five days.
for Controlled Data for Confidential Data
Data Management

Contractually ensure that UT Austin data are purged upon termination of the agreement with accommodations as necessary to comply with any applicable regulatory obligations.

for Controlled Data for Confidential Data
Privileged Access Workstation (PAW)

Administration consoles should only be accessed through a PAW when logging in with an administrative account.

Administrative accounts are defined as:

  1. Accounts with the ability to make unrestricted, potentially adverse, or system-wide changes.
  2. Accounts with the ability to override or change security controls.
for Confidential Data
Security, Privacy and Legal Review

Prior to implementation, ensure that your assets are accounted for in ISORA's inventory and that risk management details are provided.

for Confidential Data
Regulated Data Security Controls
  1. Follow all regulatory data controls as applicable (HIPAA/HITECH, NIST 800-171, PCI DSS, GDPR, etc.). 
  2. For HIPAA data, ensure that only cloud services covered under a Business Associate Agreement (BAA) are used.

for Confidential Data

Credit where credit is due: Thanks to Stanford's ISO for the content!

This set of standards supplement the UT Austin Information Resources Use and Security Policy and provides additional details related to the minimum security expectations of care required for the university's various types of data.

UT Austin requires individuals granted access to or use of the university's information resources to be aware of and abide by the university's information security policies and requirements.

These standards will evolve over time as technologies and use cases change. All changes will be captured in the respective change log.

Please feel free to contact the UT Information Security Office (security@utexas.edu) with any questions.