scap-security-guide August 2018

scap-security-guide@lists.fedorahosted.org

2 participants
3 discussions

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

20 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

Updating audit rules for container platforms
by Shawn Wells 04 Sep '18

04 Sep '18

Received an interesting question from a colleague today. The various STIG requirements have full paths for auditing, e.g. for /usr/bin/chage: https://rhel7stig.readthedocs.io/en/latest/medium.html#v-72155-all-uses-of-… Which call for an audit rule similar to: > -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F > auid!=4294967295 -k privileged-passwd However, on a container platform (e.g. OpenShift), the root user on nodes can execute chage in its own /usr/bin/ as well as within all the containers /var/lib/docker/<UUID>/bin/chage. What's the best way to capture this in OVAL rules? Was thinking updating the regex on path to include the full-path (/usr/bin/chage|/var/lib/docker/*/bin/chage).... but not sure if that's a standard path that would work for non-OpenShift platforms. +cc Jeff Pullen who asked the question. Jeff... note this is a *public* mailing list ;)

5 8

"Publish OpenSCAP scan metrics to CloudWatch and optionally send SNS notifications"
by Shawn Wells 09 Aug '18

09 Aug '18

Was told about a project that integrates OpenSCAP scanning into AWS CloudWatch. Thought it was pretty cool & wanted to share: > > Overview > > This openscap-aws rpm is intended to be used on CentOS or Red Hat AWS > instances and will configure them to self-scan each day, publish score > metrics to CloudWatch and optionally report any failures to an SNS > topic. As the scan score is a percentage of pass/fail findings and > some tests may not be applicable to your environment the use of a > tailoring file to specify which failures have been accepted by your > organization makes this much more effective because then you can > require that scans have a 100% score. > Code: https://github.com/ICFI/openscap-aws Docs: https://icfi.github.io/openscap-aws/docs.html

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide August 2018