1. Purpose
This policy sets out the University’s approach to managing its information security objectives (see below). It addresses the governance and operation of IT security and sits above the Staff and Student Information Security policies, which address user behaviour.
1.1. Audience and scope
The audience for this policy is managers and technical staff responsible for delivering IT services to University staff and students. This policy applies to all IT service providers in the University, including Technology and Information Services (TIS) and any other Faculty teams or staff with an IT support or delivery role.
2. Information security roles and responsibilities
Role: Senior Information Risk Owner (SIRO)
Role/title: University Secretary and Registrar
Responsibility: Providing accountability and assurance to UEG that information governance policies, including data protection and information security policies are complied with.
Role: Information Asset Owners
Role/title: Executive Deans Directors, Deputy Vice-Chancellors, members of the Senior Leadership forum
Responsibility: Has accountability and authority to manage the risk; approving the risk treatment plan and residual risk for the risks that they own.
Role: Risk Assessors
Role/title: Privacy Coordinators
Responsibility: Compliance with Data Protection policy, including assessment of information security risk within their organisational area.
Role: Risk Assessors
Role/title: TIS Enterprise Security
Responsibility: Assessing cyber security risk across the University and providing advice on appropriate mitigating measures.
Role: Security Incident Management
Role/title: IT Director
Responsibility: Co-ordinating the University’s technical response to a major or critical information security incident.
3. Information classification
The University Information Classification policy sets a framework for classifying and handling University information based on its level of sensitivity, and its value to the University. Personally Identifiable Information (PII) must be managed and protected in accordance with the University Data Protection and Information Classification Policies.
4. Communications security
4.1. Network controls
Any part of the University that manages their own network or networks on behalf of others, should define responsibilities and procedures to protect information in systems and applications.
University operated wireless networks must be protected using modern authentication and encryption technology ('modern' meaning currently in active development and supported by a vendor or community). Encryption must meet the current FIPS standard at the time of reading.
All connections to University systems should be protected using modern authentication and encryption technology. Where that is not possible a security risk assessment should be carried out and the residual risk accepted by the University.
Network security events should be logged on network routers and firewalls on the University network, and on virtual network infrastructure in cloud hosted environments.
Use of systems connected to the University network via wired, wireless or VPN connection must be authenticated, unless otherwise specifically approved by the institution responsible for managing the network.
4.2. Unauthorised use
Attaching more than one device to any network port by use of network switches, firewalls, routers or wireless access points or any other means without authority should be prevented using technical controls. Use of any software or hardware which causes disruption to the correct functioning of University systems is prohibited under the Student and Staff Information Security Policies. If such disruption does occur the offending device or software should be disconnected from the University network by the institution responsible for managing the network.
5. Access control
Users should only be provided with access to the University information and resources that are required for their role, in line with the University Information Classification and Data Protection Policies. Access should be added and removed to reflect changes in employment status, role and responsibility, and reviewed regularly to ensure compliance with these principles.
5.1. Regular user access control
Role Based Access Control (RBAC) should be used wherever possible to assign access rights to users throughout the account lifecycle, where the role/s associated with the user determines the access they have, driven by data from staff and student information systems.
Any access granted outside the RBAC groups should be reviewed regularly and wherever possible RBAC groups should be modified or created to incorporate that access and minimise exceptions.
All new staff and student accounts should be inactive until the user has been through an identity verification process, at which point the account can be activated, and the user must set their own unique password.
As the status of a user changes within the relevant information system accounts must be either:
- Deactivated promptly if no longer required, and deleted after no more than three months, or
- The user’s group membership must be cleared and new group membership set according to the new role.
Owners of sensitive personal identifiable information assets should review the users who have access to those assets regularly.
5.2. Privileged user access control
Staff who require privileged access for the technical administration of information systems must be provided with a separate account for that purpose. Those accounts are only for use where privileged access is required, and not for any routine activity including email or instant messaging and web browsing.
Privileged access to systems must be reviewed by system owners annually.
Role Based Access Control (RBAC) is the default method of assigning privileged access rights based on the responsibilities of that member of staff.
Any privileged access granted outside the RBAC groups must be reviewed as part of the annual privileged account review, and wherever possible RBAC groups should be created or modified to incorporate that access to minimise exceptions.
Technical controls should enforce enhanced authentication measures (including but not limited to increased password length, multi-factor authentication and conditional access) for all privileged accounts.
Access to and administration of systems by privileged accounts must be logged.
6. Protection from malware
6.1. Security awareness
6.2. Controlling software installation and use
Staff should not have administrative access to desktops and laptops unless their role requires it. Where administrative access is required it should be actively managed, proportionate to user need, wherever possible time limited, and subject to annual review.
6.3. Malware detection
The Student and Staff Information Security Policies (see above) require that all personal computers which store or process University information must be protected using up to date anti-virus software, and updated frequently with the latest operating system and application patches and updates. University computers must comply with the same requirement, and wherever possible anti-virus and patching should be managed by IT to ensure compliance.
Email services used in the University must have built-in malware protection to prevent the transmission of viruses contained in both inbound and outbound messages.
7. Management of technical vulnerabilities
7.1. Inventory of assets
All University server and endpoint (desktop and laptop) assets should be recorded within an IT asset inventory which should be maintained and regularly reviewed by the responsible IT team to ensure it is accurate.
7.2. Identifying vulnerabilities
Appropriate information resources to identify vulnerabilities should be maintained for all assets in the inventory and updated in line with changes to the inventory.
TIS is responsible for the identification and monitoring of vulnerabilities and advising the University on the level of risk presented and the appropriate corrective action. To that end, TIS may audit networks and systems to ensure compliance with this and other University policies relating to information security and regulations.
7.3. Reacting to vulnerabilities
A process for assessing the risk of identified vulnerabilities and implementing the appropriate corrective actions (patch, mitigate or workaround with a technical control) should be documented. This documentation should include roles and responsibilities, and how actions are recorded for audit and review purposes.
High-risk or critical security updates for operating systems, firmware and applications must be installed as soon as possible, and within 14 days of release for all systems within the scope of the University of Plymouth Cyber Essentials Compliant Network.
Medium to low-risk updates should applied automatically on a regular cycle, and ideally within 30 days.
7.4. Monitoring vulnerabilities
A process for confirming that all network and server infrastructure is compliant (has the most recent updates installed) should be documented. That process should include the escalation of any servers which are non-compliant to the appropriate persons for corrective action.
8. Backup
All data should be backed up according to its value to the University, the cost of recreating the data, any financial costs or penalties which might be incurred as a result of data loss or corruption, and the risk of data loss or corruption.
The primary purpose of data backup is to allow the Faculty or Service to continue its activity after a data loss incident, by retrieving some or all of the data lost, ideally from a point in time backup taken within the last 24 hours.
All backups should meet the following minimum requirements:
- It has been designed to meet the recovery time and recovery point requirements of the Faculty or service.
- It is physically secured against theft.
- It is sufficiently resilient that failure of a single hardware component would not result in data loss.
- It is held separately from the original data storage location such that it would be unaffected by hardware or software failure or physical/environmental incidents (e.g., fire or flood).
- It is protected from unauthorised access through technical controls and as far as possible physical separation from the original data storage location (to prevent destruction in the event of a security incident, e.g. ransomware).
- It is tested at least annually to ensure the data backed up could be used in the event of a data loss incident.
Suitable backup locations include cloud based backup services, tape libraries and mirroring to resilient disk storage. Portable backup devices are not suitable for backup of PII or data where loss would result in significant cost to recreate or disclosure would result in financial penalties due to breach of legislation or regulation
9. Cryptographic controls
Business information should be protected wherever possible by modern encryption at rest and in transit, and
at all times for information classified as Level 1 (i.e., Confidential; see
University Information Classification Policy
). This includes data servers and on desktop computers and laptops.
Where it is not possible to provide this protection, this must managed as an information security risk, and reviewed at least annually.
Backups should be encrypted to prevent unauthorised access or modification.
Wherever possible key management should be used to centrally provision and manage access to encryption keys and secrets, to prevent data loss in the event of key loss. Responsibility for cryptographic controls on servers, desktops and laptops should be clearly defined.
10. Physical and environmental security
Areas where sensitive or critical information is processed should be given an appropriate level of physical security and access control as detailed below. Staff with authorisation to enter such areas are provided with information on the potential security risks and the measures used to control them.
10.1. Low criticality systems
Normal building access and control procedures are adopted.
10.2. Medium criticality systems
Facilities are in defined locked rooms to which access is controlled by key, card or code. Delivery personnel and visitors must wear visitor badges and be supervised.
10.3. High criticality systems
Facilities are in specially designated areas with walls and doors of solid construction, security alarms, and access controlled and recorded by an electronic system. Deliveries and enquiries are to separate areas and visitors must wear visitor badges and be accompanied at all times.
11. Supplier relationships
Responsibility for the management of supplier relationships should be clearly documented.
Cloud service providers and third-party software suppliers should by default have no access to University data, including administrative accounts on systems. Data is protected by access control and encryption, with the encryption keys being managed and controlled by the University. Non-Disclosure Agreements (NDAs) shall be used in all situations where the disclosure of Confidential or Restricted to a Cloud service provider or third-party software supplier is deemed necessary and appropriate.
Supplier access to systems should only be allowed when authorised by the University as part of a technical support call or planned maintenance activity, provided on the principle of least privilege, audited and logged. Where necessary, supplier access will be accompanied or observed in order to ensure compliance with University policy.
12. Information security incident management
Any part of the University that manages their own network or systems, or manages networks or systems on behalf of others should establish Incident Management procedures to ensure a quick, effective and orderly response to information security incidents. Those procedures should identify the individual or team responsible for responding to information security incidents.
12.1. Identifying security events
Information security events reported by service users or triggered by monitoring and management systems should be recorded. Those events should be assessed by staff with the appropriate skills and experience (or an appropriate third party), and decision made whether those events are classified as an information security incident
12.2. Responding to security incidents
Information security incidents should be recorded as such and responded to according to the institution’s documented incident management procedures. Any knowledge gained from analysing and resolving those incidents should be recorded and used to reduce the likelihood or impact of future incidents.
Any evidence gathered during the incident response process should be appropriately recorded, and as far as possible original evidence should be preserved as per
ACPO guidelines and
ISO/IEC 27037.
The institution's incident management procedures should include appropriate escalation guidance, such as for internal escalation (including to TIS, Legal, HR, Finance and the Media and Communications Team), and for reporting to the relevant authorities (Jisc, Action Fraud, and the South West Regional Cyber Crime Unit).
Version 1.0. Reviewer: Anthony Bruton (Information Security Manager). Approved 03 June 2024. Next review Q3 2025
Version 1.0. Author: Richard Bartlett (Enterprise Security Architect). Approved 9 February 2021
