From dc34ceebd8b8c0e3561501d36078ce3e9f8d6e77 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 30 Sep 2024 15:33:03 +0200 Subject: [PATCH 01/18] Create scs-XXXX-v1-minimum-iaas-service-version.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...cs-XXXX-v1-minimum-iaas-service-version.md | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Standards/scs-XXXX-v1-minimum-iaas-service-version.md diff --git a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md new file mode 100644 index 000000000..0d66361d3 --- /dev/null +++ b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md @@ -0,0 +1,58 @@ +--- +title: Standard for the minimum IaaS services versions +type: Standard +status: Draft +track: IaaS +--- + +## Introduction + +The services, which build the IaaS Layer are, will and should be updated on a regular basis. +Older releases or versions of the software of these services may not receive updates anymore. +Those versions should not be used in deployments, so this standard will define how to determine, which versions may be used and which should not be used. + +## Terminology + +| Term | Explanation | +| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | +| CSP | Cloud Service Provider, provider managing the OpenStack infrastructure. | +| Compute | A generic name for the IaaS service, that manages virtual machines (e.g. Nova in OpenStack). | +| Network | A generic name for the IaaS service, that manages network resources (e.g. Neutron in OpenStack). | +| Storage | A generic name for the IaaS service, that manages the storage backends and virtual devices (e.g. Cinder in OpenStack). | + +## Motivation + +In software projects like e.g. OpenStack the software will be modified and receive bug fixes continously and will have releases of new versions on a regular basis. +Older releases will at some point not recieve updates anymore, because it would need to much developing persons to maintain more and more releases. +Thus older software, which may be used on the IaaS Layer, will eventually not receive security updates anymore. +This threatens the baseline security of deployments, which should be avoided under all circumstances. + +## Design Considerations + +OPTIONAL + +### Options considered + +#### _Option 1_ + +Option 1 description + +#### _Option 2_ + +Option 2 description + +### Open questions + +RECOMMENDED + +## Standard + +What is the essence of this standard? Adjust heading accordingly. + +## Related Documents + +Related Documents, OPTIONAL + +## Conformance Tests + +Conformance Tests, OPTIONAL From 913a775bdacd49dada3bb0887f2f01e6460d4385 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:55:01 +0200 Subject: [PATCH 02/18] First Draft of the Standard and Proposal of tests Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...cs-XXXX-v1-minimum-iaas-service-version.md | 53 +++++++++++++++---- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md index 0d66361d3..883ccd485 100644 --- a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md +++ b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md @@ -16,6 +16,7 @@ Those versions should not be used in deployments, so this standard will define h | Term | Explanation | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | CSP | Cloud Service Provider, provider managing the OpenStack infrastructure. | +| SLURP | Skip Level Upgrade Release Process - A Process that allows upgrades between two releases, while skipping the one in between them. | | Compute | A generic name for the IaaS service, that manages virtual machines (e.g. Nova in OpenStack). | | Network | A generic name for the IaaS service, that manages network resources (e.g. Neutron in OpenStack). | | Storage | A generic name for the IaaS service, that manages the storage backends and virtual devices (e.g. Cinder in OpenStack). | @@ -33,21 +34,52 @@ OPTIONAL ### Options considered -#### _Option 1_ +#### Only Allow th current versions of Software -Option 1 description +Considering that OpenStack as one provider of IaaS Layer Software has two releases per year, with one SLURP release per year, this option would require CSPs to update their deployment once or twice a year. +Updating a whole deployment is a lot of work and requires also good life-cycle management. +Following the SLURP releases would reduce this work to once per year. -#### _Option 2_ +While following new releases closely already provides a deployment with recent bug fixes and new features, it also makes developing standards easier. +Differences between releases will accumulate eventually and may render older releases at some point uncompliant to the scs-standards. -Option 2 description +On the other hand on the IaaS Level there aren't many breaking changes introduced by releases and also most standards will also work with older releases. +Security Updates and Bug fixes are also provided by OpenStack for a few older releases with the state `maintained`. +Additionally the [reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is cut by OpenStack. +Considering a CSP that wants to use only SLURP releases and waiting for the referene implementation will already be over a year or 2 releases behind, which cannot be considered as using the current version of IaaS Layer Software. +Thus this option can be dicarded. -### Open questions +#### Allow only maintained versions of Software -RECOMMENDED +While follwoing closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. +Following the reference implementation for example would also lead into being a little bit behind the newest release. +But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. +Which releases still are maintained is stated [here](https://releases.openstack.org/). -## Standard +Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. +Also CSPs that want to become scs-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become scs-compliant. +While this option should be at least recommended, it makes it hard for alternative IaaS Layer software, as those might have different release schedules. -What is the essence of this standard? Adjust heading accordingly. +#### Advise CSPs to maintain older or other versions of software + +CSPs may use releases of IaaS software, that are either not maintained anymore by an open source community or may be even closed source implementations of the mandatory IaaS APIs. +In the latter case the newest APIs may even be used, but the version number may differ from the OpenStack versions - expecially the microversions. +Detecting this is not easy, but would require to test specific API request, which were part of the last few releases. +An this will not show, whether security critical bugs are present or have been patched. + +Allowing older versions or closed source software would only be acceptable, when CSPs assure (e.g. in documentation), that they themself will patch the software within their deployments. +Security bug fixes must be implemented and proof of the fix then provided. +Only under that circumstances deployments with older or alternative IaaS Layer software, may be handled as compliant. + +This option seems to be a little bit too loose to actually advise using it, but when recommending the second option, this one could be used as a fall back. +And CSPs using OpenStack could even be encouraged to upgrade their deplyoments. + +## Standard for a minimum IaaS Layer Software version + +If OpenStack is used as implementation for IaaS Layer software the minimum version used SHOULD have the status `maintained`[^1]. +Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe and provide proof of that to the OSBA, so that the compliance will not be revoked. + +[^1]: [OpenStack versions and their current status](https://releases.openstack.org/) ## Related Documents @@ -55,4 +87,7 @@ Related Documents, OPTIONAL ## Conformance Tests -Conformance Tests, OPTIONAL +The conformance test need to check, whether an OpenStack microversion is used, that is part of a `maintained` release. +If that is not the case, it can be assumed that either an older OpenStack version or another software is used on the IaaS Layer. +In that case the test should give a Warning, because the CSP then has to provide proof, that all security relevant bugs are fixed. +So the test may check for a provided documented, which has a recent update date. From a2a2168d47eb3c3d539cc267587cdf775c8d0410 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 1 Oct 2024 13:48:37 +0200 Subject: [PATCH 03/18] change link Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-minimum-iaas-service-version.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md index 883ccd485..63d2d24b9 100644 --- a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md +++ b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md @@ -54,7 +54,7 @@ Thus this option can be dicarded. While follwoing closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. Following the reference implementation for example would also lead into being a little bit behind the newest release. But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. -Which releases still are maintained is stated [here](https://releases.openstack.org/). +Which releases still are maintained is stated [here](https://releases.openstack.org). Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. Also CSPs that want to become scs-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become scs-compliant. @@ -79,7 +79,7 @@ And CSPs using OpenStack could even be encouraged to upgrade their deplyoments. If OpenStack is used as implementation for IaaS Layer software the minimum version used SHOULD have the status `maintained`[^1]. Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe and provide proof of that to the OSBA, so that the compliance will not be revoked. -[^1]: [OpenStack versions and their current status](https://releases.openstack.org/) +[^1]: [OpenStack versions and their current status](https://releases.openstack.org) ## Related Documents From 1f28f0a0ea9dcde1cbcdfeb24c8ea184a666bfa9 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 1 Oct 2024 14:10:13 +0200 Subject: [PATCH 04/18] Update scs-XXXX-v1-minimum-iaas-service-version.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-minimum-iaas-service-version.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md index 63d2d24b9..57a19ea3b 100644 --- a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md +++ b/Standards/scs-XXXX-v1-minimum-iaas-service-version.md @@ -54,7 +54,7 @@ Thus this option can be dicarded. While follwoing closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. Following the reference implementation for example would also lead into being a little bit behind the newest release. But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. -Which releases still are maintained is stated [here](https://releases.openstack.org). +Which releases still are maintained can be looked up at the releases page from OpenStack[^1]. Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. Also CSPs that want to become scs-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become scs-compliant. From 356c603a11ec8b311d994dd99403dbf8f4529812 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Fri, 4 Oct 2024 14:29:02 +0200 Subject: [PATCH 05/18] Update and rename scs-XXXX-v1-minimum-iaas-service-version.md to scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...X-v1-security-of-iaas-service-software.md} | 68 ++++++++++++------- 1 file changed, 42 insertions(+), 26 deletions(-) rename Standards/{scs-XXXX-v1-minimum-iaas-service-version.md => scs-XXXX-v1-security-of-iaas-service-software.md} (54%) diff --git a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md similarity index 54% rename from Standards/scs-XXXX-v1-minimum-iaas-service-version.md rename to Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 57a19ea3b..2aa5e925c 100644 --- a/Standards/scs-XXXX-v1-minimum-iaas-service-version.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -1,5 +1,5 @@ --- -title: Standard for the minimum IaaS services versions +title: Standard for the security of IaaS service software type: Standard status: Draft track: IaaS @@ -7,9 +7,10 @@ track: IaaS ## Introduction +Software security relies on bug patches and security updates being available for specific versions of the software. The services, which build the IaaS Layer are, will and should be updated on a regular basis. -Older releases or versions of the software of these services may not receive updates anymore. -Those versions should not be used in deployments, so this standard will define how to determine, which versions may be used and which should not be used. +But older releases or versions of the software of these services may not receive updates anymore. +Unpatched versions should not be used in deployments as they are a security risk, so this standard will define how CSPs should deal with software versions and security updates. ## Terminology @@ -24,17 +25,18 @@ Those versions should not be used in deployments, so this standard will define h ## Motivation In software projects like e.g. OpenStack the software will be modified and receive bug fixes continously and will have releases of new versions on a regular basis. -Older releases will at some point not recieve updates anymore, because it would need to much developing persons to maintain more and more releases. -Thus older software, which may be used on the IaaS Layer, will eventually not receive security updates anymore. +Older releases will at some point not recieve updates anymore, because maintaining more and more releases requires too much manpower. +Thus older software will also eventually not receive security updates anymore. This threatens the baseline security of deployments, which should be avoided under all circumstances. ## Design Considerations -OPTIONAL +It would be possible to define a minimum version of IaaS Layer software to avoid security risks. +In the following paragraphs several options of defining a minimum version or dealing with security patches otherwise are discussed. ### Options considered -#### Only Allow th current versions of Software +#### Only Allow the current versions of Software Considering that OpenStack as one provider of IaaS Layer Software has two releases per year, with one SLURP release per year, this option would require CSPs to update their deployment once or twice a year. Updating a whole deployment is a lot of work and requires also good life-cycle management. @@ -46,48 +48,62 @@ Differences between releases will accumulate eventually and may render older rel On the other hand on the IaaS Level there aren't many breaking changes introduced by releases and also most standards will also work with older releases. Security Updates and Bug fixes are also provided by OpenStack for a few older releases with the state `maintained`. Additionally the [reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is cut by OpenStack. -Considering a CSP that wants to use only SLURP releases and waiting for the referene implementation will already be over a year or 2 releases behind, which cannot be considered as using the current version of IaaS Layer Software. -Thus this option can be dicarded. +Considering a CSP that wants to use only SLURP releases and waiting for the reference implementation will already be over a year or 2 releases behind, which cannot be considered as using the current version of IaaS Layer Software. +Thus this option can be discarded. #### Allow only maintained versions of Software While follwoing closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. Following the reference implementation for example would also lead into being a little bit behind the newest release. But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. -Which releases still are maintained can be looked up at the releases page from OpenStack[^1]. +All releases that are still maintained can be looked up at the releases page from OpenStack[^1]. Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. Also CSPs that want to become scs-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become scs-compliant. -While this option should be at least recommended, it makes it hard for alternative IaaS Layer software, as those might have different release schedules. -#### Advise CSPs to maintain older or other versions of software +One Problem is, that there might be new features implemented in the newest versions of the software, which are desired by other standards to be scs-compliant. +In that case allowing all maintained versions would lead to a two-year timespan customers would need to wait for before such a feature becomes available in all scs-compliant deployments. +In case of security relevant features this is not advisable. -CSPs may use releases of IaaS software, that are either not maintained anymore by an open source community or may be even closed source implementations of the mandatory IaaS APIs. -In the latter case the newest APIs may even be used, but the version number may differ from the OpenStack versions - expecially the microversions. -Detecting this is not easy, but would require to test specific API request, which were part of the last few releases. -An this will not show, whether security critical bugs are present or have been patched. +#### Standards implicitly define the minimum versions of Software +Instead of requiring a defined minimum software version, it could be derived from the standards. +Because: Whenever there is a new wanted behavior a standard should be created and a resonable timeframe given to CSPs to adopt a software version that can fulfill the new standard. +Through the combination of all standards that are in place, the minimum version for the IaaS service software is implicitly given. + +This would avoid to have conflicting versions of software in terms of feature parity, while also allowing older software. +Using this approach requires an additional advise to CSPs to update or implement patches for security issues. + +#### Advise CSPs to integrate software updates + +As long as maintained versions of software is used, updates with security patches are available and only need to be integrated. +This can and should be done in a reasonable short timeframe. + +But CSPs may even use releases of IaaS software, that are either not maintained anymore by an open source community or may be even closed source implementations of the mandatory IaaS APIs. Allowing older versions or closed source software would only be acceptable, when CSPs assure (e.g. in documentation), that they themself will patch the software within their deployments. Security bug fixes must be implemented and proof of the fix then provided. Only under that circumstances deployments with older or alternative IaaS Layer software, may be handled as compliant. -This option seems to be a little bit too loose to actually advise using it, but when recommending the second option, this one could be used as a fall back. +This option could be taken for granted, but to actually advise using it may encourage CSPs to take a closer look on their life-cycle management and security risk handling. And CSPs using OpenStack could even be encouraged to upgrade their deplyoments. ## Standard for a minimum IaaS Layer Software version -If OpenStack is used as implementation for IaaS Layer software the minimum version used SHOULD have the status `maintained`[^1]. -Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe and provide proof of that to the OSBA, so that the compliance will not be revoked. +If a maintained[^1] version of OpenStack is used as implementation for IaaS Layer software, security patches noted in OSSNs and OSSAs MUST be integrated within a reasonable timeframe. +Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe. -[^1]: [OpenStack versions and their current status](https://releases.openstack.org) +In both cases proof of the update MUST be send to the OSBA, so that the compliance will not be revoked. -## Related Documents +An open SBOM list MAY be used to propagate the current version of the software and may be used as proof of updates. -Related Documents, OPTIONAL +[^1]: [OpenStack versions and their current status](https://releases.openstack.org) ## Conformance Tests -The conformance test need to check, whether an OpenStack microversion is used, that is part of a `maintained` release. -If that is not the case, it can be assumed that either an older OpenStack version or another software is used on the IaaS Layer. -In that case the test should give a Warning, because the CSP then has to provide proof, that all security relevant bugs are fixed. -So the test may check for a provided documented, which has a recent update date. +In case of provided SBOMs the version numbers of the softwar could be checked. +But this is not a requirement, so there cannot be such a test. +Tests on the integration of security patches itself are difficult. +And even if tests for certain security issues are possible, then those might be received as an attack. +This is the reason there will be no conformance test. + +Rather the standard requiring that CSPs provide proof of the fixed vulnerabilites themself. From a3c796c2959f8fcf08e4d46fde8b800b62483012 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 8 Oct 2024 09:16:15 +0200 Subject: [PATCH 06/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 2aa5e925c..75a24b949 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -100,7 +100,7 @@ An open SBOM list MAY be used to propagate the current version of the software a ## Conformance Tests -In case of provided SBOMs the version numbers of the softwar could be checked. +In case of provided SBOMs the version numbers of the software could be checked. But this is not a requirement, so there cannot be such a test. Tests on the integration of security patches itself are difficult. And even if tests for certain security issues are possible, then those might be received as an attack. From 60c7d6188d701ec255fd9260dd02ab2da96e447b Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 8 Oct 2024 11:14:51 +0200 Subject: [PATCH 07/18] Create scs-XXXX-w1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...XX-w1-security-of-iaas-service-software.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Standards/scs-XXXX-w1-security-of-iaas-service-software.md diff --git a/Standards/scs-XXXX-w1-security-of-iaas-service-software.md b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md new file mode 100644 index 000000000..b9d29aaf7 --- /dev/null +++ b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md @@ -0,0 +1,40 @@ +--- +title: "SCS Standard for the security of IaaS service software: Implementation and Testing Notes" +type: Supplement +track: IaaS +status: Draft +supplements: + - scs-XXXX-v1-security-of-iaas-service-software.md +--- + +## Testing or Detecting security updates in software + +It is not always possible to automatically test, whether the software has the newest security updates. +This is because software versions may differ or some CSPs might have added downstream code parts or using other software than the reference. +Also vulnerabilites and their fixes are quite different in testing, some might not be testable while others are. +Additionally testing might be perceived as an attack on the infrastructure. +So this standard will rely on the work and information CSPs must provide. +There are different cases and procedures which are addressed in the following parts, that lead to compliance for this standard. + +### Procedure to become compliant to the security of IaaS service software Standard + +This is the procedure when a new deployment wants to achieve scs-conformancy. +There are two states such a deployment can be in: + +1. When a deployment is newly build or installed it usually uses software which includes all the latest security and bug fixes. +Such deployments should be considered compliant to the standard. + +2. When a CSP wants to make an older deployment compliant to the scs standards and thus also to this standard, it should be checked, whether the running software is up to date. +Any updates or upgrades to even newer versions should be done before the scs-compliance is checked. +Information about such updates or upgrade should be provided by the CSP. + +### Procedure when new Vulnerabilites are discovered + +Whenever there are new vulnerabilities discovered in IaaS service software like OpenStack there is either an internal discussion ongoing or it is just a smaller issue. +In the first case CSPs should have someone following such discussions and may even help preparing and testing patches. +From the moment on the vulnerability is announced it will be used by attackers. +So CSPs MUST watch out for announcements like in the OSSAs and OSSNs and when they are affected, update their deployment as soon as possible. + +Afterwards CSPs MUST provide proof, that they are not or not anymore affected by the vulnerabilty. +This can be done through either a manual test or through showing the updated software service version or showing configuration that renders the attack impossible. +It could also be provided a list of services, when the affected service is not used in that deployment. From a114d754ad6c90410c409483359112d83919ee8a Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 14 Oct 2024 11:38:44 +0200 Subject: [PATCH 08/18] Apply suggestions from code review Co-authored-by: Markus Hentsch <129268441+markus-hentsch@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...XX-v1-security-of-iaas-service-software.md | 30 +++++++++---------- ...XX-w1-security-of-iaas-service-software.md | 10 +++---- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 75a24b949..50cbbdb2a 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -8,7 +8,7 @@ track: IaaS ## Introduction Software security relies on bug patches and security updates being available for specific versions of the software. -The services, which build the IaaS Layer are, will and should be updated on a regular basis. +The services, which build the IaaS Layer should be updated on a regular basis based on updates provided by their respective authors or distributors. But older releases or versions of the software of these services may not receive updates anymore. Unpatched versions should not be used in deployments as they are a security risk, so this standard will define how CSPs should deal with software versions and security updates. @@ -24,10 +24,10 @@ Unpatched versions should not be used in deployments as they are a security risk ## Motivation -In software projects like e.g. OpenStack the software will be modified and receive bug fixes continously and will have releases of new versions on a regular basis. -Older releases will at some point not recieve updates anymore, because maintaining more and more releases requires too much manpower. +In software projects like e.g. OpenStack the software will be modified and receive bug fixes continuously and will receive releases of new versions on a regular basis. +Older releases will at some point not receive updates anymore, because maintaining more and more releases simultaneously requires too much manpower. Thus older software will also eventually not receive security updates anymore. -This threatens the baseline security of deployments, which should be avoided under all circumstances. +Using software which does not receive updates anymore threatens the baseline security of deployments and should be avoided under all circumstances. ## Design Considerations @@ -40,29 +40,29 @@ In the following paragraphs several options of defining a minimum version or dea Considering that OpenStack as one provider of IaaS Layer Software has two releases per year, with one SLURP release per year, this option would require CSPs to update their deployment once or twice a year. Updating a whole deployment is a lot of work and requires also good life-cycle management. -Following the SLURP releases would reduce this work to once per year. +Following only the SLURP releases would reduce this work to once per year. While following new releases closely already provides a deployment with recent bug fixes and new features, it also makes developing standards easier. -Differences between releases will accumulate eventually and may render older releases at some point uncompliant to the scs-standards. +Differences between releases will accumulate eventually and may render older releases non-compliant to the SCS standards at some point. On the other hand on the IaaS Level there aren't many breaking changes introduced by releases and also most standards will also work with older releases. Security Updates and Bug fixes are also provided by OpenStack for a few older releases with the state `maintained`. -Additionally the [reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is cut by OpenStack. +Additionally the [SCS reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is cut by OpenStack. Considering a CSP that wants to use only SLURP releases and waiting for the reference implementation will already be over a year or 2 releases behind, which cannot be considered as using the current version of IaaS Layer Software. Thus this option can be discarded. #### Allow only maintained versions of Software -While follwoing closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. -Following the reference implementation for example would also lead into being a little bit behind the newest release. +While following closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. +Following the SCS reference implementation for example would also lead into being a little bit behind the newest release. But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. All releases that are still maintained can be looked up at the releases page from OpenStack[^1]. Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. -Also CSPs that want to become scs-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become scs-compliant. +Also CSPs that want to become SCS-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become SCS-compliant. -One Problem is, that there might be new features implemented in the newest versions of the software, which are desired by other standards to be scs-compliant. -In that case allowing all maintained versions would lead to a two-year timespan customers would need to wait for before such a feature becomes available in all scs-compliant deployments. +One problem is, that there might be new features implemented in the newest versions of the software, which are desired by other standards to be SCS-compliant. +In that case allowing all maintained versions would lead to a two-year timespan customers would need to wait for before such a feature becomes available in all SCS-compliant deployments. In case of security relevant features this is not advisable. #### Standards implicitly define the minimum versions of Software @@ -76,16 +76,16 @@ Using this approach requires an additional advise to CSPs to update or implement #### Advise CSPs to integrate software updates -As long as maintained versions of software is used, updates with security patches are available and only need to be integrated. +As long as maintained versions of software are used, updates with security patches are available and only need to be integrated. This can and should be done in a reasonable short timeframe. But CSPs may even use releases of IaaS software, that are either not maintained anymore by an open source community or may be even closed source implementations of the mandatory IaaS APIs. Allowing older versions or closed source software would only be acceptable, when CSPs assure (e.g. in documentation), that they themself will patch the software within their deployments. Security bug fixes must be implemented and proof of the fix then provided. -Only under that circumstances deployments with older or alternative IaaS Layer software, may be handled as compliant. +Only under these circumstances deployments with older or alternative IaaS Layer software may be handled as compliant. This option could be taken for granted, but to actually advise using it may encourage CSPs to take a closer look on their life-cycle management and security risk handling. -And CSPs using OpenStack could even be encouraged to upgrade their deplyoments. +And CSPs using OpenStack could even be encouraged to upgrade their deployments. ## Standard for a minimum IaaS Layer Software version diff --git a/Standards/scs-XXXX-w1-security-of-iaas-service-software.md b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md index b9d29aaf7..bff375f2f 100644 --- a/Standards/scs-XXXX-w1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md @@ -18,21 +18,21 @@ There are different cases and procedures which are addressed in the following pa ### Procedure to become compliant to the security of IaaS service software Standard -This is the procedure when a new deployment wants to achieve scs-conformancy. +This is the procedure when a new deployment wants to achieve SCS-conformancy. There are two states such a deployment can be in: 1. When a deployment is newly build or installed it usually uses software which includes all the latest security and bug fixes. Such deployments should be considered compliant to the standard. -2. When a CSP wants to make an older deployment compliant to the scs standards and thus also to this standard, it should be checked, whether the running software is up to date. -Any updates or upgrades to even newer versions should be done before the scs-compliance is checked. +2. When a CSP wants to make an older deployment compliant to the SCS standards and thus also to this standard, it should be checked, whether the running software is up to date. +Any updates or upgrades to even newer versions should be done before the SCS compliance is checked. Information about such updates or upgrade should be provided by the CSP. -### Procedure when new Vulnerabilites are discovered +### Procedure when new vulnerabilites are discovered Whenever there are new vulnerabilities discovered in IaaS service software like OpenStack there is either an internal discussion ongoing or it is just a smaller issue. In the first case CSPs should have someone following such discussions and may even help preparing and testing patches. -From the moment on the vulnerability is announced it will be used by attackers. +From the moment on the vulnerability is disclosed publicly, the risk of it being actively exploited increases greatly. So CSPs MUST watch out for announcements like in the OSSAs and OSSNs and when they are affected, update their deployment as soon as possible. Afterwards CSPs MUST provide proof, that they are not or not anymore affected by the vulnerabilty. From 5278e77f69f0dc89be6c561850419fcd21cb5bf0 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 14 Oct 2024 14:23:19 +0200 Subject: [PATCH 09/18] rework glossary Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 50cbbdb2a..6a23bc2d1 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -18,9 +18,8 @@ Unpatched versions should not be used in deployments as they are a security risk | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | CSP | Cloud Service Provider, provider managing the OpenStack infrastructure. | | SLURP | Skip Level Upgrade Release Process - A Process that allows upgrades between two releases, while skipping the one in between them. | -| Compute | A generic name for the IaaS service, that manages virtual machines (e.g. Nova in OpenStack). | -| Network | A generic name for the IaaS service, that manages network resources (e.g. Neutron in OpenStack). | -| Storage | A generic name for the IaaS service, that manages the storage backends and virtual devices (e.g. Cinder in OpenStack). | +| OSSN | [OpenStack Security Note](https://wiki.openstack.org/wiki/Security_Notes) - security issues from 3rd parties or due to misconfigurations. | +| OSSA | [OpenStack Security Advisories](https://security.openstack.org/ossalist.html) - security issues and advices for OpenStack. | ## Motivation From 989cd0ef4cfd75ed40770bc52c5392f0bd4c5ed0 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 14 Oct 2024 14:58:45 +0200 Subject: [PATCH 10/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 6a23bc2d1..ea90e2d5a 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -88,8 +88,8 @@ And CSPs using OpenStack could even be encouraged to upgrade their deployments. ## Standard for a minimum IaaS Layer Software version -If a maintained[^1] version of OpenStack is used as implementation for IaaS Layer software, security patches noted in OSSNs and OSSAs MUST be integrated within a reasonable timeframe. -Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe. +If a deployment is affected by a security issue and a maintained[^1] version of OpenStack is used as implementation for IaaS Layer software, security patches noted in OSSNs and OSSAs MUST be integrated within a reasonable timeframe. +Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe, when the deplyoment is affected by a security issue. In both cases proof of the update MUST be send to the OSBA, so that the compliance will not be revoked. From 384078c073cdf71900f3fe640f04fc171630e3ba Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Fri, 18 Oct 2024 14:25:35 +0200 Subject: [PATCH 11/18] Apply suggestions from code review Co-authored-by: anjastrunk <119566837+anjastrunk@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index ea90e2d5a..19c5f5e43 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -25,8 +25,8 @@ Unpatched versions should not be used in deployments as they are a security risk In software projects like e.g. OpenStack the software will be modified and receive bug fixes continuously and will receive releases of new versions on a regular basis. Older releases will at some point not receive updates anymore, because maintaining more and more releases simultaneously requires too much manpower. -Thus older software will also eventually not receive security updates anymore. -Using software which does not receive updates anymore threatens the baseline security of deployments and should be avoided under all circumstances. +Thus older versions will also eventually not receive security updates anymore. +Using versions which do not receive updates anymore threatens the baseline security of deployments and should be avoided under all circumstances. ## Design Considerations From 1e104238e2e3d549b32be41fd7cbf8ec3408b1d3 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Fri, 25 Oct 2024 10:28:18 +0200 Subject: [PATCH 12/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...XX-v1-security-of-iaas-service-software.md | 28 ++++++++++++++++--- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 19c5f5e43..279501f01 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -86,16 +86,36 @@ Only under these circumstances deployments with older or alternative IaaS Layer This option could be taken for granted, but to actually advise using it may encourage CSPs to take a closer look on their life-cycle management and security risk handling. And CSPs using OpenStack could even be encouraged to upgrade their deployments. +#### What timeframe is needed to fix the issue? + +CSPs should be encouraged to fix security issues as fast as possible. +Some security issues are very easy to exploit so as soon as the vulnerability is disclosed attacks on deployments will start. +Other vulnerabilities may need much knowladge and more time to be exploited. +Also the impact of different vulnerabilites will differ. + +So it can be concluded that some security issues need to be fixed immediately while for others it is okay to take some time. +The BSI already has some guidance[^1] on how fast CSPs should response. +From the moment a vulnerability is disclosed these are the advised reaction times ranked by the severity of the vulnerability: + +1. Critical (CVSS = 9.0 – 10.0): 3 hours +2. High (CVSS = 7.0 – 8.9): 3 days +3. Mid (CVSS = 4.0 – 6.9): 1 month +4. Low (CVSS = 0.1 – 3.9): 3 months + +[^1]: [C5 criteria catalog with timeframes for responses on page 75.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Broschueren/C5_2020.pdf?__blob=publicationFile&v=3) + +This standard will follow this guidance and refer to these timeframes as "reasonable timeframes". + ## Standard for a minimum IaaS Layer Software version -If a deployment is affected by a security issue and a maintained[^1] version of OpenStack is used as implementation for IaaS Layer software, security patches noted in OSSNs and OSSAs MUST be integrated within a reasonable timeframe. -Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe, when the deplyoment is affected by a security issue. +If a deployment is affected by a security issue and a maintained[^2] version of OpenStack is used as implementation for IaaS Layer software, security patches noted in OSSNs and OSSAs MUST be integrated within a reasonable timeframe according to the severity of the security issue[^1]. +Otherwise the CSP MUST implement security bug fixes themself within a reasonable timeframe, when the deplyoment is affected by a security issue according to the severity of the security issue[^1]. -In both cases proof of the update MUST be send to the OSBA, so that the compliance will not be revoked. +In both cases a notice of the update MUST be send to the OSBA, so that the compliance will not be revoked. An open SBOM list MAY be used to propagate the current version of the software and may be used as proof of updates. -[^1]: [OpenStack versions and their current status](https://releases.openstack.org) +[^2]: [OpenStack versions and their current status](https://releases.openstack.org) ## Conformance Tests From 7d5818933ff73a2b1c87817c272dc32218a276a6 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Fri, 25 Oct 2024 10:31:43 +0200 Subject: [PATCH 13/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 279501f01..382c6ef1a 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -125,4 +125,4 @@ Tests on the integration of security patches itself are difficult. And even if tests for certain security issues are possible, then those might be received as an attack. This is the reason there will be no conformance test. -Rather the standard requiring that CSPs provide proof of the fixed vulnerabilites themself. +Rather the standard requiring that CSPs provide notice of the fixed vulnerabilites themself. From 447a5698dcfd182b2015b623c839268a7459f35e Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Fri, 25 Oct 2024 10:39:09 +0200 Subject: [PATCH 14/18] Update scs-XXXX-w1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...XXXX-w1-security-of-iaas-service-software.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/Standards/scs-XXXX-w1-security-of-iaas-service-software.md b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md index bff375f2f..3f0b1df8c 100644 --- a/Standards/scs-XXXX-w1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-w1-security-of-iaas-service-software.md @@ -24,17 +24,22 @@ There are two states such a deployment can be in: 1. When a deployment is newly build or installed it usually uses software which includes all the latest security and bug fixes. Such deployments should be considered compliant to the standard. -2. When a CSP wants to make an older deployment compliant to the SCS standards and thus also to this standard, it should be checked, whether the running software is up to date. -Any updates or upgrades to even newer versions should be done before the SCS compliance is checked. -Information about such updates or upgrade should be provided by the CSP. +2. When a CSP wants to make an older deployment compliant to the SCS standards and thus also to this standard, it should be checked, whether the running software is up to date and all vulnerabilites are fixed. +Any updates or upgrades to even newer versions should be done before the SCS compliance for every other standard is checked. +Afterwards the CSP may provide information about the used software in an SBOM or otherwise should provide a notice about the deployment having integrated all necessary vulnerability patches. ### Procedure when new vulnerabilites are discovered Whenever there are new vulnerabilities discovered in IaaS service software like OpenStack there is either an internal discussion ongoing or it is just a smaller issue. In the first case CSPs should have someone following such discussions and may even help preparing and testing patches. From the moment on the vulnerability is disclosed publicly, the risk of it being actively exploited increases greatly. -So CSPs MUST watch out for announcements like in the OSSAs and OSSNs and when they are affected, update their deployment as soon as possible. +So CSPs MUST watch out for announcements like in the OSSAs and OSSNs and when they are affected, update their deployment within the following timeframes according to the severity of the issue: -Afterwards CSPs MUST provide proof, that they are not or not anymore affected by the vulnerabilty. -This can be done through either a manual test or through showing the updated software service version or showing configuration that renders the attack impossible. +1. Critical (CVSS = 9.0 – 10.0): 3 hours +2. High (CVSS = 7.0 – 8.9): 3 days +3. Mid (CVSS = 4.0 – 6.9): 1 month +4. Low (CVSS = 0.1 – 3.9): 3 months + +Afterwards CSPs MUST provide a notice to the OSBA, that they are not or not anymore affected by the vulnerabilty. +This can be done through either telling, what patches were integrated or showing configuration that renders the attack impossible. It could also be provided a list of services, when the affected service is not used in that deployment. From e4e9d8efce973ee8ece654fd012d210dd4705cdc Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 28 Oct 2024 08:21:56 +0100 Subject: [PATCH 15/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- .../scs-XXXX-v1-security-of-iaas-service-software.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 382c6ef1a..31f2b6004 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -86,6 +86,12 @@ Only under these circumstances deployments with older or alternative IaaS Layer This option could be taken for granted, but to actually advise using it may encourage CSPs to take a closer look on their life-cycle management and security risk handling. And CSPs using OpenStack could even be encouraged to upgrade their deployments. +#### Dependencies of the IaaS Layer Software + +While the IaaS service software like OpenStack itself is monitored and security issues announced in OSSNs and OSSAs, these services have lots of dependecies, that are not monitored by the same entity. +When dependencies have security issues, there might be no OSSN or OSSA, so CSPs also need to watch CVEs concerning these dependencies themself. +Those dependencies must also be updated in a reasonable timeframe, when a security issue is disclosed. + #### What timeframe is needed to fix the issue? CSPs should be encouraged to fix security issues as fast as possible. @@ -113,6 +119,8 @@ Otherwise the CSP MUST implement security bug fixes themself within a reasonable In both cases a notice of the update MUST be send to the OSBA, so that the compliance will not be revoked. +If a deployment uses a dependency of the IaaS service software which is affected ba a security issue, this software also MUST be updated with security patches within a reasonable timeframe[^1]. + An open SBOM list MAY be used to propagate the current version of the software and may be used as proof of updates. [^2]: [OpenStack versions and their current status](https://releases.openstack.org) From 9d93a30cb840a88b33aa524a1113b70ad69492c7 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Mon, 28 Oct 2024 13:47:42 +0100 Subject: [PATCH 16/18] Update scs-XXXX-v1-security-of-iaas-service-software.md Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 31f2b6004..5807470ec 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -23,7 +23,9 @@ Unpatched versions should not be used in deployments as they are a security risk ## Motivation -In software projects like e.g. OpenStack the software will be modified and receive bug fixes continuously and will receive releases of new versions on a regular basis. +On the IaaS Layer the software, that needs to be considered in the scope of this standard, is mainly the APIs of IaaS Services. +Also there might be shared libraries and other dependencies, that could be considered part of the IaaS Layer. +In software projects like e.g. OpenStack that provide the main services and all APIs, the software will be modified and receive bug fixes continuously and will receive releases of new versions on a regular basis. Older releases will at some point not receive updates anymore, because maintaining more and more releases simultaneously requires too much manpower. Thus older versions will also eventually not receive security updates anymore. Using versions which do not receive updates anymore threatens the baseline security of deployments and should be avoided under all circumstances. From d136bba4ff4b51ff752958654dcbb0e53fce81d9 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Wed, 13 Nov 2024 09:42:12 +0100 Subject: [PATCH 17/18] Apply suggestions from code review Co-authored-by: Markus Hentsch <129268441+markus-hentsch@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- ...XX-v1-security-of-iaas-service-software.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index 5807470ec..ded34003d 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -47,28 +47,28 @@ While following new releases closely already provides a deployment with recent b Differences between releases will accumulate eventually and may render older releases non-compliant to the SCS standards at some point. On the other hand on the IaaS Level there aren't many breaking changes introduced by releases and also most standards will also work with older releases. -Security Updates and Bug fixes are also provided by OpenStack for a few older releases with the state `maintained`. -Additionally the [SCS reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is cut by OpenStack. -Considering a CSP that wants to use only SLURP releases and waiting for the reference implementation will already be over a year or 2 releases behind, which cannot be considered as using the current version of IaaS Layer Software. +Security updates and bug fixes are also provided by OpenStack for a few older releases with the state `maintained` according to the OpenStack releases overview[^2]. +Additionally the [SCS reference implementation](https://github.com/SovereignCloudStack/release-notes/blob/main/Release7.md) is integrating OpenStack releases after half a year - so about the time when a new release is published by OpenStack. +Considering a CSP that wants to use only SLURP releases and waits for the reference implementation to adopt them, will already lag over a year (i.e. 2 OpenStack releases) behind the latest release, this cannot be considered as using the current version of IaaS Layer Software. Thus this option can be discarded. #### Allow only maintained versions of Software While following closely to the newest releases could be advised, there are several downsides to requiring this workflow, even if it would be only for SLURP releases. -Following the SCS reference implementation for example would also lead into being a little bit behind the newest release. +Following the SCS reference implementation for example would also lead into being a little bit behind the newest OpenStack release. But this is not as bad as it may seem to be, because security related fixes and bug fixes are backported to older but still `maintained` releases. -All releases that are still maintained can be looked up at the releases page from OpenStack[^1]. +All releases that are still maintained can be looked up at the releases page from OpenStack[^2]. Allowing maintained versions would give CSPs a little bit more time to update and test their environments, while still receiving relevant security updates and bug fixes. -Also CSPs that want to become SCS-compliant may not have the burden to upgrade their deployments, but can test before an upgrade, where they need to put in additional work to become SCS-compliant. +Also CSPs that want to become SCS-compliant will not have to take on the burden to upgrade their deployments to very recent releases immediately, but can instead test with an existing release before an upgrade and identify where they need to put in additional work to become SCS-compliant. -One problem is, that there might be new features implemented in the newest versions of the software, which are desired by other standards to be SCS-compliant. +One problem is, that there might be new features implemented in the newest versions of the software, which are desired by other SCS standards to be SCS-compliant. In that case allowing all maintained versions would lead to a two-year timespan customers would need to wait for before such a feature becomes available in all SCS-compliant deployments. In case of security relevant features this is not advisable. #### Standards implicitly define the minimum versions of Software -Instead of requiring a defined minimum software version, it could be derived from the standards. +Instead of requiring a defined minimum software version centrally, it could be derived from the individual standards. Because: Whenever there is a new wanted behavior a standard should be created and a resonable timeframe given to CSPs to adopt a software version that can fulfill the new standard. Through the combination of all standards that are in place, the minimum version for the IaaS service software is implicitly given. @@ -91,18 +91,18 @@ And CSPs using OpenStack could even be encouraged to upgrade their deployments. #### Dependencies of the IaaS Layer Software While the IaaS service software like OpenStack itself is monitored and security issues announced in OSSNs and OSSAs, these services have lots of dependecies, that are not monitored by the same entity. -When dependencies have security issues, there might be no OSSN or OSSA, so CSPs also need to watch CVEs concerning these dependencies themself. +When dependencies have security issues, there might be no OSSN or OSSA, so CSPs also need to watch CVEs concerning these dependencies themselves. Those dependencies must also be updated in a reasonable timeframe, when a security issue is disclosed. #### What timeframe is needed to fix the issue? CSPs should be encouraged to fix security issues as fast as possible. Some security issues are very easy to exploit so as soon as the vulnerability is disclosed attacks on deployments will start. -Other vulnerabilities may need much knowladge and more time to be exploited. -Also the impact of different vulnerabilites will differ. +Other vulnerabilities may need much knowledge and more time to be exploited. +Also the impact of different vulnerabilities will differ. So it can be concluded that some security issues need to be fixed immediately while for others it is okay to take some time. -The BSI already has some guidance[^1] on how fast CSPs should response. +The BSI already has some guidance[^1] on how fast CSPs should respond. From the moment a vulnerability is disclosed these are the advised reaction times ranked by the severity of the vulnerability: 1. Critical (CVSS = 9.0 – 10.0): 3 hours @@ -121,7 +121,7 @@ Otherwise the CSP MUST implement security bug fixes themself within a reasonable In both cases a notice of the update MUST be send to the OSBA, so that the compliance will not be revoked. -If a deployment uses a dependency of the IaaS service software which is affected ba a security issue, this software also MUST be updated with security patches within a reasonable timeframe[^1]. +If a deployment uses a dependency of the IaaS service software which is affected by a security issue, this software also MUST be updated with security patches within a reasonable timeframe[^1]. An open SBOM list MAY be used to propagate the current version of the software and may be used as proof of updates. @@ -132,7 +132,7 @@ An open SBOM list MAY be used to propagate the current version of the software a In case of provided SBOMs the version numbers of the software could be checked. But this is not a requirement, so there cannot be such a test. Tests on the integration of security patches itself are difficult. -And even if tests for certain security issues are possible, then those might be received as an attack. +And even if tests for certain security issues are possible, then those might be interpreted as an attack. This is the reason there will be no conformance test. -Rather the standard requiring that CSPs provide notice of the fixed vulnerabilites themself. +Rather the standard requires that CSPs provide notice of the fixed vulnerabilites themselves. From 9a51b2f55af91c67b0c0efa96fb31538c34e9326 Mon Sep 17 00:00:00 2001 From: josephineSei <128813814+josephineSei@users.noreply.github.com> Date: Tue, 19 Nov 2024 15:11:11 +0100 Subject: [PATCH 18/18] Update Standards/scs-XXXX-v1-security-of-iaas-service-software.md Co-authored-by: Markus Hentsch <129268441+markus-hentsch@users.noreply.github.com> Signed-off-by: josephineSei <128813814+josephineSei@users.noreply.github.com> --- Standards/scs-XXXX-v1-security-of-iaas-service-software.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md index ded34003d..94b1200dd 100644 --- a/Standards/scs-XXXX-v1-security-of-iaas-service-software.md +++ b/Standards/scs-XXXX-v1-security-of-iaas-service-software.md @@ -110,7 +110,7 @@ From the moment a vulnerability is disclosed these are the advised reaction time 3. Mid (CVSS = 4.0 – 6.9): 1 month 4. Low (CVSS = 0.1 – 3.9): 3 months -[^1]: [C5 criteria catalog with timeframes for responses on page 75.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Broschueren/C5_2020.pdf?__blob=publicationFile&v=3) +[^1]: [C5 criteria catalog with timeframes for responses on page 70.](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CloudComputing/ComplianceControlsCatalogue/2020/C5_2020.pdf?__blob=publicationFile&v=3) This standard will follow this guidance and refer to these timeframes as "reasonable timeframes".