CoP Template, Version 1.4 20 Jun 2011 1 Use of IDM
Code of Practice Introduction
This code of practice is intended to support the Information Security Policy of the University and should be read in conjunction with this document.
http://www.ed.ac.uk/schools-departments/information-services/about/policies-andregulations/security-policies/security-policy
This code of practice is also qualified by The University of Edinburgh computing regulations, found at:
http://www.ed.ac.uk/schools-departments/information-services/about/policies-and-regulations
1. Code of Practice Version
[The CoP for any system is expected to develop over time. For this reason, it may be important to track versions of any CoP. This section in the template suggests a framework in which you could record reasons for change to the CoP for the system referred to.]
Revision Date CoP Version
Template Version
Author Notes
12/07//2013 1.0 1.4 Chris McKay Creator
02/08/2013 1.1 1.4 Chris McKay Creator
20/08/2014 1.2 1.4 Chris McKay Creator
QA Date QA Process Notes
2 Sep 2014 ITC Security WP
Suggested date for Revision of the CoP Author
CoP Template, Version 1.4 20 Jun 2011 2 2. System description
Revision Date System Version
Author Notes
N/A N/A Chris McKay
2.1 System name IDM 2.2 Description of
system Central University Identity Management system. Receives data from Golden Copy upstream sources, determines service eligibility and passes data to downstream systems to control access to University IT services.
2.3 Data Handles data from Alumni, Euclid, eVisitor, HR Staff, VRS and Org Hierarchy databases.
2.4 Components Oracle Database, 10g and 11g infrastructure Oracle Service-oriented architecture (SOA) Grouper 1.5
2.5 System owner IS Apps Service Management for service level ownership.
IS Apps Production Management for application and platform level ownership.
2.6 User base Affects all University staff, students and visitors. Only administrators are properly individual users.
2.7 Criticality High 2.8 Disaster recovery
status IDM service, database and application are backed up daily. A manual disaster recovery process is in place to restore the service to other servers.
CoP Template, Version 1.4 20 Jun 2011 3 3. User responsibilities
3.1 Data Administrators have access to information about staff and students and visitors
3.2 Usernames and passwords
The service uses the University’s central, CoSign based single authentication service, EASE.
Authorization is controlled at the database level.
3.3 Physical security Physical servers are located in data-centre at Appleton Tower and Kings Buildings, which are maintained and secured by IS IT Infrastructure Division (ITI)
3.4 Remote/mobile working
The IDM service is available offsite. As with all University systems, users are responsible for their login credentials and ensuring that they do not leave themselves logged in when leaving the device unattended.
3.5 Downloads and removal of data from premises
All data stored in IDM is potentially available offsite. .
3.6 Authorisation and
access control The service uses the University’s central, CoSign based single authentication service, EASE. Authorization is controlled at the database level.
3.7 Competencies Understanding of basic functionality as outlined at : http://www.docs.is.ed.ac.uk/docs/IDM/IDMS_Admin.pdf
CoP Template, Version 1.4 20 Jun 2011 4 4. System Owner Responsibilities
4.1 Competencies Service Management is the business owner of IDM. Issues are escalated to Applications Management who decide the priority with Service Management.
4.2 Operations The physical security of IDM is the responsibility of the appropriate areas of Information Services.
4.3 System
documentation Documentation is at: https://www.wiki.ed.ac.uk/display/insite/IDM+System+Documentation
And is maintained by Production Management and Service Management.
4.4 Segregation of Duties
Service Management controls UI administrator level access. Database level access is controlled by IS Production Management.
4.5 Security incidents All security incidents are reported to Applications Management immediately. Service Management maintains a log of security incidents.
4.6 Fault/problem reporting
Problem reporting is via the standard University helpdesk system. 4.7 Systems
development
CoP Template, Version 1.4 20 Jun 2011 5 5. System Management
5.1 User account
management User accounts are created and managed automatically according to IT service entitlement and identity ageing policies. Gold copy master systems trigger the IDM processes centrally. 5.2 Access control Admin level access is granted via a manual process, controlled by
Service Management.
5.3 Access monitoring Internal logging is minimal due to impact on system performance. The intention is to improve this as part of project COM007
5.4 Change control The IDM Users Group (major stakeholders, not ‘users’ in the conventional sense) has recently been set up to provide a forum and process for this.
5.5 Systems clock
synchronisation Automatic clock synchronisation is in place across University systems. Clocks are synchronised to a central service managed by the ITI Architecture team.
5.6 Network management
The system is publically available. There is no special network configuration required to access the service as an administrator.
Upstream and downstream system access is managed via firewall rules. 5.7 Business continuity IDM service, database and application are backed up daily. A manual
disaster recovery process is in place to restore the service to other servers.
5.8 Security Control Services requiring access must receive permission from Gold Master systems.
CoP Template, Version 1.4 20 Jun 2011 6 6. Third Party
6.1 Outsourcing None, system is for internal use only. 6.2 Contracts and
Agreements None, system is for internal use only. 6.3 Compliance with
the university security policy
Only administrators have access to IDM UI.
6.4 Personal data
