access management standard - whatdotheyknow

Access Management Standard

Title: Access Management Standard

Version: 1.0

Status: PUBLISHED 12/02/2013

Category RESTRICTED

Author:

Contact: [email protected]

RESTRICTED

RESTRICTED


IT Services / Access Management Standard2 / PUBLISHED 12/02/2013

of 17

Contents

1 Introduction ................................................................................................... 3

1.1 Background 3

1.2 Purpose 3

1.3 Scope and Applicability 3

1.4 Compliance 4

1.5 Controls 4

2 Access Control Documentation ....................................................................... 4

3 Identification Assignment and Management .................................................. 5

3.1 Standard User Accounts 6

3.2 Personal Privileged and Service Specific Accounts 6

3.3 Generic Accounts 6

4 Authentication Credential Management ........................................................ 7

4.1 Authentication Credential Controls 7

4.2 Authentication Credential Establishment 8

4.3 Authentication Credential Resets 10

5 Authorisation Management ......................................................................... 10

5.1 Access Administration 10

5.2 Access Rights 11

5.3 Privileged & Emergency Access 11

5.3.1 Privileged access 11

5.3.2 Emergency Access 12

5.4 Single Sign-On 12

6 Secure Logon ................................................................................................ 13

7 Physical Access Management ....................................................................... 13

7.1 Data Centres 13

7.2 Server and Technical Rooms 14

Glossary .............................................................................................................. 15

References .......................................................................................................... 16

Appendix A – Password Advice ............................................................................ 16

RESTRICTED



of 17

Document Control

Revision Date Author Release Notes

0.1 20-12-2011 Initial Draft

0.2 07-03-2012 Draft

0.3 30-04-2011 Added sections on Single Sign On and Remote

Access, issued for formal review

0.4 22-05-2012 Updated from review comments at ISSG 27-05-

2012 and following review cycle.

0.5 12-12-2012 Updated from comments in 2nd

review cycle.

0.6 18-01-2013 Revised according to review comments.

1.0 12-02-2013 Published

1 Introduction

1.1 Background

The University operates in a highly competitive global market for students, staff and research

funding in which information is a valuable asset, a significant amount of which is commercially

sensitive. At the same time the University must comply with the law and protect its interests –

avoiding or mitigating the risk of damage or prejudice resulting from unauthorised or accidental

disclosure, modification or destruction of information.

Information security, or information assurance, is concerned with maximising the business benefit

conferred by information while ensuring that the University also fulfils its legal and contractual

obligations by balancing the demands of:

Confidentiality – preserving authorised restrictions on information access and disclosure,

including means of preserving personal privacy and proprietary information. A loss of

confidentiality is the unauthorised disclosure of information.

Integrity – guarding against improper information falsification, modification or destruction,

and includes ensuring information non-repudiation and authenticity. A loss of integrity is the

falsification, unauthorised modification or destruction of information assets.

Availability – ensuring that information is made available as and when required for the

University to conduct its business properly and without delay. Information that is not

available may be secure but has no value if it is inaccessible.

1.2 Purpose

This Standard establishes control requirements to protect information assets against unauthorised use,

processing, disclosure, modification, damage or loss by ensuring that access to systems, data and

programs is restricted to authorised users in a controlled manner. It supplements and expands Section 5

of the University of Birmingham Information Security Policy (ISP)[1].

1.3 Scope and Applicability

This Standard is derived from the University of Birmingham Information Security Policy (ISP) [1] and

its associated documentation set. The Standard is ratified by the Information Security Steering Group

(ISSG).

This Standard applies to all members of the University and, as determined by Legal Services and/or IT

Services, to partners, third parties, external contractors, contingent workers, and other contributors,

having access to the University‟s information resources.

RESTRICTED



of 17

Control requirements in this Standard are defined to avoid breaches of any law, statutory, regulatory or

contractual obligations. Where local laws and regulations require controls that are more restrictive than

those identified in this Standard, those control requirements must be applied.

The terminology used in this document conforms to the Information Security Glossary [3]. The

requirements are stated using the MoSCoW [3] prioritisation scheme in the following sections.

1.4 Compliance

Policies and Standards are written with specific and precise language intended to ensure that they

contain identifiable and measurable indicators that facilitate compliance. Refer to the Information

Security Glossary [2] for the definitions of the terms used in this document.

Accountability for ensuring compliance with this Standard and for ensuring that relevant processes are

monitored for compliance as a part of routine operational support activities, lies with the appropriate

Senior Officer or Director.

1.5 Controls

Adoption of this Standard wholly satisfies A.11 “Access Control” of ISO 27001:200 [3] and also

satisfies or contributes to the following additional controls:

A.7.1.3 Asset management: Acceptable use of assets

A.8.1.1 Human resources security: Roles and responsibilities

A.8.3.3 Human resources security: Removal of access rights

A.10.1.1 Communications and operations management: Documented operating procedures

A.10.1.3 Communications and operations management: Segregation of duties

A.10.1.4 Communications and operations management: Separation of development, test and

operational facilities

A.10.3.2 Communications and operations management: System acceptance

A.10.6.2 Communications and operations management: Security of network services

A.10.7.3 Communications and operations management: Information handling procedures

A.10.8.1 Communications and operations management: Information exchange policies and

procedures

A.10.8.5 Communications and operations management: Business information systems

A.10.10.4 Communications and operations management: Administrator and operator logs

A.11 [all] Access control

A.15.1.5 Compliance: Prevention of misuse of information processing facilities

2 Access Control Documentation

Objective: Document security and control requirements for specific systems and services, and facilitate security assessment

1. Access control documentation must be provided and maintained for all systems and services

before go-live.

2. Access control documentation should include procedures covering all stages in the lifecycle of

user access, including:

a. Initial registration of new users.

b. Access changes for existing users.

RESTRICTED



of 17

c. Revocation of capabilities for users who no longer require access to information

systems and services.

d. Transfer, Recertification and Reconciliation processes.

3. Access Control Documentation should identify:

a. The Information Owner.

b. Any delegate(s) and their responsibilities.

c. The Access Administrator(s).

d. Any generic accounts, including built-in and default User IDs, provided with vendor-

supplied systems and their status in the live service (disabled, removed or active).

e. Procedure(s) to grant users authorised access to production and non-production

business, technical support, and access administration functions, including:

i. Access profiles by role or function.

ii. Specific roles holding privileged access, where applicable.

f. Emergency access protocol and procedures.

g. Application- or system-specific security event logging and monitoring requirements, as

needed, to detect and respond to anomalous activity.

h. Retention requirements for documentation.

4. Access Control Documentation must not contain passwords or other credentials, authentication

or keying material.

3 Identification Assignment and Management

Objective: Prevent unauthorised access by ensuring that each user is assigned a unique identifier for accessing a system or service that is based upon specified responsibilities.

Objective: Prevent unauthorised access and facilitate incident detection and response by ensuring that each account used to obtain access to information resources is traceable to an owner and maintained in a centralised repository.

1. Every member of the University, having access to the University‟s information resources, computing and/or network facilities, must be assigned a unique User ID for their personal

and sole use, stored in a centralised identity and access management (IAM) system.

2. Every User ID should be named according to a consistent convention, where possible. The User

ID is not secret or confidential. Its purpose is to identify a person and therefore it must be

unique.

3. Users must not share User IDs and or allow others to know their passwords, PINS or other

authentication factors in order to preserve traceability. If the confidentiality of a password or

PIN is compromised, then the owner must change it without delay.

4. Users must protect private keys issued to them by the University‟s Public key Infrastructure

(PKI) and request a new key if they suspect that the private key has been compromised in any

way.

5. Every user having a smartcard, or similar device, that contains a certificate issued by the

University‟s PKI must protect it and not allow its use by any other person.

RESTRICTED



of 17

3.1 Standard User Accounts

User ID is used for an identity that represents a person and system identifiers (System ID) represents a

system. System IDs are used for system to system communications.

The following control requirements concern User IDs that are assigned to a specific individual for their

sole use.

1. The user‟s personal User ID should be used, where practical, to provide access to all

University services.

2. User IDs assigned for the personal and sole use of an individual must not be reassigned

from one individual to another or otherwise re-used.

3. User IDs should not provide an indication of the exact privilege level (e.g., manager,

supervisor, or administrator).

4. Multiple User IDs could be assigned to an individual for the purposes of segregation of

duties, e.g. an individual may hold additional personal accounts within a system or service

to allow for elevated privilege.

5. User IDs that are used to input or display confidential credit card information and thus

become subject to the Payment Card Industry Data Security Standard (PCI-DSS) should be

deleted after 90 days of inactivity or have all privileges removed if kept for audit purposes.

6. Heads of Schools and Directors, or their delegates, must ensure that an access revocation

request is initiated to the Access Administrators when a user leaves their authorised role.

3.2 Personal Privileged and Service Specific Accounts

For the purposes of segregation of duties, an individual may hold additional personal accounts for a

specific system to allow for elevated privilege or where it is not possible to use standard user

accounts.

1. All controls specified for standard user accounts must be applied.

2. Where the standard user account cannot be defined to specific system or service, a reference

should be included to the standard User ID. This will likely demand notation or labelling.

3. Where feasible, access should be limited to authenticated users (those who have already signed-

on to their standard user accounts).

3.3 Generic Accounts

Generic accounts do not belong to a specific person but may be used by anyone who has the

necessary credentials. Use of generic accounts is discouraged because they weaken detective controls

by reducing traceability and preventing non-repudiation.

Generic User IDs are not assigned to a specific individual for use, although they will have a specified

individual who holds accountability for them. They should not be used in place of standard user

accounts; however there are legitimate circumstances where they may be used.

ID Type Description

System ID System IDs are special accounts used by systems to access other systems

without human intervention. Except for testing and security verification

purposes, they should not be used by human operators. System IDs used for

system to system interactions should limited in scope to a single

system/system pair in line with the principle of least privilege.

Test ID IDs used for testing that are to be defined and employed in development or

testing environments only.

Training ID Limited functionality IDs allowed only in controlled-access training environments.

RESTRICTED



of 17

ID Type Description

Guest ID Limited functionality IDs allowed only in controlled-access environments for a

specified, limited period.

Shared ID Shared IDs with production access but limited to specified functions, such as

group mailboxes.

1. Generic accounts must not be used where standard user accounts could have been used instead.

2. Generic accounts needed purely for development and testing must be deleted or disabled before

a system goes live.

3. Where feasible, access to generic accounts should be limited to authenticated users (those who

have already signed-on to their standard user accounts).

4. Additional controls should be implemented for generic accounts including manual procedures

for recording usage and ensuring that no single person has exclusive access.

4 Authentication Credential Management

Authentication credentials are generally divided into three categories or „factors‟.

Factor Example

Known by the user Password, Passphrase, PIN, private key

Held by the user Smartcard, hard token, digital certificate, ATM card, identity badge

Attribute of the user Biometric, such as fingerprint, retinal image, palm telemetry, facial pattern

Single factor authentication involves presentation from one of these three categories.

Multifactor authentication, sometimes called strong authentication, involves presentation of

more than one of these categories.

In order for multifactor authentication to provide significantly higher assurance, the following should be

considered as requirements:

Factors that are not subject to the same attack vectors.

Factors unlikely to be obtained together.

Factors that cannot easily be forged, and will remain resistant to threat over time.

The need to remember and manage passwords constitutes a vulnerability in itself and alternative factors

should be used where it is feasible and appropriate to do so.

4.1 Authentication Credential Controls

Objective: Prevent unauthorised access by implementing controls to authenticate all users to the system prior to gaining access

Objective: Prevent unauthorised access by implementing controls that ensure the effectiveness of authentication and access mechanisms, and to prevent the fraudulent use of authentication credentials

Objective: Ensure functions that require a higher level of authentication assurance are identified and that multifactor authentication is implemented for such functions

1. Passwords must be a minimum of eight (8) characters in length.

2. Users holding multiple separate User IDs and/or credentials for systems or services should

employ different passwords or PINs for each.

RESTRICTED



of 17

3. Passwords and User IDs used for accessing University services should not be reused outside

the University and those used outside should not be reused for University services.

4. Secure authentication processes employing single factor authentication in the form of passwords

should also enforce the following:

a. Passwords should be as „strong‟ as possible, containing at least one uppercase letter, at

least one lower case letter and at least one numeric digit. Appendix A contains advice

on creating strong passwords.

b. If the user did not establish the initial password, the system should require the user to

change the password during the first authentication.

c. Users should be permitted to change their own password at any time that they are

allowed to access the services protected by the password.

d. The change process for authentication credentials should require confirmation entry of

the user‟s current authentication credential or a predefined shared secret.

e. The change process for authentication credentials should require the user to confirm the

new authentication credentials.

f. User passwords should be set to expire after 180 days and the user required to input a

new password before access is granted.

g. Passwords should not match the previous ten (10) passwords. Systems must not store

passwords in plain text, or in a form that can be rendered into plain text, in order to

enforce this.

5. Secure authentication processes employing multifactor authentication should enforce a

minimum of four characters for the user-known authentication credentials, when the

authentication combines both:

A one-time password generator, such as a hard token; and,

Something that the user knows, such as a password or PIN.

4.2 Authentication Credential Establishment

This section describes controls that govern shared secrets used in the process of initially authenticating a

particular user. Shared secrets include but are not limited to passwords, passphrases and symmetric

cryptographic keys.

Objective: Control the initial phase of the process for distributing authentication credentials distributed in the form of shared secrets

Objective: Protect users from unauthorised re-assignment of authentication credentials when their characteristics change, e.g. when they are granted access to a service and require redistribution of fresh authentication credentials

1. Access Administrators must establish and implement processes to control the creation and

communication of initial authentication credentials.

a. Processes and controls must be defined and documented as part of the Access Control

Documentation for systems or services in which the user does not activate their own

User ID or establish initial authentication credentials.

b. Services in which the User IDs are self-activated must include processes and controls

that ensure the authentication credentials remain confidential between the user and

University services.

2. If the process includes cryptography, then the means of cryptography must comply with the

Cryptography Standard [4].

RESTRICTED



of 17

3. Initial shared secrets, passwords and PINs created by University services must comply with

secure authentication requirements. University systems or services must not establish rules for

distributing initial credentials with any of the following characteristics:

a. The same initial credential assigned to multiple User IDs, or initial credential that is

easily guessed from known information.

b. The user‟s name.

c. The User ID to which the password is assigned.

d. The assigned user‟s national insurance number, Staff-ID or other personally

identifiable information or data.

e. The assigned user‟s full telephone number or any recognisable portion of the telephone

number, such as internal extension number.

f. The assigned user‟s full date of birth, or any recognisable portion of the date of birth.

4. Shared secrets, passwords, and PINs must have documented controls establishing format,

length, and other restrictions.

a. PINs associated with multifactor authentication must be at least four digits long.

b. Passwords for systems where the User ID has access to confidential information or to

functionality that could compromise the integrity of confidential information:

i. If the user did not establish the initial password, the system must require the

user to change the password during the first authentication.

ii. Users should be permitted to change their own password at any time.

iii. The change process for passwords should require confirmation of the user‟s

current password or a predefined shared secret.

iv. Users must confirm changes to passwords.

v. Users should be prompted to change passwords at least every 180 days, or from

the next log-in if longer. The user‟s account may be disabled or restricted if the

password change prompt is ignored ten or more times.

vi. Passwords must not match the previous ten passwords.

5. Initial authentication credentials must be communicated only to the user, or Access

Administrator associated with the service.

6. Initial authentication credentials that are not provided to the authorised user in person must be

communicated using one of the following methods:

a. Interoffice, courier, or internal mail, in a sealed envelope marked Confidential –

preferably placed inside another envelope not so marked.

b. Encrypted data communications, including email, both within and outside the

University network. All keys and credentials used to decrypt the communication must

be distributed in accordance with this Standard and the Cryptography Standard [6].

c. In addition to the communication methods for initial authentication credentials that are

allowed in all cases, if the User ID has no access to Confidential information, then the

following additional communication methods may be used:

i. Left in the assigned user‟s telephone voice mailbox for situations in which

communication/delivery of the initial authentication credentials is time-

sensitive.

ii. Over the telephone, after authenticating the user in accordance with the other

authentication methods section in this document.

RESTRICTED



of 17

7. Initial authentication credentials that are not provided to the authorised user in person and are

used as part of multi-factor authentication model (e.g., PINs and hard tokens) must be

communicated separately.

8. Security audit logs must be protected (for confidentiality and integrity), and should include the

following:

a. The User ID for which the authentication credential was set.

b. The User ID of the Access Administrator that processed the request.

c. The date and time that the credential was set.

d. The system or service within and for which the authentication credential was set.

4.3 Authentication Credential Resets

This section describes the control requirements associated with resetting forgotten, disabled or expired

authentication credentials.

Objective: Ensure that authentication credentials that are re-issued as the result of a user forgetting or losing their credentials are provided to an authorised individual.

1. Processes to reset forgotten or lost authentication credentials must be documented and

implemented.

2. Authentication credentials should be requested and received only by the owning user.

3. Users must provide answers to shared secret questions to establish their authenticity for

credential reset. Users should be prompted to select questions with answers that are not widely

known.

4. Current or prior authentication credentials must not be divulged by the Access Administrator.

5. Forgotten or lost authentication credentials must be reset to a new value by the Access

Administrator.

6. Security audit logs must be protected (for confidentiality and integrity), and must include:

The User ID for which the authentication credential is being reset.

The User ID of the Access Administrator that processed the reset.

The date and time that the credential was reset.

The system or service within and for which the authentication credential was reset.

5 Authorisation Management

This section describes the control requirements associated with adding, changing, or removing user

access to information assets and assuring appropriate access levels are assigned to User IDs.

Objective: Prevent unauthorised access to information resources by implementing controls that ensure the timely and controlled action relating to requesting, establishing, issuing, suspending and closing User IDs

Objective: Protect systems against unauthorised access by restricting access to system resources and data to the minimum required for work to be performed

5.1 Access Administration

1. Access administrators must reference the centralised identity management system as the

definitive source to manage user access provisioning and de-provisioning functions.

RESTRICTED



of 17

2. Access administrators must ensure that access for University members who have terminated

employment, study, contractual engagement or retired is restricted to systems and services

approved for non-active University members.

3. Access administrators must ensure that access for temporary or contingent University members

who have terminated employment, study, contractual engagement is removed.

4. Access for University members whose credentials pose an immediate threat to the security of

information assets, must be suspended forthwith, under authorisation of the Director of IT

Services or delegate.

5. Access provisioning processes should include approval by a suitably authorised person prior to

adding, changing, or removing access.

6. Access rights for users who change job function or role within the University should be

reviewed and changed to reflect the new job function or role.

7. Documentation (audit trails) should be maintained that include:

a. Who approved the access, change, disablement, or deletion?

b. When it was approved?

c. Who processed the access, change, disablement, or deletion?

d. When it was processed?

5.2 Access Rights

This section describes controls necessary to safeguard and limit access to information, system

resources and data.

1. Processes must be established for both the granting appropriate access rights and for the

purpose of establishing those legitimate activities. This process should include:

a. An enrolment process to add new users to the system.

b. Authorisation processes to add, delete, or modify authorised user access to systems.

2. Authorised user access must be granted for the user‟s individual User ID and restricted to

information resources and functions that the user needs to fulfil their assigned duties.

3. User access should be provided via group or role-based administration.

5.3 Privileged & Emergency Access

Objective: Establish a common definition for Privileged and Emergency Access.

Objective: Ensure that capabilities that inherently allow a user to override one or more system controls are adequately managed and monitored.

Objective: Ensure that accountability is adequately maintained for System IDs that can inherently override system controls.

5.3.1 Privileged access

Privileged access refers to a greater level of access granted to a normal user of a system or service

and in the case of system administrators may mean „root‟ and „administrator‟ privileges.

1. Users must be granted the level of privileged capabilities necessary to perform their

assigned job duties or functions.

2. Privileged access for a given system must be documented.

3. Privileged system access must be given to at least two systems administrators for any given

system.

RESTRICTED



of 17

5.3.2 Emergency Access

Emergency access refers to a process by which users are temporarily granted capabilities that can

inherently override system controls, when such capabilities exceed the access needed by the user to

perform their normally assigned job duties on an on-going basis.

Emergency work by users who do not require more access they already have in order to perform

their normally assigned job duties is covered by the normal privileged access arrangements.

The emergency access process may be used to temporarily elevate a User ID‟s access, or temporarily

facilitate use of a System ID that has elevated privilege.

Examples of User IDs that are commonly accessed by invoking an emergency access procedure

include, but are not limited to:

„root‟ on Unix/Linux systems

„administrator‟ on Windows systems

4. The emergency access process must be documented.

5. Emergency access must be invoked according to the documented procedure to provide users

with capabilities that can inherently override system controls (either via the user‟s personal

User ID or via a System ID), when such capabilities exceed the access needed by the user to

perform their assigned job duties or function.

6. All access granted via an emergency access procedure must record:

a. The approver of the access;

b. To whom the access was granted;

c. The intended purpose or need for the access;

d. The system(s) on which the access was granted;

e. When the access was granted and revoked (date/time).

7. Emergency access should be granted for the minimum reasonable period of time to address

the intended purpose.

8. Emergency access processes that facilitate access to User IDs must ensure that:

a. A limited list of individuals approved to use the ID is maintained;

b. Information owners are identified for notification/approval;

c. ID and authentication credentials are stored securely;

d. Authentication credentials are changed after each use;

e. Strict accountability is maintained to attribute activities to a specific individual at

any given time

5.4 Single Sign-On

Single Sign-On (SSO) is where the user is required to authenticate themselves once only (e.g. by

signing on to Windows or the portal) and are not forced to re-input their credentials when accessing

services that participate in SSO.

Objective: Ensure users are authenticated before granting access to sensitive information while promoting information availability by eliminating multiple sign-on operations.

1. All services should participate in SSO if technically feasible.

Note: The University‟s single sign-on system is based on Microsoft Active Directory but „plug-in‟

components are available that allow Linux and Unix systems to integrate using Kerberos, SAML or

LDAP protocols.

RESTRICTED



of 17

6 Secure Logon

Secure logon must be used for any access to confidential information or where functionality is

exposed that may compromise the integrity of confidential information.

1. All user authentication methods used in a secure logon process must employ a minimum of

single factor authentication.

2. Risk assessments should be performed to determine whether multifactor authentication

within a system is to be used. Regulatory requirements may make risk assessments

mandatory.

3. Where risk assessments indicate that the use of single-factor authentication is inadequate,

multifactor authentication must be implemented. Regulatory requirements may make risk

multifactor authentication mandatory.

4. Secure logon processes must not display authentication credentials (e.g., passwords, PINs,

etc., on the screen), although User IDs can be displayed

5. Authentication credentials should be validated only on completion of all data input and error

conditions should not provide information that indicates which fields (e.g., User ID,

password, PIN) are incorrect.

6. User IDs should be disabled after five consecutive sign-on attempts, at which time the User

ID should remain disabled until re-enabled via a compliant process.

7. Access points that require secure logon should force users to validate their identification and

authentication credentials after a maximum of 15 minutes of inactivity.

7 Physical Access Management

The requirements concerning University data centres, server rooms and other technical areas vary

according to the type and quantity of equipment and information assets stored within. The impact of

a physical breach of security mechanisms at each location is different and the controls must reflect

the risks. The locations covered are as follows:

Primary Data Centre – Elms Road Data Centre, staffed during normal working hours.

Secondary Data Centre – Aston Webb Data Centre, usually unattended.

Main Library – server room / data centre (scheduled for demolition).

Network Technical Closets – around 160 dotted around campus, some are shared technical

spaces.

Server Rooms – IT Services and college server rooms.

Objective: Ensure that data centres and information processing or storage facilities that house University computer systems and/or network facilities are physically secured.

7.1 Data Centres

1. Physical access controls that restrict and monitor entry to the facility must be implemented.

2. An agreed and documented authorisation process must be maintained for all staff,

contractors and others needing permanent access.

3. A record of the authorisation must be maintained for at least thirty-six (36) months, unless

local laws or regulatory requirements prohibit or limit storage time.

4. Unnecessary or unused entry points must be eliminated or securely locked.

5. Access must be limited to those with a need to access based on job function or duties.

6. Physical access authorisation must be reviewed and recertified at least annually.

RESTRICTED



of 17

7. The data centre manager must review and investigate all alarm notifications and/or

monitoring interruptions.

8. Individuals not authorised for regular access must be approved and subject to monitoring or

regular checks.

9. Visitor credentials should be clearly identifiable.

10. An entry and exit log should be retained for at least three years.

11. Identification should be worn and displayed at all times.

12. Doors permitting emergency egress must activate an audible alarm.

13. Security doors that are forced open should immediately activate an audible alarm.

14. Security doors that do not close securely should activate an audible alarm after an

appropriate amount of time.

15. Removal of IT assets must be performed according to an established procedure authorised

by the data centre manager.

16. Storage media holding confidential information must not be removed from the data centre

unless protected using appropriate technical security mechanisms (e.g. encryption) or is

under the direct supervision of IT Services.

7.2 Server and Technical Rooms

1. Physical locks or access controls that restrict entry to the facility must be implemented if

they contain critical infrastructure such as uninterruptable power supplies, PABX etc.

2. Access should be logged either physically on paper or automatically via an access control

system.

3. Information assets containing confidential information should not be stored in these

locations unless they are protected by appropriate technical security mechanisms (e.g.

encryption).

RESTRICTED


IT Services / Access Management Standard2 / PUBLISHED / v 1.0

of 17

Glossary

(Elevated)

Privilege

Generalised term used within this document to denote enhanced capabilities such as

those used to override normal system or service functionality, often bypassing security

controls. Note: Access Administration is a normal system function and, as such, does

not require elevated privilege.

Access

Administrator

An access administrator holds the responsibility for granting specified, authorised

access to a user and, conversely, to revoke access.

Account In the sense of an account with a service, or system, such as an email account, user

account etc.

Administrator A system administrator, or „sysadmin‟, is an individual with the responsibility to

maintain and operate a computer system but may also refer to the elevated privileges

associated with this role.

Control An administrative, procedural, technical, physical or legal means of preventing or

managing the impact upon an asset of an information security incident. Controls may

be:

Preventative – prevents impact upon an asset.

Detective – detects impact upon an asset.

Reactive – reacts to impact on an asset, includes:

o Corrective – actively reduces impact.

o Recovery – restores an asset after impact.

Controls may reduce information security threats or impacts, although most reduce

vulnerabilities.

Credentials Data input, or otherwise provided, by users for the purposes of authentication. This

includes User ID, password, PIN etc.

Electronic

Identity

The representation of a person, or system that is used for access to information and

systems. An electronic identity may have accounts with various services (e.g. an email

account). The key, or access code, for an identity is a User ID, System ID etc. An

electronic identity may have more than one identifier (e.g. User ID).

Generic Account An account used to access a service (e.g. email account or user account) that is not

specific to a particular identity (person or system) and can be used by anyone who has

access to the appropriate credentials.

IAM Identity and Access Management system.

Information Asset A physical or virtual artefact containing data that realises information. This includes

documents, emails, databases etc.

Information

Owner

Appointed individuals who hold responsibility and accountability for management of

information assets. Ownership does not confer property rights.

Member Includes staff, students and honorary staff. Also included, where applicable, are partners, third parties, external contractors, contingent workers, and other contributors,

having access to the University‟s information resources, computing and/or network

facilities.

MoSCoW Requirements prioritisation scheme:

M – must be met.

S – should be met if possible (high priority).

C – could be met in future if time and resources permit.

W – won’t be met now but may be reconsidered in the future.

PIN Personal Identification Number – a number, usually consisting of four digits, used to

unlock a smartcard or similar device.

RESTRICTED



of 17

PKI Public Key Infrastructure consisting of a Certificate Authority (CA) and sub-authorities

that issue encrypted certificates for authentication and encryption purposes.

Risk Risk is a combination of the likelihood of a threat occurring, vulnerability to the

threat and the impact that results.

Service A defined set of functionality and information provided by one or more systems.

SSO Single Sign On – users are required to authenticate themselves when initially accessing

the University‟s network by signing on to Windows, the portal etc. Their credentials

are automatically evaluated without requiring them to manually sign-on each time they

access an application or resource.

Staff-ID Also known as Staff Number or Payroll Number.

This is a personal identifier used to denote a particular individual within the staff and

payroll systems. It is shown on the University identity card.

Strong

Authentication

The use of two or more authentication factors such as a known password or PIN

together with a security token or smartcard

System A collection of elements organised for a defined purpose or objective. Systems

consist of hardware, software, information, and human assets.

User Any member having authorised access to a specific system or service.

User ID Generalised term for user ID, account, credential, identity, subject or entity within a

directory service or database, representing an individual, group, system, device,

function, service, etc. May also be termed accurately as a principal.

Specifically, within this document, the User ID is a personal identifier which, when

used in combination with a password, passphrase or other secret, gives access to a

system or service. This is distinct from the Staff-ID.

References

1. Information Security Policy v1.03 http://www.it.bham.ac.uk/policy/

2. Information Security Glossary http://www.it.bham.ac.uk/policy/

3. Information Security Controls and Objectives http://www.it.bham.ac.uk/policy/

4. Cryptography Standard http://www.it.bham.ac.uk/policy/

Appendix A – Password Advice

Your password is your personal responsibility. Not only that, but it is the key to accessing information

under your control and you will be held accountable for its misuse.

Follow the golden rules:

Maintain a (different) strong password for access to each system or service.

Do not casually divulge your password to anyone1.

Keep passwords safely and securely.

The strength of a password is a measure of its resistance to being guessed and is therefore a

function of length, complexity, and randomness. As general guidance, consider the following:

The longer, the better

A mixture of:

o Lowercase (a-z)

1 There may be occasions where a password must be given to an authorised individual or body, such as a technician attempting to

replicate a problem, to the police or other law enforcement agency or authority, or to Customs officials at an international border.

In these cases, you must change the password at the earliest opportunity thereafter.

RESTRICTED



of 17

o Uppercase (A-Z)

o Numbers (0-9)

o Non-alphanumeric (e.g. [ } ! # or %)

Something not easily linked to you

Memorable.

The best passwords mean something to you but not to anyone else.

Bad Examples

Your username with a number on the end and/or reversed

A partner‟s or relative‟s name

Words found in a dictionary, even a specialist dictionary such as literary figures, geological

terms, foreign words, etc.

Common character sequences (such as qwertyu)

Good Examples

Phrase-based mnemonics “KmeKyou..bIcdooo!” (Knowing me knowing you .. best I can do)

Random, multi-word phrases “Horse[Staple]fly munch”

There are five main techniques that hackers can use to get hold of your password:

1. Grab it. Looking over your shoulder as you type it (“shoulder-surfing”) or finding the piece of

paper where you wrote it down. This is the most common way that passwords are compromised,

thus it's very important that if you do write your password down, you keep the piece of paper safe.

Also remember not to type in your password when someone could be watching.

2. Steal it. Surfing dubious sites, or even legitimate ones that have been compromised by

cybercriminals, can infect your machine with keyloggers, trojans and other forms of information-

stealing malware, which will silently capture and siphon off your personal data. Ensure your

antivirus software is up-to-date and that you navigate the internet carefully.

3. Guess it. It's amazing how many people use a password based on information that can easily be

guessed. Psychologists say that most men use four-letter obscenities as passwords and most women

use the names of their boyfriend, husband or children.

4. Brute force attack. This is where every possible combination of letters, numbers and symbols is

tried in an attempt to guess the password. While this is an extremely labour-intensive task, with

modern computing power and sophisticated software tools, this method is not to be underestimated.

It is currently feasible to crack an eight-character random password in less than 2 hours while a

fourteen-character password is still well out of reach.

5. A dictionary attack. A more intelligent method than the brute force attack described above is the

dictionary attack. This is where the combinations tried are first chosen from words available in a

dictionary. Software tools are readily available that can try every word in a list until your password

is found. Dictionaries with hundreds of thousands of words, as well as specialist, technical and

foreign language dictionaries are available, as are lists of thousands of words that are often used as

passwords such as "qwerty", "abcdef" etc.

access management standard - whatdotheyknow

Documents