Security Lessons from the EGSO Project

An Experience Report

Clare GryceUniversity College London

Overview

• EGSO – Some background• Characteristics of EGSO project

environment• EGSO and security • EGSO as typical e-Science project• Why is security such a problem anyway?• Indications for future work• Some Lessons learned

EGSO – Some Background

• European Grid of Solar Observations• EC 5th Framework programme

– IST– 2002 – 2005– 5 European countries (12 institutions)– Collaborations in USA

• ‘Data Grid’ application– Access to, and management of distributed

data

EGSO – The Application

• Virtual Solar Observatory• Solar Scientists

– Solar Physicists– Space Weather Community– Astrophysicists

• Distributed, heterogeneous data archives

EGSO Project Environment

• 12 institutions in 5 countries (+ USA)• Diversity of expertise and backgrounds• Stakeholders playing multiple roles• Staggered starts• Biases and ideas about technology choices

lack of rigorous process ‘ad-hoc’ sequence of activities

EGSO Security : Specification [1]

• User and Science Requirements Document– ‘High-level’ requirements– Authorisation and Authentication– Requirements partially specified by

mechanismsSE03M The system shall allow consumers to gain access to resources through user authorization

EGSO Security : Specification [2]

• Focussing on how’s rather than why’s:

“ I need the car to drive to the shops”

“ I need to get to the supermarket”

Reasoning about requirements not clear ‘Solution Space’ constrained

or…

Asking Questions…

“ I need the car to drive to the shops”why

?

• Drive to the shops in the car• Order a take-away• Check the freezer• Invite yourself round to the neighbours BBQ

“I’m hungry!”

“I need to get to the supermarket”

why?

“I need to get some food for dinner”why

?

EGSO Security : Technology • Hoping for a ‘magic bullet’

– Assume a technology solution exists…– How to recognise it?

CA

EGSO Security : Priorities

• Focus on Functional Requirements• Non-functional requirements low priority

– Performance– Usability– Security

• “get the system working first!” – Early demonstrations needed

AEGIS (Flechais et al 2002)

• Appropriate and Effective Guidance for Information Security

• Identify system assets in operational context– People– Hardware– Data

• Assign values to asset properties – Confidentiality– Integrity– Availability

AEGIS : Benefits of Approach [1]

• Facilitated analysis of security concerns• Identify areas of uncertainty/open

issues…there are known knowns, there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know…

AEGIS : Benefits of Approach [2]

• Systematic, reflective analysis of security issues• Have to think about the why’s

– Why do we think we need authorisation?– What are we actually trying to achieve?– Independent of how’s (mechanisms)

• Semi-formal graphic representation– Intuitive subset of UML– Understood by all participants

AEGIS : Outcomes

• Improved understanding of problem space• Commitment to shared conceptual model• Indications of open issues/problem areas

– E.g. Availability - need to consider how back-ups are locally managed

• Some good news!– Authorisation not so critical (80/20 rule)

EGSO – A Typical e-Science Project?

• Creation of a Virtual Organisation (VO)(EGSO - a virtual Solar Observatory)

• Distributed development (EGSO - 12 institutions in 5 countries)

• Expertise from diverse domains(EGSO - solar scientists, computer scientists, engineers)

• Blurred stakeholder boundaries(EGSO - scientists are Users and Developers)

• Abundance of tools, emerging technologies

Security for e-Science - Why so Hard?

• Technical complexity– Heterogeneity– Distribution

• Also social complexity– Heterogeneity– Distribution Security depends on social infrastructure! Need well defined processes

(communication, conflict resolution)

Need human-factors expertise!

Functional and Non-Functional Requirements

• Non-functional requirements often neglected

• ‘Functional’ requirements– Primary purpose(s) of system– Specify in concrete terms

• ‘Non-functional’ requirements– Constraints on fulfilment– Harder to specify– Lack of metrics

Specifying Requirements

• A functional requirement“The system should enable Users to upload their code to the system holding the data”

• A non-functional requirement

“The system should ensure that only Users who are known and trusted by the system holding the data can upload their code to it”? ?

Knowing the un-Knowable?

The infrastructure designed for e-Science will revolutionise the way in which scientists communicate both physically and virtually…

…revolutionise the working habits of research scientists…

…revolutionise scientific practise…

How far can we nail down security requirements?

EGSO Security : Next Steps…

• Core functionality still top priority• But awareness of security increased! • AEGIS

– Asset model will inform security design– Technology choices

• Other Requirements and Constraints– Users– Administrators– Budget? Usability? Network policies?

The (Even) Bigger Picture …

• Not just users and administrators• Other stakeholders?

– Other e-science projects, other grids?– Regulatory bodies– Standards bodies– Public interest

• Changing security requirements– User expectations likely to evolve– How can we accommodate them?

Research Indications• Stakeholder modelling

– Model system stakeholders and their r’ships: With each other With the system

– Capture further contextual information (application independent) Roles, responsibilities, regulators? Other tacit information?

• Application of Systems Science principles– Systems operate within suprasystems– Grids as open systems

Conclusions - Lessons Learned [1]

• Need for process– Methods from SE and design theory?– Not just sequential activities!

• Solutions appropriate to project environment– Lightweight methods– AEGIS

• Expand domain of enquiry– Social infrastructure and context– Suprasystem

Conclusions - Lessons Learned [2]

• Clarify partner roles for improved communication and conflict resolution– Who ‘owns’ the problem?– Need security advocate– Viewpoints?

• Focus on non-functional requirements– Unambiguous, amenable to validation– Keep asking (probing) questions! – Goal Decomposition Techniques?

References and Acknowledgements

EGSOwww.egso.org

AEGIS (I Flechais, A Sasse)www.getrealsecurity.com/aegis.htm

Flechais et al in Proc. NSPW 2003

Goal Decomposition Techniques/ViewpointsAny other questions…

c.gryce@cs.ucl.ac.uk