1 / 26

Security Lessons from the EGSO Project An Experience Report

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?

iden
Download Presentation

Security Lessons from the EGSO Project An Experience Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

  8. 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” Asking Questions… “I’m hungry!” • Drive to the shops in the car • Order a take-away • Check the freezer • Invite yourself round to the neighbours BBQ

  9. CA 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. 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…

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

  14. 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)

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

  16. 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!

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

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

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

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

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

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

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

  24. 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?

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

More Related