Create a standard for the security of iaas service software

[josephineSei]

closes #749

[josephineSei]

We discussed today in the IaaS meeting, how to proceed.
The Conclusions were:

• expecting security patches to be deployed is reasonable for SCS-Compatible, but may be not easily possible to test
  -> this would need self-reports from CSPs in the reasonable timeframe, that they have updated their deployments
• SBOMs are part of SCS-Open and will give hints on both: overall software version and security patches
• behavior changes and/or must-have new API-endpoints should be done through standards with reasonable timeframe to become "mandatory"
  -> this means that a CSP will have to look through the standards and check, whether their used software version fulfill all standards
  -> the standards will have to be adjusted ob a regular basis
  -> we should think about also enabling another test for future requirements of standards (this means nearly all SHOULDS !)

This means I will rename the issue/PR and standard and will discard work on the tests, because the presence of security patches will not be easily testable.

[markus-hentsch]

Should we maybe consider cases here where vulnerabilities are not applicable to certain deployments? E.g. vulnerability concerns storage backend driver A whereas CSP is exclusively using storage backend driver B.
In such case, the update would not be a MUST for the CSP, in my opinion.

We should maybe put a preceeding step here to instruct the CSP to do an analysis first ASAP whether they are affected and if ...

• ... they are affected, they MUST apply the update and report having done so to SCS
• ... they are not affected, they MAY apply the update but MUST report a reasoning why they are not affected to SCS

[markus-hentsch]

Good first draft! I added some minor spelling/phrasing correction suggestions and some questions.
I think the topic is not easy and we will need to be careful about two matters in particular:

1. the timeframe/deadline imposed on CSPs to apply updates
2. the way CSPs report back to SCS/OSBA about their compliance concerning software versions

No. 1 needs to be a sweet spot between giving CSPs enough room to implement/test and being strict enough to ensure security in a meaningful way.

Regarding no. 2 we maybe could be a bit more precise or provide a template. Unless I have missed something this could currently range from hand-written letters to SBOM XML files that are gigabytes in size which no human can look through in a timely manner.

[anjastrunk]

What is a reasonable time? IMO, standard should be explicit here in order to guide CSPs.

How does customers know, whether or not a specific bug is fixed? Do we "force" CSPs to document software version/patch version somewhere?

[josephineSei]

I can only propose a timeframe, but this need to be discussed with CSPs. I think i will attend the lean operator coffee next monday to ask for their opinion.

[anjastrunk]

I'm afraid, this will result in a lot of paper work and bureaucracy no one wants to do.

[josephineSei]

That really is a problem:
We want to create standards that should be followed. Therefore we need tests.
But future CVEs or OSSNs cannot be known now and may be not easily testable. Should we consider writing a test for each of these vulnerabilities? This might be several tests a year to write, if a test from the outside is possible at all. And those tests might be considered as attacks (I mean they somehow are ;) ) and might trigger responses on the side of CSPs.

So a CSP giving notice about the fixing of a vulnerability, which already implicates, that we need to trust the CSP, could be an option. Maybe - if we already need to trust the CSPs - we may reduce the paper work:
MArkus suggested that there should be some kind of form file, that could be provided. We could do something like:

How did you deal with the vulnerability on your deployment XYZ:
[ ] Deployment was NOT affected, because ....... (e.g. we use another backend)
[ ] Functionality was disabled in the deployment.
[ ] Deployment was updated with a fix for the vulnerability, that .... (e.g. was provided be upstream openstack)

And only require short descriptions like above.
This may even be easier to evaluate in the compliance checker?

[anjastrunk]

I had a look to this standard, too. IMO the standard should dictate patch time explicitly, such as two weeks. Describing time passed between publishing a patch and applying it, should not be described softly, such as "very soon", "as soon as possible". The standards does not bring any value-added to customers, as everybody interprets these words differently.

Secondly, I'm not convinced of the process a CSP uses to proof a certain vulnerability is fixed. It looks like manual steps are required, which are error-prone and will delay process additionally. I prefer to develop an automatic process, e.g. using digital signatures.