OII Seminar "User Experiences with Security in e-Science Grids: Lessons and Opportunities"

M. Angela Sasse and Brock Craft (UCL)

Alun and Mark attended (these are Mark's notes).

Overview of existing security issues in e-Science

Some security factors highly germaine to e-Science:

• collaboration
• remote access to systems, data and software
• heterogeneous background of developers
  • typically scientists, rather than computer scientists
  • applicatin software developers often don't have a professional computing background (often self-taught). May never have been taught software engineering and security
    • but strong sense of ownership and clarity of problem to be solved
• virtual organisations challenge traditional security
  • usually site-based
  • clear hierarchy brought in (traditionally) for breaking rules
    • who imposes sanctions for damage to (or in the name of) the VOs?

Previous work

Ivan Flechais PhD

Many stakeholders

• Conflicting requirements

Pressure to deliver functionality -> lack of motivation to consider security

Lack of communication between stakeholders

"High level of complexity and low level of knowledge leads to avoidance of issue".

Angela gave examples of where people may be sharing across VOs (even across continents) until the local computing service heard what they were doing and pointed out that they were breaking the conditions of use. Some projects then set up their computing resources outside the university to get around this.

People use security terms in a 'name dropping' kind of way to hide behind the technology. It has been found that if the people that use the terms 'Firewall', 'Globus', 'X.509 Certificate' etc., they didn't really understand the technology (another way of avoidance of issue).

"Security as a non-functional requirement"!!

• The old point of "Have security in there early on within the design"

Value-based design

• Raise awareness and get the stakeholders more interested in security from the early part of the project.

Description of the e-Science survey

Brock Craft

Data collection

Personal interviews

Focus groups

Observation of e-Science project planning meetings

50 candidates, 34 interviewees.

Many hours of transcript - analysed using Grounded Theory

Results

• Four major user communities
  • Researchers
  • Developers
  • Administrators (managers of the day to day operations - network admin)
  • Managers (PIs, project managers and team leaders)

Groups all had different (overlapping) areas of need, as follows...

• Documentation

  • Current doc. is non-existent, difficult to find, or difficult to use
  • Poor documentation on digital certificates and middleware tools in particular
  • Not just a security problem - e-Science requires more documentation than traditional development
    • We talked here about OMII and the idea of having a central body to harden the software and to add in security. However OMII doesn't seem to be addressing documentation!
  • Many users require better documentation AND documentation specific to their needs.
  • Developers use documentation more than end user and will hunt for answers (they are more resilient). End users are not that persistent.

• Authentication (digital certificates)

  • Web services work well but passwords have the usual associated problems (memorability vs strength etc.)
  • Digital certificates particularly difficult
  • User view: if getting a certificate is that much effort, we'll share to make it worthwhile

• Authorisation

  • Users need to maintain control over their own resources
  • Many would like to delegate (access to students, RAs)
  • Difficult to scale, especially for administrators

• Confidentiality and privacy

  • Need varies with type of data and research domain
    • e.g. biotech, medical research have serious confidentiality issues
  • even meta-data can be sensitive (e.g. when someone looked at some data)
  • can often be inadvertently subverted (e.g. cut and paste into an email)
  • Most projects are aware of this but do not have the time to solve it - changing people's behaviour is really hard.

• security in the development life cycle

  • Not considered from day 1.
  • Developers "scaffolding" may never be removed (security short-cuts to get things to work quickly). Then it looks secure but is not.
  • Security vs usability
    • Some say "security should be something that a user doesn't have to think about"
  • Stewardship - what happens to this project in the long view?
    • What happens when the software breaks down in the future? What's the exit strategy for the project?
    • No need to put a lot of effort into security if it holds back the project and/or if the system isn't going to survive very long (if they don't believe that it will survive for a long time, then...).

The seminar ended with quite a few questions, some centred on PKI and the way that the CA/RA structures work in the UK.

Bill Dutton questioned whether it would ever be possible to build security in from the start of a development project, something which I too struggle with.

• It sounds such an obviously good idea to put security in at the outset, but - knowing developers and the way they work - it isn't likely to happen. Grid developers are also usually working under time pressures to get a demonstrator working, and it isn't worth their while doing a lot of security work up front. Also, the 'thing' that they are trying to secure changes constantly - another encouragement to wait until it stops changing before trying to secure it.

Brock and Angela said that, at least, new projects were encouraged to have security work packages outlined in them (which were expected to be delivered upon). And there was more pressure to try to find developers with security knowledge to associate with each project.

Angela and Brock didn't get much chance (due to time) to go into much about recommendations and work for the future.

There were references to Angela's and Brock's presentation appearing on a handy web site somewhere, but I'm unable to find it as yet. (-- MarkNorman 2006-05-17 14:15:32)