scap-security-guide January 2019

scap-security-guide@lists.fedorahosted.org

12 participants
10 discussions

Community metrics tools
by Shawn Wells 31 Jan '19

31 Jan '19

Met with Marek Haičman (@dahaic) in person this week, who mentioned he was looking for something to measure community and development metrics. Here's something the OpenShift community uses. Would setting this up for OpenSCAP and ComplianceAsCode be interesting? https://openshift.biterg.io/app/kibana

2 1

Minimum Password Length (15 vs 12)
by Albrecht, Thomas C 11 Jan '19

11 Jan '19

All, While we’re on the topic of source policies, I’ve been trying to track down the reasoning for the 15 character minimum. I’m sure it’s not conjured from nowhere, but the only policy I’ve found that dictates minimum password length [IA-5(1)] is CNSSI-1253 (Dated Mar 2014) that says 12 characters minimum. “A case sensitive 12-character mix of upper case letters, lower case letters, numbers and special characters in including at least one of each.” I checked the classified and intelligence overlays, and didn’t see any reference to the control. So, can anyone point me to a policy that leads to 15 characters being in the STIG? Tom A. Thomas Albrecht III, CISSP-ISSEP, RHCSA Cyber Architect | Cyber Inside<https://insidelm.external.lmco.com/cyber-inside> |CAS2T Lockheed Martin, Rotary and Mission Systems (RMS) 230 Mall Blvd, | King of Prussia, PA [m] 610-906-4356 cyber.security(a)lmco.com<mailto:cyber.security@lmco.com> [cid:image003.png@01D030AD.9DBE6340]

5 4

SSG List Web Interface Account Reset
by Albrecht, Thomas C 10 Jan '19

10 Jan '19

All, Sorry for the meta question, but I can't seem to figure this one out. I've been on this a while, and it looks like the hosting has migrated at least once since the last time I tried to access the archive web page. I don't know what my password is, and when I try to reset with either of the accounts I'm using to subscribe to the list, the server is telling me that the email address doesn't exist in the system. Not sure where to go from here, but I'm hoping someone can point me in the right direction. I did get a bit of a chuckle, as the "reset password" page states "Please contact us if you have any trouble resetting your password.", but doesn't have any direction as to how to contact "us". Thanks! Tom A. Thomas Albrecht III, CISSP-ISSEP, RHCSA Cyber Architect | Cyber Inside<https://insidelm.external.lmco.com/cyber-inside> |CAS2T Lockheed Martin, Rotary and Mission Systems (RMS) 230 Mall Blvd, | King of Prussia, PA [m] 610-906-4356 cyber.security(a)lmco.com<mailto:cyber.security@lmco.com> [cid:image003.png@01D030AD.9DBE6340]

3 2

Rule rpm_verify_file_hashes and config files
by Watson Sato 10 Jan '19

10 Jan '19

Hello, Regarding rule "Verify file hashes with RPM", which files resides here: https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/syst… From description in rule.yml I understand that altered files should be reported and, altered configuration files should be reported analyzed individually. 1. Is this the intended action? To evaluate altered configuration files? Looking at the OVAL check, it mostly cares about altered files under /bin, /sbin ,/lib ,/lib64 or /usr (mainly executables and libraries according to comment). 2. Is this restriction only to optimize for search of libraries and binaries? I see a slight misalignment between check and description. This way we won't be catching much changes in config files. -- Watson Sato Security Technologies | Red Hat, Inc

8 21

Re: Rule rpm_verify_file_hashes and config files
by Trevor Vaughan 09 Jan '19

09 Jan '19

> > Are the config-file-validation-engine’s config files under RPM control? ;-) > Heh....sort of, but mostly git with mandatory 2 person review and CI. On Wed, Jan 9, 2019 at 2:43 PM Brent Kimberley <Brent.Kimberley(a)durham.ca> wrote: > One-size-fits-all vs tailored > > Are the config-file-validation-engine’s config files under RPM control? ;-) > > > > *From:* Watson Sato [mailto:wsato@redhat.com] > *Sent:* Wednesday, January 9, 2019 11:59 AM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Subject:* Re: Rule rpm_verify_file_hashes and config files > > > > > > > > On Wed, Jan 9, 2019 at 5:39 PM Gabe Alford <redhatrises(a)gmail.com> wrote: > > On Wed, Jan 9, 2019 at 9:09 AM Watson Sato <wsato(a)redhat.com> wrote: > > > > > > On Wed, Jan 9, 2019 at 3:28 AM Shawn Wells <shawn(a)redhat.com> wrote: > > > > The XCCDF currently has language stating that config files are expected to > change and should not be a finding. > > From following snippet I understand that a configuration file that changed > is a finding and should reviewed and fixed/waived. > > A "c" in the second column indicates that a file is a configuration file, which > > may appropriately be expected to change. If the file was not expected to > > change, investigate the cause of the change using audit logs or other means. > > Which if that is the case, changing the OVAL code so that it ignores the > config files and passes doesn't make sense. > > Because how will you know if you need to investigate a config file that > has changed when it wasn't supposed to change? > > > > Well, that is one of my questions. > > In practice, are people expecting that configuration files which differ > from default shipped in package to be reported? > > Won't it just end up creating large amount of findings people don't care? > > > > And if config files should really be checked, why skip /etc in OVAL > definition? > > > > > > If the OVAL is flagging config files, wouldn't that would be a bug in the > existing OVAL code? > > Yes, my suggestion is to stop checking hash of config files in rule > "Verify file hashes with RPM". > > > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > -- > > Watson Sato > Security Technologies | Red Hat, Inc > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > -- > > Watson Sato > Security Technologies | Red Hat, Inc > THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY > CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR > EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to > any privilege have been waived. If you are not the intended recipient, you > are hereby notified that any review, re-transmission, dissemination, > distribution, copying, conversion to hard copy, taking of action in > reliance on or other use of this communication is strictly prohibited. If > you are not the intended recipient and have received this message in error, > please notify me by return e-mail and delete or destroy all copies of this > message. > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

1 0

RE: Gov profiles gone from EL derivatives?
by Brent Kimberley 02 Jan '19

02 Jan '19

The problem is typically expressed along the lines of what is the SOP for quickly salvaging licensed production pet <X> dependent on RPM <Y> when RPM <Y> needs reinstallation. From: Brent Kimberley Sent: Wednesday, January 2, 2019 2:14 PM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Subject: RE: Gov profiles gone from EL derivatives? Lol! From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Wednesday, January 2, 2019 2:10 PM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: Re: Gov profiles gone from EL derivatives? Heh...well, if I'm making Frakenrepos I'm probably not all that worried about adding additional GPG keys :-P On Wed, Jan 2, 2019 at 11:07 AM Brent Kimberley <Brent.Kimberley(a)durham.ca<mailto:Brent.Kimberley@durham.ca>> wrote: It was more of an issue prior to the repo_gpgcheck flag - repository metadata signing. Nevertheless, there is always the full-lifecycle argument. From: Brent Kimberley Sent: Wednesday, January 2, 2019 10:11 AM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: RE: Gov profiles gone from EL derivatives? Agreed From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Wednesday, January 2, 2019 10:02 AM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: Re: Gov profiles gone from EL derivatives? Brent, You're missing my use case. I don't necessarily own the entire testing infrastructure where tests are occurring. We do as much as possible in public so that people have an understanding on what's going on under the hood. Technically, there are a lot of ways to do this but none of them are really great and may (or may not) violate the Red Hat licensing agreement based on package redistribution. I mean, technically, I can just point a RHEL system at the OEL or CentOS repos and be done with it, but it doesn't make for a very "correct" test. Fundamentally, the system is just behind the times for automated infrastructure testing requirements if you want FOSS participation. Trevor On Wed, Jan 2, 2019 at 9:26 AM Brent Kimberley <Brent.Kimberley(a)durham.ca<mailto:Brent.Kimberley@durham.ca>> wrote: >>Trying to do this with RHEL-proper is frustrating at best Technically, you should be able to create a local RHEL mirror using a large hard drive, a fat pipe, an unprivileged user, and your “RHEL-repo-access-pem”. From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com<mailto:tvaughan@onyxpoint.com>] Sent: Sunday, December 30, 2018 6:05 PM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: Re: Gov profiles gone from EL derivatives? Hi Chuck, So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253. That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away. Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes. Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient. In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions. Trevor On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins(a)kitware.com<mailto:chuck.atkins@kitware.com>> wrote: Why use CentOS when RHEL developer subs are free? For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both. With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper. - Chuck _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message. _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message. _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

1 0

Re: Gov profiles gone from EL derivatives?
by Trevor Vaughan 02 Jan '19

02 Jan '19

Heh...well, if I'm making Frakenrepos I'm probably not all that worried about adding additional GPG keys :-P On Wed, Jan 2, 2019 at 11:07 AM Brent Kimberley <Brent.Kimberley(a)durham.ca> wrote: > It was more of an issue prior to the repo_gpgcheck flag - repository > metadata signing. > > Nevertheless, there is always the full-lifecycle argument. > > > > *From:* Brent Kimberley > *Sent:* Wednesday, January 2, 2019 10:11 AM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Subject:* RE: Gov profiles gone from EL derivatives? > > > > Agreed > > > > *From:* Trevor Vaughan [mailto:tvaughan@onyxpoint.com > <tvaughan(a)onyxpoint.com>] > *Sent:* Wednesday, January 2, 2019 10:02 AM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Subject:* Re: Gov profiles gone from EL derivatives? > > > > Brent, > > > > You're missing my use case. I don't necessarily own the entire testing > infrastructure where tests are occurring. We do as much as possible in > public so that people have an understanding on what's going on under the > hood. > > > > Technically, there are a lot of ways to do this but none of them are > really great and may (or may not) violate the Red Hat licensing agreement > based on package redistribution. > > > > I mean, technically, I can just point a RHEL system at the OEL or CentOS > repos and be done with it, but it doesn't make for a very "correct" test. > > > > Fundamentally, the system is just behind the times for automated > infrastructure testing requirements if you want FOSS participation. > > > > Trevor > > > > On Wed, Jan 2, 2019 at 9:26 AM Brent Kimberley <Brent.Kimberley(a)durham.ca> > wrote: > > >>Trying to do this with RHEL-proper is frustrating at best > > Technically, you should be able to create a local RHEL mirror using a > large hard drive, a fat pipe, an unprivileged user, and your > “RHEL-repo-access-pem”. > > > > *From:* Trevor Vaughan [mailto:tvaughan@onyxpoint.com] > *Sent:* Sunday, December 30, 2018 6:05 PM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Subject:* Re: Gov profiles gone from EL derivatives? > > > > Hi Chuck, > > > > So, I agree with you all the way up to FIPS. Unfortunately, the tracing > that we've done on the FIPS 140-2 requirement through various ties to > policy and FISMA *appears* to be unavailable except by the President of the > US, by named position. Now, it's possible that this tracing is incorrect > but I have yet to find anyone that could find another *documented* > interpretation that overrides the Congressional mandate as handed down to > NIST and inherited through the 800-53 and CNSS 1253. > > > > That said, FIPS only applies for the "protection of sensitive > information". If you don't have any sensitive information (i.e. 100% test > and eval environment with independent credentials that have no access to > any other system) then fire away. > > > > Also, this mandate only applies to organizations directly under the > Executive and Legislative branches of Government. The Judicial branch can > do what it likes. > > > > Sorry for the slight rant, this is one of those particular items that just > drives me nuts in terms of laws (not policies) that people like to try and > ignore when it gets inconvenient. > > > > In terms of packages, I completely agree with Charlie that it's really > simple to just grab all of the packages through various means so the RHN is > really just making legitimate use more difficult for systems like yours and > rapid CI testing systems. We specifically do not use one of the many ways > of circumventing the process so that we don't run afoul of any licensing > rules or restrictions. > > > > Trevor > > > > On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins(a)kitware.com> > wrote: > > Why use CentOS when RHEL developer subs are free? > > > > For our environment where we have a small deployment of only 2-4 machines, > CentOS is much easier to manage off-line on an air-gaped network. > Mirroring the CentOS repos is pretty easy to do with reposync and monthly > drops to a web server on the red network. The CentOS workstations can then > just point to the yum repos on said webserver and everything works like > it's supposed to. Trying to do this with RHEL-proper is frustrating at > best. A satellite server is way overkill for a deployment like this and > setting up the clients for a "normal" yum repo requires removing and > uninstalling all of the subscription / rhn packages. There's also the > simplicity of only have 2 system repos to worry about to get everything > available in CentOS (Base + Updates) vs dealing with the dozens of channels > needed in a RHEL subscription to get the same set of available packages. I > certainly get the value in all of the various options for managing large > enterprise deployments but CentOS is just much simpler to deal with for us > in a small deployment and software-developer-centric environment. We end > up using both RHEL and CentOS for different use cases but need to apply the > same security framework and settings to both. > > > > With regards to allowed security configurations, as a contractor we've > never had issues with DSS and CentOS being allowed so long as we apply all > the appropriate RHEL rules and can appropriately justify where we diverge. > The only ones I've run into that end up not applicable across the two have > been FIPS related, which we have to disable anyways to accommodate third > party unsigned kernel modules for the Nvidia driver. The STIGs after all > are just a guideline and place to start from so you can adapt it to your > own environment with appropriate tailoring and justification, not a fixed > "it has to be this way". Most of the government entities we work with (DoD > and DoE) use RHEL for their infrastructure servers and end-user > workstations but CentOS for their projects and developer environments. > Many of the DoE labs we work with even use CentOS on their large scale HPC > deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper. > > > > - Chuck > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > > -- > > Trevor Vaughan > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > -- This account not approved for unencrypted proprietary information -- > > THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY > CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR > EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to > any privilege have been waived. If you are not the intended recipient, you > are hereby notified that any review, re-transmission, dissemination, > distribution, copying, conversion to hard copy, taking of action in > reliance on or other use of this communication is strictly prohibited. If > you are not the intended recipient and have received this message in error, > please notify me by return e-mail and delete or destroy all copies of this > message. > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > -- > > Trevor Vaughan > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > -- This account not approved for unencrypted proprietary information -- > THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY > CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR > EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to > any privilege have been waived. If you are not the intended recipient, you > are hereby notified that any review, re-transmission, dissemination, > distribution, copying, conversion to hard copy, taking of action in > reliance on or other use of this communication is strictly prohibited. If > you are not the intended recipient and have received this message in error, > please notify me by return e-mail and delete or destroy all copies of this > message. > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

2 1

RE: Gov profiles gone from EL derivatives?
by Brent Kimberley 02 Jan '19

02 Jan '19

It was more of an issue prior to the repo_gpgcheck flag - repository metadata signing. Nevertheless, there is always the full-lifecycle argument. From: Brent Kimberley Sent: Wednesday, January 2, 2019 10:11 AM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Subject: RE: Gov profiles gone from EL derivatives? Agreed From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Wednesday, January 2, 2019 10:02 AM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: Re: Gov profiles gone from EL derivatives? Brent, You're missing my use case. I don't necessarily own the entire testing infrastructure where tests are occurring. We do as much as possible in public so that people have an understanding on what's going on under the hood. Technically, there are a lot of ways to do this but none of them are really great and may (or may not) violate the Red Hat licensing agreement based on package redistribution. I mean, technically, I can just point a RHEL system at the OEL or CentOS repos and be done with it, but it doesn't make for a very "correct" test. Fundamentally, the system is just behind the times for automated infrastructure testing requirements if you want FOSS participation. Trevor On Wed, Jan 2, 2019 at 9:26 AM Brent Kimberley <Brent.Kimberley(a)durham.ca<mailto:Brent.Kimberley@durham.ca>> wrote: >>Trying to do this with RHEL-proper is frustrating at best Technically, you should be able to create a local RHEL mirror using a large hard drive, a fat pipe, an unprivileged user, and your “RHEL-repo-access-pem”. From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com<mailto:tvaughan@onyxpoint.com>] Sent: Sunday, December 30, 2018 6:05 PM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>> Subject: Re: Gov profiles gone from EL derivatives? Hi Chuck, So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253. That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away. Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes. Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient. In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions. Trevor On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins(a)kitware.com<mailto:chuck.atkins@kitware.com>> wrote: Why use CentOS when RHEL developer subs are free? For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both. With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper. - Chuck _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message. _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

1 0

Re: Gov profiles gone from EL derivatives?
by Trevor Vaughan 02 Jan '19

02 Jan '19

Brent, You're missing my use case. I don't necessarily own the entire testing infrastructure where tests are occurring. We do as much as possible in public so that people have an understanding on what's going on under the hood. Technically, there are a lot of ways to do this but none of them are really great and may (or may not) violate the Red Hat licensing agreement based on package redistribution. I mean, technically, I can just point a RHEL system at the OEL or CentOS repos and be done with it, but it doesn't make for a very "correct" test. Fundamentally, the system is just behind the times for automated infrastructure testing requirements if you want FOSS participation. Trevor On Wed, Jan 2, 2019 at 9:26 AM Brent Kimberley <Brent.Kimberley(a)durham.ca> wrote: > >>Trying to do this with RHEL-proper is frustrating at best > > Technically, you should be able to create a local RHEL mirror using a > large hard drive, a fat pipe, an unprivileged user, and your > “RHEL-repo-access-pem”. > > > > *From:* Trevor Vaughan [mailto:tvaughan@onyxpoint.com] > *Sent:* Sunday, December 30, 2018 6:05 PM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Subject:* Re: Gov profiles gone from EL derivatives? > > > > Hi Chuck, > > > > So, I agree with you all the way up to FIPS. Unfortunately, the tracing > that we've done on the FIPS 140-2 requirement through various ties to > policy and FISMA *appears* to be unavailable except by the President of the > US, by named position. Now, it's possible that this tracing is incorrect > but I have yet to find anyone that could find another *documented* > interpretation that overrides the Congressional mandate as handed down to > NIST and inherited through the 800-53 and CNSS 1253. > > > > That said, FIPS only applies for the "protection of sensitive > information". If you don't have any sensitive information (i.e. 100% test > and eval environment with independent credentials that have no access to > any other system) then fire away. > > > > Also, this mandate only applies to organizations directly under the > Executive and Legislative branches of Government. The Judicial branch can > do what it likes. > > > > Sorry for the slight rant, this is one of those particular items that just > drives me nuts in terms of laws (not policies) that people like to try and > ignore when it gets inconvenient. > > > > In terms of packages, I completely agree with Charlie that it's really > simple to just grab all of the packages through various means so the RHN is > really just making legitimate use more difficult for systems like yours and > rapid CI testing systems. We specifically do not use one of the many ways > of circumventing the process so that we don't run afoul of any licensing > rules or restrictions. > > > > Trevor > > > > On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins(a)kitware.com> > wrote: > > Why use CentOS when RHEL developer subs are free? > > > > For our environment where we have a small deployment of only 2-4 machines, > CentOS is much easier to manage off-line on an air-gaped network. > Mirroring the CentOS repos is pretty easy to do with reposync and monthly > drops to a web server on the red network. The CentOS workstations can then > just point to the yum repos on said webserver and everything works like > it's supposed to. Trying to do this with RHEL-proper is frustrating at > best. A satellite server is way overkill for a deployment like this and > setting up the clients for a "normal" yum repo requires removing and > uninstalling all of the subscription / rhn packages. There's also the > simplicity of only have 2 system repos to worry about to get everything > available in CentOS (Base + Updates) vs dealing with the dozens of channels > needed in a RHEL subscription to get the same set of available packages. I > certainly get the value in all of the various options for managing large > enterprise deployments but CentOS is just much simpler to deal with for us > in a small deployment and software-developer-centric environment. We end > up using both RHEL and CentOS for different use cases but need to apply the > same security framework and settings to both. > > > > With regards to allowed security configurations, as a contractor we've > never had issues with DSS and CentOS being allowed so long as we apply all > the appropriate RHEL rules and can appropriately justify where we diverge. > The only ones I've run into that end up not applicable across the two have > been FIPS related, which we have to disable anyways to accommodate third > party unsigned kernel modules for the Nvidia driver. The STIGs after all > are just a guideline and place to start from so you can adapt it to your > own environment with appropriate tailoring and justification, not a fixed > "it has to be this way". Most of the government entities we work with (DoD > and DoE) use RHEL for their infrastructure servers and end-user > workstations but CentOS for their projects and developer environments. > Many of the DoE labs we work with even use CentOS on their large scale HPC > deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper. > > > > - Chuck > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > > > > > -- > > Trevor Vaughan > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > -- This account not approved for unencrypted proprietary information -- > THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY > CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR > EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to > any privilege have been waived. If you are not the intended recipient, you > are hereby notified that any review, re-transmission, dissemination, > distribution, copying, conversion to hard copy, taking of action in > reliance on or other use of this communication is strictly prohibited. If > you are not the intended recipient and have received this message in error, > please notify me by return e-mail and delete or destroy all copies of this > message. > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedo… > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

2 1

Gov profiles gone from EL derivatives?
by Chuck Atkins 02 Jan '19

02 Jan '19

I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for RHEL7? - Chuck

6 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide January 2019