WSB Policy: Information Technology Access Control & User Management

Purpose

Protecting access to IT systems and applications is critical to maintain the integrity of the World Scout Bureau’s (WSB) technology and data and to prevent unauthorised access to such resources.

Access controls are necessary to ensure only authorized users can obtain access to the WSB’s information and systems therefore, access to WSB’s systems must be restricted to only authorized users or processes, based on the principle of strict need to know and least privilege.

Access controls manage the admittance of users to system and network resources by granting users access only to the specific resources they require to complete their job-related duties.

The objective of this policy is to ensure the WSB has adequate controls to restrict access to systems and data.

Scope

This policy represents the WSB’s official position and works in conjunction with all other relevant policies which may be developed at a local level. This policy applies to:

• All WSB Support Centres globally.
• All WSB Responsible & Relevant IT support staff.
• All IT systems or applications managed by WSB that store, process or transmit information, including network and computer hardware, software and applications.

Definitions

A list of terms used throughout this policy are defined in Appendix A.

Policy Guidelines – General Requirements

1. The WSB will provide access privileges to the WSB’s technology (including networks, systems, applications, computers and mobile devices) based on the following principles:
   • • Need to know – users or resources will be granted access to systems that are necessary to fulfil their roles and responsibilities.
     • Least privilege – users or resources will be provided with the minimum privileges necessary to fulfil their roles and responsibilities.
2. Requests for users’ accounts and access privileges must be formally documented and appropriately approved.
3. Requests for special accounts and privileges (such as vendor accounts, application and service accounts, system administration accounts, shared / generic accounts, test accounts and remote access) must be formally documented and approved by the product owner.
4. Application and service accounts must only be used by application components requiring authentication; access to the passwords must be restricted to authorized IT administrators or application developers only.
5. Access rights will be immediately disabled or removed when the user is terminated or ceases to have a legitimate reason to access WSB systems.
6. A verification of the user’s identity must be performed by the WSB Responsible IT staff or designate before granting a new password.
7. Existing user accounts and access rights will be reviewed at least annually to detect dormant accounts and accounts with excessive privileges. Examples of accounts with excessive privileges include:
   • • An active account assigned to external contractors, vendors or employees that no longer work for the WSB.
     • An active account with access rights for which the user’s role and responsibilities do not require access. For example, users that do not have authority or responsibility to approve expenses should not have access with approval permissions within a financial system.
     • System administrative rights or permissions (including permissions to change the security settings or performance settings of a system) granted to a user who is not an administrator.
     • Unknown active accounts.
     • All access requests for system and application accounts and permissions will be documented using the procedure set by the IT team in place.

Policy Guidelines – Privileged Accounts

1. A nominative and individual privileged user account must be created for administrator accounts (such as “first_name.last_name.admin”), instead of generic administrator account names.
2. Privileged user accounts can only be requested by managers or supervisors and must be appropriately approved by 2 members of the SMT and a proper document trail (electronic or otherwise) is to be maintained.
3. All privileged accounts are to be reviewed annually.

Policy Guidelines – Shared User Accounts

1. Where possible, the use of specific network domain “security groups” should be used to share common access permissions across many users, instead of shared accounts.
2. Shared user accounts are only to be used on an exception basis with the appropriate approval. This includes general user accounts such as “guest” and “functional” accounts.
3. When shared accounts are required:
   • • Passwords will be stored and handled in accordance with the Password Policy.
     • The use of shared accounts will be monitored where possible, including the recording of the time of access, the reason for accessing the shared user account, and the individual accessing his account. When the shared user account has administrative privileges, such a procedure is mandatory and access to the monitoring logs must be protected and restricted.

Policy Guidelines – Vendor or Default User Accounts

Where possible, all default user accounts will be disabled or changed. These accounts include “guest”, “temp”, “admin”, “Administrator”, and any other commonly known or used default accounts, as well as related default passwords used by vendors on commercial-off-the-shelf (COTS) systems and applications.

Policy Guidelines – Test Accounts

1. Test accounts can only be created if they are justified by the relevant business area or project team and approved by the application owner, through a formal request to the WSB Responsible IT personnel or the IT Help Desk.
2. Test accounts must have an expiry date (maximum of 6 months). Maintaining test accounts beyond this date must be re-evaluated every 90 days and approved appropriately.
3. Test accounts will be disabled / deleted when they are no longer necessary.

Policy Guidelines – Vendor & Contractors

1. Contracts with contractors / vendors will include specific requirements for the protection of data. In addition, contractor / vendor representatives will be required to sign a Non-disclosure Agreement (NDA) prior to obtaining approval to access WSB’s systems and applications.
2. Prior to granting access rights to a contractor / vendor, the WSB Responsible IT personnel or Help Desk must verify the requirements of Section 9a have been complied with.
3. The name of the contractor / vendor representative must be communicated to the IT Help Desk at least 2 business days before the person needs access.
4. The WSB will maintain a current list of external contractors or vendors having access to all WSB’s systems.
5. The need to terminate the access privileges of the contractor / vendor must be communicated to the IT Help Desk at least 1 business day before the contractor / vendor representative’s need for such access ends.

Policy Guidelines – Access Control Requirements

1. All users must use a unique ID to access WSB systems and applications. Passwords must be set in accordance with the Password Policy.
2. Alternative authentication mechanisms that do not rely on a unique ID and password must be formally approved.
3. Where possible, the use two-factor authentication is strongly recommended.
4. System and application sessions must automatically lock after 15 minutes of inactivity.

Roles & Responsibilities

Policy Distribution & Awareness

This policy and it's supporting policies, standards and guidelines will be published on the WSB Dropbox.

Soft copies of the policy and its supporting policies, standards and guidelines will be available on WSB Staff Support Center.

The IT Personnel and/or the Senior Manager, Digital & IT Services may make periodic policy announcements by email.

WSB line managers will ensure that all existing and new staff, contractors, consultants, interns, volunteers and third-party commercial service providers who report to them are made aware of and have access to the policy and its supporting policies, standards and guidelines.

Individuals requiring clarification on any aspect of the policy and its supporting policies, standards and guidelines and/or advice on general I.T. security matters may email their queries to the Senior Manager, Digital & IT Services or the local IT Personnel.

Exceptions to this Policy

Exceptions to the guiding principles in this policy must be documented and formally approved by the Global Director, Communications , with evidence of support from the appropriate Senior Management Team.

Policy exceptions must describe:

• The nature of the exception.
• A reasonable explanation for why the policy exception is required
• Any risks created by the policy exception.
• Evidence of approval.

Policy Enforcement

The WSB reserves the right to take such action as it deems appropriate against individuals who breach the conditions of this policy. WSB staff, contractors, consultants, interns and volunteers who breach this policy maybe subject to disciplinary action, including suspension and dismissal as provided for in the WSB disciplinary procedure.

Breaches of this policy by a third-party commercial service provider, may lead to the withdrawal of WSB information technology resources to that third party commercial service provider and/or the cancellation of any contract(s) between the WSB and the third-party commercial service provider.

The WSB reserves the right to refer any use of its IT resources for illegal activities to the relevant Authorities.

Review & Update

This policy will be reviewed and updated annually or more frequently if necessary, to ensure any changes to the WSB’s organisation structure and business practices are properly reflected in the policy.

Appendix A: Definitions

Access Control: the process that limits and controls access to resources of a computer system.

Users are students, employees, consultants, contractors, agents and authorized users accessing WSB systems and applications.

System or Application Accounts:  Are user ID’s created on IT systems or applications, which are associated with specific access privileges on such systems and applications.

Privileged Accounts: Are system or application accounts that have advanced permissions (as compared to regular user account permissions) on such systems or applications. Examples of user accounts with privileges include administrative and super user accounts.

Access Privileges: Systems permissions associated with an account, including permissions to access or change data, to process transactions, create or change settings, etc.

Administrator Account: A user account with privileges that have advanced permissions on an IT system that are necessary for the administration of this system. For example, an administrator account can create new users, change account permissions, modify security settings such as password settings, modify system logs, etc.

Application and Service Accounts: User accounts that are not associated with a person but an IT system, an application (or a specific part of an application) or a network service.

Nominative User Accounts: User accounts that are named after a person.

Non-disclosure Agreement: A contract between a person/organisation and the WSB stating that the person/organisation will protect confidential information covered by the contract, when this person/organisation has been exposed to such information