Information Technology Information Technology … Information Security Policy... · Information Technology University of West London ... 9.5 Patching and Updates 37 ... APPENDIX 1

Information Technology University of West London

Information Security Policy (V0.5 Draft, Feb 2011) 1 of 74 © University of West London 2011

Information Technology

Information Technology Security Policy and Guidelines

Version: 0.5 (Draft) Date: February 2011



Document Control

Master Copy location: SharePoint Document Store – ITSecurity Policy

Maintainers of Master Copy: John Waters, Assistant Director, IT Services Stephen Negi, Assistant Director, Technology Version History: Version Author(s) Date Statu

s Work Done

0.1 John Waters Aug 09 Draft Initial Draft & Review 0.2 John Waters Sep 09 Draft Revised comments, created indexes 0.3 John Waters Dec 09 Draft Added introduction, uploaded to

Sharepoint. 0.4 John Waters Feb 10 Draft Further revision and re-indexing 0.5 Stephen Negi Feb 11 Draft Change to UWL Branding Approvers: Vice Chancellor’s Executive Distribution: All UWL Staff (via HR Handbook) All UWL Students (via Student Handbook) Ownership: This Document and its’ Appendices are the intellectual property and copyright of University of West London, 2011. The content may not be copied or reproduced in any form without the written permission of University of West London. Status: This Document is intended for internal use by UWL staff and students only. It may be shared with partners and contractors where necessary, but is not intended for general publication. Date of Next Review: (12 months from date of ratified publication)

http://projects.tvu.ac.uk/secpol/Shared%20Documents/Forms/AllItems.aspx�

http://projects.tvu.ac.uk/secpol/Shared%20Documents/Forms/AllItems.aspx�



Contents

0 INTRODUCTION AND OVERVIEW 6 0.1 Scope 6 0.2 Consultation 7 0.3 Compliance 7

1 INFORMATION SECURITY RISKS 8 1.1 Identification 8 1.2 Assessment 8 1.3 Approach 8 1.4 Countermeasures 9

2 LEGISLATIVE AND ORGANISATIONAL COMPLIANCE 10 2.1 Legislation 10 2.2 Organisational 11 2.3 Investigation and Audit 12

3 PERSONNEL RESPONSIBILITIES 13 3.1 Staff 13 3.2 Students 13 3.3 IT Staff 14 3.4 Third Parties 14 3.5 Communications and Awareness 15

4 SYSTEM PLANNING 16 4.1 Assessment 16 4.2 Information Classification & Ownership 16 4.3 Hosting Equipment 16 4.4 Logical Access 16 4.5 Resilience & Availability 17 4.6 Interfaces and Dependencies 17 4.7 Implementation 18

5 OPERATIONS 19 5.1 Service Introduction 19 5.2 Physical & Environmental Security 19 5.3 Security & Loss Incidents – Reporting & Handling 19 5.4 Change Management 20 5.5 Information Security Management System(s) (ISMS) 20 5.6 System Retirement 20

6 INFORMATION HANDLING 22 6.1 Asset Management 22 6.2 Licence Management 22 6.3 Information Protection 23 6.4 Information Exchange 23 6.5 Application Systems 23 6.7 Information Storage 24 6.8 Retention, Archival & Purging 24



6.9 Secure Deletion 24 6.10 Externally Accessible Systems 25

7 USER MANAGEMENT 26 7.1 Access Control 26 7.2 Groups 28 7.3 Privileged Accounts 29 7.4 Password Management 29 7.5 Policies 30 7.6 Logging & Monitoring 30

8 SYSTEMS USAGE 31 8.2 Unattended Equipment 31 8.3 Data and Information Protection 32 8.4 E-Mail 32 8.5 Internet Usage 32 8.6 ‘Cloud’, Hosted or Shared Service Systems 33 8.7 ‘Web 2.0’ Systems 33 8.8 Printing & Copying 34 8.9 Remote Takeover and Assistance 34

9 SYSTEMS MANAGEMENT 35 9.1 Access Control 35 9.2 Privileged Accounts 35 9.3 Detection and Prevention of Malicious Software 36 9.4 Utilities 37 9.5 Patching and Updates 37 9.6 Backup & Recovery 38 9.7 Monitoring & Detection 38 9.8 Housekeeping & Logging 39

10 NETWORK MANAGEMENT 40 10.1 Configuration 40 10.2 Access 41 10.3 Management 41 10.4 Physical Security 41 10.5 Wireless Networks 42 10.6 Intrusion Detection 42 10.7 Penetration Testing 42 10.8 Public Networks 42 10.9 Telephony 42

11 MOBILE COMPUTING 44 11.1 Use of Mobile Devices 44 11.2 Portable Storage Devices 45 11.3 Use in Public Places 45 11.4 Mobile Phones 45

12 REMOTE WORKING 47 12.1 Access Methods 47 12.2 Authorisation 48



12.3 Equipment 48 12.4 Use of private or public equipment 49

13 ENCRYPTION 50 13.1 Use of Encryption 50 13.2 Key and Password Management 52 13.3 Digital Signatures and Certificates 52

14 DISASTER RECOVERY & BUSINESS CONTINUITY 54 14.1 Measures 54 14.2 Documentation 55 14.3 Testing 56 14.4 Invocation 56 14.5 Responsibilities 56 14.6 Maintenance 56 14.7 Restoration 57

APPENDIX 1 – SECURITY INCIDENT FORM 58

APPENDIX 2 – CHANGE MANAGEMENT PROCESS 61

APPENDIX 3 – DEVICE NAMING CONVENTION 63

APPENDIX 4 – NEW STARTER PROCESS (STAFF) 64

APPENDIX 5 – USER ACCOUNT REQUEST FORMS (STAFF) 65 5.1 Normal, Unprivileged Account 65 5.2 System Privileged Accounts 66

APPENDIX 6 - LAPTOP AGREEMENT 67

APPENDIX 7 – SSL ACCOUNT REQUEST FORMS 69 7.1 Staff 69 7.2 Suppliers, Contractors, 3rd Parties 72



0 Introduction and Overview This document sets out University of West London Information Technology Security Policy. This Policy primarily relates to information and data electronically held and handled by UWL’s Information Technology systems, networks and applications, used by staff, students and associates of the University. It does not specifically cover information and data held on paper or other media, although many of the same principles and controls apply. With the rapidly increasing preponderance of and reliance on digital computing technology, the ease with which UWL’s information can be accessed, copied and moved around has similarly increased. To ensure that that information is only accessed by those that need and are authorised to do so; that it is not intentionally or inadvertently lost, corrupted or falls into unauthorised hands; and that it is adequately managed and available throughout its’ creation, maintenance and eventual deletion lifecycle requires an appropriate Information Security Policy. It is the intention of this Policy to ensure that information and systems can be readily and reasonably accessed by those authorised and needing to do so, whilst also ensuring that unauthorised access or disclosure is prevented and that other risks, such as corruption or loss, are appropriately managed to ensure information integrity and availability. This Policy sets out a range of principles and practices to be adopted to achieve these requirements, with guidelines and examples where relevant. The Policy has been derived from internal UWL requirements and needs, extant legislation and directives, and general IT security recommendations and best practice. It has been broadly (though not strictly) structured to be in line with the ISO 27001 and 2 standards and related documents, to aid the assessment of its compliance with current best practice requirements. Guidance from other educational, public and private sector security policies has been incorporated, as have other best practice guidelines, such as ITIL Service Management (V3). 0.1 Scope This Policy covers all information assets ‘owned’ by UWL and for which UWL is responsible. Such assets will include, but are not limited to:

• Those originated by UWL for the purpose of directing and managing the Institution’s affairs, e.g. financial records, personnel records, student records, purchasing records, records held in Corporate or Faculty systems

• Those where UWL hold the Intellectual Property Rights (IPR), e.g. course design and content, marketing material and designs

Whilst there will also be information within UWL’s environment that it does not technically own, nor is strictly responsible for - such as certain research or academic work, or students’ course work, assignments or dissertations – if such is stored and used on a UWL-owned and managed IT system, then the provisions of



this Policy shall apply in order to protect the availability and integrity of the information and preserve confidentiality from unauthorised access. 0.2 Consultation Whilst this document originates from and is maintained by the Information Technology department within Information Services, consultation, input and agreement shall be sought from interested stakeholders across the University as part of the ratification and adoption process, including :

• Directorate, legal and registry services • Finance, HR, Facilities and Estates • External facing teams such as Marketing and the Strategic Enterprise and

Business Unit • Technology-enhanced-learning teams • Representation from each Faculty and/or School • Student representation • Trades Union representation

0.3 Compliance Once ratified, this Policy and all its’ contents shall be made mandatory on all staff, students, partners and contractors of the University, by way of handbooks and contractual terms as may be necessary. Consequences of non-compliance are elaborated within the policy, but generally follow the invocation of the Disciplinary and Performance procedures laid down by the University, up to and including summary dismissal or expulsion for gross misconduct and/or involvement of the authorities in civil or criminal legal proceedings. Staff or students that do not feel that they either can or wish to comply with all or part of this Policy should raise their concerns with the Assistant Director, IT Services in the first instance. In such cases, no or restricted access only may apply to UWL’s information systems and services. If there is a perceived legitimate need for the temporary contravention of part of this Policy, for academic, learning or organisational purposes, for example, then again the Assistant Director, IT Services should be contacted in the first instance. Any such contravention, if required, could only be sanctioned with the express written approval of a member of UWL’s Vice-Chancellor’s Executive group.



1 Information Security Risks All IT-based data and information systems and collections within UWL shall be identified, assessed and categorised. In accordance with this, appropriate levels of confidentiality, integrity and availability shall be assigned to the information system, leading to the use of appropriate mitigating measures, policies, settings and technology solutions to achieve the required levels of protection. 1.1 Identification All existing and new IT-based data and information systems, collections and assets for which UWL are responsible shall be formally identified and registered within Information Technology Services, under the responsibility of the Assistant Director, IT Services. 1.2 Assessment Each data system, collection or asset shall be assessed for risks of loss, corruption, theft, disasters or misuse under a common IT system risk assessment methodology. This methodology shall be appropriate and relevant to UWL’s needs, but will be broadly

based upon and in line with CRAMM V5 (CCTA Risk Analysis and Management Method), which is particularly suitable for handling IT and data security and integrity risks; and their management.

The assessment will take into account, through Business Impact Analysis, the relative value and importance of the data or asset to UWL, both directly and indirectly, and the assessment will be scaled and applied appropriately. 1.3 Approach Using a CRAMM-like approach, vulnerabilities and threats to system and information assets, their probabilities (low-medium-high) and impacts (low-medium-high) of occurring will be identified and assessed.

Such assessment shall be scored into a 3 x 3 risk matrix and the overall risk level to the asset categorised as low, medium or high, as follows : Prob. Impact Low (1) Medium (2) High (3)

Low (1) Very Low (1) Low(2) Medium (3) Medium (2) Low (2) Medium (3) High (6)

High (3) Medium (3) High (6) Very High (9)



1.4 Countermeasures Depending on the overall level of risk assessment to the system or information, appropriate IT risk reduction and risk management countermeasures shall be put in place and operated, in terms of :

• Access security and controls o who can access the system/data, how, from where, and when? o security policies and profiles

• Resilience and availability measures o what availability levels are required for the system/data?

• Backup, continuity and recovery o What currency of restore points are required? o What backup régime is required – frequency, type(s), retention? o What disaster recovery and business continuity arrangements?

• Change and configuration management and controls • Logging, monitoring and auditing

o Levels of logging, review, alerts and action to be taken o System monitoring required to be in place o Audit of compliance with and effectiveness of countermeasures in

place. Generally, the higher the risk, the more countermeasures that will be adopted to reduce risks and manage them if they were to occur. Policies for these countermeasures, controls and their management are developed and specified later in this Information Security Policy.



2 Legislative and Organisational Compliance All IT-based data and information systems and collections within UWL shall be subject to the requirements and considerations of appropriate and relevant external legislation, regulations, guidelines and standards. In addition, they must also comply with internal UWL organisational policies and requirements. This section gives an overview of the main areas of consideration in these respects, to help set the framework in which this Security Policy sits and has to address. 2.1 Legislation The main areas of legislation and regulation affecting UWL’s IT systems and data are :

• Computer Misuse Act 1990 Concerned with the securing of computer systems against unauthorised access or modification.

• Human Rights Act 1998 Provides for the concept of privacy – giving a ‘right to respect for private and family life, home and correspondence’.

• Regulation of Investigatory Powers Act 2000 This Act covers the extent to which organisations can monitor or record communications at the point at which they enter or are being sent within organisation’s data network and telecommunications system, and applies to public and private communication networks.

• Data Protection Act 1998 Individuals have a right, within certain limits, to request a copy of any personal data the University holds about them. Personal data includes any expression of opinion about an individual, whether held on paper or electronically. It also prescribes how personal data is to be stored, protected and treated. Responses are required within 40 calendar

• Freedom of Information Act 2000

days of the request.

Any information held by public bodies can be requested to be disclosed. The University has 20 working

• Copyright law

days to supply information requested under this Act, deemed to start the day after the request is made.

The Copyright, Designs and Patents Act 1988 (as amended) gives the same protection to digital and electronic publications as it does to printed books and other forms of publication.

• Obscene Publications Act 1959, Protection of Children Act 1978 and Criminal Justice Act 1988 These acts are concerned with material that might be criminal, cause harm to young persons or be otherwise unlawful. Circulating text or images via email might subject an individual to criminal charges.



• Privacy and Electronic Communications (EC Directive) Regulations 2003 This covers unsolicited direct marketing activity by telephone, by fax, and by email.

• Malicious Communications Act 1988 This act deals with the offence of sending communications with intent to cause distress or anxiety.

• Defamation Act 1996 Covers malicious, false or defamatory statements and communications

• Sex Discrimination Act 1975, Race Relations Act 1976, Disability Discrimination Act 1995 and other discrimination and equality legislation Covers a wide range of discrimination, bias, exclusion, rejection or unfair treatment considerations that should not be inherent in UWL’s information systems or their content.

• Health & Safety at Work Act 1974, as amended, with associated UK and European Directives, Regulations and Guidelines To ensure that the physical provision and use of UWL’s information systems and technology comply with all relevant Health and Safety requirements.

• Other national and international criminal law As may apply to the provision, use, content and communication of electronic information.

The above list of legislation and regulations is not exhaustive !

2.2 Organisational UWL has a number of internal policies, regulations and guidelines, both to direct compliance within a number of areas of the legislation outlined above; and to direct and manage internal good practice and procedures relating to the discharging of UWL’s business and providing an educational service to its’ students. Particularly relevant amongst such policies are :



• Data Protection (Directorate)

• Disaster Recovery and Business Continuity (IT, Directorate & Faculties)

• Freedom of Information (Directorate)

• Internet and E-Mail Acceptable Usage (IT)

• Procurement and Asset Management (Finance)

• Information and Data Management (Directorate & IT)

• Remote and Mobile Working (HR) 2.3 Investigation and Audit From time to time, individuals within UWL or UWL itself may be suspected of or be in breach of internal or external policies, regulations or legislation. Depending on the nature or seriousness of the alleged breach, an appropriate level of investigation and reporting shall be carried out. At an individual level, investigations requiring (privileged or clandestine) access to personal data and system logs on UWL’s systems regarding that individual will only be carried out with the express written permission of the Vice Chancellor, Deputy Vice Chancellors or the University Secretary. Circumstances when this might apply include investigating allegations of inappropriate use of Internet material, copyright infringement, identity fraud or inappropriate, offensive or defamatory communications. Such investigations may give rise to further proceedings against individuals under the UWL Disciplinary Procedure and related policies, up to and including dismissal. At the UWL level or for more serious individual situations, UWL shall co-operate fully and openly with the relevant regulatory or law enforcement agencies to assist with the investigation of allegations. To ensure UWL’s compliance with internal and external policies, regulations and legislation, UWL’s information systems and technology shall be subject to periodic professional internal and external audit and review. UWL will again co-operate fully and openly with such audits and shall receive and act upon agreed findings and recommendations arising, subject to business prioritisation and direction as may apply.



3 Personnel Responsibilities Staff, students and all other direct and indirect users of UWL’s information systems, and the information they contain, shall be bound by standards and policies over how they use the systems, backed up by appropriate controls and monitoring. 3.1 Staff UWL staff and others under direct employment contract to UWL shall be required, as part of their terms and conditions of contract, to abide by UWL’s IT security and usage standards and policies as may be in force and as amended from time to time. Staff are expected to use UWL’s IT systems sensibly and responsibly and to highlight to IT any areas of concern regarding either their own use or the usage of others. This will be reiterated as part of routine staff inductions and relevant web sites and documentation. These standards and policies include, in addition to this overarching Information Security Policy:

• IT Acceptable Use Policy Governs what is, and what is not, acceptable usage of UWL’s IT network, systems, equipment and information.

• Internet Usage and Monitoring Policy Specific policy on what is, and what is not, acceptable use of the Internet and Internet-based systems and services

• E-mail Usage and Monitoring Policy Specific policy on what e-mail should and should not be used for, or contain.

In addition, staff are bound by the need to observe and comply with all the various legislative and organisational compliance requirements mentioned in Section 2, in particular those concerning intellectual property rights, identity management and the requirements of Data Protection. As before, staff suspected to be in significant breach of any of the legislative or policy requirements can and will be investigated, either with or without their knowledge, and are subject to UWL’s staff disciplinary procedures, up to and including dismissal. 3.2 Students UWL’s students, of whatever category, are also bound by these legislative and organisational standards and policies, and similar considerations apply. Students suspected of being in breach of any of these requirements can and will be investigated, either with or without their knowledge. Potential action taken can range from an informal warning via their tutor, up to the removal of a student from their course and possible involvement of relevant authorities, including the Police.



3.3 IT Staff IT staff are subject to the same range of requirements and compliance as all other staff. However, in view of their frequently privileged ability to access and work directly with UWL’s systems and the information they contain, they will be subject to additional levels of control and scrutiny over what they can access and how :

• IT staff shall only be given elevated or privileged personal access accounts to systems or information to perform their work on formal approval of such access by the Senior Management Team of IT via the Change Management process

• Where possible, usage of privileged accounts and the activities performed from them shall be logged and regularly reviewed for appropriateness

• IT staff shall avoid, where possible, using generic, standard privileged accounts (such as ‘system’, ‘root’ or ‘administrator’) to perform their work. Any such accounts will normally be disabled

• Where the same personal or generic privileged account covers a wide range of systems or devices, the usage should be ‘zoned’ to use different passwords in different areas, to reduce the risk of a compromised account giving widespread privileged access. (It is recognised that it is impractical to have different passwords for every privileged account on every different system.)

and have any default passwords changed and held safe for disaster recovery purposes. Usage of such accounts should only be with line management knowledge and approval and, where possible, will be logged and reviewed.

• Such privileged access shall be kept under regular review by the IT Senior Management Team and removed/adjusted if deemed necessary, again via change management

• The same considerations shall apply to end-user application administration staff, who may require privileged accounts and access to individual applications that they administer.

3.4 Third Parties Where third parties, such as software suppliers, consultants, visiting staff, contract and sub-contract staff, need direct access to UWL systems or information, then strict contractual terms and conditions shall be in place to govern any such access, coupled with business justification from a senior UWL manager. Generally such access shall be limited by account or network controls to be for the duration of the work involved. Where possible and relevant, such access shall be monitored and logged. Remote access provided for support purposes shall be authorised by way of an agreement form (Appendix 7) and enabled under Change Management when required.



Where data is provided to third parties for the purpose of tests or development, it shall be appropriately protected and covered by terms that ensure adherence to UWL’s Data Protection requirements. All other third party access shall be deemed ‘public’, in that they will be able to have this level of access to those of UWL’s systems that have public facing elements. 3.5 Communications and Awareness These policy requirements shall be made explicitly part of every staff and student contract, and those of any contracted third parties, for the avoidance of any doubt as to their applicability. Where relevant, IT standards and polices shall be made clearly available on web sites and any updates or changes to them clearly communicated. They will also be referred to in staff and student handbooks and any staff or student induction sessions held.



4 System Planning When a new or significantly enhanced information system is planned, security, confidentiality and recovery aspects shall be considered and implemented as part of the system design and specification. 4.1 Assessment In a similar way to the information risk assessment described in Section 1, new systems proposals will be considered for their information security requirements, risks and countermeasures required, and at what levels. Such an assessment shall be a formal stage of each and every new information system’s proposal and development. It will form part of the project costing and approval process and will ensure that security aspects are formally provided for and implemented as part of new and enhanced systems. 4.2 Information Classification & Ownership As indicated in the Section on Information Security Risks, each information system shall be identified and appropriately classified in terms of its’ risk profile and applicable countermeasures, which will guide many of the decisions and requirements required below. In addition, each information system should have an identified business owner and sponsor who can guide decisions and requirements over data access, security and integrity. 4.3 Hosting Equipment Where the system proposal involves the provision of physical equipment, such as servers, or where the system is to be hosted on UWL owned and managed physical servers, for example as a virtual service, then the physical housing, environment and security of the equipment involved shall be considered. Where the information system is to be hosted externally to UWL, whether on specific ‘co-located’ hardware in an external facility or just as a service from the Internet, or ‘Cloud’, then a similar level of ‘physical’ systems security will be considered, in terms of physical access, environmental controls, data backup and recovery and system failure/recovery. If an external system is to process sensitive or confidential information, then the location and storage of the data involved in the system will be validated to ensure adequate compliance with the Data Protection Act. Contractual terms with the co-location facility or service provider shall ensure adequate security, confidentiality and protection of UWL’s information asset(s). 4.4 Logical Access Requirements for end-users, administrative and supplier staff to have access to the systems and data/information they contain shall also be formally considered,



leading to a mapping of what sort of roles and access rights are applicable to access to the system. Any requirements for remote access shall be given particular consideration leading to an assessment and outline planning for appropriate access and security to be achieved. 4.5 Resilience & Availability The physical and logical resilience, availability and recovery requirements of the system shall be formally considered and planned as part of the system architecture. Typically, an information system consists of one or more physical or virtual servers on which it runs. Resilience and availability considerations include dual power supplies, connections to UPS facilities, mirrored (RAID 1) system discs, local or SAN-based RAID-ed data discs; up through load balanced and fail-over clustered systems; to complete and remote system and data mirroring, depending on the level of cover required, and the budget available to achieve it. Virtual server systems have advantages in being able to be ‘moved’, whilst in operation, from one physical server to another, either to maintain workload balances or for recovery purposes. However, care should be taken to retain knowledge of where the virtual server is actually running and that it is on appropriate hardware. ‘Cloud’ or hosted system availability is usually covered by a contractual service level agreement. Equally important is the planning of the backup and recovery arrangements for the system and the data/information it contains - in terms of ‘restore points’ (intervals to which the system can be restored back to), ‘recovery time’ (how long it takes to restore and implement the restore point), and the backup régime (type – full, incremental, differential; generations and retention). Again, this ranges from simple 1-to-1 direct backups, to complex, multi-system/database, consistent ‘snapshot’ backups. In a SAN environment, it is also possible to take disc-level snapshots and copies of data, and to use both virtual and physical tape library systems. Both backup and recovery operations need to be fully actively tested and documented before a system is signed over into ‘go-live’. It will also be necessary to plan for the recovery and implementation of the system(s) that runs the data and information. Sometimes referred to as a ‘bare-metal’ recovery, where a system needs to be rebuilt from hardware up. Although this can be mitigated by having ‘hot’ standby, cluster or mirror systems, the need to rebuild from scratch can never be ruled out. Therefore, copies of all relevant system build software (versions), licence keys and required patches/updates/ service packs will need to be held in the Software Library for the lifetime of the system(s). See the Sections on Systems Management and Disaster Recovery & Business Continuity for a fuller overview of backup and recovery approaches and policies. 4.6 Interfaces and Dependencies



Most information systems have several data input and output interfaces and dependencies on other systems, including for authentication, messaging, printing and network traffic. These shall be identified during the planning phase and appropriately allowed for and documented as part of the system’s development and implementation. 4.7 Implementation There will be a full, change-managed and fully documented, ‘signed-off’ handover of any new or enhanced system into live operation. This handover should cover and address all of the items mentioned here, to ensure that the system is going live in line with its’ planned and required security profile. Typically, the handover/go-live documentation would comprise :

• Physical and logical system(s) architecture diagrams and descriptions • Access and authentication profiles • Backup and recovery régime (including full system re-build) • System interfaces and dependencies • Test and verification plan and schedule • Service level targets and service catalogue details • System owner and user contacts • Operations Manual (instructions on how the system is to be operated and

supported on a day-to-day basis. Hard (or CD/DVD) copies of this will also be maintained as part of disaster recovery procedures (see 14.2))

• Details of suppliers and underpinning support contracts.



5 Operations Once an information system or service has been formally passed into live operation, it shall be subject to the security controls and monitoring in this Section. 5.1 Service Introduction As described in the previous Section, no system, service or significant upgrade to same shall enter into live operation without an appropriate signed off formal handover, with relevant accompanying documentation. From the agreed time of service introduction, the system shall enter IT full service management régime of first, second third line and supplier support under any agreed service levels and targets that may apply. Any changes to the system, for support, upgrade or enhancement purposes, from that point on shall be made under IT Change Management process. 5.2 Physical & Environmental Security Also as previously discussed, systems running on in-house provided and operated servers will be appropriately physically housed and secured, typically in a dedicated and purpose-built systems room, managed by the IT Technology team. Access to such areas shall be confined to authorised IT and accompanied supplier staff only. Access will be controlled by one or more of swipe/contact card readers, door combination locks and/or key locks. Required environmental provision – principally power and cooling – shall be appropriately delivered and monitored, with back-up/cover provision where required and possible. Key systems shall be connected to ‘uninterruptible power supply’ (UPS) systems where possible to give at least 20 minutes cover in case of mains power failure, to allow for a controlled shut-down if necessary. Computer room environmental monitoring systems, capable of alerting staff in case of issues, shall also be used where required and practical. 5.3 Security & Loss Incidents – Reporting & Handling In the case of actual or attempted physical theft, damage or loss of an UWL IT asset, an IT security incident form, as at Appendix 1, should be completed and sent to the IT Service Desk for appropriate handling. This will include involving UWL Estates & Facilities, insurers and/or the Police as required. If UWL data, sensitive or otherwise, has been lost or damaged with the asset, or could be compromised as a result (eg through gaining account access), then this needs to be clearly identified on the form, leading to remedial steps being taken. If UWL data or IT asset (such as a web site), sensitive or otherwise, has, or is suspected to have, been attacked, accessed, copied or damaged by a network-based, virus, Trojan or other unauthorised logical means, then the security incident



form should still be completed, typically by IT staff due to the technical nature of such an incident. Occurences of virus and like incidents where no apparent damage has been caused – ie the virus was detected and contained by the anti-virus measures in place – will be recorded by the IT Service Desk as an incident, for analysis purposes. As a precaution, users reporting detected viruses will have their system checked by an IT technician. From time to time, UWL will be notified from external bodies such as JANET CERT (Computer Emergency Response Team) that suspect activity has been detected involving the UWL network, such as illegal file downloading, spam e-mails or port scanning. In these cases, UWL shall investigate the report as far as possible, report back as required to the external body and take appropriate internal action as necessary. 5.4 Change Management ALL changes to systems in live operation will be managed in accordance with the IT Change Management process (overview in Appendix 2). Routine and minor changes can be processed as part of the Service Management system, whilst more substantive changes will be subject to appropriate change request proposals, discussion and approval, including with affected University departments where necessary. ‘Emergency’ changes can have direct executive approval, but will be retrospectively recorded through the normal procedure. 5.5 Information Security Management System(s) (ISMS) UWL shall consider, design, implement and maintain appropriate ISMS tools and facilities to manage and monitor system and information security and accessibility in line with the risks, countermeasures and profile of the information systems concerned, as well as to meet the requirements of this Policy. Tools such as identity management/access control systems; firewall and network access control systems; log file analysis systems; patch level and software update management systems; asset and inventory management systems; and anti-virus/anti-malware software. If justified, intrusion detection and prevention systems can be considered and deployed to monitor, alert and possibly prevent network based attacks or unauthorised internal access. However, these systems are expensive, complex and can give rise to a high level of false positive alerts. They should thus only be considered for the most sensitive systems and data. 5.6 System Retirement Systems no longer required for live operational use or occasional historical referral shall be ‘retired’. Depending on the nature of the system and the data it contained, the system, and the hardware and software that it comprised, shall either be just dismantled and securely deleted, with possible reuse of its’ asset components; or



up to the taking of a complete ‘mothball’ copy of the system software and data, so that the system can be restored in exceptional circumstances, such as a data protection request or for other legal reasons. Mothballed systems shall include a complete

copy of the operating environment of all the parts of the system – the (eg server based) application itself, its database server back-end and any front-end PC or web-based clients, as well as the data the system contained. It may be convenient to make such a copy as one or more virtual machines (VMs), so the environment is self-contained (as long as a copy of the relevant VM hypervisor is also maintained in the Software Library, the hardware to run it on is also kept available and adequate documentation to recover and use the system is provided).

It must be accepted that recovery of and data extraction from a mothballed system could be a considerable undertaking, so these should not be considered in any way ‘live’ systems. Such a process is not the same as the disaster recovery of an operational system, and will not be given the same resources and priority. (Note that this is different to the archival or purging of data within ongoing live systems, in that the whole system is to be taken offline in a preserved, and recoverable, state.)



6 Information Handling UWL’s information assets, flows and systems, and the components they are built from, shall be subject to the following considerations and controls. 6.1 Asset Management All of UWL’s significant hardware, software and information assets shall be appropriately identified and catalogued; and stored in an appropriate management system, typically part of or an adjunct to the Service Management system. Although the asset management system shall be primarily for IT Service Management purposes, adequate information, such as order numbers, shall be maintained as part of the asset record to enable correlation with the Finance asset register. New assets shall be recorded at the time of receipt, changes to asset details as they occur; and disposals or other removals noted on the asset record. Asset records will be retained for at least 2 years after their disposal. Verification of the installed asset base shall typically be done electronically, using discovery and asset management tools, although it is accepted that occasional manual audits may be necessary to verify certain areas. Desktop and laptop assets shall be named in line with the naming convention outlined in Appendix 3. Network, server and other infrastructure assets shall be identified as appropriate. 6.2 Licence Management All relevant live software, firmware and other licensable physical, virtual or web-based facilities and services shall be appropriately and currently licensed for use. This shall be in accordance with developers’ and suppliers’ terms and conditions, including any site-, campus-, or enterprise-wide (academic) agreements that may be available. Unless covered under a site or wider arrangement, licences purchased shall be assigned as an asset to the system(s) they are to be used on. If they are to be subsequently moved, then they shall be de-assigned and re-assigned as appropriate. This also applies to ‘pool’ use licences, where a number are available for concurrent usage. Such systems frequently work through a “licence management server” system to manage and control such usage, or via “application virtualisation” systems to deploy and reclaim software for use. Again, software licence use in multi-core/multi-CPU and virtual environments shall be in accordance with suppliers’ terms and conditions. Test and development systems can benefit from trial and temporary use of software licences under programs such as Microsoft’s Developer Network (MSDN) or Oracle Technology Network, or with specific permission from other suppliers. Backup and



disaster recovery systems may also benefit from notional licensing from suppliers, depending on their terms and conditions. The area of software licensing and usage agreements is complex and highly variable. It is thus necessary to consider each licence and contract on its own merits and use the product(s) it covers accordingly. 6.3 Information Protection As discussed throughout this Policy, it is the primary goal of technical measures, processes and procedures to ensure the appropriate protection of UWL’s information. In terms of: providing authorised access when required; denying and detecting actual or attempted unauthorised access; ensuring the integrity and availability of electronic information; and the ability to recover information from loss or damage. It is the responsibility of all individual information owners and users, assisted and guided by Information Technology Services, to ensure that information is adequately protected at all times and is not disclosed, lost or corrupted and that any occurrence of such shall be appropriately reported and investigated. 6.4 Information Exchange Where UWL electronic information is required to be exchanged with partners or 3rd parties, again the provisions of the rest of this Policy shall apply. Depending on the nature and sensitivity of the information, information required to be exchanged on physical media shall be subject to appropriate encryption and signed-for carriage. Information needing to be exchanged by e-mail, FTP or via external web sites shall also, depending on its nature, be subject to appropriate protection and encryption as necessary. Where relevant, all transmitted information shall be subjected to appropriate anti-virus and anti-malware scanning, both outgoing and incoming. Generally there will also be contractual safeguards and obligations in place with the recipients of UWL information to ensure that it is handled and stored safely. Users must not use insecure or inappropriate methods of exchanging or sharing UWL’s information or intellectual property, such as placing it on public web sites, unless there is a good, and approved, business and academic reason to do so. Similarly, any incoming information from partners or 3rd parties shall be treated in the same manner and handled as UWL information once received, subject to any intellectual property considerations.

Payment Information

Where UWL systems, directly or via partners, offer or allow on-line card payment, such as for course fees or print/copy charges, this shall be appropriately in line with the the Payment Card Industry Data Security Standard (PCI DSS). Typically this shall be by using appropriate payment partners integrated with UWL’s systems. 6.5 Application Systems



Information contained within UWL’s application systems shall also be subject to the considerations of this Policy in that the information shall be appropriately handled at all times. In particular, that the internal controls and settings of the application shall be used to ensure only authorised access to information is allowed, appropriate logging of access and application data modifications is in place and that adequate measures are in place to ensure the availability, backup and recovery of the application, as may be required. 6.7 Information Storage In general, UWL’s electronic information shall be stored within UWL’s own directly- managed IT facilities, where it can be expressly fully controlled, kept available, backed up and recovered as may be required. ‘Sensitive’, confidential or commercial information should ONLY be stored under UWL’s full control. Where it is necessary to store lower category UWL information or intellectual property externally, such as on a file or document sharing web-site, then appropriate controls, such as password or closed user group access shall be used, unless it is deemed that the material can be considered and used as ‘public’. 6.8 Retention, Archival & Purging UWL’s electronic information shall generally be subject to the retention provisions of Appendix C of the University’s Data Protection Policy (q.v.), which in turn reflects both legal and best practice requirements for the retention of a wide range of types of information. Where data is no longer required to be retained, it may be deleted or purged as may be necessary. Indeed, this will often be a requirement of Data Protection considerations; not to retain information longer than is required. Data archival from information systems can take place on an as-required basis, typically to keep the information within the system current and relevant, and to improve the performance of the system by keeping indexes small and navigable. Any archival system or arrangement must provide for the secure, possibly duplicated, storage of the archived data and timely mechanisms for the restoration and review of archived data. Software and system differences predicate that many different archival solutions and data sets are likely to exist for UWL’s information. Information with very long retention times, such as 40, 50 years, “lifetime” or even “permanent” will require special consideration, as it is very unlikely that the systems or electronic media supporting such information can be kept running for anything approaching those timescales. Retention and storage as paper records, or the ongoing migration of such data to current systems and technology will be required. 6.9 Secure Deletion Any systems or media that are leaving UWL for disposal will be securely and completely erased or destroyed before leaving.



In the case of hard drives, USB drives and other magnetic or rewritable media, this shall typically be by the use of erasure programs such as “Darik’s Boot and Nuke” which will write secure erasure patterns all over the drive, to whatever level is deemed necessary by the sensitivity of the data on it, to prevent any data salvage or scavenging. For media containing data or information considered to be highly sensitive and confidential, physical destruction may also be carried out following thorough erasure. Other magnetic media that cannot easily be wiped in such a way, such as floppy discs, zip drives or magnetic (backup) tapes can either be physically destroyed by being broken up, or thoroughly ‘degaussed’ in a degaussing unit to erase the magnetisation on them. Optical media, such as CDs and DVDs, are most conveniently physically destroyed, by shredding in appropriate shredders. Infrastructure devices containing configurations and information in firmware or memory, such as network switches or firewalls, shall have their configurations fully and completely erased and/or re-set before disposal. The secure erasure of any sensitive data and information stored in externally hosted or web-based applications will be subject to contractual arrangements and be the responsibility of the information owner to arrange, verified by IT. 6.10 Externally Accessible Systems UWL information systems that are either based external to the UWL network (eg the WWW site systems) or are accessible from the Internet shall have appropriate protection applied in line with the information they contain and the risks associated with it. Please see the Section on Remote Working as to the protection considerations and measures to be applied to the various sensitivity levels of systems.



7 User Management Authorised users of UWL’s operating, application and information systems shall be subject to the following minimum account standards, control and monitoring. 7.1 Access Control Unless data and systems are deemed open for ‘public’ access, all of UWL’s systems shall be accessed by at least one level of log-in account and password. 7.1.1 Staff

New Accounts

Basic staff accounts will be created automatically driven by new starter updates from the HR system Northgate Resourcelink (process outlined in Appendix 4). The standard central Active Directory username for all UWL staff shall be :

<first 4 letters of surname><first 3 letters of first name>

Eg: smitjoh (Where either name is shorter than the letters required, then the form of <full surname><initial> will be used. Where duplicate user names might arise, either the form <full surname><initial> shall be used for the second user, or a combination of all or part of first name, surname and/or other initials will be agreed with the user on an exception basis.) An e-mail address of <first name>.<surname>@UWL.ac.uk shall also be automatically created, eg [email protected]. Again, where a duplicate is likely to arise, this will be handled via an exception basis with the user concerned, to ensure they get an e-mail address name that is acceptable to them. A number of alias e-mail addresses will be created for users, principal amongst these shall be <UWL Staff Number>@UWL.ac.uk to give a unique e-mail address for systems use, such as the Resourcelink system. New users will be required to sign an account acceptance form (Appendix 5 ) acknowledging the grant of the account and access; and agreeing to abide by the UWL IT security, usage and content policies in place. This form shall be held centrally by IT Services. (There are a number of classes of ‘staff’ requiring accounts that will not come through the HR system – eg agency staff, Governors, visiting academics. These will be dealt with on a manual, exception basis in line with this policy.)

Access

This standard account, coupled with the password as detailed below, shall give ‘single sign-on’ staff access to :



• Where applicable, log on to a UWL desktop, laptop or netbook computer

system • On–site wired and wireless network access account log on • UWL staff e-mail system, both from on-site and through remote web mail • Appropriate shared drive, data and information spaces • Access to the e-resources (Library) system (Shibboleth) • The IT Service Desk system (currently SupportWorks) • The UWL Intranet system • (planned) Blackboard Virtual Learning Environment, using additional

permissions and controls inside Blackboard as appropriate. • (planned) SharePoint information repositories and web sites (using

additional, Active Directory-based) permission and role/group controls inside SharePoint

Staff access to all other systems, data, applications and facilities will typically be by further user accounts and passwords given out to authorised users of those systems, again via signed account request forms

– such as UNIT-e, Symmetry BluQube, Northgate Resourcelink, CRM or VPN and other remote access. Some such systems may choose to use and build upon the standard Active Directory account, by using group memberships and permissions. It should be noted that most of these systems have their own account administrators, who are responsible for creating, changing and removing access.

Account/Access Removal

Staff standard log-in accounts will normally be automatically disabled at the end of their date of departure as driven by the HR Resourcelink system. Requests for retaining account access and/or e-mail forwarding will be considered on an individual basis beyond this date – in order to provide appropriate handover or academic cover. Leaver information shall also be provided to application and facilities systems administrators so that they can disable or remove leaving staff at the application account level, as required. In addition, any ICT assets held by the leaver shall be identified and steps to reclaim them on or before departure taken. Line managers shall be consulted, as part of the leaving process and paperwork, as to the disposition of UWL documents and data ‘owned’ by the staff member, on disc or in e-mail accounts. Whether it can be just deleted, whether it can be transferred to another staff member, or is required to be kept/archived for an agreed period, as well as its normal retention within the backup cycle. 7.1.2 Students

New Accounts

Similarly, student accounts shall be created automatically driven by new starter updates from the UWL UNIT-e student registration system.



The standard central Active Directory account names for Students will have the form <UWL Student Number>. This is a (unique) 8 digit number and thus consideration of duplicates does not arise. Students also have automatically created a UWL email address of <UWL Student Number>@ex.UWL.ac.uk and a more friendly form alias of <first name>. <surname>@ex.UWL.ac.uk

Access

This single standard Active Directory account, coupled with the password as detailed below, shall give ‘single sign-on’ student access to :

• Where applicable, log on to an UWL IT suite/Library desktop, laptop or netbook computer system

• On–site wired and wireless network access account log on • UWL student e-mail system, both from on-site and through remote web mail • Appropriate shared drive, data and information spaces • Access to the e-resources (Library) system (Shibboleth) • The IT Service Desk system (currently SupportWorks) • Access to the “MyUWL” online enrolment and course/details management

system (based on UNIT-e) • (planned) Blackboard Virtual Learning Environment, using additional

permissions and controls inside Blackboard as appropriate. Students requiring access to other UWL information systems or facilities as appropriate to their course or studies will have such access provided on a case by case basis, typically under authorisation of a tutor or Faculty administrator.

Account/Access Removal

Student accounts are normally automatically disabled as at their “PAT End Date” as entered into the UNIT-e system. This is typically their course/study end date plus 3 months, to allow for any re-sits, course end activities and to support job or further study search. Student data in accounts is also normally deleted at this time, although may be retained for longer, capacity permitting, as well as its normal retention within the backup cycle. Requests to keep student accounts open or retain their data available for longer periods will be dealt with on a case by case basis. 7.2 Groups Users, both staff and student, will be allocated to both generic and specific Groups within the access and authorisation management system, such as Microsoft’s Active Directory. These Groups, in turn, shall be used to grant and manage access rights and permissions to data and information. IT will manage system-level Groups, but it may be down to data owners and application administrators to manage specific Groups and permissions within their



own areas. It will be important to track any changes in people’s responsibilities, job roles or locations as this will undoubtedly affect the Groups they need to belong to and this must be appropriately managed in order to preserve security. Active Directory will be configured so as to ensure granularity of control is available – ie that data owners, application or departmental administrators will be able to control and manage their own areas without having visibility or reach over other areas. When staff leave, their account will be removed from any Groups to which they might belong. 7.3 Privileged Accounts Users requiring elevated system privilege accounts to perform their work – such as operating system or network administrators, database administrators or application administrators – shall be granted by appropriate line management through a signed approval form. It will be made clear to such users that their usage and activities performed through such accounts will be subject to close logging and monitoring The use of anonymous system, device or application privileged accounts, such as “system”, “administrator” or “root” shall be under approved line management control only. In general, these accounts will be kept disabled to deter hacking attempts. System administrators shall perform their work through personal, named accounts as far as possible (sometimes, the anonymous accounts have

to be used to perform system upgrades or low-level maintenance tasks).

7.4 Password Management There is a need to balance password ‘strength’ with usability, memorability and the avoidance of complex passwords being written down and discovered. All account passwords, staff or student shall meet the following minimum requirement

• At least 7 characters in length (privileged accounts at least 8 characters) • Enforced ‘strength’ – mixed case, alphanumeric and common symbols, not

English dictionary words, not ‘obvious’ or common passwords • Enforced expiry and change every 4 months/120 days (to be broadly in

line with terms/semesters) • Disallowed history lists of 4 previous passwords – to prevent annual recycling

of past passwords. • (Privileged accounts will have enforced expiry and change every month/30

days and will have a disallowed history list of 13) • An formulaic initial password shall be set by IT that will need to be changed

on first login to one known only to the user • Accounts shall be locked out after 5 failed log in attempts; and will require to

be re-set by IT support staff following appropriate verification • Similar considerations shall apply to in-application passwords



Some systems, particularly those involving personal or sensitive data, may ask for additional

verification following primary log on in the form of PIN numbers and/or answers to questions known only to the user. Although not yet in use within UWL, some network or laptop access may require the use of token/key generation devices and/or biometrics.

Changing Passwords

In general, staff and students shall be able and responsible for changing their own passwords on expiry or demand in line with the above standards. In the case of forgotten passwords or locked accounts, users will be required to request changes via IT, with sufficient information and verification to ensure that they are who they say they are. Subject to such verification, IT will re-set the account/password, again with an enforced change on subsequent first log in by the user. 7.5 Policies In many cases, both infrastructure and end-user operating systems and end-user accounts and profiles themselves will be subject to the automatic application of system security and other Policies, which will embody many of the settings and principles set out in the Security Policy. For UWL’s predominantly Microsoft Windows environments, this means the settings and controls available through the Active Directory facility, known as Group Policies. There are, in Windows, approximately 2,500 settings that can be controlled via Group Policies and it is not appropriate to deal with all of them here. 7.6 Logging & Monitoring All user access, success or failure, staff or student, shall be appropriately logged by the systems involved. In the case of privileged accounts, where possible, use of the account to perform privileged operations will also be logged. Accesses will generally only be monitored on an exception or query basis. Use of privileged, or anonymous, accounts shall be periodically reviewed by line management.



8 Systems Usage This Section deals with the usage policies for UWL’s data, systems and information. In general, all system and data usage shall be in line with the IT Acceptable Use Policy, March 2007, as may be amended. 8.1 Authentication As outlined in the User Management section, all users of UWL’s non-public information systems or ICT assets, staff or student, shall be required to authenticate themselves by way of a username/password logon. The majority of access and facilities shall be gained by way of a single sign on at the workstation/operating system level, although a number of more sensitive applications may require additional sign-on and verification. All end-user facing systems shall have a clear initial pre-login statement displayed, outlining users’ responsibilities and acceptable use requirements, which will outline the user’s responsibilities in respect of proceeding to log in and use UWL’s information systems. Users who contravene or attempt to subvert the authentication and usage requirements of a UWL information system can have their accounts temporarily or permanently suspended or withdrawn, in addition to any UWL internal disciplinary action or, in serious cases, referral to relevant authorities, such as the Police.

Access to Accounts

IT can facilitate access to individual accounts and data in their absence, such as leave or sickness. If the user freely gives their express written permission for IT to access their data and, eg, provide it to their colleagues, then IT will arrange for the provision. Requests to access or provide someone’s account or data in their absence and without

their written permission, either for urgent access or investigatory purposes, shall only be facilitated by IT with the express written permission of the Vice Chancellor , Deputy Vice Chancellors or University Secretary. This is to ensure that individuals’ rights and privacy are respected under the various legislation applying.

8.2 Unattended Equipment Users should be educated to close applications and/or lock their workstations when they leave them, to prevent unauthorised access to their data or use of the systems in their behalf. It will be system policy to apply a (login) password protected screen-lock after 15 minutes of inactivity. It will also be system policy to apply energy saving and power management features on workstations, to turn off displays after 10 minutes and hard discs after 20 minutes of inactivity. System standby or hibernation features shall also be considered where appropriate, along with complete power management solutions to



power systems down after prolonged inactivity or at the end of opening/working hours. (Laptops running off batteries will have similar features implemented, on shorter timescales.) 8.3 Data and Information Protection With assistance from IT as may be required, data owners shall be responsible for determining and applying access rights and permissions to their data and who should have what access to them, be they files in personal or shared local or network directories, documents in repositories such as Microsoft’s SharePoint, web sites and pages, or data records in application systems. Personal and work in progress data will typically only need to be read/write/delete accessible to the data owner themselves, eg files in ‘My Documents’ and personal network drives such as the ‘K:’ drive. Team, departmental and Faculty shared information will typically be fully accessible to the creator/owner and read accessible to the rest of their area, such as files in the ‘L:’ drive. University-wide shared information will also typically be fully accessible to the creating/owning team, but will be read accessible to all (staff) users of the University’s IT facilities, such as files in the ‘M:’ drive. Data owners should be aware that information placed at this level will be widely accessible. (UWL also has a ‘J:’ drive for the delivery of (desktop) application code and configurations. Only IT has write access to this drive and usage access is only assigned to those needing it.) Data owners should discuss with IT resilience, backup and recovery requirements for their information, to ensure any additional considerations are covered. If data or information is particularly sensitive, then password protection and/or encryption should be considered, as outlined in the Section on Encryption. 8.4 E-Mail E-mail shall be used in accordance with the University’s E-Mail Usage and Monitoring Policy, February 2007, and as may be amended. 8.5 Internet Usage Internet usage shall also be used in accordance with the University’s Internet Usage and Monitoring Policy, March 2007, as may be amended. Users of the University’s internet access are also bound by the JANET Acceptable Use Policy. With the exception of cover required for Reading FE students, UWL does not currently apply any web site or content filtering or monitoring, although web site accesses are logged at the network level. Users should thus be aware that web usage activity can be tracked back to logged in workstations. IT are occasionally



asked to investigate file downloads or other possibly illegal or inappropriate web access activity. Disciplinary or other action can result from inappropriate web activity.

Downloads

At no time shall a user download and install onto a UWL-owned system software, utilities, add-ons or plug-ins from the Internet, due to the high risk of acquiring malicious software by this method. Downloading files or acceptance of running ActiveX or other browser scripting add-ons should only be considered from known and trusted sources. If additional facilities are required, IT should be contacted to consider the requirement and how best it can be met. It is worth reiterating that UWL systems must also not be used to download or share any copyrighted material without appropriate licences or permission. Users found to be in contravention of either of these principles are at risk of having their system access withdrawn temporarily or permanently, as well as facing disciplinary or other action. 8.6 ‘Cloud’, Hosted or Shared Service Systems The same principles apply throughout to UWL data or information that may be placed or reside in systems external to UWL, such as explicitly externally hosted, ‘co-located’ or shared service systems; or in distributed, effectively location-less, ‘cloud’ systems and services, including web-based systems such as Google Docs. It remains the UWL data owner’s responsibility to ensure that adequate safeguards are in place to protect data in accordance with this policy. Contractual terms with the service provider should be used to ensure UWL data confidentiality, security and integrity. 8.7 ‘Web 2.0’ Systems Users that wish to place UWL-related (or even personal, in the context of their relationship with UWL) data into public, collaborative and social-networking systems, commonly referred to as ‘Web 2.0’ – such as FaceBook, MySpace, Bebo, YouTube, Flickr, Twitter, wikis, blogs etc. – should remain very aware of the requirements of this Policy. These sites can be very valuable marketing, support and collaboration facilities and UWL is right to have presence and involvement with them. However, UWL data or information should not

be put on these sites without appropriate consideration and clearance from line management and IT. It effectively becomes public by so doing. Data owners, staff and students should be aware of the possibilities for UWL and personal reputational damage from the inappropriate usage or disclosure of information; the possibilities of identity theft from making personal information readily known on social sites; and the possibilities of being held personally accountable for content or activities on-line.

In some cases, UWL are ‘required’ to collaborate via ‘Web 2.0’ systems with other institutions and partners as part of joint work and projects. In most cases, responsibility for the security of the information falls to the ‘lead’ organisation.



However, UWL users should be aware that the considerations of this policy still apply. 8.8 Printing & Copying In areas where printers are shared, typically large ‘multi-function device’ (MFD) units, users shall be required to ‘release’ their prints to have them actually printed when they are near the device. Users requiring to print out appreciable quantities of personal or confidential information shall have access to dedicated and ‘private’ printers on which this can be done. Copying does not normally present many security issues, providing that originals are removed from the unit and that copies are collected. Copiers that store in memory should be cleared, if the copy is sensitive. Copying should also not contravene any copyright or licensing requirements in force. See also Section 10.9 8.9 Remote Takeover and Assistance The use of remote takeover, control and assistance software – such as VNC, Remote Desktop, Dameware or GoToMyPC - shall be restricted to IT as part of their support and operational duties. Appropriate password controls shall be established as part of these software to ensure that systems cannot be accessed without authentication. Where possible, users shall be required to explicitly accept and allow such an incoming access session. Users may also request support assistance via a ‘remote assistance’ facility. This has a number of exchanges and verifications built in to ensure that only the requested person can gain access and provide support by this method.



9 Systems Management This Section addresses security considerations and procedures for UWL’s directly managed infrastructure systems, servers and storage; and desktops and laptops as regards their centralised management. Indirectly managed systems, such as via hosted or ‘cloud’, are to be subject to the same principles, via contractual terms and agreements, where necessary. 9.1 Access Control UWL’s infrastructure systems will normally only be directly accessed by authorised IT staff, via privileged or non-privileged accounts as necessary in line with the measures described in the User Management section. All successful direct logons, and unsuccessful attempts, to infrastructure and server systems will be logged.

Supplier Access

On occasions, supplier and external support consultants may be required to access such systems directly, to provide diagnosis and support for problems, or to perform or support software upgrades or system optimisation. This could be on-site or via remote network access, such as a remote terminal session. Such access shall be strictly controlled via named supplier accounts on the system(s) concerned. These are typically privileged accounts. Their grant and use will be covered by contractual arrangements with the supplier. These accounts shall only be enabled, under IT Change Management, when explicitly required for external support purposes and shall be disabled again immediately the support session has ended. In addition, explicit external controlled network access may be required to be enabled to allow the incoming support, and then also disabled again. Where possible, such local or remote support activity shall be monitored by a UWL member of IT staff , for example by observing a remote takeover session, and/or, where possible, by using screen/session recording utilities to provide a complete record of what was done. (This may not be 100% if the system needs to be restarted during the work.) 9.2 Privileged Accounts UWL IT staff frequently need to use some or all system privileges or permissions to perform their support and project work. The use of system privileges allows powerful commands and activities to be carried out, at all levels within a system, and relies on the responsibility of the staff member, intentionally or inadvertently, not misusing such privileges. All staff needing privileged access to one or more UWL system or server shall have a separate personal, named privileged account created through which to do their work. The request and approval process for such accounts shall include a detailed agreement to responsibilities, terms and conditions for the use of the account,



signed by the staff member and a member of the IT Senior Management team. (The majority of staff’s work shall be conducted via their normal, non-privileged account.) ‘Anonymous’ system privileged (and non-privileged) accounts – such as “system”, “root” or “administrator” - shall both be disabled and have any default passwords changed on installation. They shall only be used when absolutely necessary, for example they are sometime required for low level system support or a major upgrade. Any such usage shall be sanctioned via IT Change Management to enable visibility and subsequent review of the usage. As mentioned above, use of all these accounts shall be logged and reviewed by the Senior Management team. Although it is not considered practical for support staff to record every session and keystroke they make as part of their day-to-day work; in certain cases or situations, it may be necessary to ask staff to record their sessions for verification of the activities undertaken. Any cases of unauthorised anonymous system account usage shall be fully investigated. 9.3 Detection and Prevention of Malicious Software UWL shall have in place reasonable and adequate facilities to detect and prevent the use or actions of known malicious software on its’ systems. “Malicious software” covers the whole range of undesirable software that can become installed and operational on systems – viruses, trojans, adware, spyware, worms, rootkits, botnets, keyloggers, remote takeover etc. For a discussion of physical and logical network security measures, intended to prevent such software entering UWL systems in the first place, please see the Section on Network Management. Increasingly, however, such software is picked up by visiting ‘infected’ web sites, often just by accessing an html page or allowing an innocuous-looking control to run; or some other takeover and use of a legitimate outward-initiated network link. UWL shall rely on several parallel and sequential methods of detection and defence against such software. At the outer perimeter of the UWL network, a firewall shall block all unauthorised incoming sessions, ports and protocols. Allowed incoming sessions shall be managed in to appropriate destinations that will handle traffic as required – for example, e-mail traffic shall be directed to front-end spam, virus and junk mail detection systems before being allowed through to UWL’s e-mail servers. In turn, the e-mail servers shall run anti-virus and anti-malware software to detect any unwanted content in e-mails getting through. Finally, end-user workstations shall also run anti-virus software to detect, quarantine and remove any malicious software that may make it that far. Similarly, server-based filestores and document repositories shall have anti-virus and anti-malware scanning facilities. Where possible and desirable, several anti-virus products shall be used, such as a paid-for mainstream product like McAfee or Microsoft ForeFront, coupled with a alternative product such as AVG, Windows Defender or Microsoft Security Essentials. This is to allow for different approaches to increase ability to detect and prevent malicious software from running.



Outbreaks

Should UWL suffer, or believe to be suffering, a malicious software activity outbreak, apparent by multiple system/workstation problems, mass mailing, port scanning, excess network traffic etc., then the following actions will be taken :

1. Disconnect UWL network from JANET, to prevent external spread of outbreak 2. Isolate internal network segments/VLANs in order to contain the spread of

the outbreak 3. Isolate and ‘quarantine’ infected and/or broadcasting systems 4. Communicate outbreak and actions (being) taken with affected stakeholders 5. Attempt to clean up outbreak using appropriate detection and removal tools,

patches and updates, up to and including a complete wipe and re-build/re-image of affected systems

6. Where data has been lost or corrupted, restore and rebuild as required from backups known to be ‘clean’.

7. Bring systems and network segments gradually back into operation whilst monitoring for further malicious activity and traffic.

8. Appropriately record incident on Security Incident Form (Appendix 1)

Zero Day Attacks

In the case of a new virus or attack, for which no detection or prevention yet exists, a so-called “zero day attack”, the above actions shall be taken up to step 5. If no specific ‘fix’ exists, then possibly one, or a workaround, can be devised in house, but often it is necessary to wait for anti-virus or system software vendors to create a ‘fix’. 9.4 Utilities The installation and use of powerful system or database utilities, that may cut across operating system, database or application level permissions and controls, shall be strictly used on a needs only basis, under IT Change Management. Where possible, the usage of such utilities will be logged and reviewed by IT senior management to ensure appropriate and controlled use. It is accepted that there are occasions when such utilities have to be used to investigate problems and restore services. 9.5 Patching and Updates All of UWL’s server and workstation operating systems, database software, package software and applications shall be kept appropriately patched and up-to-date. UWL-network based desktop and laptop systems shall be patched from central UWL update servers, using a system management utility such as Microsoft’s System Center Configuration Management. This is to allow the controlled release of patches and minor updates across UWL, having first been tested on sample ‘build reference’ systems. In the majority of cases, this will result in the prompt release



of important security patches only a little later than they would have been by direct updating, with a reduction in risk of a rogue patch being installed. This behaviour shall be controlled via settings and parameters available through system management and configuration policies (Group Policies). Anti-virus updates, and anti-virus policy controls, shall similarly be made available from central update servers Systems that are only infrequently on the UWL network, such as roaming laptops, will be set to get their updates and patches directly from the supplier sites over the Internet, as the risk of not being updated at all is much greater than that of a rogue patch being installed. ‘Major’ upgrades and updates, typically a new version release, for systems and applications shall be appropriately planned, developed, tested and implemented as a distinct project as there are frequently many other considerations in such a update. 9.6 Backup & Recovery In line with system risk assessment and contingency measures, all of UWL’s data and information systems shall have appropriate backup and recovery measures in place, to meet the recovery time and recovery point requirements of the system. This is a very complex area and ‘backup’ can range from simple full or incremental nightly file copies to disc or tape up to multi-server system consistent application data snapshots, involving system and storage-level techniques, remote data ‘mirroring’ and virtual and physical tape libraries, under the control of possibly several layers of backup and recovery software. Is it not intended to outline every possible backup and recovery scenario in this Policy, save to set the principles that there shall be appropriate backup in place, and that recovery shall be periodically tested, at least once every 6 months, if not otherwise required. Users that may be saving data on local workstations or mobile laptops shall advised to make their own secure backup arrangements for their data. They will be provided with appropriate USB memory stick or external disc drive devices to take separate backups to. 9.7 Monitoring & Detection Where possible and practical, a wide range system activities and events shall be logged in system log files. This shall be managed so as not to unduly affect system performance or cause problems through the excessive growth of log files. Although log files can be reviewed manually, they generally contain far too many entries and ‘noise’ for events of note to be noticed, unless being specifically looked for. Where possible, log file reader and monitoring software shall be used to summarise and identify events of note. If necessary, monitoring software shall



raise alerts, system management activities and incident requests in the Service Management System for further investigation. Of particular interest to this Policy are the Security logs. Within Windows, these can be set up to record success or failure of a wide range of auditable events. In general, these will include the success or failure of all system logons; account management activities; sensitive object access, such as data files or folders; system policy changes; process and program tracking; and the use of privileges. 9.8 Housekeeping & Logging Systems shall have in place appropriate housekeeping regimes to ensure that message and log files do not become full or start to overwrite. Depending on the system involved, log files will generally be saved for a period to allow for retrospective review and ‘audit’ of system activity. Temporary and update working file locations shall be periodically cleaned out.



10 Network Management UWL’s internal networks and their interfaces to the Internet, via JANET, play a significant role in supporting and enforcing IT security. They are the way by which systems are accessed, carry traffic and data between them and present paths and gateways through which network interaction can occur with authorised and potentially unauthorised external systems and users. It is therefore vital that the network itself, and the activities it carries out, is both highly secure and can be used to detect and alert a number of potential IT security issues. 10.1 Configuration

Firewall

UWL’s main network access to the Internet, via an uplink to the Joint Academic network JANET, shall be protected by adequate ‘Firewall’ systems to ensure that only authorised incoming and outgoing traffic and sessions can pass across this interface. Again, firewall configuration is a highly complex issue and it is not intended to specify this in detail here. However, in general, the majority of outgoing traffic and protocols shall be allowed, under network address translation ( NAT) as required, whilst incoming traffic, protocols and ports shall only

be explicitly allowed under considered and approved rules, governed by IT Change Management process.

All incoming and outgoing sessions will be logged, for review and reporting as necessary.

DMZ

Where practical, systems requiring to be accessed externally shall be located in a logical and/or physical network ‘de-militarised zone’ (DMZ). This is to allow separation and containment of incoming network access sessions from the main internal network. Typically these are for internally hosted, but publicly accessible web sites, or (front ends to) web-delivered UWL applications. Systems needing to process externally incoming traffic - such as load balancers; e-mail spam/junk scanners; VPN & other remote access front-ends; and virus scanners - should also be located in the DMZ to ensure separation of their activities from the main internal network.

LAN

The main internal UWL network shall be physically and logically configured so as to provide controllable and separately manageable network segments. This will be both by way of physical switch and port wiring and connectivity; and by the use of VLANs to logically segment traffic types, protocols, usage areas. The network shall have a high degree of resilience and failover built in, typically the provision of 2 network ‘cores’ on main sites and dual pathing of edge switch



connections. Network monitoring and management tools shall be used to verify and control network operation, with appropriate logging being recorded by network equipment or being sent to a ‘syslog’ server. Unless absolutely required and approved, network ‘spidering’ – the connection of one or more local ‘fan-out’ switches to a LAN edge switch port/socket – shall not be allowed, in order to preserve network traffic load management, ‘hop’ rules and for the visibility and management of network-connected devices. Any physical or logical changes to the operational configuration of the LAN shall be subject to the IT Change Management process.

Inter-Site Connections

All ‘internal’ network links between UWL’s main sites and sub-sites shall be on private point-to-point physical or virtual circuits to maintain the control over the internal network inside the firewalled perimeter. 10.2 Access The operation and control of network devices typically requires the use of privileged accounts. Where possible, these shall be separate named accounts and used through a centralised network management system, such as Extreme’s EPICenter. Also where possible audit and logging facilities shall be used to monitor changes and the use of privileged access. Default passwords to default device accounts such as ‘administrator’ shall be changed on installation and, where possible, these accounts disabled. 10.3 Management Most network devices have both remote management capability and local, web- or telnet- based, management interfaces. Where possible, devices shall be managed through a centralised network management system. Where possible, full record of on-site wired LAN ports and their (TCP/IP address) connection back to a switch port shall be kept. Unused/unpatched switch ports should be disabled, to help prevent the unauthorised connection of devices to the UWL LAN. The non-volatile configurations for all operational network devices shall be appropriately saved either into the network management system or to appropriate locations from which they can be restored. Configurations should also be backed up as part of normal data backup operations. The planned soft/firmware patching and upgrading of network devices shall be carried out outside of core UWL working hours, to minimise potential disruption, again fully subject to IT Change Management process. 10.4 Physical Security All network devices, core and edge, shall be housed in appropriate, locked, network rooms and rack enclosures, to ensure that they are not accidentally or intentionally



accessed or interfered with. Normally, only IT technical staff and supervised supplier staff would ever need to gain physical access to network equipment. 10.5 Wireless Networks UWL’s wireless networks should only allow connectivity from authorised users and only allow the connection of appropriately configured workstations. The wireless network shall require authenticated username/password logon from staff or students. ‘Guest’ accounts are available, but these also require the use of a password, obtainable from IT. The wireless network shall run at a high level of encryption and security, using WPA2. Only authorised and approved users and devices shall be given access to the required WPA2 key to enable connection to the wireless network. Wireless network coverage shall be periodically tested to ensure that there is not excessive ‘leakage’ of the coverage outside of UWL’s campus premises, which could encourage ‘drive-by’ network access attempts. 10.6 Intrusion Detection UWL shall consider the case for the formal use of ‘intrusion detection’ systems (IDS). They can be difficult to successfully configure and manage and often report high numbers of false positive alerts to be investigated. On the other hand, they can often miss genuine attacks that use very low attack rates or involve polymorphic, mutating or encrypted viruses At present, it is not policy to deploy or use an IDS on the UWL network, although they, or similar network packet sniffing systems, may be used for development and testing purposes. 10.7 Penetration Testing UWL shall periodically commission the independent penetration testing of its publicly visible network addresses and ports to verify security, how systems deal with apparent attacks and to ensure known vulnerabilities are adequately patched. 10.8 Public Networks UWL equipment being used on, or over, public networks is covered in the section on Remote Working. The principle is that sensitive or confidential UWL data shall not travel unencrypted over a publicly accessible network, or be stored on any public or third party systems. 10.9 Telephony ‘Traditional’ wired PBX telephony does not normally present a high level of information security risk. However, more modern internet protocol (IP) and wireless telephony (including mobiles) runs a greater level of risk of interception, eavesdropping or masquerading of conversations and other telephony sessions, particularly where it is closely integrated with computer systems, eg for voicemail,



faxes etc. Such telephony shall be subject to many of the physical and logical system and network security considerations contained in this Policy, with stored and transient voice traffic considered to be (sensitive and personal) ‘data’ in this context.

Fax

Stand-alone, multi-function or computer integrated fax machines can present information security risks by :

• The fax being sent to the wrong recipient number • Faxes being stored in the memory of a unit, to be viewed or printed out by

subsequent users • Faxes left lying in open-access machines, to be picked up by passers-by

These can best be avoided by taking care and instituting good practice. Where a department needs to send and receive a lot of confidential faxes, eg Finance and HR, then dedicated, private fax machines should be used in those areas. (See also Section 8.8)



11 Mobile Computing As UWL’s places and nature of work and its workforce become increasingly diverse, dispersed and peripatetic in nature; and increasingly need to be able to work from anywhere and at anytime, there is increased reliance on and the use of UWL-supplied mobile computing devices to support this work. Mobile devices, by their very nature, present some very clear and heightened information security risks and concerns. They are outside of the main organisational information security control boundaries and are much more susceptible to loss, theft, damage or inadvertent disclosure. Mobile computing does not now just include laptops or netbooks, but cover a whole range of smart devices such as smartphones, handheld gaming consoles and a very wide range of portable storage and information handling devices. Although this policy deals with UWL-supplied and sanctioned devices, it is recognised that personal such devices may also be used and that similar considerations apply to UWL information howsoever held. 11.1 Use of Mobile Devices UWL-supplied mobile devices shall, where possible (eg laptops and netbooks), be configured with a power-on security password known only to the user of the device. An administrative security power-on password, known to IT, but not the user, shall also be applied to control the BIOS configuration of the device and to deal with cases where the user may forget their power-on password. If the device is to contain sensitive UWL data of any form, typically personal or financial information, then that data must be stored in an encrypted folder or drive. IT IS will advise on and implement encryption where required, keep a record of the type of data stored on the device, and of the protection used. Please refer to Section 13 for further information on the encryption to be used, and its management. Mobile devices will generally be configured to work in a ‘stand-alone’ way, in that they will contain all the software and facilities necessary for their basic use without needing to connect to a network. Access from the mobile device to UWL’s web and business systems shall be governed by the access controls applicable to those systems, although typically the mobile device will also be configured to use a secure VPN connection onto UWL’s network. Mobile users shall be configured as limited local administrative users of their devices, for reasons of convenience and support when remote from UWL. A control policy as to what can and cannot be changed locally shall be applied to the devices. Mobile devices shall be configured to receive anti-virus and software patches and updates direct over the Internet from supplier sites, rather than via the UWL network, as such connection may be sporadic. Users shall be provided with appropriate carry case and physical security devices, such as ‘Kensington’ cable locks to reduce the risk of damage, loss or theft. Users will be fully appraised of the risks and countermeasures in using mobile devices,



again in the areas of damage, loss, theft and inadvertent disclosure. Users will sign a laptop allocation agreement (Appendix 6) covering some of these issues and acknowledging their responsibilities in these areas. 11.2 Portable Storage Devices There is now a vast plethora of devices and media which can be used to store and transport digital information. Mobile phones, cameras, MP3 and other media players, USB sticks, external/portable hard drives and so on. These can now have sufficient capacity to store huge amounts of UWL’s information on them. It is currently considered impractical to try to prevent or police the direct or indirect use of such devices on UWL’s systems and thus the general policy statement is that sensitive UWL data should not be stored or transported on such devices. The same considerations apply to any removable digital media, from floppy discs, through CDs, DVDs and Blu-ray discs to high capacity backup and cartridge tapes (except for purposes of system operation). If sensitive data has to be stored or transported on any such media, it must be stored in an encrypted form. Again, IT will advise on and implement any such encryption required, if there is no alternative. If the media is to be sent to a specific location, then it should be carried by a reliable courier service with receipt signed for. Any third parties receiving such data would be covered by their contractual obligations Users taking copies of sensitive UWL data onto a portable storage device (or, indeed, paper) in contravention of this policy do so at the risk of disciplinary action should the information become disclosed. 11.3 Use in Public Places Users are to be reminded that the use of UWL-supplied mobile devices in public places runs several risks. Loss, damage, or theft. Inadvertent disclosure through ‘shoulder surfing’ (other people reading information off of screens). It is also technically possible for wireless communications (such as WiFi, Bluetooth or 3G) to be intercepted, which may be more of a risk in public places. Users are thus required to be vigilant and sensible in their use of mobile devices in public places, keeping them under close supervision and using discretely, particularly if for confidential or sensitive purposes. 11.4 Mobile Phones Mobile phone conversations are, in addition to being possibly overheard, theoretically susceptible to signal interception and eavesdropping. Users should again be aware of the use of mobile phones for the discussion of particularly sensitive or personal subjects, especially in public places. More importantly, many – UWL-supplied or personal - phones can be used to access e-mail on UWL’s systems. This can involve the storage of account details and UWL contacts in the phone and a potentially large number of UWL e-mails on



the phone. UWL staff should be advised not to allow the storage of any sensitive UWL e-mails on their phones. The use of Blackberry devices is common across UWL’s senior management. Although the transmission of data to and from the phones is securely encrypted, e-mails may still be visible on the phone itself, should be it be lost or stolen. Blackberry devices can have local security features enabled, and can be managed and even wiped remotely, but again the basic principle applies that sensitive data should not be allowed to persist on mobile and roaming devices, for risk of disclosure.



12 Remote Working This section deals with the remote and mobile working of UWL staff and students and their remote access to UWL data and systems, whether via UWL supplied equipment, personal equipment or public or private 3rd party equipment, such as public Internet access terminals or equipment based on other organisations’ sites and networks. 12.1 Access Methods UWL has several classes of remotely accessible systems and data :

• Publicly Accessible

Systems and data that are open to public access without any authentication being required, typically web sites. Such as the main www.UWL.ac.uk site and related sites and sub-sites. Public parts of Faculty, School and services sites. By their nature, these systems and their content can be accessed by anyone, from anywhere, at any time. Logs and monitoring of access may be undertaken, but mainly for usage information.

• Low Security Systems and data that require UWL authentication to remotely (and typically also locally) access their content, but are not deemed to be containing especially sensitive data or requiring higher security measures. Again, typically web sites. Such as the Blackboard Virtual Learning Environment, the Library e-Resources website, MyUWL student portal & registration site, staff and student e-mail web access, UWL staff Intranet/portal. UWL users will be required to use at least one level of authentication to gain access to such sites, typically requiring a username and password in line with the section on User Management, such as an Active Directory account. Such sites, where possible, shall use HTTP Secure (https://) encrypted and certificated protocols and communications.

• Medium Security Systems and data that are still Internet facing, ie have a publicly visible URL, but require additional levels of authentication and verification for their remote access. Such as the MyView/HROnline system. These sites will require ‘network’ level authentication via an Active Directory account, as above, and an additional level of logon and authentication, typically to a separate account within the application itself. Where possible, additional personal detail verification, such as date of birth, will also be used. It will be mandatory for such sites to use HTTPS.

http://www.tvu.ac.uk/�



• High Security Sites containing sensitive personal information, UWL financial and confidential information shall NOT be made Internet facing at all, even if they have a web interface. They will not have a publicly visible URL or any other direct access method. Such as the Finance BluQube application, UNIT-e student records system, HR/Payroll application ResourceLink. Remote access to these applications, if required and justified, will be granted and controlled via a secure SSL Virtual Private Network connection, using software keys and/or tokens as appropriate, which will provide a secure ‘tunnel’ into UWL’s internal network and access to these systems will be the same as though the remote user were directly on the UWL internal network. All remote access to such systems will be fully logged and trailed.

12.2 Authorisation Remote access to systems and data below ‘High Security’ shall be provided on a role-needs basis as a routine part of the staff and student lifecycle with UWL. Active Directory and application accounts shall be ‘automatically’ set up, maintained and deleted in accordance with standard procedures and processes. Use of the SSL VPN to connect to UWL’s network shall be controlled by IT, who will require appropriate justification and record of the request and proposed usage. (End user and supplier access request forms can be found in Appendix 7.) Such access will be aggressively maintained, in that users no longer needing access will be removed from the facility. At the very least, this will be through the leavers list and process. SSL VPN access will ONLY be enabled and allowed from UWL-provided and owned equipment. It will not be permitted for staff or students to use or access the VPN from their own or 3rd party equipment. Remote access to ‘High Security’ systems, on top of the VPN access, shall be granted by specific written approval of the relevant D-/P-VC, Dean or Director of the faculty or business area involved – eg the Director of Finance for BluQube. This access will be managed by a combination of IT and application-specific administrators, where such exist. 12.3 Equipment Staff will be provided with appropriate and adequate mobile and remote access equipment by UWL, typically a laptop or a netbook. This will be configured with the appropriate remote access method and technology depending on requirements for system and data access as outlined above, and also in line with the Section on Mobile Working. If certain members of staff work regularly from home, then it may be appropriate for a similar desktop system to be provided for them to use for UWL business from home. (The provision of home office (IT) equipment and considerations in that area are to be dealt with in the HR Home Working Policy.)



Students would only be provided with UWL-supplied remote access equipment for certain limited functions or project work. These are anticipated to be very limited in number and subject to consideration and approval of the study protocol involved. They will have limited remote access only to support the required function. (Where students are provided with UWL laptops as part of a course incentive, then these will be considered as the students’ own personal laptops and not have specific remote access functionality applied to them.) 12.4 Use of private or public equipment As indicated above, it will NOT be permitted or possible to access ‘High Security’ UWL systems and data from equipment that is personal, private, 3rd party or public. Only UWL-supplied, configured and managed equipment will be enabled for SSL VPN access. This is for reasons of ensuring that systems have appropriate software build, anti-virus and other anti-malware provisions and control policies as to how the system can be used, to ensure that systems of unknown provenance or potentially compromised systems cannot directly access the UWL network via the VPN. It is also to ensure that sensitive UWL data does not get transferred or left on public access or 3rd party organisation systems.



13 Encryption This Section covers when digital encryption will be required to be used to protect UWL’s sensitive, financial and confidential data and information, either whilst stored on media or in transit over a network. It is recognised that the majority of UWL’s data and information is not of a sensitive or confidential nature and thus encryption is expected to be used in relatively rare and limited cases. It is also recognised that encryption and protection appropriate to the nature of the information involved needs to be used. 13.1 Use of Encryption As stated above, encryption and other privacy protection need only be considered for use for sensitive or confidential information, such as staff or student personal data or financial data relating to UWL’s business. It is possible that encryption can be used for other information with discretion, although the policy stated here should be followed whenever such protection is used. There are many different levels, types and products for encryption and protection available for digital information. It is UWL’s policy that only standard operating system or standard software-supplied, encryption facilities be used on UWL’s computer systems, such as Windows XP’s ‘Encrypting File System’ or Windows 7’s ‘BitLocker Drive Encryption’ technology. This is to ensure that the encryption or protection used can be appropriately managed, supported and integrated. Hardware devices that have their own encryption built in, such as network appliances or USB sticks, will again use the standard offerings for those devices.

• File-level Protection

o Files (such as Microsoft Office files) can be protected by the application of various levels of security passwords, when saving it, to open or modify the document. This encrypts the contents and makes the document unreadable without the password. This is considered adequate for low-medium sensitivity information. The password(s) should clearly not be forgotten and should not be transmitted in plain text along with the document.

A similar technique would be to ‘zip’ the file or files into a password protected archive.

o It is also possible to encrypt files or folders at the operating system level. This is more secure and should be considered for high sensitivity information. This does, however, require the use of digital certificates which is discussed further below.

• E-mail

o In general, if it is really necessary to transmit confidential information by e-mail (this should be avoided if at all possible), then this should be



by way of a secured (encrypted or password protected) attachment, so the e-mail itself does not contain the information in plain view.

o If it is absolutely necessary to encrypt an entire e-mail, either to protect the contents or to adequately digitally identify the sender and receiver, then again this involves digital certificates and public/private key cryptography. A major consideration here is that the sender and recipient agree to use the same sort of encryption and have previously exchanged compatible public keys so that messages can be securely encrypted and decrypted (using respective private keys).

This is a complex area and inappropriate usage can easily reduce rather than increase security. IT should be consulted and will advise on the use of e-mail encryption.

• Network Traffic

o In general, network traffic on the internal wired UWL network shall not be explicitly encrypted, unless this is a specific requirement for the information involved when an appropriate form of protection shall be employed. Network devices inherently needing to use encrypted communications shall be configured to do so in a known manner.

o Wireless network traffic on UWL sites shall be encrypted to an appropriate level, typically using WiFi Protected Access 2 (WPA2) with an appropriate key generating password.

o As mentioned within Remote Working – Access Methods, it is mandated that network traffic to and from ‘sensitive’ UWL web sites be protected by use of the HTTP Secure protocol, which itself requires an appropriate digital certificate to encrypt and validate the site and its’ traffic.

o Instances where usernames and passwords are required to be transmitted across the network, internally or externally, shall use appropriate encryption sessions, such as HTTPS or Secure Shell (SSH), rather than using clear text.

o If large amounts of sensitive data are required to be transferred over the network, then it may be required to establish an secure File Transfer Protocol service (SFTP). However, it would be preferable for such information to be transferred on removable media, suitably encrypted and couriered.

o Secure network connections for high security access from outside of the UWL network shall be secured using an SSL VPN.

• Removable Media

o Again, only if it is absolutely necessary should sensitive or confidential information be stored on removable media, such as DVDs or USB sticks. If this is required to be done, then the information must be



stored in a encrypted form on the media. Some USB drives now come with encryption facilities and must be employed for such use (IT will supply suitable USB drives/media on request).

o A senior manager from the area ‘owning’ the information must give written approval for the information to be so stored and IT will arrange for the encryption to be applied.

o The media should be held or transported in a secure way, such as by being locked away or sent by courier.

• Application Data

o Application data, such as the data inside the Finance System BluQube or the student records system UNIT-e, whilst not technically ‘encrypted’, is stored in such a diverse format and in many layers within a database system that it is effectively protected from view. Other security considerations, as specified elsewhere in this Policy, protecting the database files themselves and internal application security and permissions complete the protection of application data.

13.2 Key and Password Management One of the main issue areas around encryption and protection of digital information is the legitimate decryption of the information in the case of key or password loss. In order to ensure that UWL can legitimately retain access to protected information, IT shall implement ‘recovery agent certificates’ and/or ‘recovery password’ facilities so that the local or domain Administrator account can provide a ‘private recovery key’ to decrypt and recover information if necessary. In addition, users will be encouraged to take backups of their keys, passwords and certificates. Users will be required to consult with and involve IT in applying and using encryption for any of the above purposes, so that appropriate recovery and decryption measures can be put in place. It is considered impractical, and insecure, for IT to ask users to store or share straightforward passwords used to protect document files or archives. Users will be encouraged to make appropriate arrangements to ensure that they do not forget, or can take steps to recall, any such passwords used. Utilities are available to apply a realistic ‘brute force’ crack on file passwords and these will be used as a matter of last resort (whereas it is not practical to use such a technique on public/ private key encryption). 13.3 Digital Signatures and Certificates For general encryption, UWL shall implement an asymmetric public key encryption scheme. This is a complex environment, but essentially consists of UWL running an internal Certificate Authority to dispense and manage certificates and keys to users of UWL’s protected information and systems. Once the identity and role of a user



requiring to use encryption has been manually verified and recorded, unique ‘private’ and ‘public’ keys and a ‘digital certificate’ will be issued to the user. Generally, users will encrypt and decrypt information using their ‘private’ key whilst recipients will decrypt and reply using the ‘public’ key, which is contained in and verified by the digital certificate. For externally visible and validated (HTTPS, SSL or SSH) sites, UWL shall use certificates from recognised public Certificate Authorities, such as Verisign, Equifax or Cybertrust, so that browsers will recognise and trust the certificates and keys involved.



14 Disaster Recovery & Business Continuity In line with system risk assessment and contingency measures, all of UWL’s live, production data and information systems shall have a level of disaster recovery planned for them and appropriate invocation capability put in place and periodically tested, from complete cold-start-rebuild recovery up to fault-tolerant continuity site failover and continuous operation. Where necessary, this shall be done in association and line with wider UWL Business Continuity procedures, which are outside the scope of this document. 14.1 Measures All of UWL’s production systems shall be categorised into one of the following 4 recovery options and measures, which decrease in anticipated elapsed recovery time, but significantly increase in cost and complexity. It is envisaged that only the most (customer facing) business critical systems will require or have the highest level of recovery planned for them :

1. Cold Start Rebuild

No dedicated recovery hardware or systems are in place. In event of disaster, hardware would be co-opted from other use, called in under contract or new procured, and the system rebuilt from the hardware upwards – operating system; drivers and utilities; any database container; application software; any client rebuild; and full restoration of most recent data from appropriate on- or off-site, on- or off-line backup media (typically an off site tape, typically a backup from the previous working day). Estimated recovery time : 3 – 5 days Recovery Point age : <24 hours Suitable for: Very low criticality business systems or

facilities; information-only web-sites; stand-alone systems with no SAN connectivity; systems with fairly static read-only data

Examples: SunGard recovery contract

2. Warm Start Rebuild

Identified or dedicated hardware is actively or passively available or reserved for system recovery purposes (eg standby or a comparable test or development system that can be rapidly co-opted into recovery use, possibly using virtual machines). Would typically have operating system; database and application software already installed, and thus only require the full restoration of most recent data from appropriate on- or off-site, on- or off-line backup media (typically an off site tape, typically a backup from the previous working day). Estimated recovery time : 1 – 2 days Recovery Point age : <24 hours



Suitable for: Low – medium criticality business systems or facilities; standard web-sites; systems with ‘NAS’-level SAN connectivity.

Examples: Student e-mail and fileshares, staff fileshares, ARC, QuestionMark, CMIS

3. Hot Start Rebuild

Dedicated reserved active or passive hardware and standby system is in place on recovery site, fully built and configured with operating system, database and application, possibly using virtual machines. Data is being regularly copied/’snapshot’ted from live system to recovery site, frequency depending on criticality, but typically at least every 4 hours (as well as being more fully backed up in the backup cycle). System can be brought live on latest snapshot relatively quickly. Estimated recovery time : <1 day Recovery Point age : <4 hours Suitable for: Medium - high criticality business systems

or facilities; dynamic, interactive web-sites; systems with ‘iSCSI’-level SAN connectivity; complex multi-server systems with application/middleware/database type configurations

Examples: BluQube, Resourcelink, TALIS, SharePoint, Blackboard, (Site) Access Control system

4. Failover

Dedicated reserved active hardware working in full ‘mirror’ capacity to primary system(s), again possibly using virtual machines. (Possibly sharing some of production workload in non-disaster situation.) Data is being copied/mirrored continuously at write-synchronisation level. System can take over production workload near-instantaneously and with no loss of transactions, sessions or data. Estimated recovery time : <1 minute Recovery Point age : Instantaneous Suitable for: High criticality, customer facing business

systems or facilities; systems with ‘fibre channel’-level SAN connectivity; systems vital to communication and operation of business

Examples: Unit-e, staff Exchange e-mail, critical network components

14.2 Documentation All systems shall have adequate disaster recovery documentation and procedures written for them as to how the system is to be rebuilt and recovered. This will be written at a systems technician level and will assume adequate existing knowledge of relevant hardware, operating systems, database and application installation. It



will focus on covering UWL-specific considerations in the system configuration and recovery to enable the system to be recovered and operated, including access and authentication. This documentation shall be held in at least 2 locations, typically within SMR IT and at the Paragon recovery site. In view of the potentially large volume of this documentation, it will be collated and held on CD/DVD/USB for viewing though a PC/laptop. It will be kept current via change maintenance and reviewed/tested as part of the periodic testing, both as described below, 14.3 Testing Disaster recovery arrangements for all production systems shall be periodically tested, not less than once per year. Testing shall generally be done at an ‘off-line’ level, ie a copy of a system will be restored and tested for completeness and functionality, but not brought on-line. The live production system shall not generally be involved, disturbed or interrupted unless absolutely necessary to test the recovery – eg. live failover – when this will be carried out in a quiet period with adequate notice and consultation. Testing shall also be used to check completeness and accuracy of the recovery documentation, invocation and communication procedures. 14.4 Invocation Invocation of a disaster recovery on a system or systems shall be at the discretion of one or more members of the IT Senior Management Team (Director of IT; Assistant Director, IT Services; Assistant Director, Technology) depending on circumstances and working with business user representatives and suppliers as necessary. Generally, a recovery will be invoked when a system or systems is likely to be and remain unavailable for an extended period and business critical usage is required. 14.5 Responsibilities It will be the responsibility of one or more members of the IT Senior Management Team (as above) to manage and co-ordinate a recovery in line with document procedures, once invoked, using other staff and members of the IT team and wider UWL community as may be required. As indicated above, it is not the purpose of this policy to deal with the many matters relating to wider and full Business Continuity, but to restore a working IT system from which current data can be retrieved, reports and queries run, and, if necessary, updates entered. This could be from a quite limited number of clients/ access points. 14.6 Maintenance



Disaster recovery requirements and plans shall generally be created and maintained as part of change management considerations. This includes on new systems introduction; hardware and capacity changes; new software installations and upgrades; and configuration and interface changes 14.7 Restoration Once invoked, it will at some point be necessary to restore back to the normal live environment and operation. This will depend upon the system(s) concerned, but will generally involve the copy and restoration of current data on the recovery system back to the normal live system, reload and test.



Appendix 1 – Security Incident Form

IT – Information Security Incident Report To IT Service Desk, C224, St Mary’s Road, Ealing From Location Email address Tel/Mobile UWL Asset Number, if known

Date and time of incident (if known)

Loss of Physical Asset (accidental or theft) Has any physical asset been lost? Give details including circumstances. Value, if known.

Have the Police been informed? If so which force and what is the crime reference number?

Data compromised (lost and/or breach of confidentiality) Has any data been lost, disclosed or maliciously corrupted ? Where was it stored? What were the circumstances of the loss ?

Is identity theft, impersonation or compromise involved ?

Has any breach of UWL confidentiality taken place? How has it occurred?

Describe the nature of any data lost or compromised

System attack – virus alert or other instance of malicious activity Has a virus alert or other attack been noted? Was there a message? Did you see the virus name?

Other Information Record any other incident or information regarding UWL information system security having been compromised



Signed: _____________________________________ Date: _____________________



IT SECURITY INCIDENT REPORT –IT USE ONLY

Description of Incident

Security Incident Log Number

Reported by/how informed Date / Time of Incident

Date / Time Incident Resolved

Type of Incident (eg: Loss, theft, web defacement, virus, etc)

Method of Intrusion (eg: Vulnerability exploited, compromised account, etc)

Level of Unauthorized Access Attained (eg: root, administrator, user, etc)

Any Other Relevant Information (Attach log extracts as separate document/file)

Affected System(s) IP Address(es)

Hostname(s)

Purpose of Affected System (eg: DNS server, router, e-mail server, application server, etc)

Operating System (Include version and patch levels)

Description/Version of Protection In Place (eg: firewall, intrusion detection system, anti-virus, etc)

Physical Location of System (or Network)

Incident Source(s), if known

IP Address(es)

Hostname(s)

Any Other Relevant Information (eg Ports of Communication (if known))

Damage Assessment (may be estimated)

Impact of incident on operations and/or services

Staff time to detect, handle, and recover from the incident

Direct Costs (insurance recoverable ?)

Data Disclosure Impact

Actions Required to Prevent Future Occurrence or Reduce Impact Action Owner and Target Date Lessons Learned Action Completed Date Action

Completed



Appendix 2 – Change Management Process





Appendix 3 – Device Naming Convention This is the device naming convention to be applied to UWL’s name-able hardware assets and used within systems such as Active Directory, asset, service and system management systems. The overall name is to be 15 characters or less, to comply with historical NetBIOS naming conventions and limitations. Optional Name : <campus> <asset number > <building> <room> <type> <staff/student> Chars : 1a 5n 2a 4n 1a 1a (14) Notes : E – Ealing L – laptop S - staff S – Slough D - desktop blank - student B – Brentford P - printer R - Reading S – server T – thin client/terminal C – comms device N – netbook G – other named ‘gadget’ Eg : E47354LC0226LS

Building Codes:

Ealing SMR TC Teaching Centre HB ‘H’ Block (Hospitality Studies) LA LRC/Library A Block LB LRC/Library B Block LC LRC/Library C Block NB North Building/Students Union NE North East Building Walpole WA Walpole House Grove GR Grove House Vestry VE Vestry Hall Studios ES Ealing Studios Brentford PB Paragon Building PA Paragon Annexe Slough SA A Block SC C Block SD D Block SJ J Block SL LRC/Library/Paul Hamlyn Reading KR King’s Road CR Crescent Road HH Hannover House HR Hamilton Road GC Gas Centre (Wokingham)



Appendix 4 – New Starter Process (Staff)



Appendix 5 – User Account Request Forms (Staff) 5.1 Normal, Unprivileged Account (A Service Desk pro-forma e-mail form is issued to request a new ordinary account) Thank you for logging a request with the IT Service Desk. Please note the below procedure for requesting Novell and /or e-mail accounts for new starters. The request should ideally be made two weeks prior to the new user’s start date by the line manager. Please provide the following details : Full Name .......................... (check the documentation provided by HR to confirm you have the correct spelling to prevent incorrect accounts being created.) Staff Number (From HR / Unique card) ..................... Name and Extension number of the line manager.................... (If the line manager will not be available during the next few weeks an alternative contact can be given, provided they are authorised to request new account creations by their department ) Type of contract ie permanent / rolling - contract / short term contract.................... If short term contract , date of end of contract ……………………….. (If the user is a very short term temp we prefer the line manager request a temp account to be created in their ownership that can be easily transferred between temps rather than creating new accounts for each temp. Note of who uses which temp account and when should be kept.) Is the user teaching or non-teaching? ........... Start date ............ Department ........... Room number....... Building ............... Campus ............. Extension number ............... (if the user does not have their own phone – you can provide the extension number of a colleague who sits close-by ) Regarding Novell account creations – please specify if access is required to specific shared folders by listing the full name of the shared drive and folder, do not simply state same access rights as “another” user Once the request has been logged it will be sent to the Operations team, and the username and password details will be emailed to the line manager (or alternative contact if requested). This can take between 3 and 7 working days. This request can be emailed to mailto:[email protected] Information Technology University of West London LRC Room C224 St Marys Road, Ealing W5 5RF

mailto:[email protected]�



5.2 System Privileged Accounts Request for Privileged Account Creation Staff Name : ____________________________________________ Staff Number: ________________ Extension: ___________ Job Title: _________________________________________________ Normal, non-privileged account name: ________________________________ E-Mail: ___________________________________________ System(s) or Device(s) To Which Privileged Account Access is Required :

Reason for Privileged Account Request Type of Privileges Required System/Device Management & Operation ___ All __________ Fault diagnosis and rectification ___ Partial (detail) __________ System Audit, Review and Reporting ___ Read-only __________ Other ___ Other __________ Duration of Account Access Start Date: __________________ End Date: _________________ I understand that the grant and usage of a privileged account to access and manage UWL’s information systems and devices is fully governed by UWL’s IT Security Policy. The account will be only be used when necessary to perform privileged operations, under Change Management when required and I further understand that such usage will be logged and reviewed. Signed: ________________________________ Date: ________________ Account Approval (by one of IT Senior Management Team) Name: _______________________________ Position: ____________________________________________ Signed: ________________________________ Date: ________________ Comment: _______________________________________________________ Account Name Created: _________________________ Date: _______________



Appendix 6 - Laptop Agreement

Information Technology Laptop Allocation Agreement

UWL Information Technology (IT) are supplying you with a laptop to replace your current desktop system and/or in response to your business need for mobile and flexible working. The laptop specification is as follows: Make: ……………………………………………………… Model: ……………………………………………………… Serial and Asset Number: Serial………………………….. Asset…………………………………. Hardware Specification: Processor…………. RAM………. Disc………… Other……………….................. Software loaded: …………………………………………………………………………………........... Operating System: ……………………………………………………… In order for the laptop to be provided to you, the following terms must be accepted :

1. All your files and data on any existing desktop PC hard disc are backed up onto other media or network drives.

2. The desktop PC has been made ready for collection by IT support staff, if applicable 3. The laptop will be your responsibility and must be handled with care and carried in a

suitable, secure case. 4. When in use, the laptop will be suitably secured down using the Kensington lock

provided. 5. When not in use, the laptop will be locked away in a secure location (out of sight). 6. Any data stored on the laptop must also be backed up and stored on other media

(network, usb, cd/dvd) to prevent possible data loss in the event of a laptop fault or loss 7. The laptop will be returned to IT at regular intervals as below for necessary maintenance

and upgrades. 8. Should you no longer require the laptop, or on leaving UWL, it will be returned to IT for

re-allocation. 9. IT has the right to recall a laptop if the terms of the allocation have not been met. 10. The usage and security of the laptop is bound by UWL’s IT policies and procedures, as

may be in force. You should bear in mind that laptops are more at risk of theft or loss than desktop PCs and therefore sensitive UWL data should not be stored on the hard drive, but on other, secure, media. (Laptops are, however, covered by UWL’s insurance policy when taken off UWL premises by authorised staff.) Please sign below to accept the terms of the allocation of the laptop. I agree to the terms and conditions outlined in this document.



Signature: ………………… Print name…….……………. Date: ………………... Department/ Faculty………………….. Location:………………. Tel:………………….. Laptop allocation agreed by IT: IT Manager’s Name………………… Signature……..……………... Date:………………

Maintenance schedule

Date of allocation: Maintenance recall date Date returned Date of maintenance Maintenance performed by

Maintenance recall 1 (after 6 months)

Maintenance recall 2 (after 1 year)

Maintenance recall 3 (after 18 months)

Maintenance recall 4 (after 2 years)

Maintenance recall 5 (after 2.5 years)

Maintenance recall 6 (after 3 years)



Appendix 7 – SSL Account Request Forms 7.1 Staff

Request for Remote Access VPN

Instructions: Type or print user information. Fill in the applicable sections for requested system. The employee must read and sign the user acceptance, section 3 prior to approval by the required authorising signature. Keep a copy for your files and forward the original form to:- Information Technology Learning Resource Centre Room C224, St Mary’s Road. Also please email the form to IT Service Desk – [email protected]

SECTION 1: To be completed by the person requesting access: User Information

Title…………………………….

Forename……………………….

Surname………………………...

Job title……………………….…

Site………………………………

User ID (staff number)………………………………………………

Department…………………………………………………………..

Phone No (please include site code)…………………………………

Email…………………………………………………………………

TYPE OF ACCESS

Name of the System…………………………………………………………………………………………

- Access required for: (Please tick)

Production………………. Development………………. Other…………………………………………

Start Date……………….. End Date………………..

SECTION 2 : General Information

Please indicate why remote access to the requested system is needed, this will form the basis for your request:




SECTION 3 : University of West London User Acceptance

This Agreement is intended to define the responsibilities of those employees who have access to the Data systems that contain sensitive or confidential data about students, employees or other individuals, and to record his or her recognition and acceptance of that responsibility.

I understand that this access is granted solely in conjunction with my assigned duties and performed on behalf of the University. I am responsible for all IDs and passwords issued to me. I understand that failure to comply will result in the loss of my computer privileges. By signing this application, I acknowledge that I have read and understand this agreement and I agree to adhere to it.

Employee: Recognising this responsibility, I agree to the following (please initial each line):

I access university records only as required to perform my assigned duties. ……

I WILL NOT access student or employee information that is not necessary to carry out my job. ……

I WILL NOT store information on my pc used for accessing the remote desktop. ……

I WILL NOT remote desktop to my work machine when other people are around including visitors. ……

I WILL ensure the pc used for remote desktop connection has all the latest Microsoft security patches installed. ……

I WILL ensure that the pc has Anti-Virus software installed and the definition files are up to date. ……

I WILL also ensure that Peer to Peer or file sharing software is not installed on this machine. ……

I am solely responsible for any and all activity that occurs under my account. ……

I agree to take full responsibility to ensure that my login details remain confidential. ……

I WILL NOT allow anyone to use my login details. ……

I agree to logout of the system when I have finished, and I have turned off my ‘Save Password’ option. ……

Print Name…………………………………… Employee Signature………………………….. Date……………….



(a) SECTION 4: To be completed by Head of Department/Unit. (b) Please forward this form for authorisation to the appropriate Head of Department/Unit.

I certify that the above-named member of staff is an appropriate person to whom access should be given and that access should be given to the system requested.

Head of Department/Unit: …………………………………………………………………………………

Signature: ……………………………………………………………… Date: ……………………….…..

SECTION 5: To be completed by the IT Department:

Access approved / Access not approved

Authorised Signature: ……………………………………………….......................................................…

Date: …..……………………….…..……..…… Review Date: …..………..……………….……………



7.2 Suppliers, Contractors, 3rd Parties

Request for Remote Access

Via SSL VPN

Version 1.1, February 2010

Instructions: Type or print user information. Fill in the applicable sections for requested system. An authorised Company representative must read and sign the user acceptance, section 3 & 4, prior to the request being considered by UWL. Please keep a copy for your files and forward the original, signed form to:- IT Service Desk Information Technology Services Learning Resource Centre Room C242, St Mary’s Road, Ealing, London W5 5RF Also please email the form to the Service Desk – [email protected] Fax: +44 (0)20 8231 2402

SECTION 1: To be completed by the Company or Organisation requesting access: User Information

Company…………………………….

Forename……………………….

Primary Contact

Surname………………………...

Job title ……………………………

Contact Telephone Number………………………………………………

Email…………………………………………………

……………………………………………………….

Main UWL Contact: …………………………………..

TYPE OF ACCESS

Name of the System…………………………………………………………………………………………

- Access required for:

Production………………. Development………………. Other…………………………………………

Start Date……………….. End Date……………….. (Access will be enabled on request within this)

SECTION 2 : General Information

Please indicate why remote access to the requested system is needed, this will form the basis for your request:




SECTION 3 : University of West London Confidentiality and Remote Access Agreement I am employed by (or work under contract with) the Company listed above, and in order to perform the Company’s work, we will require authorised remote access to a computer system of University of West London . As a condition of being allowed such access, I agree on behalf of the Company that: (a) We will use only the log-in ID assigned to us by UWL when logging on to UWL’s computer system; (b) We will log-off UWL’s system immediately upon completion of each session of service; (c) We will not allow third parties to access UWL’s computer system via our connections; (d) We will keep strictly confidential the log-in ID and all other information that enables such access; (e) We will not intentionally access any information or data other than that which we have been specifically authorized to access by UWL. (f) We will not simultaneously access the Internet or any other third party network while logged on to UWL’s computer systems (g) Our access to UWL’s computer system is subject to monitoring by UWL; and (h) We will not make any change to any of UWL systems without UWL’s prior written approval for the specific change. We also agree to keep strictly confidential all Confidential Information to which we have access or which we otherwise acquire. We understand that “Confidential Information” means: (a) any and all information about UWL that is not known to the general public, including information relating to its business plans, strategies, inventions, designs, methods, systems, improvements, trade secrets, or other confidential, secret, or proprietary matters; (b) non-public information that belongs or relates to third parties to whom UWL has an obligation of confidentiality, such as its students, customers and software licensors; and (c) non-public information about UWL’s employees and business associates such as payroll, medical, or other confidential personal information. We agree that we will not, directly or indirectly, disclose any Confidential Information to any person except specified personnel of UWL and others providing services relating to UWL who have a need to know to fulfill their job responsibilities and business obligations and have undertaken a similar confidentiality obligation. We agree that we will not appropriate any Confidential Information to our own use or to the use of any other person or entity. We further agree not to remove any Confidential Information from UWL’s premises or systems without express written permission from UWL.

Use of software

If we have received software from UWL to facilitate the conduct of business with UWL, we understand that our use of the software is governed by the terms of a separate license agreement between UWL and the Company. We agree to install and use such software only on systems that we use to conduct business with UWL. We will not install the software on any other computer. We further agree that we will not: (a) copy, distribute, rent or sublicense any portion of the software or documentation; (b) modify, enhance, add to, improve or prepare derivative works from the software or documentation; (c) transmit the software electronically by any means; (d) decompile, disassemble, decrypt, extract or otherwise reverse engineer the software; or (e) remove or modify any copyright, trademark or other proprietary notices that appear on any copy of the software or documentation. We understand that if we violate any of the foregoing, we may be liable for copyright infringement and subject to substantial civil damages and/or criminal penalties. By signing below, we agree to be jointly and severally bound by this agreement.



(c) SECTION 4: To be completed by Authorised Company Representative.

I certify that on behalf of the Company that we will comply with the terms and conditions given in this document and that we request controlled remote access to UWL’s systems as may be required.

Company: ……………………………………………………………………………….

Name: …………………………………………………………………………………

Signature: ……………………………………………………………… Date: ……………………….…..

SECTION 5: To be completed by Information Technology Services

Access approved / Access not approved

Authorised Signature: ……………………………………….….......................................................…

Date: …..……………………….…..……..…… Review Date: …..………..……………….……………