A user-friendly approach to grid security

1. A user-friendly approach to grid security A user-friendly approach to grid security “Grid ‘security’? We’re 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 don’t 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 developer’s agenda, not users’

9. How “The Grid” was designed Grid technology developer: “Here’s a thing I just developed. I’m sure it’ll be useful to you for something or other. Go on, give it a whirl…” Grid infrastructure developer: “OK, I’ll 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. I’ll build it into my application… Now my application is five times as large, doesn’t 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 what’s going on • Formal security verification …so we know we’ve got it right

12. …in a grid context • Handle local issues locally (“localise, don’t 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 • Don’t rely on IP addresses

13. So who’s 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-user’s 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?