
Update on EGI Software Vulnerability Group Procedures
Learn about the latest updates to the EGI Software Vulnerability Group's strategies and issue handling procedures to minimize risks to infrastructure due to software vulnerabilities. Details include handling reported vulnerabilities, risk assessments, resolution timelines, and advisory issuance processes.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
EGI SVG Strategy and issue handling procedure update Linda Cornwall, STFC OMB 27thJuly 2017 www.egi.eu This work by EGI.eu is licensed under a Creative Commons Attribution 4.0 International License Creative Commons Attribution 4.0 International License.
Purpose of the EGI Software Vulnerability Group (SVG) "To minimize the risk to the EGI infrastructure arising from software vulnerabilities". This document describes what SVG does to fulfil this Largest activity is handling software vulnerabilities reported Issue handling procedure is included in this document Includes a lot of details for SVG, software providers, reporters etc. Procedure itself will be on the wiki (will be placed in SEC02) Then people may refer to this document for more explanation EGI SVG Issue Handling update 8/26/2025 2
Main changes Small change to Critical/High risk boundary Detailed recommended steps for Critical risk vulnerabilities when fix not available. More on lack of homogeneity, and possible steps 4 different types of notification CMD handled similarly to UMD Improved the Software Checklist General improvement to descriptions Document at:-- https://documents.egi.eu/secure/ShowDocument?docid=3145 EGI SVG Issue Handling update 8/26/2025 3
Reminder - Basic Method of handling vulnerabilities reported Anyone may report an issue by e-mail to report-vulnerability@egi.eu If it has not been announced, SVG contacts the software provider and the software provider investigates (with SVG member, reporter, others) The relevance and effect in EGI are determined If relevant to EGI the risk in the EGI environment is assessed, and put in 1 of 4 categories Critical , High , Moderate or Low If it has not been fixed, Target Date (TD) for resolution is set - High 6 weeks, Moderate 4 months, Low 1 year Advisory is issued by SVG If the issue is Critical or High in the EGI infrastructure When the vulnerability is fixed if EGI SVG is the main handler of vulnerabilities for this software, or software is in EGI Repository regardless of the risk. If we think there is a good reason to issue an advisory to the sites. CSIRT monitors for Critical and High risk vulnerabilities EGI SVG Issue Handling update 8/26/2025 4
Critical/High boundary (1) If a vulnerability is considered Critical on the assumption that a exploit is publicly available In the past we have set to Critical if we expect this to happen in a day or two Now start as High with a warning that it is likely to become Critical , and then elevate to Critical if/when the exploit is made available. One case in 2016 where we went Critical=>High as exploit was not released EGI SVG Issue Handling update 8/26/2025 5
Critical/High boundary (2) If a vulnerability is considered Critical in middleware on the assumption that information is available publicly, and it s difficult to find, rather contrived Start as High Give people 4 weeks rather than 2 to patch when fixed Remove vulnerable versions from repositories Elevate to Critical if becomes public Critical becomes incident likely in coming days if no action is taken EGI SVG Issue Handling update 8/26/2025 6
Critical vulnerabilities especially where fix is not available Most vulnerabilities which are assessed as Critical are announced by the technology provider However some are not Zero day Those found and reported to EGI In the past we have said handle on case by case Now we have added steps which may be carried out Learnt from the VOMS Admin experience Makes it easier Includes telecon to discuss EGI SVG Issue Handling update 8/26/2025 7
Critical vulnerability Contacting management SVG may decide to contact management Makes sense to inform management if there is a critical vulnerability with widespread implications May ask management s opinion E.g. if more than 1 option E.g. Big risk to do nothing, major impact on infrastructure to stop a service But we should say what we recommend SVG s decision whether to contact management management has ultimate responsibility for security Delegated to the security teams EGI SVG Issue Handling update 8/26/2025 8
Less homogeneity Sometimes difficult to assess the risk Lack of SVG RAT knowledge We don t know the configuration at sites Option of Up to High risk advisory If we think its likely to be High for some configs in EGI Option of Alert rather than an advisory Alerting people to a problem, asking for feedback, not specifically advising people what to do. EGI SVG Issue Handling update 8/26/2025 9
4 types of e-mail HEADS UP Sites may be asked to do something urgently soon. Usually only for vulnerabilities which may be a Critical ADVISORY Sites instructed to do something The Commonest type of mail, e.g. update when vulnerability fixed in software ALERT Sites should be aware This may be important to you, you may want to take action. Often ask for feedback INFORMATION to inform sites of something E.g. if a well talked about vulnerability is not relevant EGI SVG Issue Handling update 8/26/2025 10
Federated Cloud EGI CMD is now live We handle vulnerabilities in this distribution in the same way as we do for the UMD VM endorser/Owner lists still needed VM Operator lists still needed. Some further improvement to Cloud vulnerability handling probably still needed Maybe later EGI SVG Issue Handling update 8/26/2025 11
Software Security Checklist List of things to consider for those selecting or writing software To help reduce the likelihood of security problems None guarantee security Still 9 points to consider This has been tidied Included reference to the EGI data protection policy EGI SVG Issue Handling update 8/26/2025 12
Not included Re-organisation of the document Some would prefer it to be shorter But info in it is useful, detailed description of what we do Done an update rather than re-write Further Co-operation with other infrastructures How do we do things jointly? We are working on this But do propose an e-mail list for WHITE information, which anyone can join AMBER later EGI SVG Issue Handling update 8/26/2025 13
In addition Sites should NOT be penalized for downtime due to carrying out requests from the security teams Updating software due to advisory Taking down services Any action requested by CSIRT More general than SVG EGI SVG Issue Handling update 8/26/2025 14
EGI SVG Issue Handling update 8/26/2025 15
Thank you for your attention. Questions? www.egi.eu This work by EGI.eu is licensed under a Creative Commons Attribution 4.0 International License Creative Commons Attribution 4.0 International License.