Security Lessons from the EGSO Project An Experience Report

1
Security Lessons from the EGSO ProjectAn
Experience Report

• Clare Gryce
• University College London

2
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

3
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

4
EGSO The Application

• Virtual Solar Observatory
• Solar Scientists
• Solar Physicists
• Space Weather Community
• Astrophysicists
• Distributed, heterogeneous data archives

5
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

6
EGSO Security Specification 1

• User and Science Requirements Document
• High-level requirements
• Authorisation and Authentication
• Requirements partially specified by mechanisms

SE03M The system shall allow consumers to gain access to resources through user authorization
7
EGSO Security Specification 2

• Focussing on hows rather than whys

I need the car to drive to the shops
or
I need to get to the supermarket

• Reasoning about requirements not clear
• Solution Space constrained

8
Asking Questions
Im hungry!

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

9
EGSO Security Technology

• Hoping for a magic bullet
• Assume a technology solution exists
• How to recognise it?

10
EGSO Security Priorities

• Focus on Functional Requirements
• Non-functional requirements low priority
• Performance
• Usability
• Security
• get the system working first!
• Early demonstrations needed

11
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

12
(No Transcript)
13
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
14
AEGIS Benefits of Approach 2

• Systematic, reflective analysis of security
  issues
• Have to think about the whys
• Why do we think we need authorisation?
• What are we actually trying to achieve?
• Independent of hows (mechanisms)
• Semi-formal graphic representation
• Intuitive subset of UML
• Understood by all participants

15
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)

16
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

17
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!

18
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

19
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
?
?
20
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?

21
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?

22
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?

23
Research Indications

• Stakeholder modelling
• Model system stakeholders and their rships
• 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

24
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

25
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?

26
References and Acknowledgements

• EGSO
• www.egso.org
• AEGIS (I Flechais, A Sasse)
• www.getrealsecurity.com/aegis.htm
• Flechais et al in Proc. NSPW 2003
• Goal Decomposition Techniques/Viewpoints
• Any other questions
• c.gryce_at_cs.ucl.ac.uk