Access Control and Account Management Policy Version 1.8 9 May 2015

Information Security Management Access Control and Account Management Policy Version 1.8 9 May 2015 University of Leeds 2015 The intellectual property contained within this publication is the property of the University of Leeds. This publication (including its text and illustrations) is protected by copyright. Any unauthorised projection, editing, copying, reselling, rental or distribution of the whole or part of this publication in whatever form (including electronic and magnetic forms) is prohibited. [Any breach of this prohibition m ay render you liable to both civil proceedings and criminal penalties].

Owner: Source Location: Kevin Darley, IT Security Co-ordinator, Information Systems Services, University of Leeds C:\Users\Kevin\Desktop\Access Control and Account Management Policy - Copy.doc Document Reference: Other Documents Referenced: Related Documents: Information Security Policy, Use of Computer Systems Policy, Password Usage and Management Policy, Archiving Policy, Systems Security and Network Access and Management Policy, and Security Incident and Computer Misuse Policy Acknowledgements: Document Control This document is subject to change control and any amendments will be recorded below. Change History Version Date Circulation Changes 1.0 04/07/05 http://camus.leeds.ac.uk/isms First Formal Issue 1.1 08/07/05 http://camus.leeds.ac.uk/isms Change to Appendix to reflect segregation of forms 1.2 13/08/05 http://camus.leeds.ac.uk/isms Addition of text to 4.3 1.3 25/10/05 http://camus.leeds.ac.uk/isms Removal of common information in Section 1 and Section 2.7 largely replaced by Password Usage and Management Policy 1.4. 24/03/06 http://camus.leeds.ac.uk/isms Section 5 and Removal of Appendices 1.5 21/06/06 http://camus.leeds.ac.uk/isms Replacement of Section 5 to 5.3 inclusive. 1.6 09/08/07 http://camus.leeds.ac.uk/isms Replacement 3.2; new 5.1 and 5.2; most of 5.4 deleted; Appendix deleted; general review. 1.7 04/08/09 http://camus.leeds.ac.uk/isms New 5.6 governing 3 rd party access to data and emails of those leaving under PRT/MIS 1.8 09/05/15 IT Security Website Update to Sections 3.2 and 5.8 Information Security Management 1.8 (09/05/15) Page 2 of 13

Version Awareness The audience of this document should be aware that a physical copy may not be the latest available version. The latest version, which supersedes all previous versions, is available here. Those to whom this Policy applies are responsible for familiarising themselves periodically with the latest version and for complying with Policy requirements at all times. Information Security Management 1.8 (09/05/15) Page 3 of 13

Contents 1. Introduction... 5 1.1. Background... 5 1.2. Applicability... 5 2. Cre ating, Controlling and Managing User Accounts... 5 2.1. Policy Scope... 5 2.2. Account Creation... 5 2.3. Conditions of Acceptance... 6 2.4. Traceability... 6 2.5. Identification and Authentication... 6 2.6. Passw ord Change at Initial Log-on... 6 2.7. Suspension of User Accounts and Passw ord Resets... 6 2.8. Account Privileges... 7 2.9. Account Management... 7 3. Use of User Accounts... 7 3.1. Passw ords... 7 3.2. Use of Accounts... 8 3.3. Access Parameters... 8 4. Controlling Shared and Other Accounts... 8 4.1. Shared Access and Project Accounts... 8 4.2. Temporary Accounts... 8 4.3. Conference and Visitors Accounts... 9 4.4. Lecture Theatre Computers... 9 4.5. Library Catalogue PCs... 9 5. Third Party Access to Em ail and Filestores... 9 5.1. Allow ing Others to Access Your Email... 9 5.2. Sharing Your Data... 9 5.3. Management of Unassigned Third Party Access to Email and Data... 10 5.4. Third Party Cover Arrangements for Know n Absence of Staff... 10 5.5. Third Party Access during Unexpected Staff Absence... 10 5.6. Third Party Access to Data and Emails of Staff leaving under PRT/MIS... 10 5.7. Approval and Authority - Third Party Access during Unexpected Staff Absence... 10 5.8. Access to Accounts of Former Employees - DS and Admin Domains... 11 5.9. Access to Staff Accounts and Archives on Systems outside the DS Domain... 12 5.10. Third Party Restrictions... 12 5.11. Control and Accountability of Student Accounts... 13 6. De aling with Misuse, Abuse and Illegal Activity... 13 6.1. Allegations... 13 6.2. Requests for Account Access by the Police and Law Enforcement Agencies... 13 Information Security Management 1.8 (09/05/15) Page 4 of 13

1. Introduction 1.1. Background The ever increasing use of digitised and networked information at the University intensifies the risk of data being copied or stolen, or modified, hidden, encrypted or destroyed. Unless access to our systems is appropriately managed, there is an increased risk that unauthorised persons will obtain use of our resources and gain access to University data. Furthermore, the governance of complex information related legislation, which quite often appears to be contradictory, increases the possibility that those responsible for managing systems could inadvertently fall foul of the law when undertaking their day to day systems management activities. Although technical controls provide an essential element of overall protection, they only deliver a percentage of the required solution, the most effective defence being achieved through awareness and good working practices. This document forms the University s Access Control and Account Management Policy in support of the Information Security Policy. Compliance with this Policy will enable consistent controls to be applied throughout the University minimising exposure to security breach, whilst allowing systems administration and technical support staff to conduct their activities within the framework of the law. The University s Information Security Policy and a full list of Supporting Policies within the Information Security Management System (ISMS) framework can be found here. 1.2. Applicability This particular Policy is primarily aimed at users of University computer systems and systems administrators and computer support staff (including IT staff) who are responsible for the development and maintenance of IT/IS facilities. Applicability naturally extends to anyone else who is subjected to the Policy framework who undertakes activities governed by this Policy. It is the personal responsibility of each person to whom this Policy applies to adhere fully with its requirements. However, Deans and Heads of Schools/Services 1 are responsible for implementing this Policy within their respective faculty, school or department and for overseeing compliance by staff under their direction or supervision. 2. Creating, Controlling and Managing User Accounts 2.1. Policy Scope This policy concerns user accounts comprising usernames (and passwords) that are issued to users, and which are registered on servers which authenticate login requests from clients. 2.2. Account Creation Faculties, schools, departments and IT are to implement formal procedures for granting user access to both University IT/IS facilities, and external services via University systems. 1 Also generically infers Heads of Centres and Institutes throughout. Information Security Management 1.8 (09/05/15) Page 5 of 13

User-accounts are only to be created on the correct authority. It is the responsibility of the system administrator who is creating user-accounts to confirm that the correct level of authority has been granted where there is any doubt. 2.3. Conditions of Acceptance All users are required to agree to comply with the Use of Computer Systems Policy and other relevant policies, prior to using their computer account. This agreement will be retained throughout the lifetime of the account and for a period of twelve months after the account has been terminated. IT accounts will not be made available prior to agreement by the user to adhere to the terms and conditions set by University Policy. 2.4. Traceability Accounts are to be created so that the identity of all users can be established at all times during their computer usage. 2.5. Identification and Authentication All users of University systems must be identified and authenticated by systems that they access using at least two sources of information. Prior to using University systems, users must: Present their identity to the security mechanisms of the system by entering a user-id or user-name that has been allocated to their computer account, or by presenting some other form of system recognised identity; and, authenticate themselves by providing information, such as a password or PIN, that the system corroborates as a binding between the person and the identifier, and validates them as being an authorised user. Mechanisms such as tokens, biometric readers or digital certificates may be used for the identification and authentication of users. 2.6. Password Change at Initial Log-on Where possible, systems are to be configured to force users to change their password at their first logon. 2.7. Suspension of User Accounts and Password Resets The suspension of a student s user account can only be requested by an appropriate representative in the respective faculty or School, a senior member of the Secretariat 2, the Director IT, or the University s IT Security Co-ordinator. The user account of a member of staff can only be suspended on the authority of the person suspending that individual from duty. 2 T he Secretary to the University, Deputy Secretary, Director or Deputy Director HR, and the University Legal Advisor. Information Security Management 1.8 (09/05/15) Page 6 of 13

All password resets are to be performed in accordance with the Password Usage and Management Policy. 2.8. Account Privileges Faculties, schools, departments and IT are to restrict and control the allocation and use of system privileges on each computer platform. In particular access to operating systems and applications is to be generally restricted to designated administrators and support staff associated with the management and maintenance of the respective platforms. Users are to be given specific account profiles and privileges as defined and authorised by their respective faculty, school, department or IT, in accordance with their particular function or role. When creating user-accounts, system administrators must take care to ensure that users are only granted access to systems and resources 3 that have been approved and which are necessary for operational or research purposes. User privileges are to be reviewed on a regular and frequent basis and withdrawn where the circumstances of those who have been granted privileges no longer warrant such access. 2.9. Account Management User-accounts are only to remain active for the period required for individual users to fulfil the operational, learning, or research needs for which they were granted. Faculty, School and departmental staff who administer their own local systems are to arrange a process with Human Resources so that they are notified when members of their staff either leave University employment, or transfer to a job outside their domain. Administrators are to implement a process for disabling staff user-accounts when the account holder has left University employment or moved to a different faculty, or school or department outside of their domain. Staff user-accounts that are administered by IT Username Administration that have lapsed for a period of three months are to be disabled. Where users have multiple accounts care must be taken to ensure that the above process is undertaken for all of their accounts. 3. Use of User Accounts 3.1. Passwords All user accounts must be assigned passwords which meet the requirements of the Password Usage and Management Policy. In accordance with the Password Usage and Management Policy all users are required to change their initial log-on password the first time that they log onto a system where the system itself does not automatically enforce this requirement. 3 It may be necessary for System Administrators to consult their respective User-Representative to ascertain if there are any licence implications or restriction associated with software resources. Information Security Management 1.8 (09/05/15) Page 7 of 13

3.2. Use of Accounts You may only use computer accounts that you have been officially authorised to use. Using a computer for which you have not been given permission to use can constitute a criminal offence under the Computer Misuse Act 1990. Account holders must not divulge their password to anyone else, regardless of whether the other person is a member of the University, and must not allow any other person to use their computer account at any time. The only exception to this requirement is when an official University investigation is taking place in accordance with the University s Security Incident & Computer Misuse Policy. Any misuse of a computer account may be attributed to the account holder. 3.3. Access Parameters In accordance with the Use of Computer Systems Policy under no circumstances are users to attempt to access systems, applications or data which their user account does not naturally provide access to and for which they have not been granted specific permission. 4. Controlling Shared and Other Accounts 4.1. Shared Access and Project Accounts When there is a requirement for several users to access common data and mailboxes, for example when working collaboratively, shared areas are to be created and these are to be accessed through the use of each user s own user account. However, in some cases, a project account may be permitted whereby members of a group access the account through the use of a common (shared) user-name and password. In such cases access must be tightly controlled by the account holder as the degree of accountability associated with personal accounts is diminished when using project accounts. On all such occasions the account holder is responsible for maintaining a list of all users who have been granted access to the account at any given time, and for ensuring that the password is changed whenever a user leaves the project team. 4.2. Temporary Accounts Faculties, schools and departments that have a high turn over of temporary or agency staff may utilise temporary accounts, but there must be a named custodian (and deputy) for all such accounts who are responsible for managing them. Each temporary account is to be set with a master password which is only known by the custodian and his/her deputy and this must be changed to a previously unused user-password each time an account is issued. Temporary accounts are not to be issued until each new user signs a form to confirm that they will abide by the Use of Computer Systems Policy and other applicable policies. Once signed, forms are to be retained locally for a period of 12 months after the user has left, and presented to auditors on request. Information Security Management 1.8 (09/05/15) Page 8 of 13

The custodians of temporary accounts are responsible for changing temporary account passwords back to the master password, in accordance with the Password Usage and Management Policy, as soon as a temporary user no longer requires access to the respective system. 4.3. Conference and Visitors Accounts Faculties, schools and departments that use IT operated accounts may be allocated a bulk block of user-accounts (user-names and passwords) by IT User Administration if they have large or frequent conferences, or a high turn over of visitors. In such cases, a custodian is to be designated as owner of the user-accounts and made responsible for their security, allocation and lapsing. User-accounts are only to be issued when the intended recipients have signed a copy of a form to confirm that they will abide by the Use of Computer Systems Policy and their equipment has been checked in accordance with the Systems Security and Network Access and Management Policy to ensure that it does not pose a security risk. Once signed, forms are to be retained locally for a period of 12 months after the user has left, and presented to auditors or IT staff on request. User-account custodians are responsible for notifying IT Username Administration of the lapse date requirements as they issue these accounts, or for e-mailing a lapse request to Sysadmin@leeds.ac.uk when the users no longer require access to University systems. 4.4. Lecture Theatre Computers Lecture theatre computers are to be configured so that members of staff have to log-on using their own user-account. Visitors to lecture theatres are to be issued with temporary accounts as described at 4.2 above. These will be managed by Conference Office staff. 4.5. Library Catalogue PCs Library catalogue PCS have to be made available to a large number of University members who do not have user-accounts. As a deterrent against potential abuse and in a bid to obtain a level of accountability over users, users are required to log-in using their name and library card barcode number, the details of which are authenticated via the Library Management System. As an added precaution, library catalogue PCs are to be under the supervision of video recorded CCTV facilities wherever possible. 5. Third Party Access to Email and Filestores 5.1. Allowing Others to Access Your Email Members of staff using Outlook are to assign delegated rights to their mailbox if they have a need for someone else to access their email, for example, secretaries on a permanent basis, or staff covering a particular role during periods of temporary absence. 5.2. Sharing Your Data Staff requiring shared access to data are to use public folders on the N: Drive with permissions restricted, as appropriate, to the individuals who need to share it. Information Security Management 1.8 (09/05/15) Page 9 of 13

5.3. Management of Unassigned Third Party Access to Email and Data The Use of Computer Systems Policy governs the personal use of the University s computing facilities, and warns that for operational purposes, it may be necessary for the University to occasionally access the email account and filestore of a member of staff in their absence. All third party access to other users data in their absence must be justified for operational purposes and fully accountable. As such, all applications must be considered on a case by case basis. Sections 5.4 to 5.8, below, apply to the user accounts of staff and former employees who are either in the DS or Admin Domains. Section 5.9 applies to staff and former employees whose emails and data resides outside the DS and Admin Domains. 5.4. Third Party Cover Arrangements for Known Absence of Staff When a school or department knows that a member of staff is going to be absent from work, and that for operation reasons access will be required to either their email account or filestore during their absence, they are to make arrangements in advance of the absence in accordance with 5.1 and/or 5.2 above as appropriate. 5.5. Third Party Access during Unexpected Staff Absence Where a member of staff is unexpectedly absent from work and it was not practical for advanced access arrangements to be made before their absence (see 5.4) IT will, on the correct authority, facilitate third party access to the required DS or Admin email account or file store (see 5.7). Subject to the requirements of each application, the absentees mailbox, filestore or both mailbox and filestore, will be attached to the third party s user account. Once this has been done, an email will be sent by IT to the account holder and the third party (copied to the University IT Security Co-ordinator) confirming the action. 5.6. Third Party Access to Data and Emails of Staff leaving under PRT/MIS Third party access will be granted to designated Faculty/Service personnel to the email/data of former employees who have left under PRT/MIS, on production of an email from the account holder granting permission. When access is required to data/emails and the account holder has not granted permission, the procedure for providing third party access during unexpected absence will be followed (see 5.5 above). 5.7. Approval and Authority - Third Party Access during Unexpected Staff Absence Approval for third party access to another member of staff s email, filestore or both mailbox and filestore, must be provided by the head of school or head of service for applications from within their respective domain. However, if a head of school requires personal third party access to the data of one of their staff, the application form must be authorised by the dean of faculty 4. In the event of a head of service or dean of faculty requiring third party access to the account of one of 4 If the dean of faculty is absent, applications can be approved by the Secretary to the University, or in his absence, the Deputy Secretary. Information Security Management 1.8 (09/05/15) Page 10 of 13

their staff, the application must be approved by the Secretary of the University, or in his absence, the Deputy Secretary. Following approval of the application the Director IT, or in his absence a member for the IT Senior Management Team, must provide written authority before IT staff provide the required access. Third party access to IT staff accounts can only be facilitated by IT staff when the application form has been signed by the Finance and Commercial Director, or in her absence, the Secretary to the University or the Deputy Secretary. Completed application forms will be retained by IT Username Administration for a period of two years and will be made available to auditors or the University s authorities on demand. The application form for requesting third party access to the email account or filestore of an unexpectedly absent member of staff can be found here under Third Party Access Request Form Filestores and Email Accounts of DS and Admin Domain Users. 5.8. Access to Accounts of Former Employees - DS and Admin Domains When a school or department has a need to access the data of a former employee the respective head of school or head of service is to email a request to the University IT Security Co-ordinator at it-security@lists.leeds.ac.uk which outlines the: Name of the account holder; type of account, for example mailbox or file store; period in question (date(s) or approximate date(s) of the emails or files); subject of the data required; and reason why it is required. On receipt of a request the IT Security Co-ordinator will verify that the person making the request has the correct authority to do so (head of school/service) and confirm with Human Resources that the account holder has ceased University employment and that there are no known circumstances why the handing over of the account holder s data to the requester would be in conflict of interest. For example, that there is no legal action or tribunal pending between the account holder and the University. Providing that the request meets the required criteria, the IT Security Co-ordinator will task a member of the appropriate IT team to recover the required data and make it available is suitable format to the requestor. The member of IT staff tasked to recover the data will only recover data associated with the subject specified, by using a search facility, and will not include any data that appears to be of personal, private or confidential to the account holder. In circumstances where the full details of the required data are not known, the applicant or their representative will be provided with supervised access to the respective account within IT (by Information Security Management 1.8 (09/05/15) Page 11 of 13

appointment) and IT staff will transfer a copy of the data to the required account once verified that it is work-related. 5.9. Access to Staff Accounts and Archives on Systems outside the DS Domain Faculties, school and departments that manage their own systems outside the DS domain are to ensure that controls are applied to limit third party access to their users accounts in accordance with this Policy. The same control and accountability also applies to non-microsoft systems hosted by IT, and the same authorisation and approval mechanisms at Section 5.7 apply. A third party computer access request form is to be completed when: There are operational requirements for a member of staff to be granted access to another member of staff s e-mail folders and filestore during their unexpected absence; operational access is required to a former member of staff s data after they have ceased University employment and arrangements for another member of staff to access the data have not been made prior to the person leaving; or, a member of staff other than the account holder subsequently requires operational access to archived data and the original account holder is unavailable to grant permission. In the interests of ensuring consistent and transparent practice across the University, a copy of the form must be filed with IT Username Administration before access proceeds. Any third party access that is facilitated without fulfilling this requirement may be subject to formal investigation. If a head of school or department requires personal third party access to the data of one of their staff, the application form must be authorised by the dean of faculty or the Secretary to the University or the Deputy Secretary. Any such application by a dean also requires approval by the Secretary to the University or the Deputy Secretary. On signing a third party computer access request form, both the person who is to be provided with the access to another user s account, and those providing the authority are certifying that they have read and understood the conditions. A Third Party Access Request Form Filestore and Email Accounts of Non-DS Domain Users can be found here. 5.10. Third Party Restrictions Anyone who is granted operational access to another users' data may only view material that it is considered necessary to see for the operational reason for which access was granted. They are required to treat all material as confidential and not to act upon it or disclose it to any other person except those directly associated with the operational requirement for which the access was granted. In addition, they must preserve the confidentiality of any private or personal data that they may view inadvertently whilst undertaking operational matters. A failure to do so could constitute an offence under the terms of the Human Rights Act 2000 and result in legal action being taken against that individual. Information Security Management 1.8 (09/05/15) Page 12 of 13

On signing the Third Party Computer Account Access Form the person who is to be provided with the access to another users account is certifying that they have read and understood the requirements. 5.11. Control and Accountability of Student Accounts It is the responsibility of computer support staff in faculties and schools to ensure that their students are aware that their accounts may be accessed for both teaching and computer account management purposes. Ideally this notification should be given in writing at the start of each academic year. Access to students files must be restricted to bone-fide reasons, such as, investigating plagiarism or malpractice, providing access to a specific file for cover staff when a normal member of staff is unexpectedly absent, or to verify that existing work space is not being used for the storage of non-work related material where more disk space is requested. If there is any doubt as to whether access to a student s files is bone-fide, the head of the school is to be requested to provide the required authority. Any person viewing a student s accounts must do so in the presence of a second person e.g. a lecturer with a member of IT staff, or two IT staff. A written summary as to why this was done and what the outcomes were must be produced and a copy of this is to be given to the student as well as being kept on their file. 6. Dealing with Misuse, Abuse and Illegal Activity 6.1. Allegations All allegations of misuse, abuse or illegal activity are to be investigated in accordance with the Security Incident and Computer Misuse Policy. 6.2. Requests for Account Access by the Police and Law Enforcement Agencies All requests from the police and other law enforcement agencies for access to computer information or user accounts must be directed to the Secretary to the University or in his absence, the Deputy Secretary or University Legal Advisor in accordance with the Security Incident and Computer Misuse Policy. Information Security Management 1.8 (09/05/15) Page 13 of 13