CSP-Research IT Environment

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.

Reference Links​

Instructions​

N/A

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

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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

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

Reference Links​

Instructions​

N/A

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.

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

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.

Reference Links​

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

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.

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.

Reference Links​

Instructions​

Examples of issues that may be subject to variance requests:

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;

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.

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.

Compute node running an operating system/version which is non-compliant with UBC security policy requirements, such as "Ubuntu 14.04.3 LTS"

A server, for technical reasons, cannot run Crowdstrike, therefore being out of compliance with UBC policy.

Cannot meet the password complexity requirements due to technological reasons.

Cannot implement/enforce MFA to a certain authentication request.

Cannot meet encryption requirements in certain circumstances.

Data/system cannot be stored in one of UBC approved datacenter.

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.

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 review conducted 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 required in place of a Privacy Impact Assessment (PIA) when the tool or service is used solely for research purposes.

Why is this Essential?

Adopting a new tool without a security review can introduce risks to UBC systems and research data. Requesting an STRA before adoption identifies these risks while they are still easiest and least costly to address.

Reference Links​

Instructions​

N/A

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.

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

Reference Links​

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.

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-approved tools, such as UBC OneDrive, UBC Teams, Teamshare, Globus, or an authenticated and encrypted SSH connection, rather than personal email accounts, unencrypted USB drives, or external websites that haven't been reviewed through a Privacy Impact Assessment (PIA).

Why is this Essential?

Using unapproved methods 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 UBC-approved methods that match the information's risk classification protects both the confidentiality of your work and the integrity of your research.

Reference Links​

Instructions​

N/A

What is Acceptable?

UBC-approved methods, such as UBC OneDrive, UBC Teams, Teamshare, Globus, or SSH with an authenticated and encrypted connection, are consistently used to transmit and share UBC Electronic Information, matched appropriately to the information's risk classification.

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

Reference Links​

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.

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.

Control or Process Description​

N/A

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.

Reference Links​

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

What is Acceptable?

N/A

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.

Reference Links​

Instructions​

N/A

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.

For UBC systems used in the Research IT environment where encryption is required, do you, at a minimum, have the following key management practices: 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; and have a key recovery strategy in place that involves an approved escrow or other viable alternative?

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

Reference Links​

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.

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?

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

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.

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.

Reference Links​

Instructions​

N/A

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.

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

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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

Reference Links​

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.

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

Reference Links​

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

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.

Reference Links​

Instructions​

N/A

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.

To what extent is 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.

Reference Links​

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.

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.

Reference Links​

Instructions​

N/A

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.

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; and, 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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

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.

Reference Links​

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.

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?

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.

Reference Links​

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.

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

Reference Links​

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.

To what extent are rules for all network firewalls in your Research IT Environment reviewed at least annually and configured to meet baseline requirements (deny by default, no Any-Any-Allow rules, unnecessary ports denied, ingress/egress filtering, ACL restriction, fail-closed behavior, stateful packet inspection, critical alarm notification, and hardened/patched/scanned per 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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

N/A

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.

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.

Reference Links​

Instructions​

The following notification services are recommended by UBC's Cybersecurity team: US-CERT (United States Computer Emergency Readiness), SANS NewsBites, and the Canadian Centre for Cyber Security (CCCS).

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.

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.

Reference Links​

Instructions​

N/A

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.

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

Reference Links​

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.