Call IT Support Email IT Support

Access Control

Defining the University’s approach to Access Control

Policy Statement

This control procedure defines the University's approach to access control and directly supports the following statement from the Information Security Policy:

Access to all information will be controlled and will be driven by business requirements. Access will be granted or arrangements made for users according to their role, only to a level that will allow them to carry out their duties.

A formal user registration and de-registration procedure will be maintained for access to all information systems and services. This will include mandatory authentication methods based on the sensitivity of the information being accessed, and will include consideration of multiple factors as appropriate.

Specific controls will be implements for users with elevated privileges, to reduce the risk of negligent or deliberate system misuse. Segregation of duties will be implemented, where practical.

Audience

This procedure is intended to be read and understood by all users of University IT systems.‌

Control Statements

Access to the University resources must be granted on a need to know basis. Access control must be implemented to grant the least privileges required to fulfill a role. This applies to physical access, system and device level access and methods of authentication.

Appropriate access levels are defined by business owners, in consultation with Information Asset Owners.

 1. Authentication mechanisms

The central university Active Directory (AD) system is the core authentication system and should be used by any service requiring user account authentication, including federating to non-AD or cloud services as appropriate. To maintain lists of who has access to systems, AD Groups should be used to grant privileged access to systems or aspects of systems.

At the time of writing, federated services use a third party tool, IAMcloud, to access AD. Systems using this include Office 365 and the eArcu recruitment system. There are plans to upgrade this to Microsoft’s Azure AD Premium service in 2018.

We use Shibboleth – an industry-standard system based on SAML – to control third party authentication requests for some web-based services, primarily library services.

LDAP authentication to AD is used for some corporate web sites and third party integrations, such as Moodle.

These system are managed by ISDS.

Where systems cannot use AD credentials, they will follow the same principles of need-to-know and least-privilege, but there must be an access control process ensuring that local ownership is taken for keeping access control lists up-to-date with staff and business changes.

 

2. User registration and deregistration

Human resources provide an automated data feed to ISDS each day which provides details of all new staff joining the institution. Building access and IT access, including an individual email account will be automatically assigned by teams in ISDS and Estates based on this feed.The line manager of the new staff member will receive their login details by email from the IT Helpline.

Human resources provide an automated data feed to ISDS about staff leaving the institution based on contractual information from the HR system. Leaver accounts will be timestamped, which prompts a number of actions to allow the account to be closed down. If there is any confusion over whether a member of staff has left, this should be confirmed with HR before any action is taken.

For security reasons it is essential that accounts are not left accessible for longer than is necessary once a member of staff is no longer employed by the University. Accounts of leavers will be disabled on the day the contract expires and deleted 90 days later. IT administrator accounts will be disabled on the user's last working day, even if this pre-dates the end of the contract.

Guest accounts must be requested and authorised by a permanent manager. Requests for guest accounts must be requested via the IT Helpline. All guest accounts will then be processed by ISDS with a defined end date which automatically triggers the closure of the account. Guest accounts are only provided for a specified time period and at most a period of 5 years.

The University reserves the right to disable any account with immediate effect, for example where the user is the subject to disciplinary action or there is a threat to the University or others. HR, Legal and/or the Information Security Manager will confirm the need to disable an account. Accounts will be retained for as long as necessary in line with any on-going investigation.

Student account creation follows the same principles, but information comes from the Student Record System. Students retain access to core systems for 120 days after the end of their course,  email and cloud storage for another 150 days, and are deleted after one year.

3. Changes to access rights

Changes of roles internally may require changes to access control privileges. As a change in roles will result in a change in contract, the contract changes will be updated on the HR system, which then feeds directly to ISDS. Once a current contract ends, users are automatically removed from previous access groups and their new contract will attract the users new access rights. Any specific changes may need to be made manually on receipt of specific authorisation from a manager.

4. Privileged access

The creation of user accounts with higher privileges such as administrators is controlled, and restricted to those users who have a clear business need to manage information systems or networks.

Each administrator will be given a specific administrator account, which should only be used for system administrative purposes:otherwise, their standard user account should be used. Administrator accounts will not be given access to email; to mitigate the risk of malware spreading via privileged access. More complex passphrase management is required for administrator accounts. Access over the internet to accounts with the system level privileges will use the University's VPN and two factor authentication. No other systems should be used to allow acces to privileged systems.

Unix/Linux systems should have additional accounts setup for people using the systems that do not require root access. It is often necessary to use the root account to perform system administrative tasks, so where possible these additional accounts should be used to login and root only used when necessary.

Where structure and existing staffing allows, segregation of duties will be implemented and administrators will be given the least access possible to allow them to complete administrative tasks. This will also assist with maintaining a clear audit trail of domain management and help to prevent catastrophic accidental changes being made to the domain by a single user. Full Domain Administrator accounts should only be used when there is no alternative, and their use should be documented and flagged to the Information Security Manager.

Research academics may require local administrator privileges in order to undertake their roles. Access can be granted where the access request is supported by a short written statement explaining the need, and is endorsed by the relevant Head of Service or line manager. When access is granted , research academics agree:

Accounts used to run programs or batch jobs should be unique to each service. Each should have the description field appropriately completed and be set to ‘password never expires’. Where possible these accounts should be setup in Active Directory and passphrases recorded in an encrypted secure vault with an audit trail of access. These service accounts should only be used for automated logins and never used to login manually.

  

5. Database access

Access to databases should be sufficiently granular to protect the need-to-know principle. Where possible this should relate to AD groups. Where access control is specified by naming a user on the database access control list, this must be maintained by the service owner.

 

Compliance

Failure to comply with this procedure could result in action in line with the University’s Disciplinary Procedure or Capability Procedure.

Compliance checks will be undertaken by the University’s Information Governance functions. The results of compliance checks, their risk assessment and their remediation will be managed by the Information Security Board.

Related documents

This control procedure needs to be understood in the context of the other policies and procedures constituting the University’s Information Security Management System.

Browse Information Security policies and control procedures

Review

A review of this policy will be undertaken by the Information Security Manager annually or more frequently as required, and will be approved by the Information Security Board.

Information Security