EGI SVG Strategy and issue handling procedure update

  • Slides: 16
Download presentation
EGI SVG Strategy and issue handling procedure update Linda Cornwall, STFC OMB 27 th

EGI SVG Strategy and issue handling procedure update Linda Cornwall, STFC OMB 27 th July 2017 www. egi. eu This work by EGI. eu is licensed under a Creative Commons Attribution 4. 0 International License.

Purpose of the EGI Software Vulnerability Group (SVG) • "To minimize the risk to

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 SEC 02) • Then people may refer to this document for more explanation 9/6/2021 EGI SVG Issue Handling update 2

Main changes • Small change to Critical/High risk boundary • Detailed recommended steps for

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/Show. Document? docid=3145 9/6/2021 EGI SVG Issue Handling update 3

Reminder - Basic Method of handling vulnerabilities reported • Anyone may report an issue

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 9/6/2021 EGI SVG Issue Handling update 4

Critical/High boundary (1) • If a vulnerability is considered ‘Critical’ on the assumption that

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 9/6/2021 EGI SVG Issue Handling update 5

Critical/High boundary (2) • If a vulnerability is considered ‘Critical’ in middleware on the

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 9/6/2021 EGI SVG Issue Handling update 6

Critical vulnerabilities – especially where fix is not available • Most vulnerabilities which are

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 9/6/2021 EGI SVG Issue Handling update 7

Critical vulnerability – Contacting management • SVG may decide to contact management • Makes

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 9/6/2021 EGI SVG Issue Handling update 8

Less homogeneity • Sometimes difficult to assess the risk – Lack of SVG RAT

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. 9/6/2021 EGI SVG Issue Handling update 9

4 types of e-mail • ‘HEADS UP’ – Sites may be asked to do

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 9/6/2021 EGI SVG Issue Handling update 10

Federated Cloud • EGI CMD is now live – We handle vulnerabilities in this

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 9/6/2021 EGI SVG Issue Handling update 11

Software Security Checklist • List of things to consider for those selecting or writing

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 9/6/2021 EGI SVG Issue Handling update 12

Not included • Re-organisation of the document – Some would prefer it to be

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 9/6/2021 EGI SVG Issue Handling update 13

In addition • Sites should NOT be penalized for downtime due to carrying out

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 9/6/2021 EGI SVG Issue Handling update 14

9/6/2021 EGI SVG Issue Handling update 15

9/6/2021 EGI SVG Issue Handling update 15

Thank you for your attention. Questions? www. egi. eu This work by EGI. eu

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.