A user-friendly approach to grid security

1
A user-friendly approach to grid security
A user-friendly approach to grid security
Grid security? Were not there yet.

• Bruce Beckles
• University of Cambridge Computing Service

Co-authors Peter Coveney, UCL Peter Ryan,
Newcastle Ali Abdallah, LSBU
Stephen Pickles, Manchester John Brooke,
Manchester Mark McKeown, Manchester
2
Definition of Terms

• user-friendly, a. Easy to use designed with the
  needs of users in mind (Source OED)
• approach, n. A way of considering or handling
  something, esp. a problem. (Source OED)
• grid security computer security in the context
  of a computational grid environment
• computational grid environment a distributed
  computing environment which is transparent across
  multiple administrative domains

3
State of the Grid

• Authentication
• Digital certificates (X.509-based PKI)
• Crosses institutional boundaries
• Authorisation
• Either simplistic allow lists in text files
  (the grid-mapfile), or
• Complex, heavyweight, general purpose
  authorisation frameworks (e.g. CAS, VOMS, PERMIS,
  Shibboleth)
• Auditing
• Auditing? What auditing?
• The missing link Siebenlist, Globus Alliance

4
Problems for End-Users

• Digital certificates difficult to obtain and use
  so (shock!) users hate them
• So difficult that users share certificates (and
  not just within a single institution)
• Experience so painful some users refuse to use
  grid technology if it will involve certificates
  (e.g. BRIDGES project)
• Most users dont understand digital certificates,
  so they behave inappropriately
• Multiple copies of certificates (and proxy
  certificates) scattered across the grid (not
  always protected)

5
Problems for Administrators

• Users desperate attempts to cope with
  certificates mean that soon no one knows who is
  actually using which certificates and for what
• and when does a certificate get revoked anyway?
• When a user leaves the institution?
• When they leave the project?
• How does the Certificate Authority know?
• Confusion between identity and membership (?
  authorisation)

6
Authorisation Issues

• Authorisation mechanisms choice? what choice?
• Either just an allow list
• Too simplistic
• or complex, heavyweight framework
• Difficult to understand, deploy, maintain and
  administer
• May require centralised co-ordination or
  infrastructure
• In all cases, dependent on the integrity of the
  authentication mechanism, so, currently
• doomed, doomed

7
Auditing Issues

• Who did what? From where?
• Who dependent on integrity of authentication
  mechanism uh-oh
• What executable name often lost in transit
  (data, condor_exec.exe), and executable normally
  deleted on job completion oh, good...
• Where IP address of host submitting job but job
  may arrive via a proxy or portal Anyway, IP
  addresses can be spoofed!
• And what else should we be recording?
• Audit data usually stored locally, so
• Successful attacker can modify it(!)

8
Why is it like this?

• Current solutions
• Heavyweight
• Difficult to deploy and administer
• Often require inappropriately centralised
  infrastructure
• Complex (so difficult to understand)
• Poor Usability
• Difficult for end-users to use
• Difficult to configure and administer
• Poor/Inappropriate Design
• One size fails all
• Designed to developers agenda, not users

9
How The Grid was designed

• Grid technology developer Heres a thing I just
  developed. Im sure itll be useful to you for
  something or other. Go on, give it a whirl
• Grid infrastructure developer OK, Ill deploy
  it so that my application developers can use it.
  Boy, this sure is complicated to deploy Umm,
  what did you say it should be used for again?
• Grid application developer Right, so this is
  the latest grid technology? Great. Ill build
  it into my application Now my application is
  five times as large, doesnt do anything useful
  and I have a migraine. Why am I doing this?
• End-user I am confused. Please help.

10
Our approach to grid security raison dêtre

• Grid Security (currently)
• HEAVYWEIGHT poor usability inappropriate
  design systemic errors
• Systemic Flaws Inherently Insecure!
• QED we need a new approach to grid security.

11
User-friendly security

• Designed to be lightweight
• Easy to deploy and administer
• Easy to understand
• Restricted to a sensible-sized problem domain
• User-centred design
• Design for the user, not in spite of them
• Understand and satisfy stakeholder requirements
• Continuous user involvement
• Ongoing usability testing
• Formal security methods
• Formal analysis and modelling
• so we understand whats going on
• Formal security verification
• so we know weve got it right

12
in a grid context

• Handle local issues locally (localise, dont
  centralise)
• Authentication
• authenticate against local authentication service
• VO membership
• use local identity to determine
  membership/authorisation (parameterised RBAC?)
• Distribute information across resources as
  necessary
• Certificates appalling, passwords better
• Use local authentication to obtain or create
  certificates on behalf of the user to interact
  with existing grids
• User never sees a certificate!
• Conform to best practice
• Audit data stored remotely
• Dont rely on IP addresses

13
So whos exploring this approach?

• User-Friendly Authentication and Authorisation
  for Grid Environments project
• UCL, Manchester, Cambridge, Newcastle, London
  South Bank University
• Planned start date October 2006
• EPSRC funded
• For our proposed authentication mechanism (wraps
  existing GSI mechanism), see
• Removing digital certificates from the end-users
  experience of grid environments (2004)
• http//www.allhands.org.uk/proceedings/papers/250.
  pdf
• Mechanisms for increasing the usability of grid
  security (2005)
• http//dx.doi.org/10.1016/j.ijhcs.2005.04.017

14
Questions?