Research IT Environment Compliance Reference Material

Has the management of User Accounts and Privileged Accounts been clearly assigned or delegated for the Research IT Environment?

At a minimum, this responsibility includes:

• approval of new accounts
• ensuring user accounts, other than test accounts, are not shared and are traceable back to the individuals using them
• periodic reviews of user accounts
• annual reviews of privileged accounts to validate that they remain restricted to authorized personnel

Control or Process Description​

A User is anyone who accesses information or information systems within your Research IT Environment and requires an account to do so. Accounts that give Users access to UBC Systems are called User Accounts. Privileged Accounts provide a significantly greater level of access to a system or application than regular User Accounts, and are generally restricted to IT Support Staff. Responsibility for managing these accounts, both regular and privileged, is assigned to specific individuals, typically the PI who acts as the Information Steward/Owner or delegates to another individual. The responsibility of an Information Steward/Owner includes reviewing and approving new account requests, keeping a record of who was granted access and who authorized it, ensuring accounts, other than test accounts, are unique to and traceable back to the individual using them, and periodically reviewing accounts to confirm access still matches each person's role, including at least annual review of privileged accounts.

Why is this Essential?

Without controls over who can access accounts and what level of access they hold, research information and systems are exposed to unauthorized access, and activity can no longer be traced back to the individual responsible. Account compromise is one of the most common ways systems are breached, and the Principle of Least Privilege limits the impact if it happens.

What is Acceptable?

For every system and service within your Research IT Environment, an individual (or individuals) is responsible for account management. This includes:

• approval of new user and privileged accounts
• ensuring user accounts, other than test accounts, are unique to and traceable back to the individual using them
• periodic review of user accounts
• annual review of privileged accounts to confirm access remains restricted to authorized personnel

The results of these reviews are communicated to the PI and documented across all systems and applications.

Guidance for Selecting a Response​

The minimum responsibilities for managing user and privilege accounts include:

• approval of new accounts
• ensuring user accounts, other than test accounts, are not shared and are traceable back to the individuals using them
• periodic reviews of user accounts
• annual reviews of privileged accounts to validate that they remain restricted to authorized personnel

For this question, Not implemented means that the management of User Accounts and Privileged Accounts has generally not been assigned or delegated to an individual/s.

Partially implemented means that the management of User and/or Privileged accounts have been delegated or assigned to an individual/s in 50-84% of systems and services in your research IT environment. Select this option if <=2 of the minimum responsibilities have been delegated or assigned.

Believed to be implemented in most cases means that the management of User and Privileged Accounts has been assigned to an individual/s in 85-99% of systems and services in your Research IT environment and this includes >2 of the responsibilities noted.

Implemented in all cases means that the management of User and Privileged Accounts has been assigned to an individual/s in all systems and services in your Research IT environment and this includes all responsibilities noted.

Reference Links​

• User Account Management
• Privileged Account Management

To what extent is there a formal approval process for granting User and Privileged Account access for all UBC Systems in your Research IT Environment?

Control or Process Description​

Before user or privileged accounts are granted access to an application or system, the account request must be reviewed and approved. Within your Research IT Environment, this responsibility typically falls to the Principal Investigator, acting as the Information Steward/Owner, or their delegate. This designated individual reviews each account request, confirms it is appropriate for the requester's role, and approves it before access is granted. A record of who was granted the account and who authorized it is kept for at least one year.

Why is this Essential?

Approving account access before it's granted ensures that only individuals with a legitimate need can access your research systems and information, in line with the "least privilege" principle. Without a review-and-approval step, accounts can be created or granted more broadly than necessary, increasing the risk of unauthorized access to research data.

Because account compromise is one of the most common ways systems are breached, limiting who can obtain access, and being able to show, through retained records, who approved that access and when, reduces both the likelihood and the impact of a breach, and supports accountability if an incident needs to be investigated.

What is Acceptable?

The PI or their delegate holds Information Steward/Owner responsibility for reviewing and approving requests for user and privileged account access. Requests are reviewed and approved consistently, with a record kept of who submitted each request, who approved it, and when, across all accounts, systems, and services within your Research IT Environment.

Guidance for Selecting a Response​

There are two types of accounts that provide access to systems or services: User Accounts and Privileged Accounts. User accounts provide general access to systems or services. This type of access is typically used for accessing systems or applications to store, process, read or share information. Privileged accounts provide greater level of access including adding of new users, or changing system configurations.

Prior to providing an individual with a user account and/or privileged account, Information stewards/owners need to review the request for the account, ensure that the account requested is required based on the users role or responsibilities, and then approved. A record of users being granted the accounts and who provided the authorization must be retained for at least one year. For this question, we consider this a formal process. Verbal requests and authorization are not considered a formal process given the inability to produce a record of users and authorization for these.

For this question, Not implemented, or only on some cases means you do not have a formal process to review and approve request for user and/or privileged accounts. You also do not have a process to document these as described above.

Partially implemented means you have a formal process to review, approve and record authorization for 50-84% of accounts, systems and services; However, you only apply this some of the time. For example, you only apply this process for privileged account requests but not user accounts or it is limited to only some systems or services. Select Partially implemented as well if you review and approve requests but do not retain records of authorization.

Believed to be implemented in most cases means you believe that you have a formal process (as described above) and you apply this to 85-99% accounts, systems and services.

Implemented in all cases means you have a formal process to review and approve request for and record authorization of user and/or privileged accounts. You also apply this process consistently across all accounts, systems and services.

Reference Links​

• User Account Management
• Privileged Account Management
• Data Governance at UBC
• Authorization for Privileged Account Access
• System Administrators’ Code of Ethics

To what extent do UBC Systems and Applications in your Research IT Environment undergo regular, risk-based reviews of User and Privileged Accounts, to ensure access is restricted to authorized personnel?

Control or Process Description​

User access rights must be reviewed at regular intervals to confirm they still match each person's current role and responsibilities. The frequency of review is risk based: accounts with access to High or Very High Risk information are reviewed more often than those with access to lower risk information. Privileged account access must be reviewed at least annually, or more frequently if set by the system's Technical Owner, to confirm access remains restricted to authorized personnel. Any discrepancies found during a review are reported to the Technical Owner for resolution.

Why is this Essential?

User (both privileged users and regular users) account onboarding, off-boarding processes along with periodical review of all accounts minimizes the risk of unauthorized access to your research IT environment and the research information thus, preserving the confidentiality, integrity and availability of the data, system and system settings.

Access to research information and systems is often restricted to specific individuals, roles or groups and this requirement is often documented in consent forms, contracts, agreements, or access requests. Having a process where user access is approved and reviewed, as well as revoked when necessary allows you to meet these set of requirements.

Sharing of regular user accounts between individuals reduces your ability to determine the individual responsible for a specific activity related to your research information or system. Should the system and information be compromised, it would be more difficult to determine the source of the compromise.

System compromise is very frequently associated with compromised accounts. Limiting account access following the 'least privileged' principle minimizes the number of accounts and the capabilities of these accounts reducing the likelihood and impact of a breach.

What is Acceptable?

The PI, or their delegate acting as Information Steward/Owner, ensures that user and privileged accounts across your Research IT Environment are reviewed at a risk-based frequency, more frequently for High and Very High Risk information, and at least annually for privileged accounts. Reviews confirm that access remains aligned with each person's current role and responsibilities, and access is revoked when it's no longer needed. All accounts are reviewed at the required frequency, without exception.

Guidance for Selecting a Response​

In organizations, it is typical for individuals to change roles, move to a different project, or move away from the organization all together. In the research landscape, graduate students within a research group using information, systems and applications today will likely graduate and leave the group after a few years. Collaborations may necessitate access for a set amount of time. Regularly reviewing user and privilege accounts that have access to information, systems and services is essential to ensure that, given the movement of individuals within or external to the research group, access remains restricted to those that are authorized. These reviews must be risk based - user access to high and very high risk information are reviewed more frequently than those that have access to lower risk information and privilege accounts are reviewed annually at a minimum.

For this question, Not implemented, or only on some cases means you do not, or do not regularly, review user and privilege accounts that have access to information, systems, and services within your Research IT environment.

Partially implemented means you conduct a review but only to some accounts (e.g. privilege accounts only), or account access to only some information, systems or services (e.g. account access to 50-84% of your information, systems or services). If review is conducted but not done at the required frequency, select Partially implemented.

Believed to be implemented in most cases means you conduct a review of between 85% - 99% of the accounts that have access to information, systems and services within your Research IT environment. These are reviewed at the required frequency.

Implemented in all cases means you conduct a review of all accounts that have access to information, systems and services within your Research IT environment and these are reviewed at the required frequency.

Reference Links​

• User Account Management
• Privileged Account Management
• Data Governance at UBC

To what extent is there a process for changing default Solution provider or developer passwords, and are they changed following the installation of systems or software in your Research IT Environment?

Control or Process Description​

Default vendor or solution provider passwords that come with hardware or software installations must be changed following the installation of any system or software within your Research IT Environment.

Why is this Essential?

Hardware and software devices often come with default or factory-set usernames and passwords. These credentials are documented by vendors and are publicly available online, making them one of the first things a threat actor will try when attempting to gain access to a system, application, or the information it stores or processes. Changing default passwords immediately after installation closes off this easy point of entry.

What is Acceptable?

Default vendor or solution provider passwords are changed for every system, device, instrument, and/or software within your Research IT Environment, consistently, immediately following installation.

Guidance for Selecting a Response​

Hardware or software devices often come with default or factory settings like default username and password. These credentials are documented and are publicly available on the internet. Threat actors are aware of this and are one of the first things they would look to take advantage of and gain access to a system or software and the information processed or stored within these.

For this question, Not implemented means you do not consistently change the default solution provider or developer password after the installation of systems or software in your Research IT environment.

Partially implemented means you change the default solution provider or developer password for 50-84% of the systems or software within your Research IT environment after installation.

Believed to be implemented in most cases means you change the default solution provider or developer password for 85%-99% of the systems or software within your Research IT environment after installation.

Implemented in all cases means you change the default solution provider or developer password for all systems or software within your Research IT environment after installation.

Reference Links​

• Changing Default Passwords
• Passphrase and Password Protection

Excluding systems configured with CWL/EAD authentication, to what extent are authentication systems for User Accounts in your Research IT Environment protected against password cracking (e.g., account lockout policies or incremental login delays)?

Note: An example for authentication system is a local domain controller or a localized application server that stores credentials locally. Also, it is common for an application to have more than one application system e.g., one for users, one for mobile devices and one for privileged users.

Control or Process Description​

Authentication systems for User Accounts must be adequately protected from password cracking, using at least one of the following methods:

• Locking the account for a period of time after a set number of incorrect password attempts within a specified time window
• Introducing an increasing delay before responding to each incorrect password attempt, resetting once the User successfully logs in

Why is this Essential?

Every day, UBC systems experience attempts to guess or breach user credentials through brute-force attacks and credential stuffing, where attackers use lists of previously breached passwords to try to gain access. Account lockout policies and incremental login delays make these automated attacks far less effective, protecting your research systems and data from unauthorized access.

What is Acceptable?

Account lockout policies and/or incremental login delays are implemented for every authentication system protecting User Accounts within your Research IT Environment, other than systems configured with CWL/EAD authentication, which meet this requirement by default.

Guidance for Selecting a Response​

Every day, UBC systems experience attempts to guess/ breach user credentials by brute-force attempts, credentials stuffing, etc. These adversaries are building a repository of breached passwords and easily guessable passwords and are using the data against our environment to scan weaknesses in user passwords and gain access to the compromised accounts remotely. It is important to secure accounts with a strong password and to adequately protect User accounts from password cracking using at least account lockout policies and/or incremental login delays.

For this question, Not implemented means you currently do not have or do not consistently apply account lockout policies and/or incremental login delays implemented to protect User accounts from password cracking.

Partially implemented means you have account lockout policies and/or incremental login delays implemented in 50-84% of systems and services within your Research IT environment.

Believed to be implemented in most cases means you have account lockout policies and/or incremental login delays implemented in 85%-99% of systems and services within your Research IT environment.

Implemented in all cases means you have account lockout policies and/or incremental login delays implemented in all of the systems and services within your Research IT environment.

Reference Links​

• Securing User Accounts
• Password Safes

To what extent are all user passwords used for authentication purposes in internally developed or custom-built applications protected using a salted hash?

Note:
1. Systems configured with CWL/EAD User authentication meet this requirement.
2. Cloud based (Software-as-a-Service) applications hosted and managed by third-party solution provider or developer are out of scope for this question.
3. Custom-built applications include locally hosted downloaded software e.g., from git repos.

Control or Process Description​

Authentication systems must not store account passwords in clear text. Where possible, passwords should be stored using a strong cryptographic hash that is also salted.

Why is this Essential?

If an authentication system storing passwords in clear text is compromised, an attacker gains direct access to every stored password. Since people often reuse passwords across different systems, a stolen password from one compromised system can be used to access your other accounts and research systems as well. Storing passwords using a strong, salted cryptographic hash makes stolen password data far harder for an attacker to actually use.

Instructions​

For guidance on implementing salted password hashing correctly, see: Salted Password Hashing – Doing it Right.

What is Acceptable?

All internally developed or custom-built applications within your Research IT Environment, such as locally hosted software from a git repository, store user passwords using a strong, salted cryptographic hash rather than in clear text. Where no such applications currently exist in your Research IT Environment, this requirement is met by default, though awareness of it is maintained for any future development.

Guidance for Selecting a Response​

Authentication systems must not store account passwords in clear text because if the system is compromised the bad actor would have access to a database of user's passwords. As users frequently reuse passwords across systems (a bad practice), this could result in further system compromise/harm to users.

Passwords should be stored using a strong cryptographic hash and salted to make it difficult for an adversary to crack passwords using a dictionary or brute force attacks, lookup tables, rainbow tables, etc.

Note: If there are currently no internally developed or custom-built applications within your Research IT Environment that fall within the scope of this requirement, select Implemented in all cases and note this down in your response to the subsequent description question. However, awareness of this requirement should exist to ensure that any future internally developed or custom-built applications protect stored passwords using a salted hash.

For this question, Not implemented means that authentication systems for internally developed or custom built applications within your Research IT environment do not, or do not consistently, protect stored passwords using a salted hash.

Partially implemented means that authentication systems for 50-84% of internally developed or custom built applications within your Research IT environment protect stored passwords using a salted hash.

Believed to be implemented in most cases means that authentication systems for 85-99% of internally developed or custom built applications within your Research IT environment protect stored passwords using a salted hash.

Implemented in all cases means that authentication systems for all of internally developed or custom built applications within your Research IT environment protect stored passwords using a salted hash.

Reference Links​

• Securing User Accounts
• Salted Password Hashing – Doing it Right

To what extent do you, your users and IT Support Staff aware of the requirement to report all or suspected cybersecurity incidents to “security@ubc.ca”?

Control or Process Description​

You report all incidents that have and could potentially jeopardize the confidentiality, integrity and/or availability of an information system/processes to "security@ubc.ca" and have communicated this responsibility to all users and IT Support Staff utilizing or supporting your Research IT Environment. Incidents include suspicious emails, pop-ups requesting payment or a callback number, suspicious logins to your Research IT Environment, or theft of information, systems, or devices. Report these to security@ubc.ca even if you're unsure anything malicious occurred.

Why is this Essential?

Reporting potential security incidents in a timely manner allows the incident to be assessed and contained promptly. Further, visibility of incidents supports the cybersecurity team in adjusting the response to the threat across UBC.

What is Acceptable?

You, your users, and IT Support Staff are all aware of the requirement to report suspected or confirmed cybersecurity incidents to security@ubc.ca (or by phone to the IT Service Centre), and this awareness is reinforced periodically. For example, through reminders when incidents occur locally or more broadly across UBC. Reporting happens consistently, without exception, across everyone using or supporting your Research IT Environment.

Guidance for Selecting a Response​

Incidents are security events that can either be accidental or deliberate attempts to break into systems regardless of whether the outcome is benign or malicious. This could be a suspicious email that a staff receives, a pop up on their computer screen that wants the user to contact a 1800 number or a pop-up that asks for ransom. It could also be suspicious log in into your Research IT Environment or theft of information or systems/devices. These events must be reported to security@ubc.ca even if you are uncertain that anything malicious occurred.

For this question, Not implemented, or only on some cases, means you and <50% your staff are aware of the requirement to report security incidents. Reporting occurs inconsistently or rarely.

Partially implemented, means 50-84% of your staff and you are aware of the requirement for reporting security incidents and report these incidents to security@ubc.ca.

Believed to be implemented in most cases, means 85-99% of your staff and you are aware of the requirement for reporting security incidents and report these incidents to security@ubc.ca.

Implemented in all cases, means you and all your staff are aware of their requirement for reporting security incidents and report these incidents to security@ubc.ca.

Reference Links​

• Reporting Cybersecurity Incidents

Have users and IT Support Staff using or supporting the Research IT Environment been informed of the Information Systems Policy and completed the required "Privacy & Information Security – Fundamentals" and, where applicable to their role, the "Privacy & Information Security – IT Professionals" training?

Control or Process Description​

You have communicated the requirement to adhere to information security policy and to complete information security training. There is a process in place to follow up with users (employees and student staff) that have not completed required training.

Why is this Essential?

All employees of UBC, where relevant, contractors and third party users shall receive appropriate awareness training and regular updates in organizational policies and procedures, as relevant for their job function.

Information security is everyone's responsibility. User and IT professional training provide people with the information they need to protect UBC information and systems. People are often considered information securities weakest link.

Instructions​

You can generate a report of training completion for your direct reports by following the self-help instructions here: How to Create Privacy Course Reports. Review the report for accuracy and use it to follow up with anyone who hasn't completed the required training. If you notice inconsistencies, users that do not report to you directly, or have questions, reach out to UBC PrISM Compliance (prism.compliance@ubc.ca).

What is Acceptable?

You have communicated the requirement to complete the training requirements to everyone using or supporting your Research IT Environment. Every user and IT Support Staff member has completed the training applicable to their role, and any gaps identified during review are followed up on until fully resolved.

Guidance for Selecting a Response​

For this question, Not implemented, or only on some cases, means you and <50% of your staff have completed the Privacy & Information Security training relevant to their roles.

Partially implemented, means 50-84% of your staff and you have completed the Privacy & Information Security training relevant to their roles.

Believed to be implemented in most cases, means 85-99% of your staff and you have completed the Privacy & Information Security training relevant to their roles.

Implemented in all cases, means you and all your staff have completed the Privacy & Information Security training.

Reference Links​

• Information Systems Policy (SC14)
• About the Training
• Required training for all UBC workers

To what extent are you, the users, and IT Support Staff using or supporting the Research IT Environment aware of the requirement for Administrative Heads of Units to request a variance when deviating from UBC Information Security Standards, and do you consistently inform and work with your Administrative Head of Unit when such a variance is required?

Control or Process Description​

To appropriately protect research related information, research processes, system or service selection and/or system configuration must follow UBC requirements as stated in the UBC Information Security Standards. In some occassions, processes, systems and/or services deviate from these standards. It is important for the IT staff in the research unit to identify when there is deviation from standards and inform their Principal Investigator that a variance must be submitted by their administrative head of the unit to information.security@ubc.ca.

Why is this Essential?

Non-compliance with the information security standards significantly increases the risk of a breach. Building a culture where risks and non-compliance issues are reported enables evaluation of the situation and the potential for compensating controls to be implemented with help from UBC IT & Cybersecurity teams.

Instructions​

Examples of issues that may be subject to variance requests:

1. Legacy systems that are past End of Life and no longer supported by vendors. For example: computers that are running Windows7 or WindowsXP, that control microscopes whose vendors do not support software upgrades to Windows 10 or other updateable systems;
2. EduCloud server to stay in service after end-of-support, for a period of time to give the unit time to upgrade the operating system and validate the software running on it.
3. Request to share a common login/credential for x number of laptops to be used in classroom by a large a varied number of students.
4. Compute node running an operating system/version which is non-compliant with UBC security policy requirements, such as "Ubuntu 14.04.3 LTS"
5. A server, for technical reasons, cannot run Crowdstrike, therefore being out of compliance with UBC policy.
6. Cannot meet the password complexity requirements due to technological reasons.
7. Cannot implement/ enforce MFA to a certain authentication request.
8. Cannot meet encryption requirements in certain circumstances.
9. Data or systems hosted outside UBC approved data center where the hosting location or service does not meet UBC's requirements. Note: Research data may be stored in locations outside UBC approved data centers, provided that the hosting location or service meets UBC requirements. A variance is required when the location or service cannot meet the applicable requirements.
10. Disabling vulnerability scanning of internet facing devices temporarily or long term due to technical reasons.

What is Acceptable?

You, your users, and IT Support Staff using or supporting your Research IT Environment are all aware that any process, system, or service that doesn't meet UBC's Information Security Standards requires a variance request. In practice, this means that when a deviation is identified, IT staff and users raise it with the Principal Investigator promptly. The Principal Investigator, in turn, ensures it gets submitted through the Administrative Head of Unit to information.security@ubc.ca.

Guidance for Selecting a Response​

For this question, Not implemented means that you and <50% of your staff are aware that a variance is required when process, services, or systems do not meet the UBC requirements. Not implemented should also be selected when you have instances where a variance is required but only request it <50% of the time or you request for variances inconsistently.

Partially implemented means 50-84% of your staff and you are aware of the variance requirement. Partially implemented should also be selected when you have instances where a variance is required but only request it 50-84% of the time.

Believed to be implemented in most cases means 85-99% of your staff and you are aware of the variance requirement. Believed to be implemented in most cases should also be selected when you have instances where a variance is required but only request it 85-99% of the time.

Implemented in all cases means you and all your staff are aware of the variance requirement. You also request a variance for all instances where a variance is required.

Reference Links​

• Requesting Variances

To what extent are you, users, and IT Support Staff within your Research IT Environment aware of the Security Threat and Risk Assessment service and taking appropriate action to request one when applicable?

Control or Process Description​

A Security Threat and Risk Assessment (STRA) is a security assessment conducted, ideally, before a new tool, platform, or service is adopted, or before a significant change is made to an existing one. For research projects, an STRA is generally requested in place of a Privacy Impact Assessment (PIA) when the tool or service is used solely for research purposes. An STRA identifies gaps in the security of a system or tool, documents the risks associated with these gaps, and provides recommendations to improve its security. The resulting report serves as a decision-making tool for researchers and stakeholders in determining whether to adopt a tool or system.

Why is this Essential?

How a tool, service, system, or platform is configured can introduce risk to the confidentiality, integrity, and availability of UBC systems and research data. Requesting an STRA before adoption identifies these risks while they are still easiest and least costly to address.

What is Acceptable?

You and your staff are aware of the STRA service and before adopting a new research tool or platform such as a survey tool, a cloud storage service, a connected device, etc., an STRA is requested consistently to ensure that this tool or platform is able to protect UBC systems and research data.

Guidance for Selecting a Response​

For this question, Not implemented, or only on some cases means you and <50% of your staff are aware of the Security Threat Risk Assessment (STRA) service and do not know how and when it is appropriate to request it.

Partially implemented, means you and 50-84% of your staff are aware of the STRA service and you do not know how and when it is appropriate to request it.

Believed to be implemented in most cases means you and 85-99% of your staff are aware of the STRA service and you know how and when it is appropriate to request it.

Implemented in all cases means you and all your staff are aware of the STRA service and know how and when it is appropriate to request it.

Reference Links​

• Security Threat and Risk Assessment (STRA)
• What is a PIA?

To what extent is there a process in place to ensure that the solution provider or developer complete one of the following before being granted access to Medium, High, or Very High Risk UBC Electronic Information and Systems, and is it consistently applied?

entering into a service agreement with UBC that includes a Privacy Appendix as prescribed by Procurement Services
signing a Security and Confidentiality Agreement (SACA) as prescribed by the Office of the University Counsel, or
obtaining a waiver from the Office of the University Counsel?

Control or Process Description​

Before a service provider, a solution provider, vendor, or developer is granted access to Medium, High, or Very High Risk information, one of three things must be in place:

• A service agreement with UBC that includes a Privacy Appendix (prescribed by Procurement Services)
• A signed Security and Confidentiality Agreement (SACA) in the form prescribed by the Office of the University Counsel
• A waiver obtained from the Office of the University Counsel prior to granting access to the information or information resource

Why is this Essential?

Signed SACAs set clear expectations with vendors on their responsibilities relating to UBC information and systems, and transfer some legal responsibility in the event of a breach not caused by UBC. Where a service agreement with a Privacy Appendix or a waiver from the Office of the University Counsel is used instead, that same purpose still applies: expectations are documented and responsibility is clearly assigned before access is granted.

Instructions​

Service Providers must sign a Security and Confidentiality Agreement (SACA) prior to being granted access to Medium, High, or Very High Risk Information. Where a service agreement with a Privacy Appendix already covers equivalent privacy and security terms, or where the Office of the University Counsel grants a waiver because the primary contract contains equivalent language, a separate SACA is not required. Doctors, lawyers, accountants, auditors, psychologists, and other professionals bound by a duty of confidentiality do not need to sign a SACA.

What is Acceptable?

Before any service provider is granted access to Medium, High, or Very High Risk information, one of the three required agreements or a waiver is completed and in place, for every service provider, every time, without exception.

Guidance for Selecting a Response​

For this question, think about the number of Service Providers that have access to your Medium, High or very high risk Information or have access to the systems that store or process this information. Think about whether one of the following actions have been completed prior to providing access to Service Providers:

• Enter into a service agreement with UBC that includes a Privacy Appendix as prescribed by Procurement Services;
• Sign a Security and Confidentiality Agreement (SACA) as prescribed by the Office of the University Counsel; or
• Obtain a waiver from the Office of the University Counsel

For this question, Not implemented means that before you grant a Service Provider access to Medium, High or Very High Risk Information or access to systems that store or process this information, you complete one of the above actions <50% of the time.

Partially implemented means that before you grant a Service Provider access to Medium, High or Very High Risk information or access to systems that store or process this information, you complete one of the above actions 50-84% of the time.

Believed to be implemented in most cases means that before you grant a Service Provider access to Medium, High or Very High Risk information or access to systems that store or process this information, you complete one of the above actions 85-99% of the time.

Implemented in all cases means you do the above for all Service Providers and for all Medium, High and Very High Risk information.

Reference Links​

• Outsourcing and Service Provider Management

To what extent do your users consistently use UBC acceptable methods of transmission (such as UBC OneDrive, UBC Teams, Teamshare, Globus, etc.) within your Research IT Environment to securely transmit and share UBC Electronic Information?

Control or Process Description​

UBC Electronic Information must be transmitted and shared using methods appropriate to its risk classification. Depending on the sensitivity of the information, this means using UBC accepted tools, such as UBC OneDrive, UBC Teams, Teamshare, Globus, an authenticated and encrypted SSH connection, or tools that have been reviewed through a Privacy Impact Assessment (PIA) or Security Threat and Risk Assessment (STRA), rather than personal email accounts, unencrypted USB drives, or external websites that haven't been reviewed.

Why is this Essential?

Using methods that haven't been reviewed through a PIA or STRA, or that aren't otherwise UBC accepted, to transmit or share information, such as personal email, an unencrypted USB drive, or a non-UBC cloud service, can expose your research to real risks: unpublished data or manuscripts could be accessed or stolen before you're ready to publish, participant information could be exposed to a privacy breach, or research findings could be lost or corrupted. Using accepted methods that match the information's risk classification protects both the confidentiality of your work and the integrity of your research.

What is Acceptable?

UBC accepted methods, such as UBC OneDrive, UBC Teams, Teamshare, Globus, SSH with an authenticated and encrypted connection or tools that have been reviewed through a Privacy Impact Assessment (PIA) or Security Threat and Risk Assessment (STRA), are consistently used to transmit and share UBC Electronic Information, matched appropriately to the information's risk classification.

Guidance for Selecting a Response​

Given that research is collaborative, there may be instances where your collaborators are from a different institution and their institution IS the lead institution or the data owner. In these cases, this lead institution may require the use of non-UBC tools. In answering this question, please exclude this use case. For this question, only think about the use case where UBC is the lead institution or the data owner. In most cases, this would mean that the grant funds are provided to UBC.

For this question, Not implemented means you and <50% of your staff are not aware or do not use UBC acceptable methods for transmitting or sharing information appropriate for the information's risk classification. Transmission Method Examples: - Only using non-UBC or non-institutional emails to share UBC electronic information. - Using websites for sharing high and very high risk information without an approved PIA. - Using USB without full disk/device level/media level encryption to share information.

Partially implemented, means you and 50-84% of your staff use UBC acceptable methods for transmitting or sharing information appropriate for the information's risk classification only some of the time. Transmission Method Examples: - Using UBC OneDrive to share research data with collaborators but using Dropbox or Google Drive to share unpublished and/or in-progress manuscripts with collaborators.

Believed to be implemented in most cases means you and 85-99% of your staff use UBC acceptable methods for transmitting or sharing information appropriate for the information's risk classification most of the time. Additionally, in instances where you do not use UBC acceptable methods, you have submitted a variance request. Transmission Method Examples: - Using UBC OneDrive to share most information but using Dropbox to share other information. However, you have submitted a variance to evaluate the use of the tool in your research.

Implemented in all cases means you and all your staff use UBC acceptable methods for transmitting or sharing information appropriate for the information's risk classification all the time. Transmission Method Examples: - Using UBC OneDrive, SSH with authenticated and encrypted connections, or Websites hosted outside Canada that has been approved by a Privacy Impact Assessment (PIA).

Reference Links​

• Transmission and Sharing of UBC Electronic Information

To what extent is there a process in place to maintain an inventory of UBC Electronic Services within your Research IT Environment? 
UBC Electronic Services are an integrated set of components for collecting, storing, and processing data and for providing information, to obtain a desired outcome. Examples of UBC Electronic Services include: 
• Cloud-based applications purchased using UBC funds or grant funds 
• Instruments, software applications, and associated devices purchased for or developed by your research service or research project 
• Applications developed by or for your research service or research project

Control or Process Description​

UBC Electronic Services within your Research IT Environment must be inventoried and classified using the Electronic Services Risk Classification model. This includes any cloud-based application purchased with UBC or grant funds, any instrument, software application, or associated device purchased for or developed by your research service or project, and any application developed by or for your research service or project. Where an enterprise asset inventory system is available, this inventory must be recorded in it.

Why is this Essential?

Understanding what electronic services are running in your Research IT Environment is the first step in knowing how to protect them. An inventory that records the risk posed by each service, along with who is responsible for its maintenance, enables you to prioritize your highest-risk services for protection.

Without an inventory and clear accountability for maintenance, services can become orphaned, no longer tracked or actively managed, increasing risk to your Research IT Environment and to UBC more broadly.

From a cybersecurity perspective, an inventory supports faster incident response by allowing the right service owners to be identified and involved before an issue develops into a serious incident.

Instructions​

Below is a link for an asset inventory template. This asset inventory template is intended to assist Administrative Head of Units, CSM's, IT Representatives and other System Owners in the unit/faculty or research IT environment for collaborating, gathering and recording the asset information. While this is NOT the standard or an approved asset inventory template, the idea is to get you started, at least until there is a better process or mechanism in place for your environment. You are welcome to repurpose it, customize the sheet to include more information depending on your requirements, and/or circulate it with others to whom you think it might benefit.
Asset Inventory Template

What is Acceptable?

The PI, or a delegate such as an IT Representative or System Owner, has been delegated responsibility for maintaining your Research IT Environment's inventory of UBC Electronic Services, covering cloud-based applications, purchased or developed instruments and software, and any applications built for your research. Each service is classified using the Electronic Service Risk Classification Model, and the inventory is kept current, reviewed and updated regularly, or whenever a new service is adopted.

Guidance for Selecting a Response​

An Electronic Services inventory is used to track and classify UBC Electronic Services within your Research IT Environment. This helps ensure the services are identified, risk classified, managed, and recorded consistently.

For this question, consider whether:

• a process exists to identify and record UBC Electronic Services
• the inventory is maintained and kept up to date over time

For this question, Not implemented, or only on some cases means there is no consistent process to maintain and update an inventory of UBC Electronic Services in the Research IT Environment. Services may not be identified or classified, and an inventory may not exist or is incomplete and informal.

Partially implemented means you have a process to identify and record 50-84% of your UBC Electronic Services that exists in your Research IT Environment. However, an inventory is incomplete or inconsistently maintained, and service classification is not consistently applied or updated.

Believed to be implemented in most cases means you have an inventory of 85-99% of your UBC Electronic Services that exists in your Research IT Environment. Services are generally classified using the Electronic Service Risk Classification Model found in UBC ISS U1 sec 3.2. A process is in place to maintain the inventory, but completeness and updates are not consistently verified across all areas.

Implemented in all cases means you have an inventory of all your electronic services within your Research IT environment. All services are classified using the required risk model, and there is a defined process to ensure the inventory remains complete and current.

Reference Links​

• Security Classification of UBC Electronic Information and Services
• Sample Inventory:
• Case Studies in Risk Classification

Have you, or the Technical Owner for your Research IT Environment, initiated or planned to complete a Shared Responsibility Model to document all parties with responsibilities for these services?

Note: The Shared Responsibility Model is intended to be completed collaboratively with all identified parties, and helps clarify responsibilities for cybersecurity and service management.

Why is this Essential?

When responsibility for a service, such as a cloud platform or research instrument, is shared across multiple parties or vendors, a security task such as patching or access review may be assumed to be someone else's responsibility and, as a result, not performed by anyone. Documenting responsibility for each task through a Shared Responsibility Model reduces this risk, helping to prevent unpatched vulnerabilities and unmanaged access.

Instructions​

Below is a link for a Shared Responsibility Model template. This template is intended to assist you, or the Technical Owner for your Research IT Environment, in documenting which parties or individuals are responsible for the technical tasks involved in providing a UBC Electronic Service. The template may be completed collaboratively with the service's Technical Owner. You are welcome to repurpose it, customize it to include more information depending on your requirements, and/or circulate it with others to whom you think it might benefit.
Shared Responsibility Model Template

Guidance for Selecting a Response​

A Shared Responsibility Model is a document that enumerates the tasks involved in managing services and systems and it documents the parties/organization/individuals responsible for those tasks. UBC requires this document for Very High Risk systems or services and recommends it for all other UBC Electronic Services. More information about risk classification of UBC Electronic Services can be found in section 3.2 of UBC ISS U1.

Click here for the template with case studies.

Reference Links​

• Shared Responsibility Model for UBC Electronic Services Template
• Security Classification of UBC Electronic Information and Services

To what extent are CISO-approved Endpoint Detection and Response (EDR) solutions or, where not technically possible, up-to-date anti-malware and spyware software installed on all servers and workstations within your Research IT Environment?

Control or Process Description​

CISO-approved Endpoint Detection and Response (EDR) software must be installed on all UBC-owned servers, with anti-tamper protection enabled where technically possible. The same applies to UBC-owned workstations and research workstations, where technically possible. Where EDR installation is not technically possible on a device, up-to-date anti-malware and spyware software must be installed instead, configured to update at least once per day, with anti-tamper protection enabled where technically possible.

Why is this Essential?

Without EDR or up-to-date anti-malware on your servers and workstations, malware or an intruder can operate undetected within your Research IT Environment, putting research data, unpublished results, and connected instruments at risk. EDR software allows UBC cybersecurity to detect and contain threats quickly, and to investigate what happened so similar incidents can be prevented in the future.

What is Acceptable?

All UBC-owned and non-UBC-owned servers, workstations, and devices used to conduct UBC business within your Research IT Environment have a CISO-approved EDR solution installed, or, where EDR isn't technically possible, up-to-date anti-malware and spyware software configured to update daily. Where EDR isn't technically possible, a variance is requested in consultation with the UBC IT and Cybersecurity teams.

Guidance for Selecting a Response​

For this question, Not implemented, or only on some cases means, you do not have a CISO-approved Endpoint Detection and Response (EDR) solutions on UBC-owned servers and workstations within your Research IT Environment. A computing, storage, or transmission device that is UBC-owned means these devices or systems are purchased using UBC funds, including research grants. For devices that are not UBC-owned, such as personal devices or devices owned by other institutions and you use these devices to conduct UBC business, select Not implemented if you do not have an up-to-date anti-malware and spyware software installed on these devices even though it is technically possible.

Partially implemented means 50-84% of your servers and workstations have a CISO-approved EDR or, where not technically possible, have an up-to-date anti malware and spyware software installed. For example, if only your UBC-owned servers and workstations have an EDR but personal devices used to conduct UBC business do not have an EDR, anti-malware or spyware software installed, select Partially implemented.

Believed to be implemented in most cases means that 85-99% of UBC-owned servers and workstations have a CISO-approved EDR. Additionally, 85-99% of non-UBC-owned devices used to conduct UBC business have either an EDR, anti-malware or spyware software installed.

Implemented in all cases all UBC-owned and non-UBC-owned servers, workstations, or devices conducting UBC business have a CISO-approved EDR or when technically not possible, anti-malware or spyware installed.

Reference Links​

• Securing Computing and Mobile Storage Devices/Media
• Endpoint Detection & Respose (Anti-Virus)

For UBC systems used in the Research IT environment where encryption is required, do you, at a minimum, have the following key management practices outlined below? 
• whenever a password or passphrase is used as, or to generate, a Key, it follows the standards defined in the Passphrase and Password Protection standard (U2); and 
• have a key recovery strategy in place that involves an approved escrow or other viable alternative (refer to Key Escrow Guideline).

Note, the scope of this question includes all servers, databases and applications hosted outside UBC's and UBC approved datacenter, cloud hosted systems such as servers on Compute Canada Cloud and AWS (IaaS) and PaaS based like platform.sh, etc.

Control or Process Description​

UBC systems within your Research IT Environment that require encryption, including servers, databases, and applications hosted outside UBC's data centers, such as cloud-hosted or platform services, must meet two key management practices:

• Where a password or passphrase is used to create an encryption key, it must follow the standards set out in the Passphrase and Password Protection standard
• A strategy must be in place to recover an encryption key if it is lost, corrupted, or destroyed, such as an approved key escrow service or another viable alternative, since data encrypted with a lost key cannot otherwise be decrypted

Why is this Essential?

If a password or passphrase used to generate an encryption key is weak or guessable, an attacker who obtains it can decrypt everything the key protects, undermining the encryption entirely. If a key is lost without a recovery strategy in place, the data it protects becomes permanently unrecoverable, which for research data can mean losing results, records, or participant information outright.

Instructions​

See the Passphrase and Password Protection standard and the Key Escrow Guideline for detailed requirements on encryption key generation and recovery.

What is Acceptable?

For every system within your Research IT Environment where encryption is required, including servers, databases, and applications hosted outside UBC's data centers, such as cloud-hosted or platform services, any password or passphrase used to generate an encryption key follows the Passphrase and Password Protection standard, and a key recovery strategy, such as an approved escrow service or another viable alternative, is in place.

Guidance for Selecting a Response​

Encryption key management practice is essential in preventing unauthorized access to sensitive information. It is important to have the password or passphrase used for the stated purpose not be guessable or susceptible to crack easily. Should keys be compromised, entire systems and data can be compromised.

If an encryption key is lost, corrupted or destroyed the only way to decrypt the data is through a process referred to as Key Recovery. Lack or absence of a key recovery strategy may result in data loss.

For this question, Not implemented means there is no consistent approach to encryption key management in the Research IT Environment.

Partially implemented means, 50-84% systems in the Research IT Environment follow key management practices.

Believed to be implemented in most cases means 85-99% systems in the Research IT Environment follow defined key management practices.

Implemented in all cases all systems in the Research IT Environment that use encryption follow defined key management practices, including compliant password or passphrase standards and a documented and consistently applied key recovery strategy.

Reference Links​

• Encryption Key Management
• Encryption Requirements
• Key Escrow

To what extent are digital certificates used in your Research IT Environment for client facing servers, applications, and services issued and configured in accordance with UBC cryptographic requirements?

Requirements include:
certificates used for securing Medium, High, or Very High Risk information during user transmission are issued by a trusted third-party certificate authority (CA) as part of a Public Key Infrastructure (PKI)

Control or Process Description​

Digital certificates used for client-facing servers, applications, and services within your Research IT Environment must be issued and configured according to UBC's cryptographic requirements. Specifically, any certificate used to secure Medium, High, or Very High Risk information during transmission to or from a user must be issued by a trusted third-party Certificate Authority (CA), as part of a Public Key Infrastructure (PKI).

Why is this Essential?

A digital certificate verifies the identity of a server or application and enables secure, encrypted communication with users. If a certificate isn't issued by a trusted third-party CA, users' browsers and devices can't reliably confirm they're connecting to your genuine service rather than an imposter, and the connection may be more vulnerable to interception. This matters especially when a certificate is protecting Medium, High, or Very High Risk information, such as participant or research data, in transit.

What is Acceptable?

All client-facing servers, applications, and services within your Research IT Environment use digital certificates issued by a trusted third-party Certificate Authority, as part of a Public Key Infrastructure, and configured in accordance with UBC's cryptographic requirements, consistently across the environment.

UBC cybersecurity team extends a service for procuring certificates. Certificates can be purchased through UBC's Enterprise account by contacting security@ubc.ca.

Guidance for Selecting a Response​

Digital certificates are used to secure communication between servers, applications, and users. They help ensure that information is protected when it is transmitted between systems.

For this question, consider whether digital certificates used in your Research IT Environment are issued and configured according to UBC cryptographic requirements, including use of trusted third-party certificate authorities as part of a Public Key Infrastructure (PKI) for securing Medium, High, or Very High Risk information during user transmission.

For this question, Not implemented means, digital certificates used in client-facing servers, applications, and services are largely not issued by trusted third-party certificate authorities.

Partially implemented means, 50-84% of client-facing servers, applications, and services use digital certificates issued by trusted third-party certificate authorities.

Believed to be implemented in most cases means, 85-99% of client facing servers, applications, or services use digital certificates issued by trusted third-party certificate authorities.

Implemented in all cases means, all client facing servers, applications, and services consistently use digital certificates issued by trusted third-party certificate authorities and are consistently configured in accordance with UBC cryptographic requirements.

Reference Links​

• Cryptographic Requirements
• Public Key Infrastructure (PKI)

To what extent are laptops and desktop computers in your Research IT Environment protected with Tier 1 or Tier 2 encryption (full disk and media-level encryption)?

Control or Process Description​

Laptop and desktop computers within your Research IT Environment that are used to access UBC Electronic Information and Systems, or that store UBC Electronic Information, must be encrypted. This applies whether the device is UBC-supplied or personally owned. Tier 1 encryption (full disk encryption) is required at a minimum. Where Tier 1 encryption isn't feasible due to operability or performance constraints, Tier 2 encryption (full volume encryption) is an acceptable alternative.

Why is this Essential?

If a laptop or desktop containing research data is lost or stolen, encryption prevents whoever finds it from being able to read the information stored on it. Without encryption, a stolen device can expose unpublished research, participant data, or other sensitive information directly, with no additional barrier protecting it. BC's Privacy Commissioner has also indicated that encrypting devices containing personal information is necessary to meet reasonable security expectations, making this a legal requirement.

Instructions​

To answer this question accurately, it helps to have an up-to-date inventory of the laptops and desktops in your Research IT Environment. UBC's minimum encryption standard is AES-128 bit encryption or equivalent; AES-256 bit encryption is recommended where feasible.

What is Acceptable?

All laptop and desktop computers within your Research IT Environment, whether UBC-supplied or personally owned, that are used to access or store UBC Electronic Information have Tier 1 encryption in place, or Tier 2 encryption where Tier 1 isn't feasible, applied consistently across every applicable device.

Guidance for Selecting a Response​

Encryption helps protect information stored on laptops and desktops in case of loss or theft. UBC requires Tier 1 (full disk) encryption for these devices. Where Tier 1 is not feasible, Tier 2 encryption (e.g., full volume like bitlocker or equivalent) is acceptable. These requirements apply to both UBC-owned and personally-owned devices used to access or store UBC Electronic Information.

For this question, Not implemented means <50% of the laptops and desktop computers in your Research IT Environment have Tier 1 or Tier 2 encryption in place. Devices are generally not protected with full disk or equivalent encryption.

Partially implemented means 50–84% of laptops and desktop computers in your Research IT Environment have Tier 1 encryption or Tier 2 encryption where Tier 1 is not feasible.

Believed to be implemented in most cases means you believe that 85–99% of laptops and desktop computers in your Research IT Environment have Tier 1 encryption or Tier 2 encryption where Tier 1 is not feasible.

Implemented in all cases means all laptops and desktop computers in your Research IT Environment have Tier 1 encryption, or Tier 2 encryption where Tier 1 is not feasible. Encryption is consistently applied across all applicable devices.

Reference Links​

• Device Encryption Requirements
• Storage Encryption Risk and Classification Model

When processing High or Very High-Risk Information, to what extent are web, application and database functions hosted separately, or a CISO approved variance requested/approved?

Control or Process Description​

When a web application processes High or Very High Risk information, the web, application, and database functions it relies on must either be hosted separately from one another, or, where separate hosting isn't feasible, compensating controls approved by the CISO must be implemented, appropriate to the level of risk.

Why is this Essential?

If web, application, and database functions all run on the same system, a single vulnerability, such as a flaw in the web interface, can give an attacker a direct path to the underlying database and the High or Very High Risk information it stores. Hosting these functions separately, or putting equivalent compensating controls in place, limits how far an attacker can move if one part of the system is compromised.

What is Acceptable?

All applications within your Research IT Environment that process High or Very High Risk Information have their web, application, and database functions hosted separately, or a CISO-approved variance with compensating controls in place where separate hosting isn't feasible. Where no such applications currently exist, this requirement is met by default, though awareness of it is maintained for any future application handling this level of risk.

Guidance for Selecting a Response​

Consider applications in your Research IT Environment that process High or Very High Risk Information. These applications must either:

• have web, application, and database functions hosted separately, or
• have a CISO-approved variance with appropriate compensating controls in place.

_Note: If there are currently no web applications and database function and/ or high or very high risk information being processed within your Research IT Environment that fall within the scope of this requirement, select Implemented in all cases and note this down in your response to question the subsequent description question. However, awareness of this requirement should exist to ensure future applications or changes are designed in accordance with this control or have an approved variance in place where required._

For this question, Not implemented, or only on some cases means that few or none of the web applications in your Research IT environment used to process high and very high risk information are hosted separately from database functions. A variance has also not been requested.

Partially implemented means 50–84% of applicable applications in your Research IT environment used to process high and very high risk information are hosted separately from database functions. A variance has also not been requested.

Believed to be implemented in most cases means 85%-99% of applicable applications have web, application, and database functions hosted separately, or have a CISO-approved variance in place where required.

Implemented in all cases means all applicable applications have web, application, and database functions hosted separately, or have a CISO-approved variance with compensating controls in place.

Reference Links​

• Security Architecture

To what extent do applications, or services in your Research IT Environment that transmit Medium, High, or Very High-Risk UBC Electronic Information comply with the following requirements? 
• all TLS communications must use Mozilla Security/ Server Side TLS recommendations (Intermediate) configuration https://wiki.mozilla.org/Security/Server_Side_TLS, and should use the Modern configuration where possible;
• information transmitted via other protocols (e.g., SSH) must be encrypted using a minimum of AES-256 bit Encryption with mutual authentication between the Server and User;
• known weak network protocols must be disabled

Control or Process Description​

Applications and services within your Research IT Environment that transmit Medium, High, or Very High Risk UBC Electronic Information must encrypt that transmission and meet three requirements:

• All TLS communications must use the Mozilla Intermediate configuration at minimum, and the Modern configuration where possible
• Information transmitted using other protocols, such as SSH, must be encrypted using a minimum of AES-256 bit encryption with mutual authentication between the server and user
• Known weak network protocols must be disabled

Why is this Essential?

Data in transit, such as research data being uploaded to a collaborator's server or transmitted between systems, can be intercepted if it isn't properly encrypted. An attacker able to intercept unencrypted or weakly encrypted transmissions can read or alter the information as it moves, exposing research data, participant information, or credentials. Meeting these transmission security requirements protects the confidentiality and integrity of your research information while it's in motion.

What is Acceptable?

All applications and services within your Research IT Environment that transmit Medium, High, or Very High Risk UBC Electronic Information meet all three transmission security requirements:

• TLS communications use at least the Mozilla Intermediate configuration
• other protocols such as SSH use a minimum of AES-256 bit encryption with mutual authentication, and
• known weak network protocols are disabled. This applies consistently across every applicable application and service.

Guidance for Selecting a Response​

Transmission of information in academia and research is a typical activity whether due to collaboration or moving of information from system or service to another for storage or processing. Most research related information falls under medium, high or very high risk classification and UBC has specific requirements for the transmission of these types of information.

For this question, Not implemented means few or none of the applications and services in your Research IT Environment meet the listed transmission security requirements.

Partially implemented means 50-84% of applications and services meet the listed transmission security requirements.

Believed to be implemented in most cases means 85-99% of applications and services meet the listed transmission security requirements.

Implemented in all cases means that all transmission requirements have been implemented in all applications and services within your Research IT environment.

Reference Links​

• Secure Transmission
• Security/Server Side TLS
• Mutual authentication

To what extent are all servers and services (e.g., web servers, web applications, FTP, etc.) in your Research IT Environment accessed exclusively through a controlled, boundary-protected interface (e.g., Network Firewall, security group, ACL, WAF), with a Web Application Firewall (WAF) required for systems transmitting, storing, or processing High or Very High-Risk Information and recommended for all other systems where technically possible?

Note: Vendor-delivered SaaS and PaaS solutions do not require a WAF unless recommended in a PIA or STRA.

Control or Process Description​

Servers and services within your Research IT Environment, such as web servers, web applications, and FTP, must be accessed exclusively through a controlled, boundary-protected interface, such as a network firewall, security group, access control list (ACL), or web application firewall (WAF), where technically possible. Additionally, internally developed or custom-built web applications that transmit, store, or process High or Very High Risk Information must be located behind an approved WAF; a WAF is recommended, though not required, for all other applications. Vendor-delivered SaaS and PaaS solutions don't require a WAF unless one is recommended through a Privacy Impact Assessment (PIA) or Security Threat Risk Assessment (STRA).

Why is this Essential?

A boundary-protected interface, such as a firewall, acts as a gatekeeper that only allows expected, legitimate traffic to reach your servers and services, blocking most unauthorized access attempts before they ever reach the system itself. It also provides an effective safeguard against vulnerabilities that don't yet have a patch available, known as zero-day vulnerabilities. For web applications handling your most sensitive research data, a Web Application Firewall adds a further layer of protection against attacks that specifically target web application weaknesses.

What is Acceptable?

All servers and services within your Research IT Environment are accessed exclusively through a controlled, boundary-protected interface, such as a network firewall, security group, ACL, or WAF. Additionally, every internally developed or custom-built web application that transmits, stores, or processes High or Very High Risk Information is located behind an approved Web Application Firewall.

Guidance for Selecting a Response​

For this question, Not implemented, or only on some cases means servers and services within your Research IT Environment are generally not accessed exclusively through a controlled boundary-protected interface (e.g., network firewall, security group, ACL, or WAF). Additionally, internally developed or custom-built web applications that transmit, store, or process High or Very High Risk Information generally do not use a Web Application Firewall.

Partially implemented means 50-84% of servers and services within your Research IT Environment are accessed exclusively through a controlled boundary-protected interface. Additionally, between 50–84% of internally developed or custom-built web applications that transmit, store, or process High or Very High Risk Information use a Web Application Firewall.

Believed to be implemented in most cases means 85–99% of servers and services within your Research IT Environment are accessed exclusively through a controlled boundary-protected interface. Additionally, between 85–99% of internally developed or custom-built web applications that transmit, store, or process High or Very High Risk Information use a Web Application Firewall.

Implemented in all cases means all servers and services within your Research IT environment are accessed exclusively through a controlled boundary-protected interface like a network firewall, security group, Access Control List or Web Application Firewall. Additionally, all internally developed or custom-built web applications that are transmitting, storing or processing high or very high risk information have a Web Application Firewall in use.

Reference Links​

• Secure Access

To what extent do privileged users in your Research IT Environment access all remote servers (e.g., SSH servers, Remote Instrument Control and Monitoring) using either of the following methods?

a Privileged Access Management (PAM) proxy service (preferred), limited access VPN pool, bastion host, or reverse remote protocol proxy.

Control or Process Description​

Privileged Users who access remote servers within your Research IT Environment, such as SSH servers or remote instrument control and monitoring systems, from outside the UBC network must do so using one of the following methods:

• A Privileged Access Management (PAM) proxy service (preferred)
• A limited access VPN pool
• A bastion host
• A reverse remote protocol proxy

Note, this control applies specifically to Privileged Users.

Why is this Essential?

Privileged accounts have greater access than regular accounts, so if a privileged user connects to a remote server directly, without going through a controlled access point, an attacker who compromises that connection gains a more direct and more damaging path into your Research IT Environment. Requiring remote privileged access to go through a PAM proxy, VPN pool, bastion host, or reverse remote protocol proxy adds a monitored checkpoint between the privileged user and the systems they're connecting to, making it easier to detect and limit unauthorized access.

Instructions​

A Privileged Account provides a significantly greater level of access to a system or application than a regular User Account, and is generally restricted to IT Support Staff. Are you, or are there other users in your Research IT Environment, accessing remote servers with this kind of elevated access? If so, this control applies to you.

What is Acceptable?

All privileged users access remote servers within your Research IT Environment, such as SSH servers or remote instrument control and monitoring systems, exclusively through a Privileged Access Management (PAM) proxy service, a limited access VPN pool, a bastion host, or a reverse remote protocol proxy. Direct privileged remote access outside these methods is not used, without exception.

Guidance for Selecting a Response​

Users within research teams may need to access systems within the Research IT environment remotely either to access SSH servers or control and monitor an instrument, etc. This is often done through technologies like RDP, SSH, VNC, VDI, terminal services etc.

For privileged users, when remotely accessing systems and services within your Research IT environment from a non UBC network, UBC requires that their remote access be through a Privileged Access Management (PAM) proxy service (preferred), limited access VPN pool, bastion host, or reverse remote protocol proxy.

For this question, Not implemented, or only on some cases means Privileged users generally do not use approved secure remote access methods when accessing systems in the Research IT Environment. Remote access is largely direct or inconsistent with the required access methods.

Partially implemented means 50–84% of privileged users access systems in the Research IT Environment using approved secure remote access methods. Additionally, select Partially implemented if privileged users use approved secure remote access methods only 50-84% of the time.

Believed to be implemented in most cases means 85%-99% of your Privileged Users access the systems and services in your Research IT environment using approved secure remote access methods. Additionally, privileged users use approved secure remote access methods only 85-99% of the time.

Implemented in all cases means all privileged users access systems in the Research IT Environment using approved secure remote access methods. Direct privileged remote access outside these methods is not used.

Reference Links​

• Remote Access - Privileged

To what extent do all remote users in your Research IT Environment access all remote servers (e.g., SSH servers, Remote Instrument Control and Monitoring) using either of the following methods?
• a VPN, bastion host, or reverse remote protocol proxy

Control or Process Description​

Users who access remote servers within your Research IT Environment, such as SSH servers or remote instrument control and monitoring systems, from outside the UBC network must do so using one of the following methods:

• a VPN
• a bastion host
• a reverse remote protocol proxy

Note, this control applies specifically to regular Users, not Privileged Users

Why is this Essential?

If a user connects to a remote server directly, without going through a controlled access point, an attacker who compromises that connection gains a more direct path into your Research IT Environment. Requiring remote access to go through a VPN, bastion host, or reverse remote protocol proxy adds a monitored checkpoint between the user and the systems they're connecting to, making it easier to detect and limit unauthorized access.

Instructions​

A User Account gives access to UBC Systems for standard, day-to-day activities. Are you, or are there other users in your Research IT Environment, accessing remote servers without elevated or administrative access? If so, this control applies to you.

What is Acceptable?

All users access remote servers within your Research IT Environment, such as SSH servers or remote instrument control and monitoring systems, exclusively through a VPN, a bastion host, or a reverse remote protocol proxy. Direct remote access outside these methods is not used, without exception.

Guidance for Selecting a Response​

Users within research teams may need to access systems within the Research IT environment remotely either to access SSH servers or control and monitor an instrument, etc. This is often done through technologies like RDP, SSH, VNC, VDI, terminal services etc.

For regular users, when remotely accessing systems and services within your Research IT environment from a non UBC network, UBC requires that their remote access be through a VPN, bastion host, or reverse remote protocol proxy.

For this question, Not implemented, or only on some cases means users generally do not use approved secure remote access methods when accessing systems in the Research IT Environment. Remote access is largely direct or inconsistent with the required access methods.

Partially implemented means 50–84% of users access systems in the Research IT Environment using approved secure remote access methods. Additionally, select Partially implemented if users use approved secure remote access methods only 50-84% of the time.

Believed to be implemented in most cases means 85%-99% of your users access the systems and services in your Research IT environment using approved secure remote access methods. Additionally, users use approved secure remote access methods only 85-99% of the time.

Implemented in all cases means all users access systems in the Research IT Environment using approved secure remote access methods. Direct remote access outside these methods is not used.

Reference Links​

• Remote Access - Users

To what extent do all servers (which may include host desktops and laptops), that should not be broadly accessible to users (e.g., databases) meet the following requirements:
• controlled by the Principle of Least Privilege, 
• strictly limiting connectivity to securely-managed and 
• explicitly approved subnets or IP address ranges necessary for their operational function 
• Client-facing servers and services are logically separated from non-client facing servers and services

Control or Process Description​

Servers and services that shouldn't be broadly accessible to users, such as database servers, must be logically separated from client-facing servers and services, those that users can access directly or broadly, whether through the internet, UBC wireless, or the UBC VPN pool. Network access to these non-client-facing servers must be controlled using the Principle of Least Privilege, strictly limiting connectivity to securely managed and explicitly approved subnets or IP address ranges necessary for their operational function.

Why is this Essential?

If a non-client-facing server, such as a database holding your research data, isn't separated from client-facing systems and network access to it isn't tightly restricted, an attacker who compromises a more exposed, client-facing system can move directly to that database. Logically separating these systems and limiting network access to only what's operationally necessary reduces how far an attacker can reach if one part of your Research IT Environment is compromised.

What is Acceptable?

All non-client-facing servers and services within your Research IT Environment, including those hosted in the cloud, are configured with network access controlled by the Principle of Least Privilege, strictly limiting connectivity to securely managed and explicitly approved subnets or IP address ranges necessary for their operational function. Client-facing and non-client-facing servers and services are logically separated across the environment.

Guidance for Selecting a Response​

Client-facing servers are systems and services that users can directly or broadly access either through the internet, UBC wireless, or the UBC VPN pool. Some systems and services, like database servers, require more controls or access restrictions due to the potential impact on the security of network, system, services or information stored or transmitted within these. Non-client facing servers are systems and services that are not broadly accessible. Security control requirements specific to non-client facing servers include:

• controlled by the Principle of Least Privilege,
• strictly limiting connectivity to securely-managed and

explicitly approved subnets or IP address ranges necessary for their operational function,

• logical separation between non-client facing servers and services and client-facing servers and services.

For this question, Not implemented, or only on some cases means there is no consistent approach to separating client-facing and non-client-facing systems, and network access to internal systems is not reliably restricted. Least privilege access controls are generally not applied, or are applied inconsistently across the Research IT Environment. This includes non-client facing systems and services hosted in the cloud.

Partially implemented means 50–84% of non-client-facing systems are configured with restricted network access based on least privilege principles, and some level of logical separation exists between client-facing and non-client-facing systems. This includes non-client-facing systems and services hosted in the cloud.

Believed to be implemented in most cases means 85–99% of non-client-facing systems are configured with least privilege network access controls, and client-facing and non-client-facing systems are generally logically separated. This includes non-client facing systems and services hosted in the cloud.

Implemented in all cases means all non-client-facing systems are configured with least privilege network access controls, and client-facing and non-client-facing systems are logically separated across the Research IT Environment. Network access is consistently restricted to approved subnets or IP ranges based on operational need. This includes non-client facing systems and services hosted in the cloud.

Reference Links​

• Non-Client-facing Servers & Services

To what extent do remote access connections to desktops, laptops, servers, and software applications in your Research IT Environment use Multi-Factor Authentication (MFA), where technically possible, across all supported technologies (e.g., Remote Access Gateway, RDP, SSH, VNC, VDI, terminal services, VPN)?

Note: it is acceptable to have a single MFA point rather than requiring MFA for every authentication e.g., by only remotely accessing everything via a MFA protected VPN pool.

Control or Process Description​

Where technically possible, servers and software applications within your Research IT Environment must be protected by Multi-Factor Authentication (MFA). This includes remote access connections made through technologies such as RDP, SSH, VNC, VDI, terminal services, or VPN. It's acceptable to enforce MFA at a single, central access point, such as a VPN, rather than requiring it separately for every individual system reached through that point.

Why is this Essential?

Attackers routinely attempt to guess or steal user credentials through automated password-guessing attacks and phishing. MFA adds a second layer of verification beyond a password, so even if a password is compromised, that alone isn't enough to gain access. Requiring MFA on servers, applications, and remote access connections closes off one of the most common ways attackers gain a foothold in a system.

What is Acceptable?

MFA is enabled, where technically possible, for all servers, software applications, and remote access connections within your Research IT Environment, across every supported technology, including RDP, SSH, VNC, VDI, terminal services, and VPN. This can be enforced through individual systems or through a centralized access point, such as an MFA-protected VPN, and is applied consistently as standard practice.

Guidance for Selecting a Response​

Multi-Factor Authentication (MFA) means requiring more than one method to verify a user’s identity when accessing systems. This is typically something you know (e.g., password) and something you have (e.g., phone, token, or authentication app). MFA can be applied directly to systems or through a central access point such as a VPN.

For this question, Not implemented, or only on some cases means MFA is not used for accessing servers, software applications, or remote access connections in your Research IT Environment, even where it is technically possible.

Partially implemented means 50–84% of access to servers, software applications, and remote access connections use MFA where technically possible. MFA may be enabled for certain systems or access methods (e.g., VPN), but is not consistently applied across all applicable access points.

Believed to be implemented in most cases means 85–99% of access to servers, software applications, and remote access connections use MFA where technically possible. MFA is generally in place (e.g., through a central VPN or key systems), but not all access points may be fully verified or consistently enforced.

Implemented in all cases means all access to servers, software applications, and remote access connections use MFA where technically possible. MFA is consistently applied across all supported technologies, including through centralized solutions (e.g., MFA-protected VPN), and is required as a standard practice.

Reference Links​

• Multi-Factor Authentication for Remote Access

To what extent are information in and about your research IT environment backed up?
Note: For this question, information means research information, configuration of your servers and services?

Control or Process Description​

Research information stored or processed within your Research IT Environment must be regularly backed up to a secure location and checked periodically, preferably quarterly, to confirm it can be restored. This also applies to configuration details for the systems and services within your Research IT Environment, such as screenshots, exports of configuration settings, or configuration scripts, which should be regularly backed up to a secure location as well.

Why is this Essential?

Hardware failure, malware, accidental deletion, or a natural disaster can all result in the loss of research data or system configurations with no warning. Without a backup, that loss can be permanent, potentially costing months or years of research work. Regularly checking that backups can actually be restored is just as important as making them; a backup that can't be restored when needed provides no real protection.

Instructions​

To answer this question accurately, it helps to have an inventory of the systems and services within your Research IT Environment. See the Backup Guideline for more information on backup and restore testing best practices.

What is Acceptable?

All research information stored or processed within your Research IT Environment is regularly backed up to a secure location, and these backups are checked periodically, preferably quarterly, to confirm they can be restored. Configuration information for all systems and services within your Research IT Environment are also regularly backed up to a secure location.

Guidance for Selecting a Response​

Backups of information are essential in limiting the impact of information loss. Regularly checking these backups is important to ensure that the information can be restored. Maintaining and regularly checking information backups is a UBC requirement. Additionally, it is recommended that you maintain a regular backup of the configuration details of the systems and services within your Research IT environment. When answering this question, think about the back ups for both your research information as well as the configuration details of the systems and services within your research IT environment.

For this question, Not implemented, or only on some cases means you do not have and/ or regularly save backups of the information stored or processed within your Research IT environment to a secure location. You also do not generally backup the information about the configuration of your systems and services within your Research IT environment.

Partially implemented means you have 50-84% of information within the systems and services in your Research IT environment is backed up to a secure location. Additionally, 50-84% of your systems and services have their configuration information backed up.

Believed to be implemented in most cases means you have 85%-99% of information within the systems and services in your Research IT environment backed up to a secure location. Additionally, 85-99% of your systems and services have their configuration information backed up to a secure location.

Implemented in all cases means you have and regularly save backups of all the information stored or processed within your Research IT environment to a secure location. Additionally, all your systems and services have their configuration information backed up to a secure location.

Reference Links​

• Securing Computing and Mobile Storage Devices/Media
• Securing Internet of Things (IoT) Devices
• Vulnerability Management
• Backups

To what extent do you test and periodically verify, preferably quarterly, the recoverability and integrity of your backups?
For this question, consider the information you backup as you noted in the previous question (Backup Process).

Control or Process Description​

Backups of research information, and of configuration details for systems and services within your Research IT Environment, must be periodically tested, preferably quarterly, to verify they can be successfully restored and that the information they contain is intact and complete.

Why is this Essential?

An untested backup may not restore successfully; the backup file could be corrupted, incomplete, or the result of a process that failed silently. Testing recoverability confirms the backup can be restored and the information is complete, before that confirmation is needed during an actual incident.

What is Acceptable?

All backups of research information, and of configuration details for systems and services within your Research IT Environment, are periodically tested, preferably quarterly, to confirm they can be successfully restored and that the information is complete and intact. This testing is applied consistently across every system and service, without exception.

Guidance for Selecting a Response​

For this question, Not implemented means you do not periodically (preferably quarterly) test the recoverability of your backups and you do not verify their integrity and availability.

Partially implemented means, of the information you back up, you periodically test the recoverability and verify the integrity and availability of 50–84% of the information. Select "partially implemented" if you only test and verify the backups from or about 50-84% of your systems and services.

Believed to be implemented in most cases means, of the information you back up, you periodically test the recoverability and verify the integrity and availability of 85-99% of the information. Select Believed to be implemented in most cases if you only test and verify the backups from or about 85-99% of your systems and services. Additionally, there may be occasional gaps in coverage or verification frequency.

Implemented in all cases means of the information you back up, you periodically test the recoverability and verify the integrity and availability of all of the backup information. You also test and verify the backups from or about all of your systems and services. Backup and verification practices are consistently applied across the environment.

Reference Links​

• Securing Computing and Mobile Storage Devices/Media
• Securing Internet of Things (IoT) Devices
• Backup Guidelines

To what extent is logging enabled in your Research IT Environment to capture the following key activities?
• user login, logout and access to a resource; 
• action performed by the User and the time it was performed; and 
• where feasible, any access to, or modification of, records.

Control or Process Description​

Logging must be enabled within your Research IT Environment to capture three key activities:

• User login, logout, and access to a resource
• The action performed by the User and when it was performed
• Where feasible, any access to or modification of records

This applies to systems and services you manage directly, as well as those managed by a service provider or vendor on your behalf.

Why is this Essential?

A log is a record of the events occurring within a system. If research data is accessed or modified without authorization, logs identify what was affected and by whom, which is often the only way to reconstruct what happened after a breach. Without logging, an incident can go unnoticed entirely, or leave no trail to investigate once it's discovered. Maintaining reliable logs strengthens the ability to detect and investigate incidents when they occur.

What is Acceptable?

Logging is enabled across all systems and services within your Research IT Environment, whether you manage them directly or they're managed by a service provider or vendor on your behalf, and captures User login, logout, and resource access; the action performed and when it was performed; and, where feasible, any access to or modification of records. This applies consistently across every applicable system and service.

Guidance for Selecting a Response​

Effective Logging & Monitoring procedures provide ongoing assurance that the information and systems and services within your Research IT environment are secure. These logs are also useful when investigating a security event.

Often, you may also be asked by stakeholders (e.g. Health Canada) for a project information validation, which may include information about record modification and the corresponding user who made the change.

For this question, consider both systems and services that you manage as well as those you use but are managed by a service provider/vendor.

Not implemented means you do not generally log the activities noted above.

Partially implemented means you either only log some of the activities noted above, or you only log these activities for 50-84% of systems and services.

Believed to be implemented in most cases means you log all of the activities noted above for 85%-99% of systems and services.

Implemented in all cases means you log all of the activities noted above for all systems and services within your Research IT environment.

Reference Links​

• Logging and Monitoring of UBC Systems

Do the servers in your Research IT Environment meet the following logging requirements? 
• logs are retained for at least 90 days and regularly backed up whenever possible, preferably to offsite secure storage; 
• logs are retrievable in a timely manner if they are required for analysis; and 
• logs are protected against unauthorized access and modification, preferably by locating them on a separate server outside the environment, such as a Database Server protected by a firewall, and restricting access as necessary; 
• no-one is allowed to change or delete log information

Control or Process Description​

Logs from servers within your Research IT Environment must meet three requirements. They must be retained for at least 90 days and regularly backed up, preferably to offsite secure storage. They must be retrievable in a timely manner if needed for analysis. And they must be protected against unauthorized access and modification, preferably by locating them on a separate server outside the environment, such as a database server protected by a firewall, with access restricted so that no one can change or delete log information.

Why is this Essential?

Log data is essential for managing and troubleshooting systems, and for responding to a security incident, an investigation depends on having logs that are complete, accessible, and haven't been tampered with. If logs aren't retained long enough, can't be retrieved quickly, or can be altered or deleted by anyone with access, they lose their value exactly when they're needed most, during an incident investigation or audit.

What is Acceptable?

Logs for all applicable servers within your Research IT Environment are retained for the required period, using UBC myLogs where possible or a secure alternative, protected against unauthorized access or modification, and retrievable in a timely manner when needed. This applies consistently across every applicable system.

Guidance for Selecting a Response​

System logs refer to records generated by systems and applications that can be used to identify system activity and security-related events. These logs must be retained, accessible when needed, and protected against unauthorized access or modification.

For this question, Not implemented means, logs are not in place for servers in your Research IT Environment.

Partially implemented means, 50-84% of servers meet the logging requirements.

Believed to be implemented means, 85-99% of servers meet the logging requirements.

Implemented in all cases means, logs are retained for the required period (myLogs or secure alternative), protected against unauthorized access or modification, and retrievable when needed across all applicable systems.

Reference Links​

• Logging and Monitoring of UBC Systems

To what extent are IT Support Staff responsible for managing your Research IT Environment aware that system logs should be monitored to determine the use of system resources, detect information security events (e.g., failed logons, simultaneous logins from different geographic locations, escalation of privilege, attacks against systems, etc.) and, when appropriate, configured to generate alerts to the IT Support Staff?

Control or Process Description​

IT Support Staff responsible for managing your Research IT Environment must be aware that system logs should be monitored to determine the use of system resources and detect information security events, such as failed logons, simultaneous logins from different geographic locations, escalation of privilege, or attacks against systems. Where appropriate, monitoring software should be configured to send alerts to IT Support Staff when these events occur.

Why is this Essential?

Without monitoring, a security event such as a failed login pattern, an escalation of privilege, or a login from an unexpected location can go unnoticed and undetected for a long time. Configuring alerts for these events allows IT Support Staff to respond quickly, before an intrusion has a chance to cause further damage.

What is Acceptable?

IT Support Staff responsible for managing your Research IT Environment are aware that system logs must be monitored for security-related events, and monitoring software is configured to send alerts when appropriate. This monitoring and alerting is applied consistently across all applicable servers within your Research IT Environment.

Guidance for Selecting a Response​

For this question, system logs refer to records generated by systems and applications that can be used to identify system activity and security-related events. IT Support Staff are responsible for understanding and enabling appropriate monitoring of these logs, including alerting when security-relevant events occur.

ISS M8 - Logging and Monitoring of UBC Systems

Not implemented, or only on some cases means, IT Support Staff responsible for managing the Research IT Environment are generally not aware that system logs should be monitored for security-related events or configured to generate alerts. Log monitoring and alerting activities occur rarely or inconsistently.

Partially implemented means 50–84% of servers in the Research IT Environment have logs monitored and alerts configured when appropriate. While some systems are monitored, this is not consistently understood or applied across the environment.

Believed to be implemented in most cases means Logs are generally monitored and alerts are sent for significant events for 85–99% of servers, but monitoring and verification processes are not fully formalized or consistently applied.

Implemented in all cases means, logs are actively monitored, alerts are automatically generated for relevant events, and monitoring processes are documented, tracked, and consistently followed across the Research IT Environment.

Reference Links​

• Logging and Monitoring of UBC Systems

To what extent are all servers with High or Very-High Risk Information in your Research IT Environment hosted in secure datacenters? Secure datacenters are: 
• Core UBC datacenters; 
• UBC approved service, e.g., EduCloud;
• Other solution provider datacenters approved by the CISO; 
• Departmentally managed datacenters which meet the essential physical security requirements (see instructions in link below)

Control or Process Description​

Servers within your Research IT Environment that store High or Very High Risk information must be hosted in a secure datacenter. This includes core UBC datacenters, a UBC-approved service such as EduCloud, another solution provider datacenter approved by the CISO, or a departmentally managed datacenter that meets the essential physical security requirements set out in the Physical Datacenter Controls checklist.

Why is this Essential?

A server hosting High or Very High Risk information in an uncontrolled physical location, such as an unlocked office or a shared lab space, is vulnerable to theft, tampering, or unauthorized physical access. Anyone with physical access to the server can potentially remove the drive, copy the data directly, or bypass network-level security controls entirely. Hosting these servers in a secure datacenter, with controlled physical access, closes off this attack path.

Instructions​

To evaluate whether a departmentally managed server or datacenter meets the required physical security standards, use the Physical Datacenter Controls (must-have) Checklist.

What is Acceptable?

All servers within your Research IT Environment that store High or Very High Risk information are hosted in a secure datacenter, whether a core UBC datacenter, a UBC-approved service such as EduCloud, a CISO-approved third-party datacenter, or a departmentally managed datacenter confirmed to meet the essential physical security requirements. This applies consistently across every applicable server.

Guidance for Selecting a Response​

For this question, servers include all systems in the Research IT Environment that store High or Very High Risk information. Secure datacenters include Core UBC datacenters, CISO-approved third-party datacenters, and departmental datacenters that have been evaluated to meet required physical security requirements.

_Please use the checklist (link below) of must-have controls for UBC data centers to evaluate if the departmentally managed servers or data centers meet essential physical security requirements.
Physical Datacenter Controls(must have) Checklist_

Not implemented, or only on some cases means servers storing High or Very High Risk information are not hosted in secure datacenters. Many applicable servers are hosted in locations that do not meet the defined secure hosting requirements.

Partially implemented means between 50–84% of servers storing High or Very High Risk information are hosted in secure datacenters. Some systems are hosted in approved environments such as Core UBC data centres.

Believed to be implemented in most cases means between 85–99% of servers storing High or Very High Risk information are hosted in secure datacenters. Secure hosting is generally in place across the Research IT Environment.

Implemented in all cases means all servers hosting High or Very High Risk Information are in secure datacenters. Security requirements are consistently met across all hosting scenarios, including departmental datacenters, with monitoring, access control, and protections fully in place.

Reference Links​

• Physical Security of UBC Data Centres

To what extent are all servers in your Research IT Environment—on-premise, public cloud, or private cloud (e.g., AWS, Azure) protected by a DNS firewall?

Note: 
• a DNS firewall serves a separate function to a network firewall
• For Educloud and standalone physical servers this is achieved by using the UBC DNS service. Virtual servers provisioned by UBC IT will use this service by default, unless reconfigured. 
• Infrastructure as a service (AWS, Azure etc.) servers require different approaches to put a DNS firewall in place.

Control or Process Description​

Servers within your Research IT Environment, whether on-premises or in a public or private cloud such as AWS or Azure, must be protected by a DNS firewall. On-premises and standalone physical servers achieve this by using UBC's DNS service; virtual servers provisioned by UBC IT use this service by default unless reconfigured. Servers hosted in Infrastructure as a Service environments require a different approach to put DNS firewall protection in place.

Why is this Essential?

DNS firewall is a preventive control that stops malicious internet connections before they occur. It blocks known or found Indicators of Compromise (IoC) and prevents malicious domain access across UBC's systems.

Instructions​

A DNS firewall serves as a separate function to that of a network firewall. A DNS Firewall is a network security solution that prevents network users and systems from connecting to known malicious Internet locations, using available threat intelligence to block known bad locations. Some examples of DNS firewall are Cisco Umbrella, CIRA DNS Firewall, Cloudflare DNS Firewall, Route 53 Resolver DNS Firewall by AWS, and enhanced DNS features in Azure Firewall.

What is Acceptable?

All servers within your Research IT Environment, whether on-premises, virtual, or hosted in a public or private cloud such as AWS or Azure, are protected by a DNS firewall appropriate to their environment. This protection is applied consistently across every server, using UBC's DNS service where applicable or an equivalent approach for cloud-hosted servers.

Guidance for Selecting a Response​

For this question, Not implemented, or only on some cases means devices and servers are not protected by a DNS firewall or use UBC's DNS service (MyDNS) that offers this protection by default.

Partially implemented means DNS firewall protection is applied to 50–84% of servers or devices across on-premise and cloud environments.

Believed to be implemented in most cases means DNS firewall protection is in place for 85–99% of servers or devices used in research environment, across on-premise and cloud environments.

Implemented in all cases means means all servers in the Research IT Environment are protected by DNS firewall controls appropriate to their environment (on-premise, cloud, or virtual). DNS filtering is consistently applied across all systems, and the approach is maintained across the environment.

Reference Links​

• Automatic Blocking of Malicious Websites
• UBC DNS and Network Settings
• myDNS System Overview
• Cisco Umbrella

To what extent are all systems in your Research IT Environment that are storing Medium, High or Very High-Risk information protected by a network firewall (e.g., Cisco Virtual Context ASA firewall)?

Control or Process Description​

UBC Systems within your Research IT Environment that store Medium, High, or Very High Risk information must be protected by a network firewall, such as a Cisco Virtual Context ASA firewall.

Why is this Essential?

A network firewall adds a layer of defense that works alongside other protections, such as anti-virus software and regular patching, to protect systems storing sensitive information. It blocks automated scans from finding your system and prevents someone from gaining a direct, unmonitored access to it. Firewalls also provide an effective compensating control for many types of vulnerabilities for which patches are not readily available; these are known as zero-day vulnerabilities.

Instructions​

If a network-based firewall is needed for your Research IT Environment, UBC IT provides a Virtual Firewall Service. A Firewalls Guideline, focused on host-based firewalls, is also available to supplement the Securing Computing and Mobile Storage Devices/Media standard. If you do not manage a firewall, it is highly likely that your firewall contexts are supported or managed by your department's IT or UBC IT; you can reach out to the respective IT support team for additional information.

What is Acceptable?

All UBC Systems within your Research IT Environment that store Medium, High, or Very High Risk information are protected by a network firewall. This applies consistently across every applicable system, whether on-premises or hosted in the cloud.

Guidance for Selecting a Response​

For this question, systems include servers and services within the Research IT Environment that store Medium, High, or Very High Risk information. The focus is on whether these systems are protected by a network firewall as part of their network architecture.

Not implemented, or only on some cases means systems storing Medium, High, or Very High Risk information are generally not placed behind a network firewall. Firewall protection is absent for most applicable systems, or is applied inconsistently.

Partially implemented means 50–84% of systems storing Medium, High, or Very High Risk information are placed behind a network firewall. Firewall protection is applied in parts of the Research IT Environment.

Believed to be implemented in most cases means 85–99% of systems storing Medium, High, or Very High Risk information are placed behind a network firewall. Firewall protection is generally in place across the Research IT Environment.

Implemented in all cases means all systems storing Medium, High, or Very High Risk information are placed behind a network firewall. Firewall protection is consistently applied across the Research IT Environment, with no known gaps.

Reference Links​

• Network Firewall Architecture
• Firewalls Guideline
• UBC IT Virtual Firewall Service

To what extent are rules for all network firewalls in your Research IT Environment reviewed at least annually and configured to meet the following requirements? 
• a “Deny by Default” policy must be implemented on all firewalls; 
• enabled "Any-Any-Allow" rules must not exist anywhere in the rule set;
• ports for services that are not required or have no corresponding service on destination hosts must be denied, e.g., TCP/443 (HTTPS) or TCP/22 (SSH); 
• firewalls must use ingress filtering and should use egress filtering if it is used to protect High or Very High-Risk Information; 
• ACLs must restrict traffic to the minimum necessary to conduct University Business; 
• If a Firewall is a single point of ingress and it fails, it must fail in a closed state and not allow passage of data traffic through it; 
• firewalls are capable of “stateful packet inspection” and this capability is permanently turned on. 
• All Firewall critical alarms must generate an automatic notification to the Firewall administrator;
• Firewalls must be hardened, patched and scanned in accordance with the Vulnerability Management standard.

Control or Process Description​

Rules for all network firewalls within your Research IT Environment must be reviewed at least annually and configured to meet the following baseline requirements:

• Deny traffic by default
• No enabled "Any-Any-Allow" rules exist anywhere in the rule set
• Ports for services that aren't required, or have no corresponding service on the destination host, are denied
• Ingress filtering is used at a minimum, and egress filtering as well if the firewall protects High or Very High Risk information
• Access Control Lists (ACLs) restrict traffic to the minimum necessary for University business
• If a firewall is a single point of ingress and it fails, it fails closed, rather than allowing traffic through
• Stateful packet inspection is used and permanently enabled
• All critical alarms generate an automatic notification to the firewall administrator
• Firewalls are hardened, patched, and scanned in accordance with the Vulnerability Management standard

Why is this Essential?

Firewalls are only as effective as their Access Control List (ACL) rule set, which determines how network traffic is blocked or passed. An outdated or overly permissive rule set, such as an unused open port or an overly broad allow rule, is a common gap identified through automated network scanning, providing a direct path for unauthorized access. Configuring firewalls in accordance with UBC's Vulnerability Management Standards and reviewing rules at least annually reduces this risk by limiting the network paths available to an attacker.

What is Acceptable?

Rules for all network firewalls within your Research IT Environment meet all of the baseline requirements described above, and are reviewed at least annually across every firewall, without exception.

Guidance for Selecting a Response​

For this question, Network firewall rules control how traffic is allowed or blocked between systems. This includes how rules are configured, how restrictive they are, and whether they are reviewed regularly.

Not implemented, or only on some cases means Firewall rules are largely not configured to meet the listed requirements. Controls such as “deny by default,” restricting unnecessary access, or regular rule reviews are not configured, or are applied in a very limited or inconsistent way. Only a small portion of the requirements may be in place, and practices vary significantly across the Research IT Environment.

Partially implemented means that there is 50–84% confidence that current configuration meet some of the listed requirements, but not all. Required practices such as rule restriction, configuration standards, or annual reviews are applied in parts of the environment, but there are clear gaps in coverage and consistency.

Believed to be implemented in most cases means there is 85–99% Firewall rules are configured to meet all prescribed requirements. Configurations generally follow expected practices and reviews are performed, but not all requirements may be consistently verified or enforced.

Implemented in all cases means Firewall rules for all firewalls meet the listed requirements. Rules are consistently configured to restrict access appropriately, reviewed at least annually, and all required controls are applied across the Research IT Environment.

Reference Links​

• Network Firewall Rules
• Firewalls Guideline
• UBC IT Virtual Firewall Service
• Vulnerability Management

To what extent do all devices in your Research IT Environment, including servers, laptops/desktops, and devices controlling research equipment, run operating system versions for which security updates continue to be produced or an approved variance is in place?

Control or Process Description​

All devices within your Research IT Environment, including servers, laptops, desktops, and devices controlling research equipment, must run an operating system version for which security updates continue to be produced. Where a device is at end of life and security updates and patches are no longer available from the vendor, the system must either be upgraded, or a variance with CISO-approved compensating controls must be in place.

Why is this Essential?

An operating system that no longer receives security updates stops getting fixes for newly discovered vulnerabilities, leaving it permanently exposed to any vulnerability found after support ends. Attackers specifically target out-of-support systems because these known weaknesses will never be patched, making them a comparatively easy way to gain access to research data or connected equipment.

What is Acceptable?

All devices within your Research IT Environment, including servers, laptops, desktops, and devices controlling research equipment, run operating system versions that continue to receive security updates. Where a device is running an unsupported operating system, an approved variance with compensating controls is in place. This applies consistently across every device.

Guidance for Selecting a Response​

For this question, devices include servers, desktops, laptops, and systems controlling research equipment. The focus is on whether systems are kept on supported hardware and operating systems and whether there is a process to manage systems that cannot be updated, including approved exceptions or compensating controls.

Not implemented, or only on some cases means <50% of devices in your Research IT Environment are running supported operating systems or receive security updates. Devices may be running outdated or unsupported systems.

Partially implemented means 50–84% of devices in your Research IT Environment are maintained on supported operating systems or managed through an update process. However, not all unsupported systems are consistently identified, upgraded, or managed with approved exceptions or compensating controls.

Believed to be implemented in most cases means 85–99% of systems in the Research IT Environment are maintained on supported operating systems or have approved exceptions in place.

Implemented in all cases means all systems in the Research IT Environment run supported operating systems or have approved exceptions with compensating controls in place.

Reference Links​

• Vulnerability Management
• Securing Computing and Mobile Storage Devices/ Media

To what extent are IT Support Staff in your Research IT Environment subscribed to and actively monitoring appropriate vulnerability notification services to ensure timely awareness of new vulnerabilities and corresponding patches?

Control or Process Description​

IT Support Staff responsible for managing your Research IT Environment must subscribe to and actively monitor appropriate vulnerability notification services, such as vendor notifications, security mailing lists, trusted security advisories, or UBC Cybersecurity Confidential Communications, to stay informed of new vulnerabilities and corresponding patches as soon as they become available.

Why is this Essential?

Delayed awareness of newly disclosed vulnerabilities increases the likelihood that affected systems remain unpatched and exposed to exploitation. Subscribing to and monitoring vulnerability notification services provides timely information on new vulnerabilities and corresponding patches, allowing risks to affected systems to be identified and addressed promptly.

Instructions​

The following Notification Services are recommended by UBC's Cybersecurity team:
US-CERT – United States Computer Emergency Readiness
• Current Activity
• Alerts
• RSS Feed

SANS
• NewsBites

Canadian Centre for Cyber Security (CCCS)
• Cyber Security Bulletins (RSS Feed)
• Public Safety Canada – Cyber Security Bulletins/ Alerts

What is Acceptable?

IT Support Staff responsible for managing your Research IT Environment are subscribed to and actively monitoring appropriate vulnerability notification services. This awareness is applied consistently across all IT Support Staff managing your Research IT Environment.

Guidance for Selecting a Response​

Vulnerability notification services provide alerts about newly discovered security vulnerabilities and available patches (e.g., vendor notifications, security mailing lists, or trusted security advisories, UBC Cybersecurity Confidential Communications, etc.). IT Support Staff, the individual/s managing systems and services in your Research IT Environment, are expected to subscribe to and monitor these sources to stay informed.

For this question, Not implemented, or only on some cases means IT Support Staff are generally not subscribed to, or do not actively monitor, vulnerability notification services. Awareness of new vulnerabilities and patches is limited or occurs informally.

Partially implemented means 50–84% of IT Support Staff are subscribed to and actively monitor appropriate vulnerability notification services. Some staff stay informed, but this is not consistent across the Research IT Environment.

Believed to be implemented in most cases means 85–99% of IT Support Staff are subscribed to and actively monitor appropriate vulnerability notification services. Staying informed is generally expected, but not all subscriptions or monitoring activities may be verified.

Implemented in all cases means all IT Support Staff are subscribed to and actively monitor appropriate vulnerability notification services. Staying informed of new vulnerabilities and patches is a consistent and expected practice across the Research IT Environment.

Reference Links​

• Vulnerability Management

To what extent are Critical and High Severity Vulnerability patches applied in a timely manner (Critical within 72 hours, High within 14 days) to UBC Electronic Services in your Research IT Environment following the patch release?

Control or Process Description​

Critical-severity vulnerability patches for UBC Electronic Services within your Research IT Environment must be applied as soon as possible, preferably within 72 hours of the patch's release. High-severity vulnerability patches must be applied as soon as possible, preferably within 14 days of release.

Why is this Essential?

Once a patch is released for a critical or high severity vulnerability, its details often become public, giving attackers a clear roadmap for exploiting any system that hasn't yet applied it. In addition, recent advances in AI-assisted vulnerability research have collapsed the time attackers need to turn a disclosed vulnerability into a working exploit, from what once took days or weeks down to hours. A patching timeline that felt safe in the past can no longer be assumed to be fast enough. The longer a known, unpatched vulnerability remains open, the more exposed your research systems and data are to an attack that can now be assembled and launched before most organizations even begin their patch review process.

What is Acceptable?

Critical severity vulnerability patches are applied to all UBC Electronic Services within your Research IT Environment within 72 hours of release, and High severity patches within 14 days. This timeline is met consistently across every applicable service.

Guidance for Selecting a Response​

For this question, Not implemented means Critical and High severity vulnerability patches are generally not applied within the expected timelines (Critical within 72 hours, High within 14 days).

Partially implemented means Critical and High severity patches are applied within the expected timelines for 50-84% of UBC Electronic Services.

Believed to be implemented in most cases means Critical and High severity patches are applied within the expected timelines for 85-99% of UBC Electronic Services.

Implemented in all cases means Critical and High severity patches are applied within the expected timelines for all UBC Electronic Services.

Reference Links​

• Vulnerability Management

To what extent are vulnerability reports obtained for all new or substantially modified client-facing servers and applications (excluding Software-as-a-Service), and have all necessary remediation actions be taken prior to going into production?

Control or Process Description​

Before a new or substantially modified client-facing server or application within your Research IT Environment goes into production, a vulnerability scan must be obtained for it. This applies to servers and applications attached to the UBC network, excluding Software-as-a-Service (SaaS) solutions. Any vulnerabilities detected must be resolved according to their severity, and the system must be rescanned until it passes.

Why is this Essential?

A newly deployed or modified client-facing server or application is exposed to the internet as soon as it goes live and becomes subject to routine scanning by threat actors seeking newly exposed systems. Scanning for vulnerabilities before deployment allows security weaknesses to be identified and resolved while the system is not yet in active use, reducing the risk of compromise during the period between deployment and any later security review.

Instructions​

In accordance with UBC Information Security Standard M5, Vulnerability Management, UBC Cybersecurity makes use of multiple vulnerability scanners to identify vulnerabilities within UBC. The cybersecurity team has published an article to provide a list of IP addresses involved in vulnerability scanning at UBC.

Research IT/Department IT Support Staff must not block UBC's Vulnerability Scanners.

What is Acceptable?

Vulnerability reports are obtained for all new or substantially modified client-facing servers and applications within your Research IT Environment, excluding SaaS solutions, before they go into production. All identified vulnerabilities are remediated, and systems are rescanned until they pass, before deployment. This applies consistently to every applicable system.

Guidance for Selecting a Response​

A vulnerability report is a scan or assessment used to identify security weaknesses in a server or application before it is deployed into production. This includes newly deployed systems and systems that have been substantially modified. Any identified vulnerabilities must be addressed before the system goes live.

For this question, Not implemented, or only on some cases means vulnerability reports are generally not obtained before new or substantially modified client-facing servers or applications go into production, and remediation of identified vulnerabilities is not a consistent practice.

Partially implemented means vulnerability reports and remediation activities are completed for 50–84% of new or substantially modified client-facing servers or applications before they go into production. Scanning or remediation may occur for some systems, but this is not applied consistently.

Believed to be implemented in most cases means vulnerability reports are obtained and identified vulnerabilities are remediated for 85–99% of new or substantially modified client-facing servers or applications before they go into production. This is generally the expected practice, but not all implementations may be verified or consistently tracked.

Implemented in all cases means vulnerability reports are obtained for all new or substantially modified client-facing servers or applications before they go into production, and all identified vulnerabilities are remediated before deployment. This is consistently followed for all applicable systems.

Reference Links​

• Vulnerability Scanning