the grid services security vulnerability and risk assessment activity in egee-ii enabling grids for...

1
The Grid Services Security Vulnerability and Risk Assessment Activity in EGEE-II Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 http://www.gridpp.ac.uk/ gsvg/ The Grid Security Vulnerability Group (GSVG) Why the GSVG began The GSVG started work before the beginning of EGEE-II, using GridPP funded effort and some voluntary effort. It was noted that a lot was being done concerning Grid Security functionality, such as authentication and authorization, but little was being done to ask “is the Grid secure?” We were aware that the software isn’t perfect, that some vulnerabilities were in the process of being fixed and suspected that others were there waiting to be exploited. The Hackers conference HOPE has mentioned Grids, so unfriendly people (generally without credentials) are aware of us so “security through obscurity” cannot be relied upon. In EGEE-II the GSVG is a task within SA1, the Grid Operations Support and management activity. It is called the Grid Services Security Vulnerability and Risk Assessment Activity. The aim is “To incrementally make the Grid more secure and thus provide better availability and sustainability of the deployed infrastructure”. The main aim is to prevent Grid Security incidents. The handling of specific issues, which may be identified by anyone, is the main activity for this task. GSVG in EGEE-II Grid Security Vulnerability Issue handling An Issue is submitted Anyone can submit an issue The GSVG checks the validity and carries out a Risk Assessment According to an agreed strategy A Target Date for resolution is set according to Risk Assuming the issue results in a bug, using an agreed formula The issue is then in the hands of the Developers and the EGEE-II Engineering Management Team (EMT) The EMT co-ordinates the fixing of the issue and the release An advisory is issued when the problem is fixed or on the Target Date, whichever is the sooner When the issue is fixed the advisory is included in the release notes Risk Assessments Risk Assessments are carried out by the “Risk Assessment Team” or ”RAT”, which consists of various software security experts and experienced system administrators. A lot of work went into establishing the strategy for carrying out Risk Assessments, and many people were consulted including site security officers. Site security officers most fear an attack that gives access to the whole site, especially if it can by carried out anonymously. Denial of Service is considered no more than medium risk. A vulnerability that can be exploited by an authorized user is considered by most less serious than one that can be exploited without credentials, especially if actions are clearly logged. The possibility that credentials may be stolen cannot be ignored. Issues that can be exploited trivially and reliably are considered more serious than those that are harder to exploit or can only be exploited in rare circumstances. 4 Risk Categories Extremely Critical – Target Date = 2 days High – Target Date = 3 weeks Moderate – Target Date = 3 months Low – Target Date = 6 months Basic Interactions with other groups in EGEE-II Most issues of which we are informed are bugs in the middleware, which are handled by issuing a patch. Some are operational issues, which do not require a patch in the middleware – for these we issue an advisory to the Operational Security Co-ordination Team (OSCT). Some are more general issues, these are discussed with the EGEE-II technical co- ordination Group and the security Co-ordination group. Types of Grid Security Vulnerability issues Anyone! OSCT GSVG TCG EMT + developers SCG disclosure Operationa l issue Issue submission Security bug in middleware (most issues) Patch available with advisory Patch not available on Target Date Missing functionality and other general concerns are discussed with TCG and SCG Operational Security Coordination Team MiddleWare Security Group EUGridPMA Joint Security Policy Group Grid Security Vulnerability Group The GSVG is one of several security related activities in EGEE-II, and interacts with each of these activities. These activities are The Joint Security Policy Group (JSPG) which considers policy. The MiddleWare Security Group (MWSG) which considers architecture and security design and interoperability of the middleware, The Operational Security Co-ordination Team (OSCT) which considers operational issues, and the EUGridPMA which considers certificate handling and trust. The Chairs of these activities form the Security Co-ordination Group (SCG), which is responsible for ensuring overall security co-ordination. The goal is to ensure the relationship between the various security related work items does not overlap or leave gaps that could be exploited. What to do if you find a Grid Security Vulnerability This is what happens – to first order If you find a Grid Security vulnerability, or think you have found a vulnerability please send an e-mail to [email protected] Alternatively, if you are familiar with the LCG Savannah you may enter the issue as a ‘bug’ in the GSVG savannah at https://savannah.cern.ch/projects/grid-vul/ for obvious reasons these bugs are set to ‘private’ so you cannot browse these bugs The GSVG will investigate the issue, and inform you of the findings. We will also inform you of progress if the issue results in a software bug. Please refrain from discussing vulnerabilities on open mailing lists. Note that if a security vulnerability has been exploited it is considered to be an security incident, and should be reported according to the EGEE incident response procedure at http://lcg.web.cern.ch/LCG/activities/security/oper-security.html Author List Linda Cornwall (RAL), Stephen Burke (RAL), Vincenzo Ciaschini (INFN), Akos Frohner (CERN), David Kelsey (RAL), Oscar Koeroo (NIKHEF), Daniel Kouril (ICS), Kalman Kovari (KFKI-RMKI), Maarten Litmaath (CERN), Eygene Ryabinkin (RCC-KI), Ake Sandgren (HPC2N), John Walsh (TCD), Romain Wartel (CERN) CERN, CH-1211, Geneve 23, Switzerland HPC2N, Umea University, S-90187 Umea, Sweden ICS, Czech republic INFN, Instituto Nazionale di Fisica Nucleare, Italy KFKI-RMKI, Hungary NIKHEF The National Institute for Nuclear Physics and High Energy Physics, Kruislaan 409, 1098 Amsterdam, The Netherlands RAL, Science and Technology Facilities Council, The Rutherford Appleton Laboratory, Harwell Science and Innovation Campus, Didcot, OX11 OQX, England RCC-KI, Russia TCD, Trinity College, Dublin, Ireland Current Status of GSVG issue handling (30 th April 2007) Since the activity started a total 102 potential issues have been submitted, 53 are open, and 49 have been closed. S/W bugs are closed when a patch is issued, Operational issues are closed as soon as the OSCT has been informed. Many of the open S/W bugs have been fixed but are awaiting the next software release. 0 10 20 30 40 50 60 S/W bugs O perational G eneral Concerns Invalid D uplicates closed open

Upload: arron-hodges

Post on 16-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Grid Services Security Vulnerability and Risk Assessment Activity in EGEE-II Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688

The Grid Services Security Vulnerability and Risk Assessment Activity in EGEE-II

Enabling Grids for E-sciencE

EGEE-II INFSO-RI-031688 http://www.gridpp.ac.uk/gsvg/

The Grid Security Vulnerability Group (GSVG)

Why the GSVG beganThe GSVG started work before the beginning of EGEE-II, using GridPP funded effort and some voluntary effort. It was noted that a lot was being done concerning Grid Security functionality, such as authentication and authorization, but little was being done to ask “is the Grid secure?” We were aware that the software isn’t perfect, that some vulnerabilities were in the process of being fixed and suspected that others were there waiting to be exploited. The Hackers conference HOPE has mentioned Grids, so unfriendly people (generally without credentials) are aware of us so “security through obscurity” cannot be relied upon.

In EGEE-II the GSVG is a task within SA1, the Grid Operations Support and management activity. It is called the Grid Services Security Vulnerability and Risk Assessment Activity. The aim is “To incrementally make the Grid more secure and thus provide better availability and sustainability of the deployed infrastructure”. The main aim is to prevent Grid Security incidents. The handling of specific issues, which may be identified by anyone, is the main activity for this task.

GSVG in EGEE-II

Grid Security Vulnerability Issue handling

• An Issue is submitted

Anyone can submit an issue

• The GSVG checks the validity and carries out a Risk Assessment

According to an agreed strategy

• A Target Date for resolution is set according to Risk

Assuming the issue results in a bug, using an agreed formula

• The issue is then in the hands of the Developers and the EGEE-II Engineering Management Team (EMT)

The EMT co-ordinates the fixing of the issue and the release

• An advisory is issued when the problem is fixed or on the Target Date, whichever is the sooner

When the issue is fixed the advisory is included in the release notes

Risk AssessmentsRisk Assessments are carried out by the “Risk Assessment Team” or ”RAT”, which consists of various software security experts and experienced system administrators. A lot of work went into establishing the strategy for carrying out Risk Assessments, and many people were consulted including site security officers. Site security officers most fear an attack that gives access to the whole site, especially if it can by carried out anonymously. Denial of Service is considered no more than medium risk. A vulnerability that can be exploited by an authorized user is considered by most less serious than one that can be exploited without credentials, especially if actions are clearly logged. The possibility that credentials may be stolen cannot be ignored. Issues that can be exploited trivially and reliably are considered more serious than those that are harder to exploit or can only be exploited in rare circumstances.

4 Risk Categories• Extremely Critical – Target Date = 2 days

• High – Target Date = 3 weeks

• Moderate – Target Date = 3 months

• Low – Target Date = 6 months

Basic Interactions with other groups in EGEE-II

Most issues of which we are informed are bugs in the middleware, which are handled by issuing a patch. Some are operational issues, which do not require a patch in the middleware – for these we issue an advisory to the Operational Security Co-ordination Team (OSCT). Some are more general issues, these are discussed with the EGEE-II technical co-ordination Group and the security Co-ordination group.

Types of Grid Security Vulnerability issues

Anyone!

OSCT

GSVG

TCG

EMT +developers

SCG disclosure

Operational issue

Issue submission

Security bug in middleware (most issues)

Patch available with advisory

Patch not available on Target Date

Missing functionality and other general concerns are discussed with TCG and SCG

OperationalSecurity

CoordinationTeam

MiddleWareSecurityGroup

EUGridPMA

JointSecurityPolicyGroup

GridSecurity

VulnerabilityGroup

The GSVG is one of several security related activities in EGEE-II, and interacts with each of these activities. These activities are The Joint Security Policy Group (JSPG) which considers policy. The MiddleWare Security Group (MWSG) which considers architecture and security design and interoperability of the middleware, The Operational Security Co-ordination Team (OSCT) which considers operational issues, and the EUGridPMA which considers certificate handling and trust. The Chairs of these activities form the Security Co-ordination Group (SCG), which is responsible for ensuring overall security co-ordination. The goal is to ensure the relationship between the various security related work items does not overlap or leave gaps that could be exploited.

What to do if you find a Grid Security Vulnerability

This is what happens – to first order

If you find a Grid Security vulnerability, or think you have found a vulnerability please send an e-mail to [email protected]

Alternatively, if you are familiar with the LCG Savannah you may enter the issue as a ‘bug’ in the GSVG savannah at https://savannah.cern.ch/projects/grid-vul/ for obvious reasons these bugs are set to ‘private’ so you cannot browse these bugs

The GSVG will investigate the issue, and inform you of the findings. We will also inform you of progress if the issue results in a software bug.

Please refrain from discussing vulnerabilities on open mailing lists.

Note that if a security vulnerability has been exploited it is considered to be an security incident, and should be reported according to the EGEE incident response procedure at

http://lcg.web.cern.ch/LCG/activities/security/oper-security.html

Author List

Linda Cornwall (RAL), Stephen Burke (RAL), Vincenzo Ciaschini (INFN), Akos Frohner (CERN), David Kelsey (RAL), Oscar Koeroo (NIKHEF), Daniel Kouril (ICS), Kalman Kovari (KFKI-RMKI), Maarten Litmaath (CERN), Eygene Ryabinkin (RCC-KI), Ake Sandgren (HPC2N), John Walsh (TCD), Romain Wartel (CERN)

CERN, CH-1211, Geneve 23, Switzerland

HPC2N, Umea University, S-90187 Umea, Sweden

ICS, Czech republic

INFN, Instituto Nazionale di Fisica Nucleare, Italy

KFKI-RMKI, Hungary

NIKHEF The National Institute for Nuclear Physics and High Energy Physics, Kruislaan 409, 1098 Amsterdam, The Netherlands

RAL, Science and Technology Facilities Council, The Rutherford Appleton Laboratory, Harwell Science and Innovation Campus, Didcot, OX11 OQX, England

RCC-KI, Russia

TCD, Trinity College, Dublin, Ireland

Current Status of GSVG issue handling

(30th April 2007) Since the activity started a total 102 potential issues have been submitted, 53 are open, and 49 have been closed. S/W bugs are closed when a patch is issued, Operational issues are closed as soon as the OSCT has been informed. Many of the open S/W bugs have been fixed but are awaiting the next software release.

0

10

20

30

40

50

60

S/W bugs Operational GeneralConcerns

Invalid Duplicates

closed

open