security vulnerability identification and reduction linda cornwal, jra1, brno 20 th june 2005...

Security VulnerabilityIdentification and

ReductionLinda Cornwal, JRA1, Brno

20th June 2005

[email protected]

20-Jun-05 Vulnerability reduction - Linda Cornwall -JRA1 Brno

2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

security vulnerability identification and reduction linda cornwal, jra1, brno 20 th june 2005...

Documents