Security Lessons from the EGSO Project
An Experience Report
Clare Gryce
University 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 mechanisms
SE03M
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”
or…
“ I need to get to the supermarket”
¾ Reasoning about requirements not clear
¾ ‘Solution Space’ constrained
Asking Questions…
why?
“ I need the car to drive to the shops” why?
“I need to get to the supermarket”
why?
“I need to get some food for dinner”
“I’m hungry!”
• Drive to the shops in the car
• Order a take-away
• Check the freezer
• Invite yourself round to the neighbours BBQ
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
…revolutionise the
both physically and virtually…
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
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@cs.ucl.ac.uk