Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The EGI Software Vulnerability Group (SVG)

...

Purpose of the EGI Software Vulnerability Group (SVG)

'To minimize the risk of is "To minimise the risk to the EGI infrastructure arising from software vulnerabilities“.This has been recently updated to say "To minimise the risk to all service providers, infrastructures, users and other parties which interact with the EOSC-hub, arising from vulnerabilities in software deployed on the constituents of the distributed infrastructure. In essence, to minimise the risk of security incidents due to software vulnerabilities."'

What does the EGI Software Vulnerability Group (SVG) do?

The largest activity is the running of We provide some information onSVG Scope in the ESOC era.The EGI SVG runs a procedure for handling software vulnerabilities reported which are relevant to the EGI infrastructure. This includes vulnerabilities announced by major providers, as well as vulnerabilities in software which is developed by collaborating projects and organisations used in the EGI infrastructure. This includes software used to enable the sharing of distributed resources.

SVG handles vulnerabilities according to the EGI Software Vulnerability Issue Handling Process and our issue handling summary contains a brief summary of this process.

Advisories  are issued by SVG as part of this process.

The EGI Operations Management Board (OMB) has formally approved the EGI Software Vulnerability Issue Handling Process.

However, this procedure is at present undergoing major revision. (Oct 2020)

Intel and other processor speculative execution vulnerabilities (including Meltdown and Spectre)

Here SVG provides information that may be useful to various sites concerning the various SVG Speculative execution vulnerabilities

Software for use on the EGI infrastructure

SVG cannot dictate what software is in use on the infrastructure, especially in the rapidly changing environment.

If you are involved in selecting software for use in the EGI infrastructure, or developing software for use in the EGI infrastructure it is important that you take some of the responsibility for the security of that software.

To help, we have produced a Software Security Checklist of things that you should consider.

These are usually initially only sent to sites, and only published publicly at least 4 weeks after fixes are available to sites. 

The EGI SVG collaborates with other partners to identify vulnerabilities and share information on vulnerabilities, in particular OSG

All those involved in the selection and deployment of software are strongly encouraged to be aware of software security, be aware that software deployed should be under security maintenance and configured in a secure manner. We provide a Software Security Checklistto help with this.

Developers are strongly encouraged to write secure code, we provide some information and links on Secure Coding 

SVG also provides consultation on software vulnerabilities to the CSIRT team and other EGI groups.

Some information on Why do we need an an SVG?You may also be interested in joining the Deployment Expert Group. (DEG)

What if you find a software vulnerability?

If you discover or become aware of a software vulnerability which is relevant to EGI,

Report it to report-vulnerability (at) egi.eu

This should be done whether it is a publicly announced vulnerability or a vulnerability you have discovered or become aware of.

This ensures SVG is aware of them, and able to assess the impact.

If it has not been announced publicly: --

...

DO NOT publicise in any way - e.g. to the media

IMMEDIATELY Report it to report-vulnerability (at) egi.eu

Vulnerabilities announced publicly may be reported to this address too, which may be serious either to EGI, EUDAT, or other services in the EOSC-hub catalogue. This ensure SVG is aware of them, and able to assess the impact.

See Reporters View

Main Tasks of the EGI Software Vulnerability Group

  • Provide an efficient process to report, handle, and resolve software vulnerabilities in software used in the EGI infrastructure.

This is the largest activity of the EGI SVG.

  • Provide consultation on software vulnerabilities to the CSIRT team and other EGI groups.
  • Collaborate with other partners to identify vulnerabilities, and share information on vulnerabilities.
  • Encourage developers to write secure code, thus reducing the likelihood of future problems, by education and awareness.
  • Encourage all those involved in the selection and deployment of software to be aware of security, aware that software deployed should be under security maintenance and configured in a secure manner.

It is also important that you do not discuss publicly announced vulnerabilities relevance to and impact on EGI publicly.

Security Incidents

If a vulnerability has been exploited, it is an incident, and is NOT handled by the EGI Software Vulnerability Group.

You should then follow the EGI CSIRT Incident Handling Procedure

Also see the CSIRT Incident reporting

Several people are in both the EGI Incident Response Task Force as well as the Software Vulnerability group, so sending to either will probably get forwarded fairly quickly to the right people.

The Software Vulnerability Issue Handling process

The EGI Software Vulnerability issue handling summary contains a brief summary of the issue handling process, and links to further information.

This has been updated and updates approved by the Operations Management Board in December 2015, further updated and updates approved by the OMB in November 2017.

This is undergoing revision at time of writing, to cope with the increased inhomogeneity of the infrastructure.

Other activities

Vulnerability Assessment is the proactive examination of software in order to find vulnerabilities that may exist. At present there is no funding to carry out this activity.

The SVG also encourages developers to write Secure Code Secure Coding

A poster is available summarising the work of SVG PosterSVG-2011.pdf (This is a little old, and rather focussed on Grid Middleware)