A user-friendly approach to grid security

Bruce BecklesUniversity of Cambridge Computing

Service

A user-friendly approach to grid security

“Grid ‘security’? We’re not there yet.”

Co-authors:

Peter Coveney, UCL

Peter Ryan, Newcastle

Ali Abdallah, LSBU

Stephen Pickles, Manchester

John Brooke, Manchester

Mark McKeown, Manchester

Definition of Termsuser-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”

“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

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)

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)

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” …

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(!)

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’

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.”

Our approach to grid security: raison d’être

• Grid Security (currently):

HEAVYWEIGHTHEAVYWEIGHT + poor usability + inappropriate design = systemic errors

Systemic Flaws = Inherently Insecure!Inherently Insecure!

QED: we need a new approach to grid security.

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

…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

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

Questions?