FIPS Checker
by Trevor Vaughan
Hi All,
Does anyone know of a project that can correlate the running operating
system with the latest information on the FIPS 140 approved products list.
Basically, I'm looking for a command where I can run something like
`fipscertified` and get back a `0` or `1` based on the result of the
latest/updated data.
Bonus points, I'd love to be able to point it at apps and have it tell me,
but that's a long shot given the statically compiled wonderland we all seem
to be living in these days.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
5 years, 5 months
Re: FIPS Checker
by Trevor Vaughan
Hey, doesn't bother me, we finally got TPM and trusted boot support
integrated into SIMP ;-).
Except for...well...the fact that UEFI doesn't Trusted Boot in RHEL
(*sigh*).
Trevor
On Mon, Oct 29, 2018 at 4:30 PM Brent Kimberley <Brent.Kimberley(a)durham.ca>
wrote:
> Like Trusted computing: power-on-self-test, trusted core, trusted
> interpreter measurements?
>
>
>
> *From:* Trevor Vaughan [mailto:tvaughan@onyxpoint.com]
> *Sent:* Monday, October 29, 2018 4:24 PM
> *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
> *Subject:* Re: FIPS Checker
>
>
>
> Well, checking to see if the system is in FIPS mode at the kernel level is
> pretty easy (fipscheck).
>
>
>
> I would like to know that it's actually the way the vendor intended but I
> couldn't determine a good way to do that. Seems like something that the
> vendors would want to supply/encourage for those customers that need it.
>
>
>
> On Mon, Oct 29, 2018 at 4:17 PM Mark Thacker <mthacker(a)redhat.com> wrote:
>
> AHHH.
>
> Well, checking the signatures of the RPMs verses what we posted in the
> certification would be a start. (sorry, manual there unless you automate
> using Ansible or OpenSCAP perhaps)
>
> You can check that the kernel is running in FIPS mode, of course, but I'm
> not sure that's all you want to check.
>
> BTW : That process of checking that the system is configured in FIPS does
> get easier in the future.....
>
>
>
> On Mon, Oct 29, 2018 at 4:03 PM Trevor Vaughan <tvaughan(a)onyxpoint.com>
> wrote:
>
> Actually, Mark, you've kind of nailed it on the head for me.
>
>
>
> I would like to be able to know that the system is the way it's *supposed*
> to be instead of just kind of doing my best and hoping that something
> didn't break.
>
>
>
> I was hoping that the validated modules area would have an XML file or
> something that could be downloaded and processed :-|.
>
>
>
> Anyway, it seems like it would be an appropriate addition to the SCAP
> scans since there is already the requirement to be enabled being checked
> for various profiles. I was just hoping that someone had magically created
> it.
>
>
>
> Thanks,
>
>
>
> Trevor
>
>
>
> On Mon, Oct 29, 2018 at 3:59 PM Mark Thacker <mthacker(a)redhat.com> wrote:
>
> We've definitely talked about this and there isn't a clear programmatic
> means to achieve this.
>
> Of course, we do log which specific version of the libraries that we build
> and test against in our certification report. So, those could be used to
> compare a running system against the certification report.
>
>
>
> Yes, I also understand that sometimes the desire is to be able to show
> that CentOS or Fedora is NOT FIPS certified verses RHEL. Of course, that
> assumes that the RHEL you are running on IS actually certified.
>
>
>
> On Mon, Oct 29, 2018 at 3:39 PM Gabe Alford <redhatrises(a)gmail.com> wrote:
>
> Outside of going to
> https://csrc.nist.gov/projects/cryptographic-module-validation-program/va...
>
> and clicking `search` with empty search parameters, don't know of anything.
>
>
>
> On Mon, Oct 29, 2018 at 1:33 PM Trevor Vaughan <tvaughan(a)onyxpoint.com>
> wrote:
>
> Hi All,
>
>
>
> Does anyone know of a project that can correlate the running operating
> system with the latest information on the FIPS 140 approved products list.
>
>
>
> Basically, I'm looking for a command where I can run something like
> `fipscertified` and get back a `0` or `1` based on the result of the
> latest/updated data.
>
>
>
> Bonus points, I'd love to be able to point it at apps and have it tell me,
> but that's a long shot given the statically compiled wonderland we all seem
> to be living in these days.
>
>
>
> Thanks,
>
>
>
> Trevor
>
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> (410) 541-6699 x788
>
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> 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.fe...
>
> _______________________________________________
> 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.fe...
>
>
>
>
> --
>
> Mark Thacker
>
> Principal Technical Product Manager, Security, Red Hat Enterprise Linux
>
> Email: mthacker(a)redhat.com
>
> IRC / Freenode : mthacker
>
> Mobile: +1-214-636-7004
>
> _______________________________________________
> 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.fe...
>
>
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> (410) 541-6699 x788
>
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> 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.fe...
>
>
>
>
> --
>
> Mark Thacker
>
> Principal Technical Product Manager, Security, Red Hat Enterprise Linux
>
> Email: mthacker(a)redhat.com
>
> IRC / Freenode : mthacker
>
> Mobile: +1-214-636-7004
>
> _______________________________________________
> 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.fe...
>
>
>
> --
>
> 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.fe...
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
5 years, 5 months
open-scap.org down?
by Trevor Vaughan
I'm not able to access the site, is this a known issue?
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
5 years, 5 months
Re: [Open-scap] Developing content for Oracle Linux
by Jan Cerny
Hi,
I'm adding the scap-security-guide-list to the conversation because the openscap-list
is about the scanner, not about the content.
Jan Černý
Security Technologies | Red Hat, Inc.
----- Original Message -----
> From: "Jan Cerny" <jcerny(a)redhat.com>
> To: "Tina Rose" <tina.rose(a)oracle.com>
> Cc: open-scap-list(a)redhat.com
> Sent: Monday, October 22, 2018 9:03:20 AM
> Subject: Re: [Open-scap] Developing content for Oracle Linux
>
> Hi Tina,
>
> Thank you for reaching us. There is ComplianceAsCode project (formerly known
> as SCAP Security Guide) that provides SCAP content for various Linux
> distributions.
>
> ComplianceAsCode is an open-source project and it's developed actively on
> GitHub.
> Here's the link: https://github.com/ComplianceAsCode/content
> Check out the README there.
>
> ComplianceAsCode already has some SCAP content for Oracle Linux 7. It needs a
> lot of
> improvements, but it's a great place to start. It's possible to reuse a lot
> of stuff
> that is used in RHEL content. There is a person from Oracle, Ilya Okomin,
> who used work on that.
>
> The process for sharing content with the community is to submit patches
> via GitHub using pull requests. We are willing to provide feedback and help
> your developers with that.
> There is a developer guide that explains how the content is built:
> https://github.com/ComplianceAsCode/content/blob/master/docs/manual/devel...
>
> Hopefully this helps. We're looking forward to hear from you soon.
>
> Regards
>
> Jan Černý
> Security Technologies | Red Hat, Inc.
>
>
>
>
> ----- Original Message -----
> > From: "Tina Rose" <tina.rose(a)oracle.com>
> > To: open-scap-list(a)redhat.com
> > Sent: Friday, October 19, 2018 7:38:45 PM
> > Subject: [Open-scap] Developing content for Oracle Linux
> >
> >
> >
> > I had a customer request Open-SCAP content specific to Oracle Linux to
> > complete STIG compliance. Can someone point me in the right direction to
> > begin researching this request? Is there a process for creating and sharing
> > content to the open-scap community?
> >
> >
> >
> >
> >
> > Tina Rose | Consulting Member of Technical Staff
> >
> > Office: +1 719 757 3203
> >
> > Oracle Platform Integration MAA Team
> >
> >
> >
> > _______________________________________________
> > Open-scap-list mailing list
> > Open-scap-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/open-scap-list
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
5 years, 5 months
Issue with Repo GPG Checking
by Trevor Vaughan
Hi All,
I've been re-roaming through the SSG and this is probably the first of a
many part thread regarding different checks.
TL;DR; The potential risk caused by enabling 'repo_gpgcheck' outweighs any
potential benefit if TLS is enabled.
In my opinion, the following check should *only* be enabled if all of your
repositories are internally managed
xccdf_org.ssgproject.content_rule_ensure_gpgcheck_repo_metadata.
The reason for this is that YUM presently does not (to my knowledge) have
any way to differentiate between package signing GPG keys and repo signing
GPG keys.
This means that if, for instance, I host my packages via some shared Nexus,
then I have to add the Nexus GPG key to my trust list for the repo.
I fundamentally do *not* want to do this! I shouldn't be allowing my Nexus
maintainer to potentially install software on my system without my explicit
knowledge.
You should use TLS, and the repo should have a trusted certificate there
and that should be sufficient for the metadata until RPM can tell the
difference between these two certificates.
Please let me know if I've missed something, but I don't remember seeing
options to split out the two sets of certs.
Additionally, this is marked as 'high' severity and that seems to be
massive overkill considering that 1) the packages are still signed and
validated and 2) TLS is required.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
5 years, 5 months
SCAP Security Guide 0.1.41
by Watson Yuuma Sato
Hello everybody,
We have the pleasure to announce release of SCAP Security Guide 0.1.41.
Although it is named SCAP Security Guide, the project is now under
ComplianceAsCode organization (https://github.com/ComplianceAsCode/content).
For more on this move, see
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
This release continues with fixes "under the hood", the checks and fixes
are now better placed, in the same directory as the rule description.
We also feature new Products and new Profiles, test coverage for the
rules was significantly improved, along with testing capabilities of
SSGTestSuite.
Highlights of this release:
- Improved test scenario coverage of rules
- Improvements regarding content for Kubernetes for opencis-ocp-master
Profile
- Introduction of concept of stable Profiles
- Addition of Ubuntu 1804 Product with ANSSI and standard Profiles
- Addition of OSPP 4.2 Profile for Fedora
- Addition of PCI-DSS Profile for Fedora
- Possibility to manually debug test scenarios
- Addition of Example Product
- Support to evaluate test scenarios on container images
- Introduction of SSG unit tests for build system functions
- Reorganization of checks and fixes to be closer to rule description
For a more detailed overview of changes (bug fixes, enhancements)
implemented in this release, please have a look at more detailed changelog:
* https://github.com/ComplianceAsCode/content/releases/tag/v0.1.41
Full changelog at:
* https://github.com/ComplianceAsCode/content/issues?q=milestone%3A0.1.41
Zip archives with pre-built benchmarks in DataStream form:
*
https://github.com/ComplianceAsCode/content/releases/download/v0.1.41/sca...
(Zip archive using OVAL-5.11.1 language version)
*
https://github.com/ComplianceAsCode/content/releases/download/v0.1.41/sca...
(Zip archive using OVAL-5.10 language version only)
Thank you to everyone who contributed with issues, patches and discussions!
Happy hardening!
--
Watson Sato
Security Technologies | Red Hat, Inc
5 years, 6 months