DICE development projects - 0_Pending

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

Provision of secure web service for user data

roger — Mon, 03 Mar 2014 14:04:29 +0000

Project ID:

301

Current stage:

0_Pending

Manager:

roger

Unit:

services-unit

What:

We have a considerable amount of user web content (homepages is one obvious example) mounted on our web servers via NFS and AMD. This project would provide a more secure alternative using a separate web server with AFS filespace for sensitive data.

Why:

Customer: School

Case statement: NFS mounted web space has many security disadvantages, as well as being only accessible from within the School. AFS, with proper safeguards, would allow both file access and web access in a secure and controlled manner.

When:

Status: proposal

Priority: medium

Time: 1 week

How:

Proposal:
To provide secure, on-request, user web space

Resources:
Sufficient AFS space to contain the content
Knowledge of AFS and apache/waklog

Plan/Issues:

Install basic test web server
Add support for authentication (CoSign & Kerberos) & waklog
Confirm ID naming scheme
Create AFS/Kerberos IDs for web server & users
Generate & store appropriate keytabs
Configure appropriate ACLs for filesystem access via command-line & browser
Generate volumes
Confirm filestructure &naming scheme and configure volume mount-points
Rebuild suEXEC
Configure CGI execution environment

(also see earlier AFS Web Server Plan/Issues Document)

Other:

Dependencies:
This project requires a working version of waklog for our web servers.
This project relates to, and will have an impact on, the "Move user and group web space to AFS" project.

Risks:

AFS performance could be affected - possibly by significant web traffic to/from the servers. Any such degradation could, perhaps, be reduced by separate storage/servers for web areas.
Using AFS makes web data potentially available from any location (via browswer or filesystem), thus increasing security concerns.
Future dependency on waklog. Note that the future of mod_waklog is uncertain - any reliance we place on it may mean that might have to become involved in supporting it - either locally or publically.

Milestones

Proposed date	Achieved date	Name	Description

Firewall Hole Admin/Tracking

timc — Mon, 03 Feb 2014 09:51:12 +0000

Project ID:

300

Current stage:

0_Pending

Summary:

Put in place a simple means to manage firewall holes opened for end users (generally on self-managed machines).

What:

Users request firewall holes for services to be opened beyond EdLAN. We need a clean approval process to check that the users have done all the basic security measures. At an annual interval we review all our current firewall holes that are open to see if they are still required. These processes are currently carried out manually.

Why:

By doing this we minimise our attack vector, reducing the number of ports, services and hosts that are directly accessable from outside EdLAN. We have some level of duty of care to self managed users to inform them of the risks and to pro actively minimise that risk.

When:

No specific timeframe.

How:

One suggestion is that we use the RT ticket requesting the firewall hole as the tracking element. We craft a stock reply to these requests (based on what we have already) that support can easily select from a drop-down and reply with in the first instance. We can add a dedicated RT queue/category (a'la software requests) for this purpose. We should be able to build a standard query that can be run against the RT database (or just using the existing search options) to pull out on a monthly basis firewall hole requests that have been open for more than a year which could be used as an email prompt to support to initiate checking for continued requirement.

See https://wiki.inf.ed.ac.uk/DICE/FirewallHolesAndDetonator which could be used as the basis for a boilerplate response.

Other:

Dependencies:

Risks:

Computing help site enhancements

ascobie — Wed, 04 Dec 2013 16:09:48 +0000

Project ID:

298

Current stage:

0_Pending

Manager:

ascobie

Unit:

compexec

Summary:

Implement various enhancements to the computing.help.inf.ed.ac.uk web site

What:

The existing computing support form is still hosted on the old CVS based computing support web site. This form needs to be implemented in the new drupal service.
The mechanism for editing and displaying system status was a quick and dirty solution so as to not hold back delivery of the new help site. It needs implemented properly, ideally deriving some of its data from Nagios
A user must click on the printer icon to display a printer-friendly version of a page. It would be nicer if this was automatic, using a printer specific stylesheet.

When:

Not time critical

Other:

Virtual desktop infrastructure

squinney — Fri, 11 Oct 2013 09:05:32 +0000

Project ID:

295

Current stage:

0_Pending

Manager:

squinney

Unit:

mp-unit

Summary:

Virtual desktop infrastructure

What:

Provide a decent virtual desktop infrastructure. For researchers (e.g. staff, postdocs, postgrads) who have DICE desktops, the service might utilise the computing resources of the desktop machine allocated to the particular user. This is not possible with NX but there are probably other systems out there which can be used, this project will evaluate the various options to come up with a proposal for future implementation.

Why:

The recently deployed NX service has been wildly popular and users would like an even better service. It's clear that running just one server for this purpose is not going to be sufficient. We have to limit resource access (e.g. memory) so that it is reasonably usable by all. Most staff have DICE desktop machines so it would be nice to have some system to allow remote graphical access.

Effort estimate:

2 weeks

Other:

Dependencies:

Risks:

InfHR Migration from Legacy SchoolDB to Theon

timc — Mon, 23 Sep 2013 08:46:51 +0000

Project ID:

294

Current stage:

0_Pending

Manager:

timc

Unit:

rat-unit

Summary:

Migrate the systems used by InfHR in the old School database into Theon

What:

This covers a number of areas. The first is driven by a business analysis being done by admin. This will determine the shape of the structure under Theon. It is unlikely that there will be much migration (data or structure) from legacy in the end. It is more likely that the processes will be changed to be driven by upstream data from HR systems and the VRS, reducing the duplicated data entry currently done. Associated with this migration will be review/conversion of old conduits generating staff and institute landing pages to move into the Portal.

Why:

The InfHR systems will in due course be the only thing remaining in the old School DB setup (database, outgoing conduits framework). After this migration the old systems can be shut down removing a maintenance burden. At the moment data in 3g comes from the HR upstream source, but web pages are generated from the old 2g InfHR maintained data. There is an increasing interference/drift of the main Theon data processing from the data that is still maintained locally by InfHR resulting in discrepancies. This would be corrected by migration. The migration is an opportunity for admin to improve/automate more of the HR processes (to take advantage of features supported by Theon but not in the legacy systems).

When:

Largely this is waiting on business analysis by admin, probably not until mid 2014.

How:

TBD based on business analysis.

Effort estimate:

Not possible at this stage but likely to be more than 4 weeks

Other:

Dependencies:

Risks:

Hadoop cluster revamp

iainr — Mon, 26 Aug 2013 15:09:49 +0000

Project ID:

291

Current stage:

0_Pending

Manager:

iainr

Unit:

rat-unit

Summary:

Rework the existing hadoop component and headers to provide better management and monitoring

What:

Rework the hadoop component to
* Allow individual nodes to be added and removed from jobtracker
* Allow additional diskspace on nodes to be added and removed from the hdfs filesystem
* Better support the use of multiple clusters.

Develop a small test suite that could be used to automatically test the operation of the cluster and possibly integrate this with nagios.

Deploy performance/usage monitoring software to better quantify the cluster usage.

Why:

The current component works well at configuring a fairly static cluster but adding and removing nodes, both to run jobs and as disk nodes in hdfs is awkward and time consuming. The configuration often does not reflect the actual nodes in the cluster which has led to data loss in the past.

Being able to remove nodes when the cluster was not being used would allow us to sleep nodes (where supported) and reduce the cluster power footprint. Ideally this could be scripted and allow the cluster to automatically minimise it's power usage without affecting it's usability.

The current hadoop configuration (version and installed packages) is largely dictated by the extreme computing course. Being able to set up multiple hadoop or hdfs clusters on the existing hardware with a minimum of overhead would allow us to respond more flexibly to requests from other groups of users where better security or a more recent version of hadoop is required.

Having a standard set of test jobs would allow us to monitor the clusters health and hopefully reduce downtime.

How:

Core:
Rewrite the hadoop component to fully manage the configuration of all the clients and the starting and stopping of the various daemons.
Produce a mechanism that would as much as possible automate managing the membership of the cluster (say via a spanning map) and also manage which member nodes are currently active within the cluster.
Take the basic hadoop example tutorial and automate execution of it so that it could be run as a nightly cron job. Investigate any hadoop nagios clients and integrate them into our nagios setup.
Generate basic monthly logs of cluster usage.

Optionally:
Write a daemon that monitors the cluster usage and dynamically activates and sleeps nodes to match the cluster usage.
Investigate any hadoop nagios clients and integrate them into our nagios setup.
Check for any useage/accounting type packages available for hadoop or write one if there is none available.

Effort estimate:

2-3 weeks for reworking the component, 2-3 days for the test setup 2+ weeks for the optional stuff.

Other:

Dependencies: Any development would have to fit in alongside current cluster usage

Risks:

Mimic new 2013 Uni web look

neilb — Thu, 22 Aug 2013 11:30:22 +0000

Project ID:

288

Current stage:

0_Pending

Summary:

The main University web site has had a graphic refresh. We could/should update our local pages to look similar.

What:

In the past we've developed local templates/skins to mimic the current www.ed.ac.uk look at the time. As www.ed.ac.uk now has a new look, our pages are now out of step with the Uni's current look. This project proposes we spend some time updating our local templates/skins to mimic the new 2013 Uni web look.

Why:

We now have 3 different styles for the main Informatics pages:

The new look Polopoly hosted content - http://www.ed.ac.uk/schools-departments/informatics/
the previously mimicked Uni look that we use in our Plone content - http://www.inf.ed.ac.uk/school-services/start-1
and the even older pre-Polopoly pages - http://www.inf.ed.ac.uk/teaching/courses/ct/.

Then there's also things like our new computing help pages - http://computing.help.inf.ed.ac.uk/

When:

There's no particular need/rush to do this, other than a desire to have a more consistent web look.

How:

Basically study the current structure of the Uni web pages and their CSS, and then:

www.inf

Effort estimate:

2 to 3 weeks

Other:

Dependencies: Access to Uni's new look CSS, images.

Risks: Simply changing the CSS/images may not be enough, some content structure make need altered. If this is required, it needs to be an automatic process, rather than burdening web content authors with effort to update their content.

It may be worth looking at updating our Plone to the latest version, and using its new skinning tools, which are apparently easier than the method used for Plone 3, which we are currently using. Though that will take effort too.