Compliance Support - Administrative Head of Unit

Control or Process Description​

Please identify the highest risk system in your unit/environment and determine what would the impact be to UBC. Take into consideration the financial, reputational, operational, strategic and/ or academic impacts resulting from a cyber incident.

Why is this Essential?

The response identifies the severity of the impact due to a breach or a compromise of the highest-risk system in the unit or department

Reference Links​

Risk Register Guidelines & Instructions

Instructions​

Please use the Enterprise Risk Management - Severity of Impact sheet below to select the severity level that corresponds to the most significant type of impact.

Severity of Impact Rating:

Constituents include internal groups (e.g. students, faculty, and staff) and external groups (e.g. the Province of BC, the City of Vancouver, donors, the University Neighbourhoods Association, and other community groups).

What is Acceptable?

Identifying the highest risk system in the unit and an understanding what would the impact be to the University be if the highest risk system was compromised.

1. Information Systems Inventory

Do you have a process in place to maintain an inventory of UBC Information Services^ⓘ under your control?

Control or Process Description​

Do you have a process in place to keep a record of the tools used in the organized collection, processing, transmission, and dissemination of UBC's electronic information under your control.

From an Administrative Head of the unit's prospective, it is considered essential the inventory accurately captures the following information at minimum.

• Name of System / Information Repository
• Server Name(s)
• Key Operational Processes that the technology supports
• Process / System Owner
• Functional Area with-in the unit
• Impact Rating of the system/ application

Why is this Essential?

Understanding what you have is the first step in knowing how to protect it. Having an inventory of information systems, a description of the risk posed if compromised and the responsible parties for maintenance enables prioritization of security efforts to the highest-risk systems. Further, in larger IT portfolios, maintaining an inventory is a key step towards strategic planning around system life-cycling and aligning systems optimally with your specific needs. In the absence of an inventory with accountabilities for maintenance, it is likely systems may become orphaned (lack business and IT ownership) and would pose an increased risk to all of UBC.

From a Cybersecurity perspective, inventories support expediated incident response by involving the right system owners on time before it evolves into a serious incident.

Reference Links​

• Information Security Standards – U1 Security Classification of UBC Electronic Information
• Inventory of UBC-owned laptops and desktops

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 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 till the time there is a better process or mechanisms in place for your unit.

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?

A person (IT Representative or a System Owner within the unit) or a group (e.g. IT Team) has been delegated responsibility to maintain the asset inventory, or to update the unit's inventory and refreshes the inventory at a defined frequency.

2. Account & Permissions Management

Has management of User Accounts and Privileged accounts been clearly delegated to be handled by information stewards/owners for all systems under your control?

At a minimum this responsibility includes:

• Approval of new accounts
• Periodic reviews of user accounts
• Annual reviews of privileged accounts to validate that they remain restricted to authorized personnel.

Control or Process Description​

Every person in your unit is considered a User and each of those Users is the holder of an Account, which allows them to have access to UBC's network and systems. For example, to have a UBC email address, access to Workday, Sharepoint, OneDrive, Microsoft Teams etc. you will need a UBC-provided account. Every time someone new gets an account, typically the hiring manager needs to decide which systems they need access to, ideally not more or less than what he needs to do his job - that is what we call "least privileged, need-to-know job-function-basis". When someone changes jobs, or leaves UBC, those access need to be reviewed to ensure that the least privileged, need-to-know job-function-basis principles is still being observed for the new job or if access has been cut off, as the case may be.

UBC policy and standards require that, in addition, one or more people within the Unit is appointed to be the information steward, with delegated powers by the Administrative Head of Unit of Unit to manage and periodically review theses accesses to the Unit's various user accounts.

By answering yes to this question, you are stating that the accesses to your Unit's various User accounts (such as service accounts for running programs, system accounts for storing system files and administrator accounts for system administration, regular user accounts etc.) are handled by the information owners/ system owners for all the systems under your control.

In addition, you are stating that there is a process in place for the Information Owners/ System Owners ensure all accounts that have more privileges than ordinary users are reviewed at least annually. Examples of privileges these accounts might have are installing or removing software, upgrading the operating system, or modifying system or application configurations etc.

Why is this Essential?

User account onboarding, off-boarding processes along with periodical review of all accounts minimizes the risk of takeover of a system, unauthorized access, and preserves confidentiality, integrity and availability of the data, system and system settings. Furthermore, 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?

Each system has person(s) and a process for account management. They consider appropriate approval, periodic review that is done at least annually and deprecation. Further, for all systems and applications, the results of the review of accounts are communicated and documented.

3. Backup

Do you have a process or vendor agreement(s) to ensure data backup and recovery systems are in place for UBC Systems under your control?

Control or Process Description​

Every UBC System under my control has either:

• an internal process in place or
• a third-party agreement(s) executed to ensure that its data is backed up.
   

Why is this Essential?

Backups are an essential disaster recovery measure. Many events including including human error, hardware failure, software failure, malware, cyber attack, power failure, natural disasters, etc. can cause loss of date/systems.

This is a safeguard to prevent data loss should any of these events occur and there is not other way to restore data/systems.

Reference Links​

• Policy SC14 - Acceptable Use and Security of UBC Electronic Information and Systems
• Information Security Standards – U7 – Securing Computing and Mobile Storage Devices/Media
• Privacy Matters @UBC – Back up my data
• Backups - Information Security Guideline

Instructions​

N/A

What is Acceptable?

All systems managed by UBC IT have a written Service Level Commitment (SLC) covering backup requirements.

Cloud service agreement or contracts have been reviewed to ensure appropriate backup and recovery measures are in place. If self-managed, backups are run and tested.

4. Incident Reporting

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

Control or Process Description​

I report all occurrences 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 in my unit.

Why is this Essential?

Reporting potential security incidents in a timely manner allow the incident to be assessed and contained promptly. Further, visibility of incidents support the cybersecurity team in adjusting the response to a greater 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 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 that a staff receives or a pop up on their computer screen that wants the user to contact a 1800 number or a pop-up that asks for ransom, etc. should all be reported to security@ubc.ca for analysis.

What is Acceptable?

I am aware, and periodic reminders are communicated e.g. when minor incidents happen, or there are broader incidents at UBC/the world.

5. Training

Have you informed users and IT Support Staff within your unit of the importance of adhering to the Information Systems Policy and confirmed that they have completed both "Privacy & Information Security - Fundamentals" courses and "Privacy & Information Security - IT Professionals" training, as applicable to their role?

Control or Process Description​

I 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, contractors, student appointments) 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​

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

Instructions​

Training reporting can be generated by following the self-help instructions below.
How to Create Privacy Course Reports

The Administrative Head of Unit and the IT Representative should evaluate the report for accuracy and use the information to follow up with users. Please reach out to "UBC PrISM Compliance(prism.compliance@ubc.ca) to report inconsistencies or if any questions.

Reporting in relation to contractors is not available.

What is Acceptable?

Training compliance stats have been reviewed and reminders have been sent. Although the expectation is the unit is 100% compliant achieving over 85% within reports can be considered a 'yes' from a compliance reporting perspective

6. Variances

Are users and IT Support Staff in your unit aware of the requirement for Administrative Heads of Units to request variances from the Information Security Standards and will they inform you when they believe one is required?

Control or Process Description​

There is an ongoing process to set the expectation (e.g. through ongoing communications/ questioning) that the Administrative Head of Unit be made aware of significant non-compliance with UBC's Information Security Standards.

Why is this Essential?

IT Representatives/ System Owners, or a custodian of data or system are aware of the requirements pertaining to security requirements (policies, standards and controls). Especially, in understanding the risks of being non-compliant.

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.

Reference Links​

• Information Security Standards – M1 Requesting Variances from Information Security Standards

Instructions​

Examples of Variance:

• 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 virtual 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?

The Administrative Head of Unit and corresponding IT Representative, Technical System Custodian within the unit and System Owners actively discuss compliance with the Information Security Standards(ISS). When for operational reasons unable to comply to an ISS, they are reported to the Administrative Head of Units. The Administrative Head of Units are encouraged to seek a variance/support with the CIO.

7. Privacy Impact Assessment

Are Users and IT Support Staff in this Unit aware and held accountable for conducting Privacy Impact Assessments?

Control or Process Description​

Are Privacy Impact Assessments conducted for all new or substantially modified projects. A “project” refers to any system, process, program or activity that supports University business.

Why is this Essential?

It is the project owners responsibility to conduct a Privacy Impact Assessment (PIA), working in collaboration with the PrISM team. PIA requests should be submitted as early as possible within a project when enough is know to submit the request. This should be around the business case stage and before a contract is signed. The PIA will usually be completed around the time of the project going live.

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 – PIA

Instructions​

To learn how to initiate a PIA , visit Privacy Matters @UBC – PIA

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.

8. Security & Confidentiality Agreement

"Are Users and IT Support Staff in this Unit held accountable for obtaining a Security and Confidentiality Agreement (SACA) before any Service Provider is granted access to Medium, High or Very-High risk UBC Electronic Information and Systems?"

Control or Process Description​

The Administrative Head of Unit should set a clear expectation that SACAs be put in place where required.

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

Why is this Essential?

Signed SACAs both set clear expectations with vendors on their responsibilities relating to UBC information and systems as well 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
• Office of the University Counsel/ Protection of Privacy/ Security and Confidentiality Agreements

Instructions​

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

The Administrative Head of Unit must be comfortable that the unit is aware of this requirement and in most circumstances will request a SACA.

For any individual vendor either a SACA is signed, or a waiver is obtained from University Counsel where equivalent privacy and security language exists.

9. Log Management

Are IT Support Staff in this Unit aware and held accountable for ensuring that server logs are captured, retained and monitored in accordance with the Logging and Monitoring of UBC Systems standard? In addition, if your unit manages an ERP, are application logs for these captured, retained and monitored?

Control or Process Description​

For most departments, logging at the server level will be done by an IT support function or a cloud service provider. The Administrative Head should set this expectation using Service Level Agreements with third parties or by specifying this requirement with internal service providers or staff.

Why is this Essential?

A log is a record of the events occurring within 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?

• Assurance exits that the following logging is in place for all servers:
       1. User login, logout and access to a resource;
       2. Action performed by the User and the time it was performed;
       3. Where feasible, any access to, or modification of, records.
• Assurance usually takes the following form:
  • Cloud Service Provider:
    • Contract or Service Level Agreement. If not available, written assurance will suffice.
  • UBC IT Service Provider or staff:
    • Service Level Commitment with UBC IT for systems supported by the UBC IT team.
    • If a system is managed with-in the unit, the system owner is tasked to configure logging and monitoring in accordance to the Logging and Monitoring requirements as prescribed in the Information Security Standard M8.

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

Control or Process Description​

UBC Treasury maintains PCI compliance for UBC. Units are expected to work with Treasury to evaluate the most efficient way to be PCI compliant and to maintain compliance on an ongoing basis

Why is this Essential?

PCI-DSS is an industry standard for payment card handling enforced by acquiring banks and PCI Security standards council. It prevents a threat actor from accessing cardholder data (CHD) and using it to commit fraud, which affects consumer confidence and damages your reputation as a merchant. Non-compliance exposes 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 project that requires:

• anyone who stores, process or transmit 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 IS applicable to you.

What is Acceptable?

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

11. Website Naming

Are all UBC web application services provisioned within this Unit in the ubc.ca domain name space (e.g. instead of widgets.com, we use widgets.ubc.ca), unless not technically possible?

Control or Process Description​

The Unit's staff and faculty are aware that UBC services provisioned within the unit should utilize ubc.ca domain space unless where it is not possible due to technical limitations (e.g. certain SAAS applications).

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​

• Information Security Standards – M11 Development and Modification of Software Applications
• myDNS FAQs
• Subdomain Registration

Instructions​

N/A

What is Acceptable?

Staff/IT support staffs likely to provision websites/web applications are aware that all applications/sites are in the UBC domain space (unless this has been validated to not be technically possible).