Use of UniDesk Code of Practice

Transcription

1 Use of UniDesk Code of Practice Introduction This code of practice outlines the support mechanisms in place for the security of the UniDesk service. References are made to Exchange, EASE, Shibboleth, Identity Management (IDM) and the bulk mail relays. This code of practice is intended to support the Information Security Policy of the University and should be read in conjunction with this document. This code of practice is also qualified by The University of Edinburgh computing regulations, found at: Code of Practice Version Revision Date CoP Template Author Notes Version Version 28/03/ st Draft 1.4 Matt Beilby 1 st Draft 03/04/ Alex Carter Review 17/09/ Matt Beilby Review QA Date QA Process Notes 10 Sep 2014 IT Security WP Suggested date for Revision of the CoP Author 01/11/2015 Matt Beilby UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

2 2. System description Revision Date System Author Notes Version 28/03/ Matt Beilby 1 st Draft 17/09/ Matt Beilby Revision _._/_._/ <......> <......> <......> 2.1 System name UniDesk 2.2 Description of system UniDesk is a web based, cross platform service improvement solution, with modules for Incident, Problem and Change Management, as well as a Configuration Management database. UniDesk is a shared service provided by and for the UniDesk partnership, comprising the Universities of Edinburgh, St. Andrews, Abertay Dundee, and is provided as SAAS to member institutions, who currently include Sheffield Hallam University and the University of Ulster. Although based on shared infrastructure each institution has a separate application layer and database, protected by their local Shibboleth Identity Provider (IdP). 2.3 Data End User Data includes: Name, College/Support Group, School/Division, Type of User (inc Online Distance), UUN, Address, Employee number or matric number and library card number. Also, where available (generally where set manually): Preferred contact method, location, telephone number. Operator Data includes: Name, College/Support Group, School/Division, Type of User, UUN, Address, Operator Group(s), Task settings. Also, where available: Telephone number, Location Data is also held on other Systems and Hardware in the Configuration Management database. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

3 2.4 Components Core system: Application layer, (inc. TOPdesk software, Apache, Shibboleth, and bespoke pieces) Database layer (mirrored) Dependencies for all systems: Virtualised infrastructure, Network, Bulkmail relay Dependencies for Edinburgh Environment: idp for Shibboleth EASE single sign on Exchange IDM system Telephones database External Dependencies for partner/member systems: Local idp service, Local IMAP mail service Local single sign-on Nightly data feed, pushed to Edinburgh. 2.5 System owner The system owner is IS Applications Service Management. 2.6 User base As operators, potentially all members (and some visitors) of the Universities of Edinburgh, St. Andrews, Abertay Dundee, Sheffield Hallam and Ulster, in their respective environments. End users serviced using UniDesk could include not only staff, students, visitors but also applicants and alumni or any other parties serviced by Operators using UniDesk 2.7 Criticality The UniDesk service is considered to be a Priority 2 service, occupying a priority space just below critical services. 2.8 Disaster recovery status DR procedure is available at UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

4 Terminology 3. User responsibilities Users are all members of the University community and external contacts who receive support via UniDesk Operators are staff members responsible for providing support to users who have all the responsibilities of users as well as those identified for operators alone 3.1 Data Users are required to protect their password to access the system which is provided by each institution s single sign on system. 3.2 Usernames and passwords They are also governed by the computing regulations and applicable law to ensure that data protection principals are adhered to when exporting or forwarding personal data via , or any other applicable method. Operators are responsible for the contents of memo fields in Incidents, which in most cases are by default visible to end users via Self Service and to other operators, except for certain operator groups whose incidents are classified as confidential to the caller. Procedures are in place for removing sensitive information from the UniDesk service, where it has been entered in error. UniDesk uses Shibboleth for authentication for both users and operators, tying into a local single sign on service. At Edinburgh, the single sign on service is EASE. The provision of EASE passwords is described in the EASE security code of practice. 3.3 Physical security Users are expected to maintain security practices consistent with other single sign on services, keeping PCs and physical spaces locked, or by logging out before going away. 3.4 Remote/mobile working Users may access UniDesk via certain mobile devices or via the web from any Internet connected device with a supported browser setup. If accessing via the web, users should ensure that they logout properly at the end of their session. This is especially important if using a system in a public place such as an Internet cafe. If accessing via a mobile device then they should ensure appropriate physical security of their mobile device, which may include configuring a device level passcode. If accessing from a user's own PC then appropriate virus protection software should be used to protect against viruses and Trojans such as key loggers. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

5 3.5 Downloads and removal of data from premises 3.6 Authorisation and access control There are no controls to prevent people from removing data from the premises since the data is available externally. The system holds support data which is generally open within the confines of the appropriate University support community. However information about users is also held, and Operators should take care when dealing with personal data that would be covered by applicable data protection law. See also the University's Policy on the Storage, Transmission and Use of Personal Data and Sensitive Business Information Outwith the University Computing Environment. All users with a full EASE account should be able to check their own incidents in Self Service (other institutions than Edinburgh will have their own policies on Self Service). At Edinburgh, Operator Groups are maintained and created centrally within Information Services. New Operators are intended to be created and managed by a devolved administrative role, called Team Admin. These are not full administrator accounts. Typically there is one such Team Admin per Operator Group. For the Edinburgh environment only IS Staff are permitted administrator privileges in order to support users accordingly. Administrator access may in some cases be granted to key contacts at other institutions for their own environments only. Further administrative access to those environments is effectively devolved to those key contacts. A local administration role has been developed to assist with further devolvement, but its use is currently discretionary to those key contacts. Operators at the University of Edinburgh must abide by university regulations when handling users accounts and data. 3.7 Competencies All users should have an understanding of their responsibilities as set out in the computing regulations. Operators should further have an understanding of any UniDesk processes which apply to them, such as Incident, Problem or Change Management. Help and guidance information is available online, and on-demand training sessions can be arranged via User Services Division, where there is sufficient interest. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

6 4. System Owner Responsibilities 4.1 Competencies Systems staff in IS Applications along with our infrastructure and network providers in ITI are all skilled and trained technically to support the security of the UniDesk service. As well as traditional server management, staff require a good working knowledge of the processes relating to use of UniDesk 4.2 Operations Schedules are in place for regular patches to operating systems and server software. These are detailed on the IS Intranet. Security patches are prioritised as required for components such as Shibboleth. 4.3 System documentation 4.4 Segregation of Duties Systems documentation along with service level procedures are located in the collaborative tools section of the IS wiki (Insite) which is accessible to appropriate staff at all UniDesk institutions. Service level documentation and Self-help guidance for all users is published on the IS website, and at the Using UniDesk wiki. Service level documentation is owned and maintained by IS Service Management. User help topics are owned and maintained by IS User Services. Additional internal user support documentation may be located on the User Services knowledge base. Access to this is controlled by IS User Services IS Technical and Support staff have administrator privileges on the system as described in 3.6 above. IS Applications Service Management permit administrator Operator access to the web interface as required, with appropriate authorisation. Technology Management internally manage Administrator Console access for the production services and access to this would be granted only by senior IS staff approval (such as to Development teams during project work). All users login to the system via Shibboleth, which at Edinburgh is authenticated via EASE. At other institutions, other single sign on services are used. 4.5 Security incidents Security incidents are raised with IS IRT team to take the appropriate action, with support from other IS areas as required. Incidents raised with IS IRT are not accessible to other operators. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

7 4.6 Fault/problem reporting 4.7 Systems development Faults and problems should be reported to the IS Helpline who would then escalate to 2nd and 3rd line support if necessary. IS Helpline have established support procedures in place, to continue providing support in the event that UniDesk is itself unavailable. Key contacts at other institutions may contact 2 nd line directly, though they are encouraged to go via the IS Helpline. Additionally, there is some server side monitoring which may help to proactively identify issues. Changes to the UniDesk service are managed by a Change Advisory Board containing representation from all institutions. Smaller developments (i.e days effort) such as service improvements are prioritised and managed through service calls between IS teams and the business accordingly. All planned changes are communicated, recorded, and any known user impact is published to IS alerts. Larger developments (10 days or more effort) are managed through a project cycle (following IS Applications methodology). A range of online project tools and templates provide a framework for managing new developments. All work is quality checked by project stakeholders at key stages of the project. Changes being applied to the UniDesk system, other than standard changes, are tested in a test environment before being deployed onto the live systems. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

8 5. System Management 5.1 User account management End user (Self Service) accounts are driven by automated data feed (at Edinburgh from the IDMS) including creation and archiving old accounts. Operator accounts are created manually, and archived manually. At Edinburgh, permissions to do this are intended to be devolved to each individual Operator Group using the Team Admin role. At other institutions, centralised local administrators are able to manage Operators and Groups. 5.2 Access control Admin level access is granted following a manual process as described in 3.6 and again in 4.4 above. End users entitled to use Self Service are granted user level access to their own accounts automatically. Operator level users are managed by Team Admins at Edinburgh, and by local administrators at other institutions. 5.3 Access monitoring There is auditing on most changes saved to UniDesk. Access is controlled as above, but not directly audited. 5.4 Change control UniDesk has change processes documented on the IS Intranet: 5.5 Systems clock synchronisation 5.6 Network management 5.7 Business continuity +and+change+process System clock is set at the server level, and is synchronised to UTC. All network activities are carried out by ITI Communications Infrastructure. Refer to the code of practice for University network systems. Special routing for mail relays is arranged in conjunction with ITI UNIX for external institutions. UniDesk is a priority 2 application. IS Applications will therefore recover service within its defined protocols. The full infrastructure is mirrored, including databases. There is a manual failover arrangement. 5.8 Security Control Access is via https, incoming IMAP mail connections use SSL UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun

9 6. Third Party 6.1 Outsourcing There is no outsourcing of responsibility for hosting, running or maintaining of the UniDesk service, other than as may be defined by dependent services, and which would be subject to relevant regulations and codes of practice. 6.2 Contracts and Agreements 6.3 Compliance with the university security policy UniDesk is provided to several members and partners by University of Edinburgh. Service levels are set in Service Level Agreements, which are stored on the IS intranet. UniDesk as provided to external organisations does not contain Edinburgh University data. Where external parties may be granted Operator level access to the live Edinburgh environment, this will be subject to agreement including computing regulations. User level access may technically be available to users not currently members of Edinburgh University, such as Applicants, Alumni and some Visitors. However, user level access is to own incidents only, and subject to computing regulations. 6.4 Personal data Edinburgh University data is not expected to be made available to third parties, other than as described above. If this were to be required it would be arranged to comply with University governance and Policies. UniDesk CoP v1.1 03/04/2013 based on Template, Version Jun