UO Minimum Information Security Controls

UO.1 CMS:Registration
UO.2 CMS: Management (OS)
UO.3 CMS: Management (Apps)
UO.4 Vulnerability Scanning
UO.5 Penetration Testing
UO.6 Organizational communication and data flows are mapped
UO.7 Externals services must be compliant with UO  Minimum Security Standards & Controls
UO.8 Resources (e.g., hardware, devices, data, time, personnel, and software) are prioritized based on their classification
UO.9 Cybersecurity roles and responsibilities for the entire userbase are established
UO.10 Cybersecurity roles and responsibilities for the third party stakeholders (e.g., suppliers, customers, partners) are established
UO.11 The organization’s place in critical infrastructure and its industry sector is identified and communicated
UO.12 Priorities for organizational mission, objectives, and activities are established and communicated
UO.13 Privileged users understand their roles and responsibilities
UO.14 Conduct a Risk Assessment
UO.15 Physical Security
UO.16 Wall Jack Access Control
UO.17 System Hardening
UO.18 Security Baseline
UO.19 Security Updates
UO.20 Application Blocklisting
UO.21 Anti-malware
UO.22 Auto-lock screens or consoles
UO.23 Firewall (Host-based)
UO.24 Firewall (Network)
UO.25 Encryption: Data-at-Rest
UO.26 Encryption: Data-in-Transit
UO.27 Encryption: Full Disk
UO.28 User Access Control: Unique Access Account
UO.29 User Access Control: Least Privilege Access
UO.30 User Access Control: Access Approval
UO.31 User Access Control: Authentication
UO.32 User Access Control: Limit Failed Login Attempts
UO.33 User Access Control: Inactive Session Timeout
UO.34 User Access Control: Two-Factor Authentication
UO.35 User Access Control: Remote Privileged Access Session Security
UO.36 Web Reputation Filtering
UO.37 Security and privacy architectures
UO.38 Power requirements
UO.39 Remote access is managed
UO.40 All users are informed and trained
UO.41 Data is destroyed according to policy
UO.42 Cybersecurity is included in human resources practices (e.g. personnel screening, deprovisioning)
UO.43 Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
UO.44 Incident Response Plan is developed
UO.45 Logging and Retention
UO.46 Log Monitoring
UO.47 File Integrity Monitoring
UO.48 Incident Recovery: Backup & Recovery
UO.49 Incident Recovery: Restoration Testing
UO.50 Determine critically of Information system components
UO.51 Resiliency requirements will be established based on data classification
UO.52 Organizational cybersecurity policy is established and communicated
UO.53 Cyber threat intelligence is received from information sharing forums and sources
UO.54 Risk management processes are established, managed, and agreed to by organizational stakeholders
UO.55 Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
UO.56 Separation of system and user functionality

System shall be registered via an ISO approved Configuration Management System (CMS).

CMS: Registration includes inventorying of system including identifiers (e.g., MAC address), IT support contact, hardware, operating system, and some software or services. CMS: Registration systems include MECM, JAMF, or Puppet.

UO.2 CMS: Management (OS)

System Operating Systems shall be managed via an ISO approved Configuration Management System (CMS).

CMS: Management (OS) includes inventorying of system hardware, operating system, and some software or services. CMS administrators (OS) will be able to push patches and updates to systems under management. CMS administrators (OS) will also be able to push security settings and monitor for compliance for systems under management. CMS: Management (OS) systems include MECM, JAMF, or Puppet. CMS: Management (OS) also includes CMS: Registration services.

UO.3 CMS: Management (Apps)

Applications shall be managed via an ISO approved Configuration Management System (CMS).

CMS: Management (Apps) includes inventorying of applications (or application module or components) running on a system, where practical. CMS (Apps) administrators may be able to push patches and updates to applications under management. CMS administrators (Apps) may also be able to push security settings and monitor for compliance for applications under management. CMS: Management (Apps) also includes CMS: Registration services.

UO.4 Vulnerability Scanning

System SHALL be registered and configured for ISO ongoing vulnerability scans and identified vulnerabilities MUST be addressed in a timely manner not to exceed:

30 days for critical risk vulnerabilities (CVSS 9.0 -10.0)
90 days for high risk vulnerabilities (CVSS 7.0 -8.9)
120 days for medium risk vulnerabilities (CVSS 4.0 -6.9)
As time allows for low risk vulnerabilities (CVSS 0.1 -3.9)

Our adversaries are constantly scanning our environment in search of vulnerable systems that can be exploited. Addressing ISO identified vulnerabilities in an expeditious manner significantly reduces the risk of the systems and data compromise.

UO.5 Penetration Testing

The system shall be subjected to ISO conducted (or directed) penetration testing to confirm the strength of implemented controls or identify weaknesses.

ISO will perform or coordinate penetration testing activities to confirm the effectiveness or weakness of controls to protect the system. Penetration testing exercises should only be performed following approval by the system owner.

UO.6 Organizational communication and data flows are mapped

A data flow diagram maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination.

Example:

UO.7 Externals services must be compliant with UO  Minimum Security Standards & Controls

Identify and inventory external services & systems and ensure they meet UO Minimum Security Standards & Controls and or through PCS review

UO.8 Resources (e.g., hardware, devices, data, time, personnel, and software) are prioritized based on their classification

Information System resources are classified by the highest level of data they process. Use the Information Asset Classification and Management Policy to determine sensitivity level.

UO.9 Cybersecurity roles and responsibilities for the entire userbase are established

Cybersecurity roles, expectations, and responsibility should be established and communicated to the University, including roles for recovery. The role of CISO should be established and staffed to advocate for the office in the Intuitional decision making bodies.

Roles to Communicate:

Recovery
Security
Incident Response

UO.10 Cybersecurity roles and responsibilities for the third party stakeholders (e.g., suppliers, customers, partners) are established

Cybersecurity roles, expectations, and responsibility should be communicated to third party vendors, including roles for recovery. The role of CISO should be established and staffed to advocate for the office in the Intuitional decision making bodies.

UO.11 The organization’s place in critical infrastructure and its industry sector is identified and communicated

Identify the University's place in the local infrastructure. Who depends on University IT Services, who does the University depend on for IT services. Understanding what dependencies third-parties has on UO infrastructure, will help to identify critical components and service level targets.

UO.12 Priorities for organizational mission, objectives, and activities are established and communicated

Organizational priorities are established and communicated to employees. Resources are aligned with priorities, and the resources understand how to prioritize their time.

UO.13 Privileged users understand their roles and responsibilities

The privileged users, external and internal, have their responsibilities and expectations communicated to them

UO.14 Conduct a Risk Assessment

Conducting risk assessments includes the following specific tasks:

Identify threat sources that are relevant to organizations
Identify threat events that could be produced by those sources
Identify vulnerabilities within organizations that could be exploited by threat sources through specific threat events and the predisposing conditions that could affect successful exploitation
Determine the likelihood that the identified threat sources would initiate specific threat events and the likelihood that the threat events would be successful
Determine the adverse impacts to organizational operations and assets, individuals, other organizations, and the Nation resulting from the exploitation of vulnerabilities by threat sources (through specific threat events)
Determine information security risks as a combination of likelihood of threat exploitation of vulnerabilities and the impact of such exploitation, including any uncertainties associated with the risk determinations.

Track risk to system and data by:

Maintaining an up-to-date list of risks (or threats, vulnerabilities, exposures)
Rollup risks at least annually to the University Strategic Enterprise Risk Management Committee (SERMC)

UO.15 Physical Security

System shall be physically protected and monitored to prevent theft or unauthorized access to data via the system consoles or keypads.

System should be hosted within a protected and monitored area with a secure perimeter (e.g., walls, lockable doors and windows) that protects the system from unauthorized physical access. UO datacenters should be used for hosting server devices. Endpoint devices should be kept safe to prevent them becoming loss or stolen.

UO.16 Wall Jack Access Control

Require approval for connecting unmanaged and/or non-university-owned devices to UO network wall jacks.

Unmanaged and/or non-university owned devices should be blocked from connecting to UP VLANs, unless specifically vetted and authorized by ISO. Unmanaged or non-university-owned devices can cause network loops that could disrupt availability of critical systems or loss of connectivity to entire buildings. Additionally, these devices could be used to hijack or “sniff” sensitive traffic propagating over High-Risk segments of the network

UO.17 System Hardening

Systems shall be hardened by removing unnecessary applications, services or features prior to implementation in production or assignment to users.

Hardening a system involve removal or disabling of all unnecessary default accounts, applications (e.g., database, web server) or services (e.g., ftp service) to minimize potential vulnerabilities and the attack surface of that system. In the case of applications, unused modules are features may be disabled or uninstalled as part of the hardening exercise.

UO.18 Security Baseline

System shall be configured to comply with applicable ISO approved security baseline.

ISO security baselines are developed based on industry best practices for the system in question. UO has adopted the Center for Internet Security (CIS) benchmarks to guide development of our baselines.

UO.19 Security Updates

Security updates shall be applied prior to system deployment into production or assignment to users and be kept up to date thereafter.

System should be configured to automatically download and install security updates whenever possible. This will reduce vulnerabilities on the system that could be exploited to cause major security incidents.

UO.20 Application Blocklisting

Application Blocklist shall be used to prevent “known bad” applications from executing.

Application blocklists are often included as part of major operating systems to be able to limit applications executed on the system. Note: Allowlists are often more secure but may cause more inconvenience and are generally more expensive to implement.

UO.21 Anti-malware

Anti-malware (including antivirus) software shall be in used kept up to date.

Anti-malware software runs continually to detect and remediate known malware (including viruses) based on heuristic or known malware signatures. To be effective, the software should always be running and should be set to automatically update signatures and rules from the manufacturer.

UO.22 Auto-lock screens or consoles

Systems shall be configured to automatically lock and require a logon, pin, biometrics, or other means of authentication after being unattended or inactive for at most 15 minutes.

Auto-lock prevents unauthorized access by passersby or others without approval for access. Inactivity timeouts may vary between 5 and 30 minutes for Moderate Risk (Amber) or Low Risk (Green) systems. High Risk (Red) systems should be set to lock after not longer than a 15 minute period of inactivity. Red systems in high visibility or high traffic areas, should be set to have screens lock after a 5 minute period of inactivity.

UO.23 Firewall (Host-based)

Host-based firewall shall be used and kept up-to-date and be configured to block inbound traffic by default

A host-based firewall (a.k.a, personal firewall) prevents other systems (including those on the same subnetwork or VLAN) from communicating with the system unless specifically allowed. This helps to prevent malicious software and activities to spread from nearby systems.

UO.24 Firewall (Network)

Data-at-rest (stored) shall be encrypted to ensure confidentiality.

Sensitive files, records, tables or entire databases should be encrypted with the decryptions keys properly managed and changed periodically. In some cases, encryption may not be needed if ISO deemed that appropriate compensating controls have been implemented, or the risk of breach of confidentiality or integrity is substantially low.

Note 1: certain combinations of Medium Risk data elements may constitute on aggregate High Risk data.
Note 2: for cloud-based services, the goal is to employ the “trust no one or TNO” principle which requires decryption keys to be accessible only by approved UO personnel, thereby preventing cloud-service vendor personnel or subcontractors from accessing UO data.

UO.25 Encryption: Data-at-Rest

Data-at-rest (stored) shall be encrypted to ensure confidentiality.

UO.26 Encryption: Data-in-Transit

Encrypted protocols or secure channels shall be used to transmit data to and from the system to ensure confidentiality of data and protection of UO data subjects.

Encrypted communication prevents eavesdropping or man-in-the-middle attacks that can be used to breach the confidentiality of data. Acceptable secure communication protocols include SSH, SCP, sFTP, IPSec, TLS, VPN.

Note: in the case of connections for management or administration, data in this case may also refer to configuration files or other systems settings.

UO.27 Encryption: Full Disk

Full disk encryption shall be enabled to prevent unauthorized access to data on hard drives.

Full disk encryption prevents access to data on hard drives without a valid decryption key (or password). E.g., if a laptop is loss or stolen, the data cannot be accessed without the decryption key. Central encryption key escrow is required to be able to assist users who forgot their encryption keys.

UO.28 User Access Control: Unique Access Account

Uniquely identifiable (user ID/login name) shall be used for accessing the system to ensure accountability for user activities.

System should be configured to use unique identifier assigned by the University (e.g., DuckID) for accessing the system. Shared IDs should be avoided to ensure that activities done on a system are individually identifiable. For cases where shared IDs must be used, additional process should be put in place to assist with unique identifiability for activities carried out on the system (e.g., ID checkout or assignment tracking process).

UO.29 User Access Control: Least Privilege Access

Least privilege shall be employed to provide the minimum privileges to users and processes.

Privileges shall be restricted and controlled in accordance with the principle of least privilege to reduce opportunities for unauthorized access or misuse of the system.

UO.30 User Access Control: Access Approval

Access and privileges shall be authorized by the system owner and reviewed at regular intervals.

System owners should approve access to system based on the users "need to have" to perform a university function. Privileges should be assigned on a "least privilege" basis. System owners should regularly review access rights and privileges to ensure they are still needed; activities of interest include terminations, departmental transfers, or roles changes. Access re-certification should be performed at least annually.

UO.31 User Access Control: Authentication

Authentication shall be required for all access to the system.

Acceptable UO authentication elements include username/password, PINs, digital certificates, and biometrics. ISO approved authentication sources include one of the following secure/encrypted log-on procedures: Active Directory, LDAP, UO Single Sign-on, external vendor authentication approved by ISO.

UO.32 User Access Control: Limit Failed Login Attempts

System shall be configured or otherwise controlled to limit failed login attempts to 10 or less, by temporarily disabling the account.

Login attempts should be limited to prevent brute force attacks, where automated tools are used to continuously guess the password until they are successful. Non-privileged accounts may automatically be reenabled after being disabled for 15 -30 minutes.

UO.33 User Access Control: Inactive Session Timeout

Controls shall be implemented to timeout or expire sessions after a period of 10 hours or less of inactivity.

Inactive session timeout reduces exposure to session hijacking attacks, where an attacker could intercept an active session to gain unauthorized access to the system as the user.

UO.34 User Access Control: Two-Factor Authentication

Two-factor Authentication shall be used, at least once, in the path required for all network access, and for all local access by privileged accounts.

Two-factor authentication refers to the combination of any two of the following factors:

something you know(e.g., a password or PIN)
something you have(e.g., a phone, a token, proximity access card, a digital certificate)
something you are(e.g., finger print, hand scan, iris scan, etc.)

UO.35 User Access Control: Remote Privileged Access Session Security

Encrypted communication protocols shall be used for remote privileged access to the system.

Encryption protocols are required for privileged access to the system from outside of the UO wired network (including from the University wireless networks.) Acceptable protocols include SSH, SCP, sFTP, or virtual private network tunneling protocols (TLS or IPSEC VPN). Depending on specific requirements, split tunneling may be prohibited to prevent access to the local network and VPN destination network simultaneously.

UO.36 Web Reputation Filtering

Web Reputation Filtering shall be used to protect user from known malicious websites as identified by ISO.

Web reputation filtering service tracks known malicious websites to protect users. Web reputation filtering services may be included as part of web browsers or as part of other endpoint protection service. Automatic updating of the blocklist is highly recommended.

UO.37 Security and privacy architectures

During the system design stage of development, the system is designed with privacy and security controls commensurate with the data classification of stored information.

UO.38 Power requirements

Emergency and standby power systems provides alternate power such as UPS. Devices and systems should have power redundancies.

UO.39 Remote access is managed

Remote access to the system or service is centrally managed, through an institutionally approved VPN. This VPN service needs to be compliant with the University's logging standard. This type of remote access implies a full connection to the University's LAN, vs an HTTPS connection to a website, which is not considered Remote access, unless you are tunnelling other protocols through the HTTPS connection.

UO.40 All users are informed and trained

Members of the university community will receive security training depending on the highest data classification they accessed, their level of privilege and regulatory requirements.

UO.41 Data is destroyed according to policy

Data is destroyed according to this standard and in accordance to Data Retention policy.

UO.42 Cybersecurity is included in human resources practices (e.g. personnel screening, deprovisioning)

During the hiring process, HR conducts a background screening on the potential employee to determine suitability of employment.

UO.43 Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes

User identities and credentials are issued by the Accounts team, access levels and privileges are determined by the role of the user, verified by the employees supervisor (if user is an employee), and audited to verify access level permissions remain consistent with role.

UO.44 Incident Response Plan is developed

Incident Response Plans that detail severity of impact and prescribed responses for cybersecurity incidents are developed, published, and advertised to those that have been identified as having action as a part of the Incident Response Plans.

UO.45 Logging and Retention

System shall be configured to log and retain privileged and non-privileged user activities, and system security events.

Logs should be configured to capture events showing "who did what and when". Systems Logs should be sent to the ISO-approved Logging and Monitoring service to ensure appropriate retention and analysis for security events.

UO.46 Log Monitoring

System generated logs of user activity and system security events shall be monitored for potential security issues by the system administrator and ISO. Logs should be sent to the ISO-approved Logging and Monitoring service to be analyzed for indicators of security issues and to provide alerting and notification.

UO.47 File Integrity Monitoring

File integrity monitoring shall be used to validate the integrity of important operating system and application software files.

Unauthorized changes or replacement of critical operating system or application files often signals infiltration by attackers. File integrity monitoring provides a means to detect such changes by using cryptographic methods (e.g. hashing functions) for detection.

UO.48 Incident Recovery: Backup & Recovery

System and data shall be backed up and retained according to University record retention policies, and system owner recovery point and recovery time objectives (RPO, RTO).

System and data backups should be stored as far away from the original system as possible to avoid destruction of both originals and backups. This is also a key control to recover from dangerous attacks such as ransomware. For desktop computers, users should focus on ensuring that important data is backed up, as opposed to full backup of those systems.

UO.49 Incident Recovery: Restoration Testing

Backup system shall be tested periodically to verify the integrity of the backup process and recoverability of data and system.

Recovery testing increase assurance that the process is working correctly and increases confidence that backups are being captured appropriately. This activity can either be done on a scheduled basis or recoveries performed during normal operations can be documented and leveraged as evidence of process and data integrity.

UO.50 Determine critically of Information system components

During the recovery process, some assets will be more critical or will have to be started before others in the information system can be. Determine the proper order of recovery for the systems (E.g. Border protections first) and determine the relative criticality of the system in a disaster scenario.

UO.51 Resiliency requirements will be established based on data classification

Data classification (Red, Amber, and Green) accounts for both criticality and sensitivity of data.

UO.52 Organizational cybersecurity policy is established and communicated

UO.53 Cyber threat intelligence is received from information sharing forums and sources

Monitoring the websites of your software vendors and reading relevant industry publications for news about emerging threats and available defenses.

UO.54 Risk management processes are established, managed, and agreed to by organizational stakeholders

UO.55 Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders

UO.56 Separation of system and user functionality

Separate user functionality, including user interface services, from system management.

Information Security Office

Site Navigation

Take Action

Search form

UO Minimum Information Security Controls

Take Action