scap-security-guide June 2018

scap-security-guide@lists.fedorahosted.org

5 participants
5 discussions

Issue with Repo GPG Checking
by Trevor Vaughan 21 Oct '18

21 Oct '18

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 --

7 20

Fwd: [PatternFly] PatternFly Demo Recording and Survey
by Shawn Wells 27 Jun '18

27 Jun '18

Saw this from the PatternFly project. Public demos of what they've been working on to keep the broader community engaged/aware and helps keep devs accountable for producing demo-able code (read: things customers would get value from). Would it make sense for OpenSCAP family of projects (Workbench, Anaconda, SSG, etc) to do something like this every month? -------- Forwarded Message -------- Subject: [PatternFly] PatternFly Demo Recording and Survey Date: Tue, 26 Jun 2018 17:18:41 -0400 From: Leslie Hinson <lhinson(a)redhat.com> To: patternfly <patternfly(a)redhat.com> Fliers, Thank you to everyone that was able to attend today's PatternFlydemo. Please take the time to fill out the corresponding survey [1] <https://www.surveymonkey.com/r/HQHJVJ7> to give us your feedback on what was presented. This survey will close eod on Friday, July 6. If you missed the meeting, you can catch the recording [2] <https://youtu.be/PLIMerrV0sE> on our youtube channel. [1] https://www.surveymonkey.com/r/HQHJVJ7 [2] https://youtu.be/PLIMerrV0sE -- Leslie Hinson PatternFly Lead, UXD

1 0

Looks like the SSG build might be broken
by Trevor Vaughan 26 Jun '18

26 Jun '18

https://travis-ci.org/simp/inspec-profile-disa_stig-el7/jobs/395700762#L4971 Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

5 5

CI Enabled Cross Checking
by Trevor Vaughan 24 Jun '18

24 Jun '18

Hi All, As part of delving into InSpec for my CI tests, I decided that I need to have some form of baseline to follow. To that end, our public STIG profile does the following: 1. Build a system 2. Download and compile the SSG 3. Run an oscap remediate using the SSG 4. Check the system using InSpec The idea here is that the remediation should get the system to a point where the more static OVAL checks that SCAP uses should be used as a low water mark for the more dynamic InSpec checks. I wanted to share the tests in Travis CI in case it helps anyone here find issues with the SSG in the future. For instance, some of the profile renaming just bit us and makes automating the scans pretty interesting. Anyway, you can watch the 'System Test' build stage here https://travis-ci.org/simp/inspec-profile-disa_stig-el7 that will get triggered any time things are updated in the repo and, of course, you can also download it and run it locally. Ideally, these tests will start showing a 100% pass across the board and this can serve as some help to the community. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

3 3

New GitHub teams
by Martin Preisler 14 Jun '18

14 Jun '18

GitHub has been notifying us for ages that we should migrate from legacy teams to the new system. I decided it was time to finally do it. As part of this change the Owners team has been removed. GitHub recommends doing that (because once you migrate, the "Owners" team loses its special meaning). We had 10 teams in the organization which was way too much. And they were overlapping a lot. I decided to merge them into just 2 teams - trusted tools developers for everything except SSG and trusted SSG developers for SSG. These 2 teams have full push rights to the repos (github write access). This should make it much simpler to audit and keep up to date. Besides, if we trust someone to push into openscap we probably trust them to push into scap-workbench as well... You might have received notifications about deleted teams and you might have received invites to the new teams. I couldn't find any option to migrate people from team to team without notifying them like this, sorry for the inconvenience. I tried my best to keep everybody's permissions but with the amount of people and teams maybe I missed something. In case you encounter permission issues please let me know and I will fix it. -- Martin Preisler

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide June 2018