Software Vulnerability Group Vulnerability issue handling Procedure update

Software Vulnerability Group – Vulnerability issue handling Procedure update Linda Cornwall, STFC EGI OMB 30 th July 2015 www. egi. eu EGI-Engage is co-funded by the Horizon 2020 Framework Programme of the European Union under grant number 654142

Contents Purpose of SVG Why we need a procedure update Checklist for those writing or selecting software Selected changes including to responsible disclosure • Some points concerning Virtual Machines • Still to do • • 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 2

Purpose of SVG "To minimize the risk to the EGI infrastructure arising from software vulnerabilities“ 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 3

New software vulnerability issue handling procedure • New procedure is at: https: //documents. egi. eu/secure/Show. Document? docid=2538 not public (yet) • Main purpose of this talk today is to ask for comments/feedback – Some of the changes presented today • Later after a little more iteration will ask for approval • Probably revise again in 2016 after a few months use 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 4

Main reasons for updating the procedure • Previous focus was largely on Grid Middleware – SVG members had quite a lot of expertise on this • Technology is changing – Especially the emergence of the EGI Federated Cloud • A wider variety of software is being deployed – Cloud enabling software, software within VMs, VMs themselves – VO specific software – Other software deployed on sites – Some commercial, some which is produced by our collaborators – SVG members can’t be expert in everything 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 5

Security Checklist for software • SVG cannot dictate what software is deployed on the EGI infrastructure – Nor do we have the manpower to do an assessment on all software people want to deploy – But want to continue to minimize security problems • Those developing and/or selecting software for deployment should consider security – So we provide a checklist to help – see document – A lot of emphasis is in security support – This is more lightweight than the TP questionnaire 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 6

Principles of vulnerability handling remain (roughly) the same • Issue handling carried out by the SVG Risk Assessment team (RAT) – RAT members have access to information on 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 • Then 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 – When vulnerability is fixed if EGI SVG IS the main handler of vulnerabilities for this software, or software is in EGI UMD regardless of the risk. – If the issue is ‘Critical’ or ‘High’ in the EGI infrastructure 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 7

What else has changed over the years • SVG and CSIRT have worked more closely together – Incident Response Task Force (irtf) members who take an operational security duty are also in the RAT • Can act if there is something serious/critical that can't wait • No longer need to distinguish between CSIRT alerts and SVG advisories – This also means we are acting more in interest of infrastructure • So making vulnerabilities public if they are not fixed on the TD is often not in our interest. • Propose modification to the ‘responsible disclosure’ 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 8

If issues not fixed by TD • Change from previous ‘responsible disclosure’ – Where we (said we would) release advisory on TD • Contact software provider – Remind them issue is near (or past) TD • If no satisfactory response and ‘High’ risk – If more than 1 week past the TD, SVG will escalate to management – Advisory may be released to sites as ‘Amber’ and remain ‘Amber’ until a satisfactory solution found • If ‘Moderate’ or ‘Low’ – Release 1 month after TD – Possibly delay if a software release is imminent 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 9

Some other changes • No longer set 3 day Target Date for ‘Critical’ issues – Handle on a case by case basis – Most are publicly announced after they have been fixed anyway • For ‘High’ and ‘Critical’ issues if information is not public advisory sent to sites as ‘AMBER’ – made public on wiki at least 2 weeks later • Less manpower, sometimes having to process vulnerabilities with only 2 opinions on the risk 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 10

Policy violation issues • For vulnerabilities which are Policy violations, Risk Assess but don’t set TD • SPG and management handle • E. g. publicly readable DN vs usage of resources • A few of these recently – useful for logging purposes but doesn’t comply with data protection legislation • We don’t inform sites (yet) 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 11

Endorsed VM issues • VM Endorser should consider the checklist before including software • A bad endorsed image is seen as a vulnerability with the VM Endorser as the Technology Provider if – It is a case of a misconfigured VM image (e. g. containing passwords, private keys etc. ) – It is case of including vulnerable non-standard, poorly maintained software • A bad endorsed image is seen more like a site if – Security updates have not been applied Running VMs based on vulnerable endorsed VMs are likely to be treated by IRTF in a similar way to other vulnerabilities exposed in the infrastructure, according to risk 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 12

VM Operator issues • The VM Operator is responsible for any software added on contextualization or later in the lifecycle of the VM – Should consider the checklist • The VM Operator is responsible for ensuring security patches are correctly applied • Found that VM Operator is not a special role within VOs – Thousands can become VM Operators – Consider risk in security threat RA 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 13

Contacts for VM Endorsers and VM operators • VM Endorsers and VM Operators all need to ensure that they are not installing vulnerable software – Should receive advisories on Critical and High risk vulnerabilities from SVG – We need to be able to send advisories to them • How this is done is TBD, lists not available • Possibly for now use the VO security contacts we recognised as needed a couple of years ago – For ‘Amber’ can’t send to VO security contacts and then ask all to distribute to all members • That would be too wide 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 14

RAT Members • No ‘Observers’ or ‘for interest’ only active people added • Currently 29 RAT members – 3 -4 do most of the work in running process – Others include prolific reporters, experts on some software, people who are good at investigating but don’t give an opinion on risk – All IRTF members – Fed Cloud people 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 15

Still lots to do • Update RT fields, templates etc. • Contact details – SW providers, VOs, How to contact VM endorsers and VM operators • Update wiki with some details • Update To. R • Update TP questionnaire 11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 16

11/3/2020 SVG procedure update for OMB –July 2015 – Linda Cornwall 17

Thank you for your attention. Questions? www. egi. eu This work by Parties of the EGI-Engage Consortium is licensed under a Creative Commons Attribution 4. 0 International License.