1. Security Vulnerability Identification and Reduction Linda Cornwal, JRA1, Brno 20 th June 2005 L.A.Cornwall@rl.ac.uk

2. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno2 Introduction Why do we need to act? What are we protecting and preventing happening by addressing vulnerabilities? How to approach it Addressing Specific Vulnerability issues Discussion

3. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno3 Why do we need to act? We know some vulnerabilities are there, some are being fixed by developers, some are waiting to be exploited by hackers It will be really embarrassing if when LHC comes on line we get a serious attack on the grid system which prevents data being stored or processed Hackers Conference HOPE mentioned Grids –unfriendly people without credentials are becoming aware of us We are deploying real grids, no longer a research/proof of concept activity

4. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno4 What and who are we protecting? Protect the system –Ensure the system is available and working –Cannot be disrupted by an authorized user on purpose or by mistake –Cannot be disrupted by a hacker Protect data –Ensure it is stored in a reliable manner –Ensure it cannot be accessed by those who should not access it (Esp. Confidential data) Protect the user –We need to protect the user from being accused of doing something they did not do –We need to protect the user from doing something they did not intend to do (e.g. running up large bills)

5. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno5 What and who are we protecting? Protect others from our system –Prevent our system being used to crack a certificate by brute force –Prevent denial of service attacks from our system –Ensure it’s not used to store and distribute illegal material –If we don’t take care to address these issues we could find ourselves in serious trouble, it would be more than embarrassing, we may be considered criminally negligent for setting up these systems without sufficient protection Protect the system administrators –do not way to be accused of installing insecure software Protect those developing grid projects –don’t want to be accused of distributing software that has problems

6. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno6 3 way approach Recording known issues –Recording knowledge of specific vulnerabilities or potential vulnerabilities –Getting them dealt with –Most of the rest of this talk is about this Checklists –Things we need to take care of to minimize or avoid vulnerabilities –One for Middleware –One for Deployment –Already presented to MWSG Anti use cases –Use cases that should be prevented

7. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno7 Specific issue logging This is a sensitive issue –There has been a reluctance to write anything down because sysadmins will rightly want info, and then may not want to install the software It was agreed at the EGEE conference in Athens that we will form a vulnerability group to try and tackle specific vulnerability issues We can’t fix everything quickly, we know that Some people wanted all issues making totally public after a certain amount of time We can’t take the same approach as other projects, e.g. 45 days to fix, then things become completely public We want to ensure grids become more secure and keep them deployed

8. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno8 Purpose of Vulnerability group Inform developers and deployment people of vulnerabilities as they are identified, and encourage them to produce fixes or reduce their impact Aim is to keep grids deployed, keep appropriate people informed, not inform potential hackers, and fix problems It may be necessary to fix problems quickly if a problem is serious, in order to keep grid deployed This is not for incidents – if a vulnerability has been exploited it is handled by incident response Can be seen as incident prevention

9. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno9 Vulnerability organisation (1) Vulnerability group –Members have read and write access to the Savannah grid vulnerability project –Members log any problems they become aware of as bugs in the Grid Vulnerability Savannah –Non members may submit bugs, and they should receive feedback, but they may not read the database –Members may be members of the Grid vulnerability mailing list – which means they may write to the list. (It is not archived publically) –Problems or potential problems may be discussed on the mailing list

10. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno10 Vulnerability Organisation (2) Vulnerability Core –Manage membership of the vulnerability group –Ensure that appropriate people take responsibility for dealing with vulnerabilities Developers Deployment people Appropriate people to carry out risk assessments Information is passed on by appropriate people being members of the vulnerability group –Core group ensures appropriate people are taking action, typically by assigning the vulnerability ‘bug’ to an appropriate person and checking they are dealing with it.

11. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno11 Vulnerability group members Ask to join Are members of an appropriate Grid or e-science project (LCG, EGEE, GridPP…) Are known (first or second hand) to a member of the vulnerability core Should include e.g. –People involved in security policy –Deployment people –Loose Cannons –Developers (at least 2 per development cluster, e.g. MWSG members) –Regional Operational Centre Representatives – possibly should be included in Core group as they ‘know’ people

12. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno12 Process (1) Vulnerability bug is submitted in the Grid Vulnerability Savannah Group members look at it If there is a recommendation for immediate action, this is forwarded to sysadmins –At present via the project-lcg-security- contacts, better approach in work by OSCT

13. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno13 Process (2) If it concerns some EGEE middleware, a reference bug will be placed in jra1mw savannah, referring to the Grid Vulnerability bug but with no details. JRA1 will then be able to look at the problem –This allows bugs to be signed off and fixed in the jra1 procedure, but does not reveal details to potential hackers

14. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno14 Process (3) If the vulnerability cannot be solved in ~45 days inform appropriate deployment people and include risk assessment. –Again, initially project-lcg-security-contacts –But not to the general public If it has been solved, e.g. new software is available, of course pass information on (probably via the deployment process.) –Can be made public after giving time to update installations This is a compromise between going totally public and keeping things confidential

15. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno15 JRA1 involvement JRA1 clusters should be involved, obviously for fixing vulnerability bugs in appropriate MW At least 2 people per cluster should be members of the Grid Vulnerability group –E.g. MWSG member plus one other JRA1 members will probably also be involved in risk assessment

16. 20-Jun-05Vulnerability reduction - Linda Cornwall -JRA1 Brno16 Questions and discussion Are you happy with JRA1 procedure? Any comments? e-mail myself to join the e-mail list Request membership of the Grid Vulnerability Savannah by logging onto Savannah