1. Update on the Grid Security Vulnerability Group Linda Cornwall, MWSG7, Amsterdam 14 th December 2005 L.A.Cornwall@rl.ac.uk

2. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG72 Contents Reminder of current strategy Getting started Current status First order problems Improvements/changes Going forward to EGEE2 3 options Discussion

3. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG73 Reminder of strategy Joint activity between developers, sysadmins and any other deployment or security experts in LCG, GridPP, EGEE Log issues in Savannah, set target date usually 45 days If issue is still open on TD, distribute information including risk assessment to security contacts –But the vulnerability group will not make issues public –Security contacts considered internal Issues entered by anyone, it’s a general activity for any potential vulnerability whether known by sysadmins, developers, 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

4. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG74 Getting started My aim was (and still is) to –Keep grids deployed –Avoid incidents by dealing with issues Far harder than I expected! People couldn’t agree on disclosure policy People were worried about the legality Got formal approval of our approach from LCG, EGEE and GridPP

5. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG75 Current status (9 th Dec 2005) 73 issues in there 4 closed as invalid/not a problem 1 closed as a duplicate 4 closed as they are fixed in the current release 8 fixed or mitigated in 1.5 (still open) 1 emergency patch (after being placed on public list before being entered in our savannah!) 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. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG76 First order problems Not seeing enough issues closed –Not enough effort Not blaming anyone, no-one is funded to work on this apart from part of me! It is best efforts work –Priority is being given to increased functionality rather than vulnerability work Some functionality does tackle vulnerability problems –Issues include things we know we are not fixing in the short term, e.g. no service authorization

7. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG77 Sysadmins religious! Many sysadmins will not participate unless we go for full public disclosure when an issue reaches the target date This is a religious issue Sysadmins will preach, and not participate until they have converted us Even though we have management approval for the way we do things As issues are not closed, go public to force the issue –E.g. R-GMA pong servlet problem Also, suspect even if we solved the disclosure strategy there would be other problems with some of the sysadmins

8. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG78 First order problems- contd Although the Grid Security Vulnerability group has been formally approved, that does not mean that all members of LCG, EGEE and GridPP accept it as the way to deal with issues Not enough participation/clarity of interface with operational security –Operational security people need to be involved, and involved in decisions/priority Need to define the boundary of the activity –LCG, EGEE, GridPP deployment + EGEE MW –Can’t be all grids on all projects anywhere in the world

9. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG79 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 Possibly set a Target Date according to risk (max 90 days?) Who should do this? –JRA3? –OSCT? –Sysadmins? –?? Need a clear system for reliable risk assessments

10. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG710 Need to add impact As well as considering who can exploit, need to consider in what circumstances and the likely impact –Disrupt site/service –Major grid wide disruption –Gain access to resources –Gain confidential info –Disrupt other systems –….

11. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG711 If an issue is allocated to you 1.Quickly establish whether you are an appropriate person to allocate the issue to (if not, pass it on) 2.Carry out initial assessment, check its valid, check in what circumstances it applies 3.Check which versions it applies to 4.Consider whether urgent action is needed 5.Check category is set correctly 6.Submit mirror bug in JRA1? 7.(Risk assessment) 8.Track progress, fill in appropriate fields..

12. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG712 Going forward in EGEE2 There needs to be an agreed strategy project wide on how we handle vulnerabilities –Project management approval doesn’t mean project wide agreement Need clear interfaces between operational security people and the vulnerability group –Operational security people need to be involved I intend to push forward establishing agreements and appropriate interfaces with the new Security Coordination Group (SCG) defined as part of EGEE2 Need appropriate people to carry out risk assessments, both in terms of knowledge and availability –Better than best efforts Need to see issues solved

13. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG713 Going forward in EGEE2 (2) There will be a lot of pressure for public disclosure of vulnerability issues at the beginning of EGEE 2 (1 st April 2006) Security will have to have a higher priority That includes handling vulnerabilities The process should help us tackle issues, including prioritizing, not be a chore in itself I see 3 strategies for the Group in EGEE2

14. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG714 Strategies (1) Continue with the current model of not making information public but informing security contacts This has the advantages –Can be used as a general forum, including the recording impact of missing functionality –Developers will put issues in there they know about –Can inform security contacts early –All the information on all types of issues is in one place Disadvantage –Probably can’t persuade sysadmins to join in, due to religious problem

15. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG715 Split in 2! Maybe it is not possible to have a procedure where there is a collaboration between sysadmins and developers to identify, prioritize and solve issues. 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 –Follow a responsible disclosure policy – make public after Target Date –Probably wouldn’t include issues that arise from lack of functionality (e.g. no service authz)

16. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG716 Split in 2 (contd) Advantages –Would look better, more get fixed quickly –Only need public disclosure on issues that are identified by deployment people and users Disadvantages –Would not be somewhere where developers write issues into that they cannot fix quickly –Loose the ‘all the problems in 1 place’ –Developers would need to track progress on other issues separately (deployment people not included) –Priority would get given to issues identified by users or deployment people, whether or not they are the most serious

17. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG717 Allow long TD, public disclosure Continue with all issues in 1 place Allow public disclosure when issues reach target date Set the target date as Time for Resolution, agreed between deployment people and developers –which in cases like ‘No authz in x’ may be a long time (1 year or more) –Deployment /security operations people from group have final say on TD, and have strong involvement in the group Advantages –Might be acceptable to all Disadvantages –Issues in Savannah we don’t tell security contacts about for a long time.

18. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG718 Give security more priority Up the Game! Got away with a lot up to now due to –No financial gain –Friendly user base, no malicious users –Trustworthy sysadmins Can’t rely on security through obscurity –But we don’t want to advertise problems Can’t assume no malicious users forever Or sysadmins –E.g. User proxies on UIs –Bank manager should not be able to impersonate customers!

19. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG719 To Join – in case anyone hasn’t 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/

20. 14th Dec 2005Vulnerability group update - Linda Cornwall - MWSG720 Discussion How do we tackle risk assessments? Which of the 3 ways forwards for EGEE2 do you prefer? How would you feel if we went for public disclosure on 1 st April 2006 and everything in the Savannah went public? Any other questions/comments?