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

2. Reminders….
Purpose of SVG "To minimize the risk to the EGI infrastructure arising from software vulnerabilities“
Wiki at
Checklist for selecting/writing software
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

3. Issue handling Reminder
Anyone may report an issue by to
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

4. 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.

5. 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

6. 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
Suggestions for further improvements welcome.

7. 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
No advisory needed
Possibly this is another part of the procedure.

8. Cloud Middleware Distribution CMD V1 now available
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
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.

9. 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

10. 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

11. Other Notes on Risk – needs updating – no progress yet