Information security policy (including acceptable use policy) for staff

Very exceptionally, it is sometimes necessary for a staff member to have local administrator access to their UWL issued computer.

Local administrator rights are a significant risk to the security of the University’s infrastructure and must be handled with great care. It is essential that their password is strong, secure and unique, and if possible, local administrator rights should only be assigned temporarily to allow a staff member to carry out a specific task.

Requests for local administrator access rights must be made in writing. They must include a detailed justification and be approved by the staff members Dean of College, Head of School, or Head of Central Service Department, as well as by IT Services.

If you are granted local administrator rights, then you are responsible for ensuring you do nothing to compromise the security of the UWL network and IT infrastructure. In particular:

• You must not remove or modify UWL provided anti-malware and security software
• You must not remove or modify features which permit IT Services to manage or monitor devices
• You must not make changes to network configuration settings

IT Services will revoke local admin rights if necessary to protect the security of the UWL network and infrastructure.

That means:

• Ensuring that the system meets the requirements of this policy and the data protection policy.
• Ensuring information security and data protection are built into the design throughout the life cycle of the system.
• Ensuring that appropriate technical and organisational measures are in place to keep the system secure.
• Ensuring appropriate incident response and business continuity plans, aligned to the UWL incident management and business continuity framework are in place for the system and regularly reviewed and tested.
• Ensuring accounts – both regular and privileged – are managed properly and decommissioned when that user no longer has need of them.
• Ensuring the system complies with all legal and contractual requirements, such as the UK GDPR and PECR.
• Ensuring that systems and data are protected from damage, retained no longer than required, and securely disposed of when no longer needed.
• Co-operating with and supporting internal audit functions.

Security by design and default

When developing a new system, process or service, information security and data protection are a requirement from the beginning. While much of the work may be delegated to IT Services or a vendor, the responsibility for defining security requirements and ensuring the system is protected remains with the system owner.

Systems must be designed so that:

• Users can only access the data and functionality they have been authorised for (the “least privilege” approach)
• Accountability for usage is maintained by audit trails
• Availability is addressed through suitable high availability, business continuity and disaster recovery arrangements
• Regular security testing and review is part of the business-as-usual operation of the system

Each new service requires consideration of the unique risks it presents and the determination of necessary controls.

Systems must adopt the principle of defence in depth by having multiple resilient and redundant security controls in place that will continue to protect data even if one control fails or is bypassed.

Systems should never rely solely on perimeter or network defences, such as the UWL network firewalls, for security.

The default or vendor recommended configuration of a system should be subject to review.

There should be separate development, test and production environments for all business-critical applications, and attention should be given to the protection not just of live data but also test data and approved source/object code.

Web-based services

UWL has adopted a “cloud first” approach to new IT systems, so frequently a new service will be accessed via a web front end, accessible from the public internet.

Before deploying a new web service, systems owners must gain the approval of key stakeholders (such as IT Services and Marketing) and ensure that:

• Data protection legislation is complied with and this has been recorded (via Form D or a DPIA as appropriate)
• The service meets the Public Sector Bodies Accessibility Regulations
• The service meets the ICO’s age-appropriate Design Code
• The service meets PCI/DSS requirements if required
• Published content is licensed
• Content moderation is in place where user generated content is published
• Due consideration has been taken of the impact of the web service on UWL’s reputation, branding and search engine optimization (SEO)

Managing user accounts

A user account is a set of credentials and associated data that allows a specific person to log in to one or more UWL services. The account is used both to authenticate the person (confirm who they are) and to authorise them (confirm what services and data they should have access to).

Access to systems should only be granted on a “need to know” basis, with users having the minimum access required to perform their work.

Systems should be designed so that all activity on the system can be linked to an identified individual’s account.

System owners need to ensure they have documented processes for approving and managing the creation, change, emergency suspension and deletion/decommissioning of accounts and a mechanism for regularly auditing this process to confirm it is working.

All accounts in a system must be secured with a password or comparable authentication method.

Password strength rules should be implemented, requiring:

• Passwords be at least 10 characters long
• Passwords contain a mixture of at least three of upper-case letters, lower case letters, numbers and special characters such as punctuation marks
• Passwords do not contain the users name or username or other common weak passwords

Multi-factor authentication (MFA) should be enabled if available.

Managing privileged accounts

A privileged account is one which has additional permissions above and beyond what is provided to a “normal” account on the system. By their nature they are higher risk and must be protected accordingly. All privileged access to systems must be traceable to an individual and, if technically possible, logged in a way that prevents the privileged account altering it.

Privileged accounts must never be used to perform tasks that a non-privileged account can do. if one staff member needs to perform both privileged and non-privileged then they should either have multiple accounts assigned or, if supported by the system, use an account that is normally running without privilege but can be temporarily elevated when required.

Individuals with privileged accounts have been placed in a position of trust and must follow all applicable laws, regulations, policies and procedures.

As with all accounts, there must be documented processes for approving and managing the creation, change, emergency suspension and deletion of privileged accounts, and a mechanism for regularly auditing this process to confirm it is working. Approval for a privileged accounts creation must be given by the system owner.

Systems are often supplied with pre-defined, generic privileged accounts, such as "admin", “superuser” or "root”. If possible, these should be disabled and separate privileged accounts, assigned to named administrators, used instead. Where these accounts must be kept active, their password must be immediately changed from the default, and if possible, the username should also be changed. If any member of staff who knows that password leaves, it must be immediately changed and recirculated.

Licensing and patch management

All software used in UWL (including free or open-source software) must be correctly licensed, supported (by either the vendor or a third party) and have security patches applied in a timely manner.

Patches whose severity is rated by the vendor as CRITICAL or HIGH must be installed within 14 days of release. Other patches MUST be installed within 28 days of release.

Where a vendor does not indicate severity with a CRITICAL-HIGH-MEDIUM-LOW ranking, reference may be made to the Common Vulnerability Scoring System (CVSS); but otherwise, such patches will be treated as CRITICAL.

If there is a business critical need to continue to run unsupported software, mitigating controls, such as network segmentation, must be put in place and documented in order to ensure that the University is not exposed to unacceptable risk.