Minimum Security Standards for Mission-Critical Systems
Mission Critical Information Resources – Information Resources defined to be essential to UNTHSC’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 UNTHSC’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 Category I 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, Payment Card Environments (PCI), 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.
♻ : A recurring task; this should be automated when possible
| Control Category | What to Do |
Recurring
|
Backups |
||
| System administrators should establish and follow a procedure to carry out regular system backups. |
♻ |
|
| Backups must be verified at least monthly, either through automated verification, through customer restores, or through trial restores. |
♻ |
|
| Systems administrators must maintain documented restoration procedures for systems and the data on those systems. |
♻ |
|
Change Management |
||
| There must be a change management process for systems configuration. This process must be documented. |
♻ |
|
| 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. |
♻ |
|
| 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). |
♻ |
|
Anti-Malware/Antivirus Protection |
||
| Malware protection software must be installed and enabled, as technology permits. If technology does not permit, a security exception must be submitted. Example: McAfee Endpoint Protection |
♻ |
|
Anti-virus and, if applicable, anti-spyware software should be configured to update signatures daily. |
♻ |
|
Documentation |
||
| There must be documentation and/or playbooks 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. |
♻ |
|
Physical Access |
||
| Systems must be physically secured in a UNTHSC data center or in physical or virtual facilities approved by the Information Security Office. | ||
| 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. | ||
System Hardening |
||
|
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:
|
||
| 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 remedied. |
♻ |
|
| Enable automatic notification of new patches if possible. | ||
| Services, applications, and user accounts that are not being utilized should be disabled or uninstalled. |
♻ |
|
| 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. | ||
| Services or applications running on systems manipulating Category I data must implement encrypted communications as required by confidentiality and integrity needs. (See Data Encryption Guidelines.) | ||
|
Systems must 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 (see Data Encryption Guidelines), access controls, file system audits, physically securing the storage media, or any combination thereof as deemed appropriate. Examples: |
||
| 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:
|
♻ |
|
| Integrity checking of system accounts, group memberships, and their associated privileges should be enabled and tested. |
♻ |
|
|
The required university warning banner should be installed. Examples: Windows: Group policy – UNT System AUP Logon Banner |
||
| Whenever possible, all non-removable or (re-) writable media must be configured with file systems that support access control. | ||
| Access to non-public file system areas must require authentication. | ||
| Strong password requirements must be enabled that comply with UNTHSC/UNT system Standards. | ||
| 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. |
♻ |
|
| 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 EUID and password, where possible. All administrator accounts must be reviewed at least 90-days to ensure their current state is correct. |
♻ |
|
| 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: |
||
| 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. |
|
|
| If an ISO hardening guideline 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. | ||
Security Monitoring |
||
| 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 Category I data must be logged and tied to an account and a timestamp. All administrative access must be logged. |
♻ |
|
| Operating system and service log monitoring and analysis should be performed routinely. This process should be documented. |
♻ |
|
| All service and operating system authentication logs must be forwarded to a central logging server. |
♻ |
|
| Any logs not forwarded to a managed log service must be retained for a minimum of 14 days and must be made available to the ISO upon request. |
♻ |
|
| 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 occurring. 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. |
♻ |
|
| 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. |
♻ |
|
Resilient Infrastructure |
||
| All systems and applications must be designed 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. | ||
| 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). |
♻ |
|
Staffing and Training |
||
| All systems and applications must be operated by system administrators (or service owners) that are professionally trained according to UNTHSC/UNT System Policies. | ||
| Systems and applications must have sufficient resources assigned to maintain, patch, monitor and provide customer support. | ||
| 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. | ||
Social media