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.
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
The University Induction Policy
requires all staff to complete Data Protection and Information Security
Training at the start of their employment, and every two years thereafter.
This training includes information on how to stay safe online and avoid viruses.
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).
Author: Richard Bartlett (Enterprise Security Architect); Version: 1.0; Approved: 9th February, 2021; Next review: Q1 2022
