-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
See also the rendered version |
There was a problem hiding this 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.
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"). |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments inline.
There was a problem hiding this 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.
There was a problem hiding this 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. |
There was a problem hiding this comment.
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?
Thanks @fdobrovolny -- very good points! I added them to today's agenda. |
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. |
There was a problem hiding this 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!
There was a problem hiding this 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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.)
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>
Resolves #337 and #346.
Supersedes #239.