Software Vulnerability Group Status update Linda Cornwall, STFC CSIRT F2F 17-19th Jan 2017 – Prague.

Reminders…. Purpose of SVG "To minimize the risk to the EGI infrastructure arising from software vulnerabilities“ Wiki at https://wiki.egi.eu/wiki/SVG Checklist for selecting/writing software https://wiki.egi.eu/wiki/SVG:Software_Security_Checklist Do we want to publicise this further? Or update? Main activity continues to be handling software vulnerabilities reported Advisories sent to sites and placed on the wiki

Issue handling Reminder 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

Advisories issued:-- Advisory is issued by SVG When the vulnerability is fixed if EGI SVG is the main handler of vulnerabilities for this software, or software is in an EGI Repository regardless of the risk. If the issue is ‘Critical’ or ‘High’ in the EGI infrastructure If we think there is a good reason to issue an advisory to the sites. Advisory is ‘Amber’ if:-- ‘High’ or ‘critical’ risk and information is not public There is some other reason to be Amber Usually ‘White’ after 2 weeks assuming it is fixed Otherwise usually white.

Numbers since start of 2016 (as of 12th January 2017) 41 reported issues in 2016 (4 already this year) 5 glite, 2 dCache, 6 kernel, 6 OS general, 6 Cloud enabling Risk – 6 ‘Critical’, 9 ‘High’, 10 ‘Moderate’ 26 advisories issued publicly 2016 table. (+ 2 this year already.) Since last CSIRT F2F meeting - 15 reported. At present 8 open tickets

Advisory Template Further minor revisions to the advisory template Most recently added the Context section Stating that the risk is in the context of the EGI infrastructure People may re-use if credit SVG. Also added some ‘skeleton’ references See https://wiki.egi.eu/wiki/SVG:General_Advisory_Template Suggestions for further improvements welcome.

Some other issues – deviation from procedure Ask sites to check – no risk assessment E.g. OpenStack Nova Metadata information leak Some vulnerabilities it’s enough for Enol/other Fed Cloud people to update in AppDB E.g. Docker escape vulnerability CVE-2016-9962 No advisory needed Possibly this is another part of the procedure.

Cloud Middleware Distribution CMD V1 now available http://repository.egi.eu/category/os-distribution/cmd-os-1/ This contains cloud enabling software on top of OpenStack Mitaka At present contains - Keystone-VOMS 9.0.3 - ooi 0.3.2 - gridsite 2.3.3 Cloud BDII Information provider 0.6.12 Openstack itself obtained from elsewhere (rather like OS) This will allow sites to easily install tools needed, AND SVG can handle in the same way as the UMD.

Other Cloud related VM Operator role got discussed again at FedCloud F2F at the end of November Some still not keen. I thought I’d won this battle in June 2016

Mailing lists related to Fed Cloud (Vincent) For the Critical Vulnerability handling & VA de-endorsement procedure, I think that we would need mailing lists for: VA owners + VA endorsers (Advisory) VM Operator (Advisory + de-endorsement notifications) For de-endorsement notification, it would be better to only notify people using it, but I don't think this is currently possible. But we do have VO security contacts via ops portal

Other Notes on Risk – needs updating – no progress yet https://wiki.egi.eu/wiki/SVG:Notes_On_Risk