1. Security Lessons from the EGSO Project An 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 5 th 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 SE03MThe 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 I need to get to the supermarket Reasoning about requirements not clear Solution Space constrained or…

8. 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 Im hungry! I need to get to the supermarket why? I need to get some food for dinner why?

9. EGSO Security : Technology Hoping for a magic bullet –Assume a technology solution exists… –How to recognise it? CA

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

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@cs.ucl.ac.uk