So, I tied doing this via github but it seems the issue and PR were just abruptly closed within 20m without any meaningful conversation so I'm hoping that there can be a more fruitful discussion on list here.
https://github.com/ComplianceAsCode/content/issues/4917 https://github.com/ComplianceAsCode/content/pull/4920
The issue in question is that any FIPS related check includes a test for whether or not the OS is FIPS certified. That seems to make sense as a stand alone rule but shouldn't that be orthogonal to whether or not SSH is configured to use FIPS approved crypto algorithms or if AIDE is configured to exclusively use FIPS approved hashes? The rule isn't whether or not ssh is FIPS approved but just whether or not it's configuration is such that only approved ciphers are used.
---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
I had the same thoughts on these checks, but the wording in the DISA STIGs are very subtle.
V-72073 (AIDE implements FIPS..) has a note in the Check Text that reads:
Note: If RHEL-07-021350 is a finding, this is automatically a finding too as the system cannot implement FIPS 140-2 approved cryptographic algorithms and hashes.
RHEL-07-021350 is related to the system running in FIPS mode (V-72067).
V-72067 states :
The Red Hat Enterprise Linux operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
Notice the phrase “NIST FIPS-validated cryptography”….that implies that the FIPS implementation must be certified by NIST. Centos and others implementation of FIPS are not officially certified by NIST, so they can never pass V-72067 and thus never pass V-72073.
At least that is how I am reading the logic.
Robert
From: Chuck Atkins chuck.atkins@kitware.com Sent: Friday, October 11, 2019 12:11 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Excessive FIPS checks
So, I tied doing this via github but it seems the issue and PR were just abruptly closed within 20m without any meaningful conversation so I'm hoping that there can be a more fruitful discussion on list here.
https://github.com/ComplianceAsCode/content/issues/4917https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FComplianceAsCode%2Fcontent%2Fissues%2F4917&data=02%7C01%7Crhayden%40cerner.com%7C68be8534c0704fd1e8c408d74e6e0c64%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C637064106878960817&sdata=mF%2BQ3Jmq11qjcqa50znNzdxu4%2BUTl5fWmdxMoL6mBfs%3D&reserved=0 https://github.com/ComplianceAsCode/content/pull/4920https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FComplianceAsCode%2Fcontent%2Fpull%2F4920&data=02%7C01%7Crhayden%40cerner.com%7C68be8534c0704fd1e8c408d74e6e0c64%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C637064106878960817&sdata=c0ofqKRQ8RLBWsopLweoxMHoUsE5h2GAbPdGEfeJhiM%3D&reserved=0
The issue in question is that any FIPS related check includes a test for whether or not the OS is FIPS certified. That seems to make sense as a stand alone rule but shouldn't that be orthogonal to whether or not SSH is configured to use FIPS approved crypto algorithms or if AIDE is configured to exclusively use FIPS approved hashes? The rule isn't whether or not ssh is FIPS approved but just whether or not it's configuration is such that only approved ciphers are used.
---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
Chuck,
This is a very philosophical question, and I tend to lean towards what I see as RH’s perspective. FIPS certification is more than just turning on ciphers, which you can do on CentOS, but doing so only does the technical part, but it’s not the whole chain. If you look at the DISA STIG checks for FIPS ciphers, they check not only that sshd_config is correct, but also that you’re running RH (even if you turn off the OS check). It doesn’t do this for every check, but just the checks related to FIPS.
If I can give an analogy, FIPS is like a signature on a piece of paper. Configuring FIPS is like signing a document, but having that signature notarized, while not technically doing anything to the signed piece of paper, gives the paper much more legal weight. However, that doesn’t make an unnotarized signed document worthless. So, having a CentOS system with proper technical configurations in place is better than not doing so (like having a will on a piece of paper in the top drawer of your dresser is better than not having a will), calling that configuration “FIPS enabled” is not the case. It’s “just” a server with certain ciphers enabled.
So, if I were king for a day, I would propose the idea that having a server pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS system could be configured to pass the cipher check and kernel checks, but fail the supported OS and the meta FIPS validated check.
--
Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA Cyber Architect, Lockheed Martin RMS thomas.c.albrecht@lmco.commailto:thomas.c.albrecht@lmco.com – 610-906-4356
Please consider supporting my work in Africa https://www.gofundme.com/computer-network-for-abi
From: Chuck Atkins chuck.atkins@kitware.com Sent: Friday, October 11, 2019 1:11 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: EXTERNAL: Excessive FIPS checks
So, I tied doing this via github but it seems the issue and PR were just abruptly closed within 20m without any meaningful conversation so I'm hoping that there can be a more fruitful discussion on list here.
https://github.com/ComplianceAsCode/content/issues/4917 https://github.com/ComplianceAsCode/content/pull/4920
The issue in question is that any FIPS related check includes a test for whether or not the OS is FIPS certified. That seems to make sense as a stand alone rule but shouldn't that be orthogonal to whether or not SSH is configured to use FIPS approved crypto algorithms or if AIDE is configured to exclusively use FIPS approved hashes? The rule isn't whether or not ssh is FIPS approved but just whether or not it's configuration is such that only approved ciphers are used.
---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
FIPS certification is more than just turning on ciphers,
For sure, I'm not arguing that point at all.
but doing so only does the technical part, but it’s not the whole chain.
So, that's what the rules in question are checking though. The technical implementation of the ciphers. The
So, having a CentOS system with proper technical configurations in place is better than not doing so (like having a will on a piece of paper in the top drawer of your dresser is better than not having a will), calling that configuration “FIPS enabled” is not the case. It’s “just” a server with certain ciphers enabled.
Right, but that's not what I'm advocating for. The rules are supposed to be testing whether or not certain ciphers, hashes, or packages are enabled. Those are technical checks that should be able to pass regardless of "certification". There is already a stand alone rule for if the OS is FIPS certified, and certainly none of the derivatives should pass. But shouldn't some of the technical components still be able to pass? "Is ssh configured to exclusively use FIPS approved ciphers?" is different than "Is ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies OS?" The checks are two different tests and the OS check is already a stand alone rule.
So, if I were king for a day, I would propose the idea that having a server pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS system could be configured to pass the cipher check and kernel checks, but fail the supported OS and the meta FIPS validated check.
That can already effectively happen by just enabling all of the FIPS related rules. The profile can require all of them and then in the case of being run on a derivative OS, most of them can still pass as they are testing technical implementation but the "Is OS Certified" and "Is OS vendor supported" will always fail.
This is of particular interest outside of RHEL derivative OSs. We're currently trying to develop NIST 800-171 content for ubuntu and I don't see why we shouldn't be able to enforce the cipher configurations.
- Chuck
On Fri, Oct 11, 2019 at 12:25 PM Chuck Atkins chuck.atkins@kitware.com wrote:
FIPS certification is more than just turning on ciphers,
For sure, I'm not arguing that point at all.
but doing so only does the technical part, but it’s not the whole chain.
So, that's what the rules in question are checking though. The technical implementation of the ciphers. The
That's not true. The rules also make sure that you are on a FIPS validated system by design to meet compliance requirements hence the quote of the NIST 800-53 controls.
So, having a CentOS system with proper technical configurations in place is better than not doing so (like having a will on a piece of paper in the top drawer of your dresser is better than not having a will), calling that configuration “FIPS enabled” is not the case. It’s “just” a server with certain ciphers enabled.
Right, but that's not what I'm advocating for. The rules are supposed to be testing whether or not certain ciphers, hashes, or packages are enabled. Those are technical checks that should be able to pass regardless of "certification". There is already a stand alone rule for if the OS is FIPS certified, and certainly none of the derivatives should pass. But shouldn't some of the technical components still be able to pass? "Is ssh configured to exclusively use FIPS approved ciphers?" is different than "Is ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies OS?" The checks are two different tests and the OS check is already a stand alone rule.
No. FIPS ciphers running on non-validated FIPS systems are considered equivalent to cleartext. FIPS ciphers are validated by compiled binary and not source code. A very common misconception is that these profiles/rules is about "hardening to a standard" rather than "validating and ending up in a compliance state" to 800-171, STIG, Common Criteria, etc. Which is why certification profiles are no longer being delivered downstream from RHEL in addition to the rules passing for FIPS as there are no more waivers in the Federal government for not using FIPS or FIPS validated crypto. Not to mention the fact that RHEL certifications and certifying content do not apply to CentOS. There are many issues with CentOS that are related to compliance areas, e.g. secure supply chain, certifications, validating crypto, etc. which is why PRs surrounding compliance profiles and FIPS will be closed. And it isn't about us not wanting to do it, it is about making sure that compliance profiles get users to compliance end states. For those that don't have to "comply" with FIPS (anyone not in the Federal Government), they don't care that they fail.
So, if I were king for a day, I would propose the idea that having a server pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS system could be configured to pass the cipher check and kernel checks, but fail the supported OS and the meta FIPS validated check.
That can already effectively happen by just enabling all of the FIPS related rules. The profile can require all of them and then in the case of being run on a derivative OS, most of them can still pass as they are testing technical implementation but the "Is OS Certified" and "Is OS vendor supported" will always fail.
Rules can be tailored out and removed. Plus, once again, FIPS running on non-validated systems is considered cleartext.
This is of particular interest outside of RHEL derivative OSs. We're currently trying to develop NIST 800-171 content for ubuntu and I don't see why we shouldn't be able to enforce the cipher configurations.
There is a different conversation that takes place when we talk about other distributions, because if we are talking about Canonical-supported Ubuntu, they do have FIPS-validated crypto. BTW. FIPS validated crypto is also a requirement of NIST 800-171 for CUI.
- Chuck
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Okay, so I'm starting to get a clearer picture of the fips issues. The clearest explanation I can find is in the dod guidance for implementing nist 800-171, 3.13.11 "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.". It explicitly explains there the caveats and issues you raised, in particular:
"Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140."
I know this is what has been said by others, but I feel the explicit justification has been somewhat difficult to track down. So that's great, it's explicitly spelled out, which is a big part of what I was looking for. Given that, it's clear that the derivatives should never be passing any of the fips checks as they're intended to be implemented.
Even still though, I think the way the fips checks are implemented is off in a couple of ways:
The rules themselves are documented to check whether or not ssh (and friends) is configured to use fips validated ciphers. That by itself shouldn't be checking if the os is validated. But from what I can tell the rule should actually be whether or not ssh is configured as a fips validated module, which as discussed, is more than checking the ciphers configuration. So at a minimum, maybe the documentation for the rule should change? Beyond that though, looking at the RHEL documentation, what needs to be checked to test whether or not ssh is configured as a fips approved module is the cipher configuration, whether or not the kernel is in fips mode, I'd if the os is fips certified. It seems those three things together are what makes ssh a fips validated module. As implemented, the checks would pass if ssh is configured with the right algorithms on rhel proper even if the kernel isn't in fips mode. So should the related rules be changed to also check the kernel mode?
Putting it all together, is it then a reasonable assertion that the various fips related rules for individual packages be changed as follows: - the description changed to "package is configured as a fips validated module" - checks implemented as requiring all of the following: -- package is configured to exclusively use fips validated algorithms -- kernel is in fips mode -- os is fips certified
?
On Fri, Oct 11, 2019, 6:11 PM Gabe Alford redhatrises@gmail.com wrote:
On Fri, Oct 11, 2019 at 12:25 PM Chuck Atkins chuck.atkins@kitware.com wrote:
FIPS certification is more than just turning on ciphers,
For sure, I'm not arguing that point at all.
but doing so only does the technical part, but it’s not the whole chain.
So, that's what the rules in question are checking though. The technical implementation of the ciphers. The
That's not true. The rules also make sure that you are on a FIPS validated system by design to meet compliance requirements hence the quote of the NIST 800-53 controls.
So, having a CentOS system with proper technical configurations in place is better than not doing so (like having a will on a piece of paper in the top drawer of your dresser is better than not having a will), calling that configuration “FIPS enabled” is not the case. It’s “just” a server with certain ciphers enabled.
Right, but that's not what I'm advocating for. The rules are supposed to be testing whether or not certain ciphers, hashes, or packages are enabled. Those are technical checks that should be able to pass regardless of "certification". There is already a stand alone rule for if the OS is FIPS certified, and certainly none of the derivatives should pass. But shouldn't some of the technical components still be able to pass? "Is ssh configured to exclusively use FIPS approved ciphers?" is different than "Is ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies OS?" The checks are two different tests and the OS check is already a stand alone rule.
No. FIPS ciphers running on non-validated FIPS systems are considered equivalent to cleartext. FIPS ciphers are validated by compiled binary and not source code. A very common misconception is that these profiles/rules is about "hardening to a standard" rather than "validating and ending up in a compliance state" to 800-171, STIG, Common Criteria, etc. Which is why certification profiles are no longer being delivered downstream from RHEL in addition to the rules passing for FIPS as there are no more waivers in the Federal government for not using FIPS or FIPS validated crypto. Not to mention the fact that RHEL certifications and certifying content do not apply to CentOS. There are many issues with CentOS that are related to compliance areas, e.g. secure supply chain, certifications, validating crypto, etc. which is why PRs surrounding compliance profiles and FIPS will be closed. And it isn't about us not wanting to do it, it is about making sure that compliance profiles get users to compliance end states. For those that don't have to "comply" with FIPS (anyone not in the Federal Government), they don't care that they fail.
So, if I were king for a day, I would propose the idea that having a server pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS system could be configured to pass the cipher check and kernel checks, but fail the supported OS and the meta FIPS validated check.
That can already effectively happen by just enabling all of the FIPS related rules. The profile can require all of them and then in the case of being run on a derivative OS, most of them can still pass as they are testing technical implementation but the "Is OS Certified" and "Is OS vendor supported" will always fail.
Rules can be tailored out and removed. Plus, once again, FIPS running on non-validated systems is considered cleartext.
This is of particular interest outside of RHEL derivative OSs. We're currently trying to develop NIST 800-171 content for ubuntu and I don't see why we shouldn't be able to enforce the cipher configurations.
There is a different conversation that takes place when we talk about other distributions, because if we are talking about Canonical-supported Ubuntu, they do have FIPS-validated crypto. BTW. FIPS validated crypto is also a requirement of NIST 800-171 for CUI.
- Chuck
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
I agree with Chuck in that the checks should go all the way down the stack for validation since this is what is actually correct.
The current checks do not do that and are incorrect in that sense. Technically, I could replace system openssl with a recompiled openssl and invalidate the whole thing. This should be checked for to produce an actual valid check down the stack.
A valid check (in the case of SSH) would be:
* SSH is from Red Hat * SSH is configured with correct ciphers/hashes/etc... * SSH is using system openssl * System openssl is the one from Red Hat * Kernel is one of the approved ones from Red Hat * Kernel is FIPS enforcing
Now, the reason that I wanted this capability is just to see if things break horribly when put in FIPS mode on a CentOS system. Why? Because, it's easy to do in GitLab CI without exposing my RHN keys to the world. I tried this several different ways without success so far. While I made it function, I couldn't do it in a way that didn't expose the keys in the logs.
Thanks,
Trevor
On Sat, Oct 12, 2019 at 8:51 AM Chuck Atkins chuck.atkins@kitware.com wrote:
Okay, so I'm starting to get a clearer picture of the fips issues. The clearest explanation I can find is in the dod guidance for implementing nist 800-171, 3.13.11 "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.". It explicitly explains there the caveats and issues you raised, in particular:
"Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140."
I know this is what has been said by others, but I feel the explicit justification has been somewhat difficult to track down. So that's great, it's explicitly spelled out, which is a big part of what I was looking for. Given that, it's clear that the derivatives should never be passing any of the fips checks as they're intended to be implemented.
Even still though, I think the way the fips checks are implemented is off in a couple of ways:
The rules themselves are documented to check whether or not ssh (and friends) is configured to use fips validated ciphers. That by itself shouldn't be checking if the os is validated. But from what I can tell the rule should actually be whether or not ssh is configured as a fips validated module, which as discussed, is more than checking the ciphers configuration. So at a minimum, maybe the documentation for the rule should change? Beyond that though, looking at the RHEL documentation, what needs to be checked to test whether or not ssh is configured as a fips approved module is the cipher configuration, whether or not the kernel is in fips mode, I'd if the os is fips certified. It seems those three things together are what makes ssh a fips validated module. As implemented, the checks would pass if ssh is configured with the right algorithms on rhel proper even if the kernel isn't in fips mode. So should the related rules be changed to also check the kernel mode?
Putting it all together, is it then a reasonable assertion that the various fips related rules for individual packages be changed as follows:
- the description changed to "package is configured as a fips validated
module"
- checks implemented as requiring all of the following:
-- package is configured to exclusively use fips validated algorithms -- kernel is in fips mode -- os is fips certified
?
On Fri, Oct 11, 2019, 6:11 PM Gabe Alford redhatrises@gmail.com wrote:
On Fri, Oct 11, 2019 at 12:25 PM Chuck Atkins chuck.atkins@kitware.com wrote:
FIPS certification is more than just turning on ciphers,
For sure, I'm not arguing that point at all.
but doing so only does the technical part, but it’s not the whole chain.
So, that's what the rules in question are checking though. The technical implementation of the ciphers. The
That's not true. The rules also make sure that you are on a FIPS validated system by design to meet compliance requirements hence the quote of the NIST 800-53 controls.
So, having a CentOS system with proper technical configurations in place is better than not doing so (like having a will on a piece of paper in the top drawer of your dresser is better than not having a will), calling that configuration “FIPS enabled” is not the case. It’s “just” a server with certain ciphers enabled.
Right, but that's not what I'm advocating for. The rules are supposed to be testing whether or not certain ciphers, hashes, or packages are enabled. Those are technical checks that should be able to pass regardless of "certification". There is already a stand alone rule for if the OS is FIPS certified, and certainly none of the derivatives should pass. But shouldn't some of the technical components still be able to pass? "Is ssh configured to exclusively use FIPS approved ciphers?" is different than "Is ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies OS?" The checks are two different tests and the OS check is already a stand alone rule.
No. FIPS ciphers running on non-validated FIPS systems are considered equivalent to cleartext. FIPS ciphers are validated by compiled binary and not source code. A very common misconception is that these profiles/rules is about "hardening to a standard" rather than "validating and ending up in a compliance state" to 800-171, STIG, Common Criteria, etc. Which is why certification profiles are no longer being delivered downstream from RHEL in addition to the rules passing for FIPS as there are no more waivers in the Federal government for not using FIPS or FIPS validated crypto. Not to mention the fact that RHEL certifications and certifying content do not apply to CentOS. There are many issues with CentOS that are related to compliance areas, e.g. secure supply chain, certifications, validating crypto, etc. which is why PRs surrounding compliance profiles and FIPS will be closed. And it isn't about us not wanting to do it, it is about making sure that compliance profiles get users to compliance end states. For those that don't have to "comply" with FIPS (anyone not in the Federal Government), they don't care that they fail.
So, if I were king for a day, I would propose the idea that having a server pass a “FIPS valid” check would requiring passing other checks (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS system could be configured to pass the cipher check and kernel checks, but fail the supported OS and the meta FIPS validated check.
That can already effectively happen by just enabling all of the FIPS related rules. The profile can require all of them and then in the case of being run on a derivative OS, most of them can still pass as they are testing technical implementation but the "Is OS Certified" and "Is OS vendor supported" will always fail.
Rules can be tailored out and removed. Plus, once again, FIPS running on non-validated systems is considered cleartext.
This is of particular interest outside of RHEL derivative OSs. We're currently trying to develop NIST 800-171 content for ubuntu and I don't see why we shouldn't be able to enforce the cipher configurations.
There is a different conversation that takes place when we talk about other distributions, because if we are talking about Canonical-supported Ubuntu, they do have FIPS-validated crypto. BTW. FIPS validated crypto is also a requirement of NIST 800-171 for CUI.
- Chuck
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide@lists.fedorahosted.org
-
Albrecht, Thomas C -
Chuck Atkins -
Gabe Alford -
Hayden,Robert -
Trevor Vaughan