Essential Controls

Essential Controls- Administrative Head of Unit

#	ISS & Section	Category	Topic	Control Statement	Reference Link
1	U1 3.2 U7 6.1	Information Systems Inventory	Information Systems Inventory	U1 3.2 The Administrative Head of Unit is responsible for knowing the types of UBC Electronic Information under their control, its information security classification and where it is stored. In order to comply with our legal obligations, it is recommended that the Administrative Head of Unit keep an inventory of types of records that contain High Risk and/or Very High Risk Information. At a minimum, the inventory should contain the type of information, description and storage location. Refer to the sample inventory attached to this standard. This responsibility may be delegated to the Information Steward/Owner. U7 6.1 Central UBC IT support staff must maintain an inventory of UBC-owned laptops and desktops that they have deployed, including which Users these Devices are assigned to. All other University IT Support staff are recommended to maintain such inventories.	Information Systems Inventory
2	M2 2.1 M3 3.2 M2 5.1 M3 6.1	Account & Permissions Management	Account & Permissions Management	M2 2.1 Applications for User Accounts must be reviewed and approved by Information Steward/Owners and a record must be kept of all Users being granted these accounts and who provided authorization. This record must be retained for at least one year. M3 3.2 Unnamed Privileged Accounts may be shared between multiple Users. However, for all privileged account types, a single individual must be assigned with accountability for the security of the account. M2 5.1 Users’ access rights must be reviewed at regular intervals to ensure they remain aligned with current roles and responsibilities. The frequency of the review must be risk based (e.g. access rights to High or Very High Risk Information such as Personal Health Information should be reviewed more frequently than access rights to Medium Risk Information that may not do as much harm if exposed to unauthorized individuals). M3 6.1 Access to Privileged Accounts must be reviewed at an interval stipulated by the Technical Owner of the UBC System (in consultation with the Administrative Head of Unit), or at a minimum annually, to validate that they remain restricted to authorized personnel. Discrepancies must be reported in a in a timely manner to the Technical Owner for resolution.	Account & Permissions Management
3	U7 2.1	Backup	Backup	U7 2.1 Any UBC Electronic Information stored on the Device must be regularly backed up to a secure location and checked periodically (preferably quarterly) to ensure the integrity and availability of the information such that it can be restored. See the Backup guideline.	Backup
4	U4 1.2 SC14 6.1.6 U4 1.2	Incident Preparedness	Incident Reporting	U4 1.2 Standards for Users to report any suspicious incidents relating to the security of UBC Electronic Information and Systems. University IT Support Staff (including both departmental IT and UBC IT staff) are responsible for handling security incidents in coordination with UBC Cybersecurity. SC14 6.1.6 ensuring that breaches and potential breaches of this policy occurring within their unit are resolved and/or referred to the CIO, as appropriate, and that where they are so referred, continuing to assist in the investigation, preserving evidence where required U4 2.1 Users must report the following information security incidents (if there is uncertainty whether a violation has occurred, Users must err on the side of caution and report the incident anyway): all violations of Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems; examples include but are not limited to: use of UBC computing facilities to commit illegal acts; unsolicited or spam email originating from UBC sources; unauthorized access, use, alteration or destruction of UBC Electronic Information or UBC Systems, including but not limited to: software, computing equipment, Merchant Systems, network equipment and services; theft of any UBC Electronic Information whether it be via electronic means or physical theft of any Device containing this information; and loss or theft of any Multi-Factor Authentication Device (MFA Device). unauthorized wireless access points discovered in either merchant areas or areas accessing, transmitting or storing UBC Electronic Information; and use of Malicious Code, which may show up as unexplained behavior on desktops, laptops or servers such as webpages opening by themselves, new files or folders appearing on the local hard drive, and lockouts of user accounts.	Incident Reporting
5	SC14 6.1.8 SC14 6.1.7	Training & Awareness	Training	SC14 6.1.8 working with UBC Information Technology to make training and other information and resources necessary to support this policy available to Users in their unit. SC14 6.1.7 ensuring that technical staff within their unit are aware of and adhere to this policy, and that they support University standards in the design, installation, maintenance, training, and use of UBC Electronic Information and Systems.	Training
6	M1 1.1	Training and Awareness	Variance	M1 1.1 In order to protect University information assets, the Chief Information Officer (CIO) has issued binding Information Security Standards. Academic and administrative units that wish to deviate from these Information Security Standards are required to request a variance from the CIO.	Variance
7	U9 2.2	Outsourcing and Service Provider Management	Privacy Impact Assessment	U9 2.2 In addition to the requirement to use the above checklist, a Privacy Impact Assessment (PIA) is required if Personal Information is involved. Please refer to the PIA Process Overview for more information.	Privacy Impact Assessment
8	U9 5.1	Outsourcing and Service Provider Management	Security & Confidentiality Agreement	U9 5.1 Service Providers must sign a Security and Confidentiality Agreement (SACA) prior to being granted access to Medium, High or Very High Risk Information. The Administrative Head of Unit may request the Office of the University Counsel to grant a waiver of the requirement for a SACA where the primary contract with the Service Provider contains equivalent privacy and security language. Doctors, lawyers, accountants, auditors, psychologists and other professionals who are bound by a duty of confidentiality do not need to sign a SACA.	Security & Confidentiality Agreement
9	M8 2.1 M8 2.3	Log Management	Log Management	M8 2.1 The following key activities must be logged: 2.1.1 User login, logout and access to a resource; 2.1.2 action performed by the User and the time it was performed; and 2.1.3 where feasible, any access to, or modification of, records. M8 2.3 Logs provide valuable information that can be used to validate the integrity and confidentiality of UBC Electronic Information; to be effective, logs must be: 2.3.1 retained for at least 90 days (except for ERP logs, which must be retained for at least 365 days) and regularly backed up whenever possible, preferably to offsite secure storage; 2.3.2 retrievable in a timely manner if they are required for analysis; and 2.3.3 protected against unauthorized access and modification, preferably by locating them on a separate server outside the Demilitarized Zone (DMZ), such as a Database Server protected by a firewall, and restricting access as necessary; no-one should be able to change or delete log information.	Log Management
10	U3 5.1 M6 5.1 M10 4.1	Payment Card Information Protection	Payment Card Industry-Data Security Standard(PCI-DSS)	U3 5.1 Due to the sensitivity of Payment Card Industry (PCI) Information, it is subject to the following additional requirements: PCI Information must only be stored in approved Merchant Systems; PCI Information must never be transmitted via email or instant messaging systems. This activity is prohibited; PCI Information must never be transmitted unencrypted by any of the other above methods; media containing PCI Information must be sent by secured courier or other delivery method that can be accurately tracked; and management must approve the transfer of PCI Information from a secured area. M6 5.1 Users responsible for Merchant Systems must: ensure that a perimeter firewall is in place between any Wi-Fi network and Merchant Systems processing Payment Card Industry (PCI) Information. These firewalls must be configured to deny or control any traffic from the Wi-Fi environment to Merchant Systems; test for the presence of unauthorized WAPs on a quarterly basis. Note: Methods that may be used in the process include, but are not limited to, Wi-Fi network scans, physical/logical inspections of system components and infrastructure, network access control NAC), or Wi-Fi IDS/IPS; and report any unauthorized WAPs as a security incident, in compliance with the Reporting Information Security Incidents standard. M10 4.1 University IT Support staff must configure Remote Access technologies, used in Merchant Systems, to automatically disconnect User sessions after a specific period of inactivity. 30 minutes is recommended.	PCI-DSS
11	M11 5.1	Development & Modification of Software Applications	Website Naming	M11 5.1 Web Applications used to conduct University Business must be provisioned within the ubc.ca domain name space, e.g. widget.ubc.ca, unless not technically possible.	Website Naming

Essential Controls- IT Representative

#	ISS & Section	Category	Topic	Control Statement	Reference Link
1	U1 3.2 U7 6.1	Information Systems Inventory	Information Systems Inventory	U1 3.2 The Administrative Head of Unit is responsible for knowing the types of UBC Electronic Information under their control, its information security classification and where it is stored. In order to comply with our legal obligations, it is recommended that the Administrative Head of Unit keep an inventory of types of records that contain High Risk and/or Very High Risk Information. At a minimum, the inventory should contain the type of information, description and storage location. Refer to the sample inventory attached to this standard. This responsibility may be delegated to the Information Steward/Owner. U7 6.1 Central UBC IT support staff must maintain an inventory of UBC-owned laptops and desktops that they have deployed, including which Users these Devices are assigned to. All other University IT Support staff are recommended to maintain such inventories.	Information Systems Inventory
2	SC14 6.1.8 SC14 6.1.7	Training & Awareness	Training	SC14 6.1.8 working with UBC Information Technology to make training and other information and resources necessary to support this policy available to Users in their unit SC14 6.1.7 ensuring that technical staff within their unit are aware of and adhere to this policy, and that they support University standards in the design, installation, maintenance, training, and use of UBC Electronic Information and Systems	Training
3	U3 5.1 M6 5.1 M10 4.1	Payment Card Information Protection	Payment Card Industry-Data Security Standard(PCI-DSS)	U3 5.1 Due to the sensitivity of Payment Card Industry (PCI) Information, it is subject to the following additional requirements: PCI Information must only be stored in approved Merchant Systems; PCI Information must never be transmitted via email or instant messaging systems. This activity is prohibited; PCI Information must never be transmitted unencrypted by any of the other above methods; media containing PCI Information must be sent by secured courier or other delivery method that can be accurately tracked; and management must approve the transfer of PCI Information from a secured area. M6 5.1 Users responsible for Merchant Systems must: ensure that a perimeter firewall is in place between any Wi-Fi network and Merchant Systems processing Payment Card Industry (PCI) Information. These firewalls must be configured to deny or control any traffic from the Wi-Fi environment to Merchant Systems; test for the presence of unauthorized WAPs on a quarterly basis. Note: Methods that may be used in the process include, but are not limited to, Wi-Fi network scans, physical/logical inspections of system components and infrastructure, network access control NAC), or Wi-Fi IDS/IPS; and report any unauthorized WAPs as a security incident, in compliance with the Reporting Information Security Incidents standard. M10 4.1 University IT Support staff must configure Remote Access technologies, used in Merchant Systems, to automatically disconnect User sessions after a specific period of inactivity. 30 minutes is recommended.	PCI-DSS
4	U4 1.2 SC14 6.1.6 U4 1.2	Incident Preparedness	Incident Reporting	U4 1.2 Standards for Users to report any suspicious incidents relating to the security of UBC Electronic Information and Systems. University IT Support Staff (including both departmental IT and UBC IT staff) are responsible for handling security incidents in coordination with UBC Cybersecurity. SC14 6.1.6 ensuring that breaches and potential breaches of this policy occurring within their unit are resolved and/or referred to the CIO, as appropriate, and that where they are so referred, continuing to assist in the investigation, preserving evidence where required U4 2.1 Users must report the following information security incidents (if there is uncertainty whether a violation has occurred, Users must err on the side of caution and report the incident anyway): all violations of Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems; examples include but are not limited to: use of UBC computing facilities to commit illegal acts; unsolicited or spam email originating from UBC sources; unauthorized access, use, alteration or destruction of UBC Electronic Information or UBC Systems, including but not limited to: software, computing equipment, Merchant Systems, network equipment and services; theft of any UBC Electronic Information whether it be via electronic means or physical theft of any Device containing this information; and loss or theft of any Multi-Factor Authentication Device (MFA Device). unauthorized wireless access points discovered in either merchant areas or areas accessing, transmitting or storing UBC Electronic Information; and use of Malicious Code, which may show up as unexplained behavior on desktops, laptops or servers such as webpages opening by themselves, new files or folders appearing on the local hard drive, and lockouts of user accounts.	Incident Reporting
5	U5 3.1	Device Encryption	Device Encryption	U5 3.1 Encryption requirements apply to Devices, whether UBC-supplied or personally-owned, that are used to access UBC Electronic Information and Systems, or store UBC Electronic Information. For more information on Device Encryption requirements click here	Device Encryption
6	U7 2.1	Endpoint Detection & Response	Endpoint Detection & Response	Computing Devices used for University Business must comply with the following electronic security requirements. Endpoint Detection and Response (EDR) Servers: EDR software approved by the CISO must be installed on all UBC-owned Servers. Workstation: EDR software approved by the CISO must be installed on all UBC-owned Workstations, where technically possible. On Computing Devices not required to have EDR, install up-to-date anti-malware and spyware cleaning software (except for smartphones and tablets that do not offer this feature) and configure it to update at least once per day. See the UBC IT Malware Protection page.	Endpoint Detection Response
7	U7 2.1	Firewall Management	DNS Firewall Management	Computing Devices used for University Business must comply with the following electronic security requirements. Automatic Blocking of Malicious Websites Servers: Servers on-premises and in the cloud (Infrastructure as a Service) must be protected by a DNS firewall. It is recommended that Servers on-premises use UBC Domain Name Servers, which make use of DNS firewall protection. Workstation: UBC-owned Devices that access, process or store Medium, High or Very High Risk Information must be protected by a DNS firewall. It is recommended that on-premises Devices use UBC Domain Name Servers, which make use of DNS firewall protection. For all other Devices, a DNS firewall is recommended.	DNS Firewall Management
8	U7 2.1	Firewall Management	Network Firewall Architecture	Firewalls: Install and configure firewalls (except for tablets and smartphones that do not offer this feature).	Network Firewall Architecture
9	M5 6.2	Firewall Management	Network Firewall Rules	M5 6.2 Firewalls are only as effective as their Access Control List (ACL) rule set, which determines how traffic is blocked or passed. Firewall ACL rule sets must be configured as follows: a ”Deny by Default” policy must be implemented on all firewalls; services that are not explicitly permitted must be denied; firewalls must use ingress filtering at a minimum and must 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; and rule sets must be reviewed annually for optimization and validation of effective rules.	Network Firewall Rules
10	U7 2.1	Patch & Vulnerability Management	Supported System	U7 2.1 U7 2.1 The Device must run a version of its operating system for which security updates continue to be produced and are available. If this is not possible, see the Vulnerability Management standard for compensating controls. If the Device is University-owned, software updates must not be impeded, and no unauthorized changes may be made to the Device.	Supported System
11	M5 2.1	Patch & Vulnerability Management	Vulnerability Notification Service	M5 2.1 University IT Support Staff are responsible for subscribing to the Appropriate Notification Services to ensure they are aware of new vulnerabilities and corresponding patches as soon as they are available.	Vulnerability Notification Service
12	M5 2.5	Patch & Vulnerability Management	Patching Cadence	M5 2.5 Unpatched software is frequently exploited by malicious individuals to access information or resources. To mitigate this threat, vendor provided patches for UBC Systems (e.g. operating systems, applications, databases, etc.) must be patched, with service outages where required, in accordance with Severity Ratings for Vulnerabilities (CVSS) or as defined by the vendors or other third parties as follows: Critical-Severity Vulnerabilities as soon as possible, preferably within 72 hours of the patch release; High-Severity Vulnerabilities as soon as possible, preferably within 14 days of the patch release; and Medium-Severity Vulnerabilities as soon as possible once all Critical and High-Severity Vulnerabilities have been resolved.	Patching Cadence
13	M5 3.3	Patch & Vulnerability Management	Vulnerability Scanning(New Systems)	M5 3.3 University IT Support Staff have the responsibility to obtain a vulnerability scan for all new or substantially modified Internet-facing servers and applications attached to the UBC network prior to going into production. Any detected vulnerabilities must be resolved in accordance with their severity, as outlined in section 2.5 above; rescans are required until passing results are obtained.	Vulnerability Scanning(New Systems)
14	M5 3.4	Patch & Vulnerability Management	Vulnerability Scanning (Ongoing)	M5 3.4 University IT Support Staff must not block UBC’s Vulnerability Scanners.	Vulnerability Scanning (Ongoing)
15	U7 2.1	Backup	Backup	U7 2.1 Any UBC Electronic Information stored on the Device must be regularly backed up to a secure location and checked periodically (preferably quarterly) to ensure the integrity and availability of the information such that it can be restored. See the Backup guideline.	Backup
16	U9 5.1	Outsourcing & Service Provider Management	Security & Confidentiality Agreement	U9 2.1 Before Service Providers provision software applications or are granted access to UBC Electronic Information and Systems, information security risks must be assessed and managed using the Service Provider Security Checklist. U9 5.1 Service Providers must sign a Security and Confidentiality Agreement (SACA) prior to being granted access to Medium, High or Very High Risk Information. The Administrative Head of Unit may request the Office of the University Counsel to grant a waiver of the requirement for a SACA where the primary contract with the Service Provider contains equivalent privacy and security language. Doctors, lawyers, accountants, auditors, psychologists and other professionals who are bound by a duty of confidentiality do not need to sign a SACA.	Security & Confidentiality Agreement
17	U9 2.2	Outsourcing & Service Provider Management	Privacy Impact Assessment	U9 2.2 In addition to the requirement to use the above checklist, a Privacy Impact Assessment (PIA) is required if Personal Information is involved. Please refer to the PIA Process Overview for more information.	Privacy Impact Assessment
18	M2 2.1 M3 3.2	Account & Permissions Management	Account & Permissions Approval	M2 2.1 Applications for User Accounts must be reviewed and approved by Information Steward/Owners and a record must be kept of all Users being granted these accounts and who provided authorization. This record must be retained for at least one year. M3 3.2 Unnamed Privileged Accounts may be shared between multiple Users. However, for all privileged account types, a single individual must be assigned with accountability for the security of the account.	Account & Permissions Approval
19	M2 5.1 M3 6.1	Account & Permissions Management	Account & Permissions Review	M2 5.1 Users’ access rights must be reviewed at regular intervals to ensure they remain aligned with current roles and responsibilities. The frequency of the review must be risk based (e.g. access rights to High or Very High Risk Information such as Personal Health Information should be reviewed more frequently than access rights to Medium Risk Information that may not do as much harm if exposed to unauthorized individuals). M3 6.1 Access to Privileged Accounts must be reviewed at an interval stipulated by the Technical Owner of the UBC System (in consultation with the Administrative Head of Unit), or at a minimum annually, to validate that they remain restricted to authorized personnel. Discrepancies must be reported in a in a timely manner to the Technical Owner for resolution.	Account & Permissions Review
20	M4 2.6	Account & Permissions Management	Changing Default Passwords	M4 2.6 Default vendor passwords must be changed following the installation of systems or software.	Changing Default Passwords
21	M4 3.2	Account & Permissions Management	Securing Authentication Systems	M4 3.2 Authentication systems for User Accounts must be adequately protected from password cracking using at least one of the following methods: the account is locked for a period of time if an incorrect number of passwords/passphrases is entered over a specified time period (for example, if an incorrect password/passphrase is entered 10 times within a 30 minute window, the account will be locked for 30 minutes); and/or each time an incorrect password/passphrase is entered, the system introduces a delay before providing the failure response; this delay increases as the failed login attempts continue but will reset once the User successfully logs in (for example, the delay period could begin at 100 milliseconds, and double after each subsequent failed login).	Securing Authentication Systems
22	M4 3.3	Account & Permissions Management	Protecting Stored Passwords	M4 3.3 Authentication systems must not store account passwords in clear text. Where possible, passwords should be stored using a strong cryptographic hash and salted.	Protecting Stored Passwords
23	M7 2.4 M7 4.1	Cryptographic Controls	Encryption Key Management	M7 2.4 Whenever a password or passphrase is used as an encryption key (”Key”), it must follow the standards defined in the Passphrase and Password Protection standard, which details strong password/passphrase construction. Keys that are compromised (e.g. lost or stolen) must be reported immediately in accordance with the Reporting Information Security Incidents standard. The Key must be revoked or destroyed and a new key generated. Key re-assignments require re-encryption of the data. M7 4.1 For encryption to be effective, encryption Keys must be protected against unauthorized disclosure, misuse, alteration or loss. In order to reduce the risk of loss or exposure of Keys, it is recommended that all Key management processes be performed with automated software. A Key management plan must also be in place that covers the following process areas: Key Generation Key Distribution Key Storage and Protection Key Recovery Key Change	Encryption Key Management
24	M7 2.6.4	Cryptographic Controls	Cryptographic Controls (Procurement of Certificates)	M7 2.6.4 X.509 certificates may be purchased under the University’s Enterprise account, via security@ubc.ca.	Cryptographic Controls (Procurement of Certificates)
25	M7 2.6	Cryptographic Controls	Cryptographic Controls (Certificates)	M7 2.6 The following requirements apply to X.509 certificates: X.509 certificates used for the securing of Medium, High or Very High Risk Information during User transmission must be issued by a trusted third party CA, as part of a Public-Key Infrastructure (PKI); server-to-server transmissions should be encrypted and should use a trusted third party certificate; newly purchased or renewed X.509 certificates must be a minimum of 2048-bits; and X.509 certificates may be purchased under the University’s Enterprise account, via security@ubc.ca.	Cryptographic Controls (Certificates)
26	M8 2.1	Log Management	Logging Key Activities	M8 2.1 The following key activities must be logged: 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.	Logging Key Activities
27	M8 2.3	Log Management	Log Retention and Protection	M8 2.3 Logs provide valuable information that can be used to validate the integrity and confidentiality of UBC Electronic Information; to be effective, logs must be: retained for at least 90 days (except for ERP logs, which must be retained for at least 365 days) and regularly backed up whenever possible, preferably to offsite secure storage; retrievable in a timely manner if they are required for analysis; and protected against unauthorized access and modification, preferably by locating them on a separate server outside the Demilitarized Zone (DMZ), such as a Database Server protected by a firewall, and restricting access as necessary; no-one should be able to change or delete log information.	Log Retention and Protection
28	M9 1.3	Physical Security	Physical Security (Server Rooms)	M9 1.3 The University has a responsibility to protect High and Very High Risk Information from unauthorized viewing and use. In particular, the BC Freedom of Information and Protection of Privacy Act (FIPPA)[1] and Policy GA4, Records Management[2] require public bodies to implement reasonable and appropriate security arrangements for the protection of Personal Information (in both electronic and paper format). Therefore, servers containing significant quantities of High or Very High Risk Information must be hosted in UBC Datacentres or in third party servers that have an equivalent level of security to this standard. Where appropriate, Low and Medium Risk Information may also be hosted in UBC Datacentres.	Physical Security (Server Rooms)
29	M10 3.1	Internet-Facing Systems & Services	Secure Transmission	M10 3.1 Secure transmission of Medium, High or Very High Risk Information must comply with the following requirements: any form, application or service that requires some type of authentication, or that is used to collect or transmit information from User to server or between servers, must be encrypted using HTTPS with TLS version 1.2 at a minimum (or the equivalent, for non-web-based applications); information transmitted via SSH must be encrypted using a minimum of AES-256 bit encryption with mutual authentication between the server and User; and known weak network protocols (e.g. all versions of SSL, and TLS versions prior to 1.2) should be disabled.	Secure Transmission
30	M10 3.4.2	Internet-Facing Systems & Services	Demilitarized Zones (DMZ) - Inclusion	M10 3.4.2 remote access servers (e.g. terminal server, VDI, Remote Access Gateways, etc.) must be located in the DMZ and use strong encryption for server-to-User transmissions, e.g. RDP with Network Level Authentication, SSH with AES-256 bit encryption, etc.;	Demilitarized Zones (DMZ) - Inclusion
31	M10 3.4.3	Internet-Facing Systems & Services	Demilitarized Zones (DMZ) - Exclusion	M10 3.4.3 host desktops, laptops or servers not located in the DMZ must be remotely accessed via a Remote Access Gateway, VPN or SSH	Demilitarized Zones (DMZ) - Exclusion
32	M10 3.4.1	Internet-Facing Systems & Services	Multi-Factor Authentication for Remote Access	M10 3.4.1 Multi-Factor Authentication (MFA) must be used;	Multi-Factor Authentication for Remote Access
33	U7 5.2	Internet-Facing Systems & Services	Secure Internet Facing Devices	U7 5.2 Users must not run Server applications on desktops or laptops (e.g. web or FTP Servers) that are Internet-facing. Exceptions may be approved by the Administrative Head of Unit, in consultation with University IT Support Staff, provided that compensating controls are put in place to control security risks.	Secure Internet Facing Devices
34	M11 2.1	Development & Modification of Software Applications	Software Application Security Checklist	M11 2.1 Prior to storing or accessing UBC Electronic Information, complete a Software Application Security Checklist for all new or substantially modified applications that store or access Medium, High or Very High Risk Information.	Software Application Security Checklist
35	M11 5.1	Development & Modification of Software Applications	Website Naming	M11 5.1 Web Applications used to conduct University Business must be provisioned within the ubc.ca domain name space, e.g. widget.ubc.ca, unless not technically possible.	Website Naming

Return to CSP Home Page Go to Self-Assessment Page

This page was last updated on Thursday, February 23, 2023 - 23:24