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
: 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:
|
||||
| 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. All new servers should be designed with the appropriate level of resiliency to accommodate rapid patching. All existing servers much have documented procedures in place to ensure that out of band patching can be completed in 1-3 days exigent situations that are declared by the ISO. | ||||
| 4.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 | Systems must leverage Active Directory, or other centralized identity services, for user account provisioning as technology permits. 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. A user's primary account should not have administrative privileges. Accounts with administrative privileges should not be used for non-administrative purposes. Accounts using UT EID authentication should not be granted administrative privileges unless the system is capable of requiring multi-factor authentication each time administrative access is invoked. Examples: |
||||
| 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
- Information Resources Use and Security Policy
- UT Austin Acceptable Use Policy for Employees
- UT Austin Data Classification Standard
- UT Austin Information Security Exception Process
This is not an all-inclusive list of policies and procedures that affect information technology resources.
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 |