Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document certification issuing process #356

Merged
merged 18 commits into from
Jan 12, 2024
Merged

Document certification issuing process #356

merged 18 commits into from
Jan 12, 2024

Conversation

mbuechse
Copy link
Contributor

@mbuechse mbuechse commented Oct 6, 2023

Resolves #337 and #346.
Supersedes #239.

@mbuechse
Copy link
Contributor Author

mbuechse commented Oct 9, 2023

See also the rendered version

Copy link
Contributor

@josephineSei josephineSei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only have one bigger point, that maybe should be discussed in a meeting. Its about the interval of the tests repeated.

Standards/scs-xxxx-v1-achieving-certification.md Outdated Show resolved Hide resolved
Standards/scs-xxxx-v1-achieving-certification.md Outdated Show resolved Hide resolved
Standards/scs-xxxx-v1-achieving-certification.md Outdated Show resolved Hide resolved
Standards/scs-xxxx-v1-achieving-certification.md Outdated Show resolved Hide resolved
@neuroserve
Copy link

At point two I'd expect a link/reference to the (valid/versioned) "SCS compliance test suite". Same for the basis of the "classification" (e. g. what is meant by "light", "medium" and "heavy").

Copy link
Member

@frosty-geek frosty-geek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added my 2¢ but overall LGTM either way


3. If the desired certificate requires manual checks, then the operator MUST offer the SCS project suitable access. Manual checks MUST be repeated once every 3 months.

4. Details on the standards achieved, as well as the current state and the history of all test and check results will be displayed on a public webpage (henceforth, _certificate status page_) owned by SCS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we publish results of SCS conformance tests, we need the permission of CSP to do so in order to prevent any legally conficrts. I do not know, if this should be part of "Regulations for achieving SCS-compatible certification". However, we should keep this in mind and add an appropriate statement to SCS certificate's terms and conditions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that any CSP objecting to this kind of publication should NOT apply for certification. Nobody is being forced.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that any CSP objecting to this kind of publication should NOT apply for certification. Nobody is being forced.

I agree. They can run their tests the same as non-public clouds for their own information and don't need to apply for the certification.

However, practically speaking there should be some retention period such as 5 years, not all time.

Would we remove test results for CSPs who no longer wish to be certified in case they recertify later?

Copy link
Member

@garloff garloff Nov 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we need to write a little "SCS certification terms & conditions document" that states obligations and conditions. I don't want to sign individual contracts, so it's a T&C thing. (In German: Allgemeine Geschäftsbedingungen.)

Copy link
Contributor

@anjastrunk anjastrunk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments inline.

Copy link
Member

@garloff garloff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me.
I have a slight preference for "once per quarter" over "once every 3 months" because of the stated reasons. Feel free to apply this proposed change.
Next steps then would be to merge this and ask for opinions before we turn the draft into an approved document.

Copy link
Contributor

@fdobrovolny fdobrovolny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I now saw that I did a review a week ago but did not send it.

I added my two cents other than that LGTM.


3. If the desired certificate requires manual checks, then the operator MUST offer the SCS project suitable access. Manual checks MUST be repeated once every 3 months.

4. Details on the standards achieved, as well as the current state and the history of all test and check results will be displayed on a public webpage (henceforth, _certificate status page_) owned by SCS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that any CSP objecting to this kind of publication should NOT apply for certification. Nobody is being forced.

I agree. They can run their tests the same as non-public clouds for their own information and don't need to apply for the certification.

However, practically speaking there should be some retention period such as 5 years, not all time.

Would we remove test results for CSPs who no longer wish to be certified in case they recertify later?

@mbuechse
Copy link
Contributor Author

I now saw that I did a review a week ago but did not send it.

I added my two cents other than that LGTM.

Thanks @fdobrovolny -- very good points! I added them to today's agenda.

@fkr fkr requested a review from flyersa January 10, 2024 11:42
@fkr
Copy link
Member

fkr commented Jan 10, 2024

I just talked to @mbuechse since I was missing the part of "things to check for compliance that requires system level access" - which will (of course) be done by the operator with a results file submitted to SCS.
@mbuechse and I agreed that we will open an issue for that and revisit that ONCE we have the first compliance check that requires this (since so far, we have none that require that).

Copy link
Member

@fkr fkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mbuechse for your efforts on this!

Copy link
Contributor

@josephineSei josephineSei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All my comments are of informational nature.

I put in a few implications this will have on airgapped and high-security infrastructures.

To summarize: this might be enough for operators of such infrastructures to not go for scs-compatability. I have no strong opinion on whether this is okay or not.


<!-- Initially this will probably be eMail -->

3. If the desired certificate requires manual checks, then the operator MUST offer the SCS project suitable access. Manual checks MUST be repeated once every quarter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In an airgapped scenario this would mean a real person has to go their and do the checks. And even that is not always possible, as the physical entrance to data centers may be restricted to certain persons. (I have already seen this in public cloud offerings).


For public clouds, it is recommended to offer the SCS project access to the infrastructure so the test suite runs can be triggered continuously by the SCS team.

Alternatively, and for non-public clouds, the results (log files) MUST be submitted to SCS by a mechanism of SCS' choice and need to be reproduced again on request by SCS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have a set of options for providing the results ready. On some airgapped infrastructures getting information like that out of it is nearly impossible as every information is classified. That may even lead to a letter with printed logs, that need to be destroyed in certain ways after reading.


3. If the desired certificate requires manual checks, then the operator MUST offer the SCS project suitable access. Manual checks MUST be repeated once every quarter.

4. Details on the standards achieved, as well as the current state and the history of all test and check results of the past 18 months will be displayed on a public webpage (henceforth, _certificate status page_) owned by SCS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for some infrastructures we will talk about classified information, it would be very interesting to define exactly, what information will be displayed. (No need to do this here in this standard, but it will be good to have such information.)

alexander-diab and others added 18 commits January 12, 2024 16:08
Signed-off-by: alexander-diab <59739986+alexander-diab@users.noreply.github.com>
…ucture as per scs-0001

Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
…see #346)

Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Co-authored-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
Signed-off-by: Matthias Büchse <matthias.buechse@cloudandheat.com>
@mbuechse mbuechse merged commit b2c0c4f into main Jan 12, 2024
5 checks passed
@mbuechse mbuechse deleted the issue/337 branch January 12, 2024 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking and documenting compliance of clouds with SCS certificates Document certification issuing process
10 participants