E-Science Projects and Security

1. E-Science Projects and Security M. Angela Sasse & Mike Surridge

2. Who are we? • M. Angela Sasse, Department of Computer Science, University College London (UCL) • a.sasse@cs.ucl.ac.uk • Mike Surridge IT Innovation, University of Southampton • ms@it-innovation.soton.ac.uk • Members of the Security Task Force

3. Why are we here? • Previous STF work with projects unveiled raft of issues • Awareness of security issues • Perception • Management • Implementation

4. Security not high on agenda ‘Still early stages … going from requirements to design’ ‘Get it to work first, then we’ll worry about security.’ • ‘There are no security issues: all our data are public.’ • ‘This is just a proof of concept – no commercial implications.’

5. Perceptions & Attitudes

6. Management issues • Nobody in charge of security • Virtual organisations: no clear lines of communication or responsibility • Ad-hoc decision-making • Urban legends • Implicit assumptions: security is taken care of by others • people (sysadmin, other developers networking, computer centre, …) • technologies (Globus, firewalls, certificates, …)

7. Difficulties implementing security • Knowledge lacking or inaccurate • Threats • Countermeasures • Best practice • Developers and administrators feel overloaded • Conflicts with institutional regulations and mechanisms

8. Image problem • Projects vs. security • “security is used to prevent change” • bureaucrats, detached, “preach”, not helpful • projects have many questions, but don’t pursue them in a coherent manner or involve security experts • Security vs. projects • “users don’t care” • something that must be controlled

9. Policy Purpose • To promote best practice in security • in UK e-Science projects • in the UK e-Science Programme • To recognise and manage security risks from • distributed networked (grid) information systems • distributed, collaborative project management • newly discovered security problems in new grid or e-Science technology • The policy is part of the Programme’s overall security approach

10. Stipulations • Projects must adopt secure practices • commensurate with the risks they face • Project must • document their security policy and practices • undertake a detailed threat and risk analysis • ensure adequate resources to address threats • provide staff training where appropriate • keep up to date with security developments • Projects may be subject to audit • against their own security policy…

11. Project Security Policies • Must be commensurate with risks faced • driven by a project threat and risk analysis • not based on any “pre-ordained” security level • May need to address • policy and guidance from the Programme • legal obligations: health and safety, personal data protection • ethical frameworks: oversight committees, etc • specific security threats • actions to be taken if security is breached • community best-practice

12. Responsibility • Responsibility for the programme policy • UK e-Science Core Programme Directorate • advised by STF and TAG • Responsibility for project security • project Principal Investigator • aided by their project management team • Principal Investigator must • identify and address security roles • establish operational security contact points • ensure project security policy is maintained

13. Security Risk Management • Should drive project security policy • Requires identification of threats and risks • to project staff and associated personnel • to computer systems • to information • to relationships • to reputation • to the UK Programme • etc • Project security policy must address threats

14. Practical Security Workshop • Support for project PI’s and their teams • practical risk identification and management • practical advice on specific policy issues • disseminating best practice • Support for the UK Programme through STF • identifying security risks to the overall programme • identifying security risk management methods • identifying gaps in technology, processes and skills • disseminating best practice • The Programme must observe its policy too!

15. Purpose of Workshop • Help security projects to define their security needs • Share experiences, learn from each other • Introduce methods and tools (risk analysis and management) • First steps towards developing good practice • Identify training and support needs

16. Workshop Approach • Presentations • on risk identification and management • on project experiences • Breakout sessions • to identify project security risks • to identify appropriate security mechanisms • Results • greater awareness of types of risks and defences • understanding of best practice for projects • gaps and needs of the Programme

17. Overview Day 1 - morning 10.00 Registration and coffee 10.30 Welcome (Alan Robiette, Chair, Security Task Force for the e-Science Programme) 10.45 Workshop Introduction: e-Science projects and security (Mike Surridge, IT Innovation & Angela Sasse, UCL) 11.15 Understanding and managing risks (Jonathan Moffett, York University) 12.15 Lunch

18. Overview Day 1- afternoon 13.30 myGrid security issues (Luc Moreau, Southampton University) 14.30 Breakout sessions: Identifying risks in your projects (including tea at 15.30) 16.30 Reports from workshop groups 17.15 Security lessons from the EGSO Project (Clare Gryce, UCL) 18.00 Close 19.30 Dinner

19. Overview Day 2 09.00 Coffee 09.15 Managing security in the DAME Project (Howard Chivers, York University) 10.00 Breakout sessions: Managing risks in your projects (including coffee at 11.00) 12.30 Lunch 13.45 Reports from workshop groups 14.15 Establishing secure practices (Peter Ryan, Newcastle University) 15.00 Closing remarks: Security in e-Science projects -First steps in the right direction (Mike Surridge, IT Innovation & Angela Sasse, UCL)