Compliance Support - IT Representative

2. Training

Have Technical Owners and IT Support staff involved in supporting systems for and employed by, the unit I represent completed Privacy & Information Security – IT Professionals training?

Note: the scope of this question is IT support staff within the unit. UBCIT professionals supporting the unit should not be considered for this question.

Why is this control 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 provides people with the information they need to protect UBC information and systems. People are often considered information security's weakest link.

Reference Links​

• Policy SC14 - Acceptable Use and Security of UBC Electronic Information and Systems
• Privacy Matters @UBC – Training

Instructions​

Privacy & Information Security – IT Professionals training is a mandatory requirement for faculty, staff, researchers, student employees and contractors who are Technical Owners of UBC systems and University IT Support Staff.​

A complete report can be generated by following the self-help instructions below.

In some cases employees are not identified in Workday, therefore the IT Representative should take the necessary steps to ensure all the professionals carrying an IT-related function take the training. The Administrative Head of Unit and the IT Representative are strongly encouraged to generate and evaluate reports for accuracy. Please reach out to "UBC PrISM Compliance " if any questions. Further instructions and the link to the training can be found here: Privacy & Information Security - IT Professionals

What is Acceptable?

We understand that there may be staff in various situations, such as on leave, or just starting. If your unit's completion rate is 85% or above, you can answer "Yes" to this question.

The goal in this control is to reach as close to 100% completion as soon as possible and continue to review training completion on an ongoing basis.

3. Payment Card Industry-Data Security Standard(PCI-DSS)

Does your unit work with UBC Treasury to comply with the Payment Card Industry – Data Security Standard (PCI-DSS) requirements for all merchant payment card handling?

Why is this control essential?

PCI-DSS is a regulatory requirement. It prevents a threat actor from stealing cardholder data (CHD) and using it to commit fraud, which affects consumer confidence and damages your reputation as a merchant. Non-compliance exposes the university to substantial financial and reputational risks.

Reference Links​

• UBC Finance - PCI DSS Compliance
• Information Security Standards – M10 Internet-facing Systems and Services
• Information Security Standards – M6 Security of Wi-Fi Infrastructure
• Information Security Standards – U3 Transmission and Sharing of UBC Electronic Information

Instructions​

There are a number of types of payment cards, the most common being credit cards, debit cards and prepaid cards. Most commonly, a payment card is electronically linked to an account or accounts belonging to the cardholder.

Engage UBC Treasury for all initiatives or projects that require:

• anyone who stores, processes or transmits cardholder data
• payment application software development
• payment hardware manufacturing

Answer N/A if your Unit does not handle any payment card information, not even through a vendor. If your unit uses a vendor for handling payment card information, this question applies to you.

What is Acceptable?

Working with treasury to understand the requirements and compliance. Compliance must be renewed annually.

4. Incident Reporting

Are you and your team aware of your responsibility to report all information security incidents to security@ubc.ca?

Why is this Essential?

Reporting security incidents or a potential anomaly promptly allows the incident to be assessed and contained as soon as possible. That includes any incidents or breaches that you and/or your team may be able to handle yourselves - those still need to be reported immediately to Cybersecurity. Further, visibility of incidents would aid the cybersecurity team in adjusting the response to a threat across UBC.

Reference Links​

• Policy SC14 - Acceptable Use and Security of UBC Electronic Information and Systems
• Information Security Standards – U4 - Reporting Information Security Incidents
• Privacy Matters @UBC – Report an Incident
• Creating quick steps to report phishing and remove it in one click

Instructions​

All IT Staff and users in the unit must be aware of the requirement to report potential information security incidents to security@ubc.ca. For example, a suspicious email or a pop-up on a computer screen that wants the user to contact a 1-800 number or a pop-up that asks for a ransom, etc. should all be reported to security@ubc.ca for analysis. IT Staff should always encourage Users to report suspected or confirmed incidents, like attempted phishing emails, directly to cybersecurity as well.

What is Acceptable?

IT support staff have been made aware of this responsibility through one of the following: - communications, awareness sessions, training, and I am confident there is broad awareness within IT support staff. IT Support Staff advise Users accordingly.

5. Device Encryption

What is the percentage of laptop and desktop computers under my control for which full disk encryption is in place?

Why is this Essential?

Encryption is the process of making information unreadable to protect it from unauthorized access. After the information has been encrypted, a secret key or password is needed to unencrypt it and make it readable again. It enables the preservation of the confidentiality and integrity of UBC Electronic Information so that the information is protected from unauthorized access. Further, BC's Privacy Commissioner has indicated repeatedly that encryption of mobile devices with personal information is necessary to achieve reasonable security measures, effectively making this a legal requirement.

Reference Links​

• Encryption Requirements

Instructions​

To properly answer this question, an up-to-date inventory of laptops and desktops must be maintained. 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. Further, UBC’s minimum encryption standard is AES-128-bit encryption or equivalent; AES-256-bit encryption is recommended.

What is Acceptable?

One of the following:

• Inventory of workstations (sccm and jamf, etc.) with encryption requirements applied to devices.
• Newly procured devices through UBC IT are encrypted by default.

6. Endpoint Detection & Response

What is the percentage of UBC-owned servers and workstations under my control on which CISO-approved Endpoint Detection Response Software (EDR) is installed (or if not technically possible up-to-date anti-malware and spyware software)?

Why is this Essential?

EDR software enables UBC cybersecurity to identify and prevent known exploits as well as contain incidents promptly. Furthermore, the EDR software enables investigation to determine what happened, when and how to better mitigate further threats to UBC's Electronic Information and Systems.

Reference Links​

• Endpoint Detection and Response
• Securing Computing and Mobile Storage Devices/Media
• Instructions on how to deploy UBC's EDR

Instructions​

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.

• Malware Protection

What is Acceptable?

EDR is installed 100% on all servers unless technically not possible.

7. DNS Firewall Management

Are all of the servers under my control, on-premise, in the public or private cloud (AWS, Azure, etc.), protected by a DNS firewall (note, a DNS firewall serves a separate function from a network firewall)?

For Educloud and standalone physical servers, this is achieved by using the UBC DNS service. Virtual servers provisioned by UBC IT will use this service by default unless reconfigured.

Infrastructure as a service (AWS, Azure etc.) servers require different approaches to put a DNS firewall in place.

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​

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

Instructions​

A DNS firewall serves as a separate function from 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. DNS Firewall works by using available threat intelligence to block known bad locations. Some examples of DNS firewalls are Cisco Umbrella, CIRA DNS Firewall, Cloudflare DNS Firewall, Route 53 Resolver DNS Firewall by AWS, enhanced DNS features in Azure Firewall, etc.

What is Acceptable?

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.

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.

85% of servers and UBC-owned devices using- as informed by a system inventory or confidence of protection by a DNS firewall through systems configuration checklists for new systems and a historic inventory.

8. Network Firewall Architecture

All servers under my control are protected by a network firewall, e.g. a Cisco Virtual context ASA firewall?

Why is this Essential?

Properly configured firewalls provide an additional layer of defense that works with anti-virus and regular patching, in the overall protection of UBC Systems and UBC Electronic Information.

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. UBC Systems storing Medium, High or Very High-Risk Information must be protected by a firewall.

Reference Links​

• Firewalls
• Firewalls Guideline
• UBC IT Virtual Firewall Service

Instructions​

If network-based firewall is required for a department or faculty, UBC IT provides a Virtual Firewall Service. You may refer to the Virtual Firewall Service link under the Reference Links section.

Further, firewall guidelines focusing on host-based firewalls have been issued by the Chief Information Officer to supplement the Securing Computing and Mobile Storage Devices/Media standard. Refer to the Firewalls Guidelines link under the Reference Links section.

If your firewalls are entirely managed by UBC IT, you can refer to your service level commitment for response.

What is Acceptable?

You have a list or are aware of all firewalls, configured at each department both on Premise and/ or on cloud (public and private) to protect all your servers or networked assets.

9. Network Firewall Rules

Are rules associated with all network firewalls under my control reviewed annually and configured as follows?

Why is this Essential?

Firewalls are only as effective as their Access Control List (ACL) rule set, which determines how traffic is blocked or passed. By configuring a firewall as highlighted in the UBC Vulnerability Management Standards(M5) and reviewing existing rules periodically (at least annually), the firewall can minimize the risk of unauthorized access to the network and reduce attack surface.

Reference Links​

• Firewall Configuration
• Vulnerability Management

Instructions​

N/A

What is Acceptable?

There is an annual review process to confirm the rules are configured appropriately and that obsolete rules are purged/ deleted (for all firewalls).

10. Supported System

What is the percentage of devices (consider servers, laptops/desktops, devices controlling research equipment) under my control that run a version of its operating system for which security updates continue to be produced? Please include devices that have out-of-date operating systems in the percentage if compensating controls approved by the CISO have been applied.

Why is this Essential?

Out of date and out of support operating systems will not continue to receive security fixes and updates that fixes known vulnerabilities. Without compensating controls (like system hardening, etc.) they pose high risk of unauthorized access to UBC Electronic Information or resources.

Reference Links​

• Automatic Blocking of Malicious Websites
• Firewalls Guideline
• UBC IT Virtual Firewall Service

Instructions​

N/A

What is Acceptable?

Where the system is at end of life and security-related updates and patches are no longer available from the vendor, then the unit has upgraded the system to the current supported version or have requested for a variance and have implemented compensating controls approved by the CISO.

11. Vulnerability Notification Service

Are IT Support Staff in my unit subscribed to appropriate Notification Services to ensure they are aware of new vulnerabilities and corresponding patches as soon as they are available?

Why is this Essential?

As part of the vulnerability management process it is important to be notified of any new security issues around the products being used that could increase the probability of systems becoming compromised. These subscriptions or notifications provide assistance in keeping University IT Support Staff up-to date on new vulnerabilities, so that appropriate steps can be taken to reduce risks to the affected systems.

Reference Links​

• Patch Management
• Security Vulnerability Information Sources
• Appropriate Notification Services
• Vulnerability Management Program (VMP)

Instructions​

The following Notification Services are recommended by UBC's Cybersecurity team:

• UBC Confidential Communication

US CERT:

• Current Activity
• Known Exploited Vulnerabilities
• Alerts
• RSS Feed

SANS

• NewsBites

Canadian Centre for Cyber Security (CCCS)

• Cyber Security Bulletins (RSS Feed)
• Public Safety Canada – Cyber Security Bulletins/ Alerts

What is Acceptable?

Clear assignment of responsibility for monitoring notification services to individual(s) within IT support function.

12. Patching Cadence

Do most of the UBC servers under my control have Critical and High Severity Vulnerability patches applied within 72 hours and 14 days respectively of the patch release time?

Why is this Essential?

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 highlighted in UBC's Information Security Standards.

Reference Links​

• Patch Management
• Vulnerability Awareness & Patching Prioritization

Instructions​

**“Most” in the question should be interpreted as 85% or more of the UBC servers under my control

What is Acceptable?

Best estimate is acceptable, but ideally this would be informed by information from real world examples e.g. ticket open/close time.

13. Vulnerability Scans/Reports (New Systems)

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

Why is this Essential?

Internet-facing servers are constantly being probed by threat actors looking for ways to access and/or control the system and data. It is important that no known vulnerabilities are left unpatched which would allow threat actors to access vulnerable systems and gain control.

In addition, vulnerability scanners are also a repository of hosts and services giving valuable insight to the exposure of internet facing systems.

Reference Links​

• Vulnerability Scanning
• Vulnerability Management Program (VMP)
• Vulnerability Scanners
• Internal vs External Network Contexts
• Vulnerability Scanners – Minimal

Instructions​

N/A

What is Acceptable?

There is a process in place to confirm security of new/substantially modified internet facing systems, which includes vulnerability scans.

14. Vulnerability Scans/Reports (Ongoing)

Are UBC’s Vulnerability Scanners allowed appropriate access to scan infrastructure under my control at all times?

Why is this Essential?

Vulnerability scanners are a critical tool for identifying potential security vulnerabilities in UBC infrastructure by scanning network assets. Additionally, vulnerability scanners provide insights into system and service exposure, making them a valuable repository of information.

Specifically blocking access to a cybersecurity-approved vulnerability scanner can lead to incomplete or inaccurate reporting of vulnerable assets or services. While it may be necessary to configure certain systems to follow security rules that limit access, vulnerability scanners should never be intentionally blocked from scanning network assets.

Reference Links​

• Vulnerability Scanning
• Vulnerability Management Program (VMP)
• Vulnerability Scanners – Minimal

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.

• Vulnerability Scanners

When configuring your network firewall there are two categories of network scanners that require you to treat your firewall differently.

1. External network vulnerability scanners.
   These vulnerability scanners scan from a network external to UBC and need to be treated like regular internet traffic. No rules should be specifically configured in the firewall for these scanners. This allows us to have the best picture of how our network looks to someone outside UBC.
2. Internal network vulnerability scanners
   These vulnerability scanners scan from a UBC internal network and should have rules created in your network firewall to open up full access to all network assets. This enables us the best picture of how our network looks from the inside.

What is Acceptable?

University IT Support Staff must not block UBC’s Vulnerability Scanners without evaluating the options with UBC’s Cybersecurity team.  

15. Backup

What is the percentage of UBC Servers and Applications under my control that are regularly backed up to a secure location and checked periodically (preferably quarterly) to ensure the integrity and availability of the information is such that it can be restored?

Why is this Essential?

Backups are essential for disaster recovery and business continuity processes, which reduce harm in the event of system failure/data loss due to human error, hardware failure, software failure, malware (like ransomware), power failure, natural disasters, etc.

A process to both backup and periodically check the integrity of backups can save time and money when it comes to restoring a system, data or configuration(s) in an event of a failure.

Reference Links​

• Information Security Standards – U7 – Securing Computing and Mobile Storage Devices/Media
• Backups - Information Security Guideline
• Privacy Matters @UBC – Back up my data

Instructions​

N/A

What is Acceptable?

1. A minimum inventory of servers and applications must exist in order to answer this question.
2. All systems are managed by UBC IT and have a Service Level Commitment covering backup is in place.
3. Cloud systems have been reviewed to ensure appropriate backup and recovery testing.
4. If the system is managed by a vendor or third party, there in an agreement in place to ensure appropriate backup and recovery testing is happening.
5. If self-managed, backups are run and tested.

16. Security & Confidentiality Agreement

Is the Service Provider Security Checklist reviewed, and the Security and Confidentiality Agreement (SACA) signed (when required) before any Service Provider is granted access to UBC Electronic Information and Systems?

Why is this Essential?

The Service Provider Security Checklist supports you in ensuring the minimum required controls for managing privacy/information security risk have been considered when engaging with a vendor.

Signed SACAs both set clear expectations with vendors regarding their responsibilities relating to UBC information and systems as well as a transfer some legal responsibility in the event of a breach not caused by UBC.

Reference Links​

• Information Security Standards – U9 Outsourcing and Service Provider Management
• Service Provider Security Checklist
• Security and Confidentiality Agreement

Instructions​

Service Providers must sign a Security and Confidentiality Agreement (SACA) before being granted access to Medium, High or Very High-Risk Information. The Administrative Head of Unit 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.

What is Acceptable?

There is a process in place to ensure service providers are reviewed against the checklist, SACAs are signed and there is knowledge or awareness in the IT support community.

17. Privacy Impact Assessment

Are Privacy Impact Assessments conducted on all projects handling personal information (Note: Guidance is available on when to conduct a PIA and exceptions for research projects)?

Why is this Essential?

Privacy and information security at UBC is a shared responsibility. A Privacy Impact Assessment (PIA) is a risk management and compliance review process used to identify and address potential information privacy and security issues, thus avoiding costly program, service, or process redesign and minimizing exposure to potential privacy breaches.

Furthermore, British Columbia’s Freedom of Information and Protection of Privacy Act (FIPPA) requires public bodies such as UBC to conduct a PIA for all new or substantially modified projects. For additional information, please refer: Privacy-impact-assessment

Reference Links​

• Information Security Standards – U1 Security Classification of UBC Electronic Information
• Information Security Standards – U9 Outsourcing and Service Provider Management
• Information Security Standards – U11 Securing Internet of Things (IoT) Devices
• Information Security Standards – M11 Development and Modification of Software Applications
• Privacy Matters @UBC - Personal Information, How to protect personal information online
• Privacy Matters @UBC – Privacy Impact Assessment

Instructions​

N/A

What is Acceptable?

The importance of assessing privacy/information security risk is part of the unit's culture. Staff are educated and encouraged to "prepare for" and "complete" Privacy Impact Assessments.

18. Account & Permissions Approval

Do you have a formal approval process for granting User and Privileged Account access for all UBC Systems under the unit you represent?

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 and preserves confidentiality, integrity and availability of the data, system and system settings.

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​

• Information Security Standards – M2 User Account Management
• Data Governance at UBC
• Information Security Standards – M3 Privileged Account Management

Instructions​

N/A

What is Acceptable?

A formal process would entail knowing who to ask for approval - the Information Steward as designated by the Administrative Head of Unit - and documented (e.g. via email), for all UBC Systems/Applications that require formal approval.

A reasonable level of compliance would mean 85% of applicable Systems Applications have formal approval processes for access grants.

19. Account & Permissions Review

What is the percentage of UBC Systems and Applications within the unit you represent where a regular (risk-based) review processes exist for User Accounts and Privileged user accounts; and communicated to the Administrative Head of Unit to validate that they remain restricted to authorized personnel?

Why is this Essential?

Users’ (both privileged users and regular users) access rights must be reviewed at regular intervals to ensure they remain aligned with current roles and responsibilities. Periodical review of all accounts along with User account onboarding, off-boarding processes minimizes the risk of takeover of a system, unauthorized access, and preserves confidentiality, integrity and availability of the data, system and system settings.

Reference Links​

• Information Security Standards – M2 User Account Management
• Data Governance at UBC
• Information Security Standards – M3 Privileged Account Management

Instructions​

N/A

What is Acceptable?

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). A resonable level of compliance would mean 85% of applicable Systems/Applications are regularly reviewed.

20. Changing Default Passwords

Are default vendor passwords forcibly changed following the installation of systems or software?

Why is this Essential?

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

Reference Links​

• Securing User Accounts

Instructions​

N/A

What is Acceptable?

There is an operational process or procedure in place to change the default password when a system or a software application is installed/ configured.

21. Securing Authentication Systems

What is the percentage of authentication systems for User Accounts that are adequately protected from password cracking using at least one of the following methods?

Note, it is common for an application to have more than one application system e.g. one for users, one for mobile devices and one for privileged users.

Why is this Essential?

Every day, UBC systems experiences attempts to guess/ breach user credentials by brute-force attempts, credentials stuffing, etc. These adversaries are building a repository of breached passwords and easily guessable passwords and are using the data against our environment to scan weaknesses in user passwords and gain access to the compromised accounts remotely. It is important to secure accounts with a strong password (refer: Creating a Passphrase/Password link below) and to adequately protect User accounts from password cracking.

Reference Links​

• Authentication System Requirements
• Creating a Passphrase/Password

Instructions​

N/A

What is Acceptable?

The expectation is that all authentication systems have this level of control, however over 85% is considered a yes for the self-assesment. All exceptions should be evaluated from a risk perspective and have variance requests where remediation is not possible.

22. Protecting Stored Passwords

Are all user passwords used for authentication purposes protected using a salted hash?

Note: Systems configured with CWL/EAD User authentication meet this requirement.

Why is this Essential?

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

Reference Links​

• Authentication System Requirements
• Guidelines

Instructions​

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

What is Acceptable?

There are no passwords stored in clear text or without the required controls. Passwords must never be stored in cleartext or use weak hash algorithms.

23. Encryption Key Management

For UBC Systems under your control where encryption is required, do you have encryption "Key” management practices as outlined below?

Note, the scope of this question includes all servers, databases and applications hosted outside UBC's and UBC approved datacenter, cloud-hosted systems such as servers on Compute Canada Cloud and AWS (IaaS), SaaS-based like workday and PaaS-based like platform.sh, etc. Respond 'Yes' unless you are aware of situations where encryption is required and key management is not in place.

Why is this Essential?

Encryption key management practice is essential in preventing unauthorized access to sensitive information. It is important to have the password or passphrase not be guessable or susceptible to crack easily. Should keys be compromised, entire systems and data can be compromised. By following the standards defined in the Passphrase and Password Protection standard in setting up a passphrase or a password, we make it hard for a threat actor(s) to access the data.

Further, If an encryption key is lost, corrupted or destroyed the only way to decrypt the data is through a process referred to as Key Recovery. The purpose of securely backing up these keys is to be able to decrypt data that would not otherwise be recoverable. Lack or absence of a key recovery strategy may result in data loss.

Reference Links​

• Key Management
• Password Requirement section of U5
• Key Escrow Guideline

Instructions​

N/A

What is Acceptable?

A key management process is required where encryption keys are used to protect information. This process should cover key distribution, storage and protection, recovery and key change. The knowledge that a process exists and is followed will suffice, however, ideally a documented process exists.

24. Cryptographic Controls (Procurement of Certificates)

For the UBC Systems under your control (consider servers, databases and applications) where encrypted sessions (data in transit) are required, do you have a process in place to ensure that X.509 certificates are issued by the University’s Enterprise account, via security@ubc.ca, and are configured and installed in collaboration with UBC Cybersecurity or other X.509 certificates that comply with the Information Security Standard M7 - Cryptographic Controls?

Why is this Essential?

The X.509 certificate provided by the cybersecurity team offers an enhanced level of protection for UBC Electronic Information in the event of theft, loss or interception by rendering information unreadable by unauthorized individuals.

Reference Links​

• Cryptographic Requirements
• Request SSL Certificates

Instructions​

N/A

What is Acceptable?

IT support teams being aware of and utilizing the enterprise service constitutes a yes. If other services are used it is expected that the X.509 configuration has been reviewed against ISS M7 - Cryptographic Controls requirements.
 

• Refer to: Request SSL Certificates

25. Cryptographic Controls (Certificates)

Can you confirm that, for the UBC Systems under your control (consider servers, databases and applications) where encrypted sessions (for data in transit) are required, all existing X.509 certificates comply with the requirements of Information Security Standard M7 - Cryptographic Controls?

Why is this Essential?

Cryptographic controls provide an enhanced level of protection for UBC Electronic Information in the event of theft, loss or interception by rendering information unreadable by unauthorized individuals. It is also a legal requirement to encrypt sessions over the network, which has been affirmed by the British Columbia Information and Privacy Commissioner in their interpretation of the BC Freedom of Information and Protection of Privacy Act (FIPPA).

Reference Links​

• X.509 Certificates Requirements

Instructions​

N/A

What is Acceptable?

There has been a review of X.509 certificates and we are aware that all under our control comply with the guidance in ISS M7 - Cryptographic Controls requirements.
If there are questions or if you need assistance in understanding the existing X.509 certificate, reach out to cybersecurity for assistance.

• Request a consultation with Cybersecurity

26. Logging Key Activities

For the UBC Servers under your control, is logging enabled and capturing the following key activities?

Why is this Essential?

A log is a record of the events occurring within the application(s)/systems and networks. Effective logging and monitoring procedures (i.e. continual monitoring and/or periodic reviews) provide ongoing assurance that UBC Systems and the UBC Electronic Information that they hold are secure and that confidentiality and integrity are effectively being ensured. In the event of a security breach, audit logs are relied upon to determine whether or not information has been accessed or modified without authority.

Reference Links​

• Information Security Standards – M8 Logging and Monitoring of UBC Systems
• Information Security Standards – M10 Internet-facing Systems and Services

Instructions​

N/A

What is Acceptable?

There is a process to ensure logging is enabled for all systems during system implementation.

If the process is new, a review of older systems has been conducted to confirm logging requirements are met.

27. Log Retention and Protection

What percentage of servers under my control meet the requirements below?

Why is this Essential?

A log is a record of the events occurring within an application(s)/systems and networks. Log data is invaluable in managing, maintaining and troubleshooting. Furthermore, log management is critical for cyber incident response, audit and non-repudiation.

Reference Links​

• Information Security Standards – M8 Logging and Monitoring of UBC Systems
• Information Security Standards – M10 Internet-facing Systems and Services

Instructions​

N/A

What is Acceptable?

Through knowledge of the ecosystem/active review, you are confident that in at least 85% of cases, these requirements are met.

28. Physical Security (Server Rooms)

Are all servers under your control in a secure data center?

Secure data centers are:

• Core UBC datacenters
• UBC-approved data centers, e.g. EduCloud, Compute Canada HPC,
• Other third-party data centers approved by the CISO
• Departmentally managed data centers which meet the essential physical security requirements (see instructions below)

Why is this Essential?

While electronic controls are important, they may become ineffective if the device is physically accessed or removed by an unauthorized party. UBC's and UBC-approved datacenters (including third-party datacenters) are intended to provide a secure location for operations, , controlled access to equipment and data, protection against environmental threats and support for the availability requirements.

Further, UBC as a public body, we are obligated by the "BC Freedom of Information and Protection of Privacy Act (FIPPA)" and "Policy GA4, Records Management" 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 data centers or in third-party servers that have an equivalent level of security as prescribed in Information Security Standard M9.

Reference Links​

• Physical Security of UBC Datacenters
• Security Classification of UBC Electronic Information Standard

Instructions​

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

What is Acceptable?

All servers are in a secure data center. What is a secure data center:

• UBC datacenter and UBC approved datacenters e.g. EduCloud, Compute Canada HPC
• or other third-party data centers approved by the CISO.
• Departmentally managed data centers which meet the essential physical security requirements

29. Secure Transmission

What percentage of forms/applications/services that transmit Medium, High or Very High-Risk UBC Information within my unit that comply with the following requirements?

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

Why is this Essential?

UBC Systems and services that are internet-facing (i.e. visible or accessible from the internet) are prime targets for exploitation. Without adequate security, these systems and services provide an avenue for malicious activity such as the theft of UBC Electronic Information or the denial of service to UBC resources. To ensure there are adequate controls to preserve confidentiality and integrity of the data in motion, to improve confidence in end users of the service offering and brand reputation.

Reference Links​

• Information Security Standards – M10 Internet-facing Systems and Services
• To engage the Cybersecurity team

Instructions​

N/A

What is Acceptable?

The list of applications and/ or services has been reviewed to confirm compliance either manually or using suitable tools.

30. Demilitarized Zones (DMZ) - Inclusion

Are all remote access servers (e.g. terminal server, VDI, Remote Access Gateways, etc.)

• a. located in a DMZ;
• b. using strong encryption for remote access transmission e.g. RDP with Network Level Authentication, SSH with AES-256 bit encryption)

Why is this Essential?

Users frequently access desktops, laptops and servers remotely. Remote Access covers a broad range of technologies, protocols and solutions (e.g. RDP, SSH, VNC, VDI, terminal services, etc.). Remote Access must comply with the requirements where possible to prevent takeover of a system, unauthorized access, and preserve confidentiality and integrity of the data, system and system settings.

Reference Links​

• Information Security Standards – M10 Internet-facing Systems and Services

Instructions​

N/A

What is Acceptable?

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

31. Demilitarized Zones (DMZ) - Exclusion

Can you confirm that all host desktops, laptops and database servers, as well as any servers that should not be internet accessible, are not in the demilitarized zone (DMZ)?

Why is this Essential?

A DMZ is a zone where there are systems that are accessible from the internet and is usually considered a low trust - high-risk zone due to the exposure. The systems in this zone are constantly scanned and fingerprinted over the internet by threat actors, crawlers, scanners, and security researchers alike. It is important to minimize exposure of all host desktops, laptops and database servers, as well as any servers that don't have to be internet-facing. This reduces the attack surface and the likelihood of compromise.

Reference Links​

• Information Security Standards – M10 Internet-facing Systems and Services

Instructions​

N/A

What is Acceptable?

The DMZ does not contain database servers that store or process High or Very High Risk Information, host desktops, laptops or other servers that should not be internet accessible.

32. Multi-factor authentication for Remote Access

Does all remote access to host desktops, laptops or servers require multi-factor authentication (MFA) over the technology used to access (like Remote Access Gateway, VPN or SSH)?

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

Why is this Essential?

Every day, UBC is experiencing an increase in attempts to guess/ breach user credentials. The adversaries are building a repository of breached passwords, and commonly used passwords and are using the data against our environment to scan for weaknesses in user passwords and gain access to the compromised accounts remotely.

Multi-factor authentication (MFA) provides another layer of security on top of the login credentials. By properly configuring and implementing MFA, it immediately neutralizes the risks associated with compromised passwords. If a password is guessed, or even phished, that's no longer enough to give an intruder access.

Reference Links​

• Information Security Standards – M10 Internet-facing Systems and Services

Instructions​

N/A

What is Acceptable?

Multi-factor authentication (MFA) is enabled for remote access services such as Remote Access Gateway, VPN or SSH, etc. for accessing UBC's host desktops, laptops or servers.

33. Secure Internet Facing Devices

Can you confirm that there are no server applications under my control running on desktops or laptops (e.g. web or FTP servers) that are internet-facing?

Why is this Essential?

UBC's desktops or laptops are primarily configured for end users to conduct University business. In order to minimize exposure of such devices over the internet, users must not run server applications (e.g. web or FTP Servers) that are Internet-facing on desktops or laptops. Direct exposure of end-user systems in any capacity on the internet may put other systems on the network at risk of being exploited.

Reference Links​

• Special Requirements for Servers

Instructions​

N/A

What is Acceptable?

Server applications running on desktops or laptops should never be internet-facing. Instances should be evaluated and if necessary compensating controls defined.

34. Software Application Security Checklist

Is there a process in place to ensure that, before storing or accessing UBC Electronic Information, a Software Application Security Checklist is completed for all new or substantially modified applications that store or access Medium, High or Very High-Risk Information?

Why is this Essential?

When purchasing, designing or substantially modifying Software Applications, it is important that security requirements are understood, documented and implemented at the earliest appropriate stage of the project. This is substantially cheaper and more effective than trying to apply security controls retroactively.

Reference Links​

• Development and Modification of Software Applications
• Software Application Security Checklist

Instructions​

Here are some examples of substantially modified applications:

• Granting access privileges to Medium, High or Very High-Risk Information to new categories or groups of individuals
• outsourcing management, storage or security of Medium, High or Very High-Risk Information to an external service provider
• changing how Medium, High or Very High-Risk Information is collected, used or displayed

What is Acceptable?

IT support staff are aware of the checklist and are known to utilize it as part of the implementation/release process.

35. Website Naming

Are all the online sites/tools/applications/services delivered by the unit I represent in the ubc.ca domain space?

Why is this Essential?

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.

Placing applications in the ubc.ca domain space enables users to validate authentic UBC websites, significantly reducing the likelihood of users responding to phishing attempts. Further various cybersecurity services (including proactive monitoring) are only available to site in the ubc.ca domain space, so being outside the domain is likely to result in less secure web applications.

Reference Links​

• myDNS FAQs
• Subdomain Registration

Instructions​

N/A

What is Acceptable?

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.