1. Security Vulnerabilities Linda Cornwall, GridPP15, RAL, 11 th January 2006 L.A.Cornwall@rl.ac.uk

2. 11th January 2006Security Vulnerabilities - GridPP152 Introduction Getting started Reminder of the current strategy Status First order problems Plans for way forwards Discussion

3. 11th January 2006Security Vulnerabilities - GridPP153 Getting started Formed the Grid Security Vulnerability group to log and tackle Grid Security Vulnerability issues My aim was (and still is) to –Keep grids deployed –Avoid incidents by dealing with issues Far harder to get started than I expected! People couldn’t agree on disclosure policy People were worried about the legality Iterated our approach and got formal approval from LCG, EGEE and GridPP

4. 11th January 2006Security Vulnerabilities - GridPP154 Reminder of Strategy Joint activity between developers, sysadmins and any other deployment or security experts in LCG, GridPP and EGEE Log issues in Savannah, set Target Date usually 45 days Issues entered by anyone, it’s a general activity for any potential vulnerability whether known by sysadmins, developers, users, or anyone else. –Developers enter issues they know about –Includes information from internal knowledge –Includes impact of missing functionality which will not be available in the short term If an issue is still open on TD, distribute information including risk assessment to LCG security contacts –But the vulnerability group will not make issues public –Security contacts considered internal

5. 11th January 2006Security Vulnerabilities - GridPP155 Status – (Dec 2005) 48 members of the group 73 issues in there 4 closed as invalid/not a problem 1 closed as a duplicate 4 closed as they are fixed in LCG 2.6 1 patched 8 fixed or mitigated in EGEE 1.5 (still open) 49 reports sent out (some closed mostly still open) 14 open and no reports sent out –6 past target date Thanks to those who have put effort into the group, e.g. in analysing problems, risk assessments, entering issues

6. 11th January 2006Security Vulnerabilities - GridPP156 Overall Not enough effort put into tackling security vulnerability issues –Not enough appropriate effort for doing risk assessments and prioritising –Fixing security issues not given enough priority Many people more keen on criticizing the process than putting work into the process No manpower defined for security vulnerability issues envisaged at the beginning of EGEE or GridPP2 However, for EGEE2 this is envisaged as part of the plan

7. 11th January 2006Security Vulnerabilities - GridPP157 First order problems Not seeing enough issues closed –Not enough effort into solving issues Not blaming anyone –Priority is being given to increased functionality rather than security Some functionality does tackle security problems –Issues include things we know we are not fixing in the short term, e.g. no service authorization As issues are not closed, people don’t have enough confidence in the process, and there is a temptation to go public to force an issue –E.g. R-GMA pong servlet problem –Fortunately the pong servlet could be temporarily turned off –Not good for keeping grids deployed

8. 11th January 2006Security Vulnerabilities - GridPP158 First order problems (2) Management approval does not mean project wide agreement or management instruction to follow process or give work on vulnerability issues priority Many sysadmins will not participate unless we go for full public disclosure when an issue reaches the target date –Even though we have management approval for the way we do things Risk assessments often made by developers, who assume potential hackers will not find out how to exploit issues –I had hoped sysadmins would be involved in risk assessments, and hence that would provide pressure to solve the issues that they considered highest priority

9. 11th January 2006Security Vulnerabilities - GridPP159 First order problems- (3) Not enough participation/clarity of interface with operational security –Operational security people need to be involved Many members of the group only seem to be members in order to see what is going on –Don’t want to/ or don’t have time to do work –I don’t mind people being members for this reason. Half of me not really enough Tendency of many to take the attitude ‘the system isn’t perfect, therefore I’m not participating’ –But won’t improve without more participation/effort

10. 11th January 2006Security Vulnerabilities - GridPP1510 Where do we want to be in 1 year (or less)? Grids need to be far more secure –When LHC comes on line we really don’t want the Grid to be disrupted by hackers –The Grid includes a lot of storage, CPU and high speed network so will be attractive to hackers –We have a lot to loose if we get hacked Have to give security more priority, that includes fixing issues Most issues that are exploitable should be resolved –At least those that can be exploited by a user without authorization New issues that are identified resolved quickly

11. 11th January 2006Security Vulnerabilities - GridPP1511 Going forwards However we go forwards - dealing with vulnerability issues needs more effort –Analysing problems –Fixing things There needs to be an agreed strategy project wide on how we handle vulnerabilities between EGEE, LCG and GridPP –As well as Project management approval we need project agreement/instruction to follow process I intend to push forward establishing agreements and appropriate interfaces with the new Security Coordination Group (SCG) defined as part of EGEE2 Probably need vulnerability group meetings

12. 11th January 2006Security Vulnerabilities - GridPP1512 Risk Assessments Need a clear system for reliable risk assessments Need to do risk assessments early, so as to provide a better indication of priority Need the risk assessment to include a viewpoint that is independent of the developers of the middleware being assessed –Although developers are important for checking facts/reality Also set a Target Date according to risk Need appropriate people to carry out risk assessments, and put effort into the group, both in terms of knowledge and availability –Better than best efforts Will look at tools for risk assessments

13. 11th January 2006Security Vulnerabilities - GridPP1513 Evolving the process The other issue for going forwards is how to evolve and improve the process We have based the current process on –Issues known by developers as well as those identified by Users and operations people –Knowing many of these cannot be fixed quickly –This means all issues are in 1 place

14. 11th January 2006Security Vulnerabilities - GridPP1514 Exclude issues known by developers? The EGEE 2 proposal talks about the vulnerability group dealing with vulnerabilities identified by Grid Operations Groups and User communities –These could be handled as 1 activity –Don’t include issues known by developers (unless there is a fix likely to be available shortly) –Probably won’t include issues that are a matter of lack of functionality

15. 11th January 2006Security Vulnerabilities - GridPP1515 Public disclosure after Target Date? Many want public disclosure after Target date –Not make Savannah public, but provide information on a public web page –Or possibly a page accessible by those who have signed the EGEE terms Target date replaced by time for resolution, which can be long if an issue is hard to fix and hard to exploit –Set after a discussion between developers and security experts analysing the problem Management should probably decide which issues are made public. This morning’s discussion with favoured some sort of public disclosure, details to be resolved at a later date

16. 11th January 2006Security Vulnerabilities - GridPP1516 To Join e-mail myself to join the e-mail list –L.A.Cornwall@rl.ac.uk Request membership of the Grid Vulnerability Savannah by logging onto Savannah –https://savannah.cern.ch/projects/grid-vul/https://savannah.cern.ch/projects/grid-vul/

17. 11th January 2006Security Vulnerabilities - GridPP1517 Discussion Any comments? Who should do Risk assessments? Do sysadmins prefer to know early about a problem and keep information quiet? Do people prefer to move to public disclosure? –Which probably means not including issues identified by developers Can we continue to have a collaboration with developers and get things fixed more quickly Or would people prefer to see the sysadmins and users seen as customers and developers as being pressured to fix things?