Account & Permissions Management
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 ManagementData 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 ManagementData 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 AccountsInstructions
N/A
What is Acceptable?
There is an operational process or procedure in place to change 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 RequirementsCreating 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 RequirementsGuidelines
Instructions
Passwords should be stored using a strong cryptographic hash and salted to make it difficult for an adversary to crack password 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.