DICE development projects - cms

Review Handling of Sensitive Data Within the School

cms — Mon, 10 Mar 2014 09:50:27 +0000

Project ID:

302

Current stage:

0_Pending

Assigned Priority:

Manager:

cms

Unit:

services-unit

Summary:

Review Handling of Sensitive Data Within the School

What:

Examine the way sensitive data, both personal and research, is currently handled within the School and to suggest ways in which this could be improved.

Why:

It is important that the School can be confident that all the requirements (both legal and as imposed by funding bodies) for the correct securing, retention and eventual disposal of secure data are being met. Not doing so opens the School up to both the threat of legal proceeding and the potential loss of research funding. This is not an easy task and has traditionally been overlooked or ignored as a consequence but it is becoming increasingly clear that this is an issue the School must address in a timely fashion.

When:

Though there are no hard deadlines, this is something which should be done as soon as possible.

How:

An important first step is to determine what sensitive data the School possesses. This information should be generated by the Research Data Audit project and the sensitive data audit currently under way. The Archiving Project shoudl provide details of such things as mandated retention periods and access criteria. With this information to hand, decisions can be taken as to how the School can improve its handling of sensitive data, acting in consultation with the University units such as Registry and the library.

Effort estimate:

3 weeks

Other:

Dependencies:Devproj 290 (research data audit), devproj 194 (Meeting the School's Archiving Needs), Sensitive data audit
Risks: The Risks are all concerned with not doing this project. Failing to address this issue will leave the School open to legal action and loss of research funding

Research Data Audit

cms — Fri, 23 Aug 2013 15:31:57 +0000

Project ID:

290

Current stage:

1_Proposal

Assigned Priority:

Manager:

cms

Unit:

services-unit

Summary:

An audit of all research data within the School

What:

This project will attempt to all research data held on School storage and create appropriate metadata (owner, status etc) for each item of data identified. The project will also encompass decisions regarding how the audit should be conducted, how the metadata should be stored and how best to ensure that the audit data remains current after the end of the project

Why:

The requirements of many funding bodies regarding the creation of, access to and eventual deletion of data are becoming ever stricter. This audit will be a useful first step towards ensuring that the requirements of these funders are met. It will also be extremely useful for management of the School's storage.

How:

To be decided as part of the project. Much of the work of actually collecting the data can be CSOs or even by research staff

Effort estimate:

one week for decision making.. up to four weeks CSO/other time for actual collection of data

Other:

Dependencies:An audit of group space usage was conducted by Lindsey Brown in 2011. This project will build on that work

Risks: Not doing this risks failing to comply with the requirements of funding bodies with detrimental affects on the School's reputation and income

Deploy Git and Gerrit as full services

cms — Tue, 05 Feb 2013 10:54:57 +0000

Project ID:

272

Current stage:

3_Implementation

Assigned Priority:

Manager:

cms

Unit:

services-unit

Summary:

The School has been running a Git and Gerrit not-a-service for several years now. This project will upgrade Git and Gerrit to full services

What:

Set up new virtual server for Git/Gerrit
produce header files to allow Git/Gerrit servers to be easily set up
ensure that service data is being backed up
update documentation and helper programs

Why:

Git and Gerrit have seen a reasonable take-up by the School since the introduction of the not-a-service. It is being used to manage the Prometheus project, and has also been used for coursework group practicals in the past. Given the need to update the server on which the service is running to SL6, It makes sense to promote the service to a full service now.

How:

build obtain necessary RPMS
create header file to install RPMS, generate certificates and configure gerrit web interface
Build new virtual server
Install latest versions of Git/Gerrit on new server
Move data from not-a-service to new server
Test compare data for discrepancies
port/update helper/support programs
Set up mirrors/database dumps
Determine best way of configuring gerrit automatically.
deploy new service

Effort estimate:

In total the project should take around 2 man-weeks

Other:

Dependencies:
postgresql, apacheconf, cosign infrastructure

Risks:

Investigate AFS on ECDF storage

boss — Fri, 25 Jan 2013 15:46:29 +0000

Project ID:

268

Current stage:

2_Evaluation

Manager:

cms

Unit:

services-unit

Summary:

AFS access to the ECDF provided 500GB per research user.

What:

Description: The University is proposing to provide each research active user with 500GB disk space. Unfortunately, IS are currently proposing that this space will be presented by NFS, CIFS or SSHFS. This project would investigate whether we (working with IS) can add AFS as an access mechanism.

Deliverables: Report of the investigations, and a working AFS path to the space if possible.

Why:

Customer:
All research active users within School

Case statement:
It wouldn't make sense to not use the space being made available to us, however for better integeration with our file system, AFS access would seem a better option than the proposed filesystems.

When:

Status:
Proposal

Timescales:
It's been resourced this third (T1, 2013) for 3 weeks.

Priority:
Medium/low - It's not mission critical, and at the last CCPAG (Feb 2013) ECDF were still waiting for the go ahead to provide the space.

Time:
1 hour so far

How:

Resources: Total of 3 weeks.

Proposal:
Two weeks to create an .ed.ac.uk AFS cell on GPFS nodes. One week to benchmark end-user performance and effect on GPFS cluster.

Plan:

Get to know how ECDF GPFS works.
Research strategies for running AFS on GPFS.
Assuming it is possible, mount GPFS on machine in Forum, or get access to machine at ECDF that does have access and setup AFS. Probably a test cell first.
If it isn't possible, can we get access to raw disk space and mount as a normal /vicep
Test and bench mark, check performance and affect on cluster.
If all is good, then make what ever changes to run it as a full service - eg hardware, final cell name.

What if a researcher doesn't want "their" space as AFS. Some may want to opt out and use one of the IS proposed protocols. eg researchers with Windows machines?

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/Project268AFSonECDF

Other:

Dependencies:
Access to ECDF storage.

Risks:
This would be a new service, not impacting on current services, so risks would be low. Perhaps performance issues affecting network/ECDF.

Milestones

Proposed date	Name	Description
22/3/2013	access	Get access to ECDF and GPFS
	testcell	Setup test AFS cell
	perf	Performance testing
	results	Present results/findings/thoughts
	production	Turn into production service if all went well
	writeup	Final Report

Do we still do these?

Move user and group web space to AFS

boss — Fri, 25 Jan 2013 15:46:24 +0000

Project ID:

243

Current stage:

0_Pending

Manager:

cms

Unit:

services-unit

What:

Description: We still have a considerable amount of user and group web content (homepages is one obvious example) mounted on our web servers via NFS and AMD. This project would move this content to the Schools AFS file system.

Deliverables: Most, if not all web content now on NFS file space moved to AFS space

Why:

Customer: School

Case statement: NFS mounted web space has many disadvantages. It can only be edited on machines within the School's firewalls and its existence requires that we maintain our NFS and AMD infrastructure. Moving this data to AFS would allow us to expend this effort elsewhere.

When:

Status: proposal

Timescales: Three weeks

Priority:

Time:

How:

Proposal:

Resources: Sufficient AFS space to contain the content

Knowledge of AFS and apache/waklog

Plan:

This project now has two elements

The transfer of homepages sites to separate AFS volumes. This will have many advantages including fine grain access control, fine grain quota control, the ability to access homepages sites from outwith the university and the ability to remove homepages sites as part of the account lifecycle mechanism.
The segregation of sensitive and non-sensitive data on homepages. This will probably involve running two homepages server, one much more secure than the other.

Other:

Dependencies: This project depends on there being a working version of waklog for our web servers, This of course is not a requirement exclusive to this project

Risks: Performance of AFS service. Could AFS server be adversely affected by significant web traffic. Perhaps this could be mitigated by separate storage/servers for web areas.

Future dependency on waklog.

Milestones

Proposed date	Achieved date	Name	Description

Documentation update - services unit

boss — Fri, 25 Jan 2013 15:46:24 +0000

Project ID:

247

Current stage:

4_Signoff

Manager:

cms

Unit:

services-unit

What:

Description: Review and update end-user documentation. Includes porting across any remaining documentation not already on new drupal based site.

Deliverables:

Why:

Customer:

Case statement:

When:

Status:

Timescales:

Priority:

Time:

How:

Proposal:

Resources: 2 weeks effort

Plan:

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport247

Other:

Dependencies:

Risks:

Milestones

Proposed date	Achieved date	Name	Description

SL6 upgrade for Services Unit

boss — Fri, 25 Jan 2013 15:46:19 +0000

Project ID:

219

Current stage:

4_Signoff

Manager:

cms

Unit:

services-unit

What:

Description: Upgrade all Services Unit servers and services to use the SL6 Operating system

Deliverables: All Services and Servers using SL6

Why:

Customer: School

Case statement:

When:

Status:

Timescales:

Priority:

Time: Estimate 10 weeks in total. This include 4 weeks for converting all websites using apache to use the apacheconf component

How:

Proposal:

Resources:

Plan:

Final report URL:

https://wiki.inf.ed.ac.uk/DICE/FinalProjectReport219

Other:

Dependencies:

Risks:

URL: https://wiki.inf.ed.ac.uk/DICE/ServicesUnitServers2SL62

Milestones

Proposed date	Achieved date	Name	Description

Enhancements to existing room booking system

boss — Fri, 25 Jan 2013 15:46:18 +0000

Project ID:

217

Current stage:

0_Pending

Manager:

cms

Unit:

services-unit

What:

Description: Since it now seems extremely unlikely that the procurement of a new room booking system will go ahead, this project is concerned with user requested enhancements to the current room booking system

Deliverables: Enhancements as requested by users. In particular:

A better ability to track the history of events (creation, edits made, deletion)

The ability to more easily managed the booking of multiple rooms for a single event

Further features as requested by users

Why:

Customer: School

Case statement: Improvements to the current room booking system are frequently requested by the admin staff but have been deferred do the to plan to purchase a new RBS/event management system. Now that this procurement is unlikely to go ahead, we should revisit the improvement of out existing system

When:

Status: proposal

Timescales: 4 weeks. 2 weeks for existing enhancements detailed above, 1 week for familiarisation with PHP/mySQL and 1 week for any further features requested by staff.

Priority:

Time:

How:

Proposal:

Resources: Knowledge of PHP, mySQL

Plan:

Other:

Dependencies: Our RBS is based on an external freeware project, MRBS. Any enhancements to our system shoudl be made with the intention of feeding them back to the main project

Risks:

Milestones

Proposed date	Achieved date	Name	Description

Web based student password portal

boss — Fri, 25 Jan 2013 15:46:18 +0000

Project ID:

215

Current stage:

3_Implementation

Manager:

cms

Unit:

services-unit

What:

Description: This project covered the creation of a simple web based portal to allow new students to collect their DICE password after authenticating via EASE.

Deliverables: the above web portal

Why:

Customer: ITO

Case statement: At the start of every year, the ITO are besieged by large numbers of students seeking to collect their DICE account information, particularly their passwords. This causes a great deal of disruption to the ITO at their busiest time of year. This project will allow students to collect their passwords without troubling the ITO

When:

Status: Active

Timescales: This project must be completed by the start of the next semester (12th September 2011)

Priority: High

Time: A maximum of 4 weeks FTE though it should take less

How:

Proposal:

Resources: Knowledge of apache configuration, cosign authentication and Prometheus

Plan: Set up EASE authenticated web server
write code to have Prometheus display newly generated password as web page
write CGI to call prometheus code
add step to account generation process to send mail to newly created account's SMS email address telling them to collect password from the new web portal

Other:

Dependencies: Central EASE authentication service
School Prometheus service (for password generation)

Risks: Distruption to ITO if this is not completed in time

Milestones

Achieved date	Name	Description
2011-08-12	webserver	Set up server to run portal on
2011-08-12	website	Set up EASE authenticated web site
2011-08-16	Prometheus Code	Write code to display web page containing newly generated password
2011-08-23	CGI	Write CGI to call prometheus code and display generated password
2011-08-16	student email	modify account creation process to email student's SMS mail address with detail of how to access portal

Meeting the School's Archiving Needs

boss — Fri, 25 Jan 2013 15:46:14 +0000

Project ID:

194

Current stage:

2_Evaluation

Assigned Priority:

Manager:

cms

Unit:

services-unit

What:

Description: This project will investigate how best to meet the School's requirements for archiving data

Deliverables: A cohesive archival policy for the School's data along with guidence on how this policy may achieved

Why:

Customer: School

Case statement: The report produced by https://devproj.inf.ed.ac.uk/project/show/149 concluded that the School's current approach to archiving was no longer appropriate and that investigation should be carried out on how best the School's archiving needs could be met. This project will carry out that investigation. This project will conduct that investigation and in addition formualte and publicise a policy on when it is permissible for personal information such as home directories to be retrieved from archive.

When:

Status:

Timescales: Identifying the requirements and constraints which an archiving solution for the school needs to meet may take some time given the many different contributers to those requirements. Allow a week for this. Identifying archive methods and evaluating how they meet the needs of the School may also take up to two weeks. Categorising and assigning ownership of data and engaging those owners in initiating the archiving process will take a considerable amount on time (just how much depends on how much data we are dealing with and how many separated owners) but much of this work can be done by CSOs.

Priority: High. Archiving of data in an appropriate way is vital for the School and is something that is just not happening at the moment

Time: 3 weeks

How:

Proposal:

Resources:

Plan:

Formulate specification of School's archiving needs
Quantify data needing archived
Survey available archiving methods/services and assess best fit for 1) and 2)
Produce and implement plan/policy for migration or initiation of data archiving

Effort estimate:

3 weeks + CSO time

Other:

Dependencies: Familiarity with the School's data

Risks: We greatly increase the chances of losing vital data if we do not address this issue urgently.

Milestones

Proposed date	Name	Description
19/8/2013	Identify needs	Identify the archiving needs of the School
26/8/2013	quantify data	Estimate the amount of data (both existing and potential) needing archived
9/9/2013	Identify methods/services	Identify and characterise the archiving services we can potentially make use of
23/9/2013	Plan implimentation	Produce plan for implementation of new archiving strategy and implement