scap-security-guide March 2017

scap-security-guide@lists.fedorahosted.org

9 participants
9 discussions

VMs, containers vs. bare-metal machines in SSG
by Martin Preisler 15 Aug '17

15 Aug '17

We have had increasing requests to scan containers and VM storage images for compliance. In those use-cases a lot of our rules don't make sense. For example separate partition for /tmp isn't really applicable to containers. I thought about how we can deal with this in SSG. We have several options: 1) Separate benchmark and datastreams for containers and VM storage images: ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml 2) Separate profile for containers and VM storage images: pci-dss and pci-dss-container 3) Use applicability and CPE platforms to distinguish between what is being scanned. That allows us to use the same pci-dss profile for bare-metal, VM, VM storage image and container image. Right now I am leaning towards 3) because it "unlocks" the feature transparently to our users. There is nothing extra they have to study to start scanning containers. The downside is that we will have to add "fake" CPE IDs for platforms like "vm-storage" and "container". Rules that apply to everything will have no <platform> element in them. Rules that apply to just containers will have something like: <platform idref="cpe:/a:*:container-image"/> or <platform idref="cpe:/a:*:vm-storage"/> Official NIST CPE ID dictionary has these related CPE IDs cpe:/a:redhat:docker:1.5.0-27 cpe:/a:linuxcontainers:lxc:0.5.0 cpe:/a:redhat:libvirt:1.2.7 Not sure we want to go with any of those though. I would like to keep it container and VM tech agnostic. Before I start hacking this I would like to hear your thoughts. -- Martin Preisler Identity Management and Platform Security | Red Hat, Inc.

7 12

SCAP Security Guide 0.1.32
by Watson Yuuma Sato 30 Mar '17

30 Mar '17

Hello folks, We have the pleasure to announce that SCAP Security Guide version 0.1.32 has has been release. Highlights of this release: * New CMake build system * Improved NIST 800-171 profile * Initial RHVH profile * New CPE to identify systems like machines (bare-metal and VM) and containers (image and container) * Template clean up in lots of remediations 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/OpenSCAP/scap-security-guide/releases/tag/v0.1.32 Full changelog at: * https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.32 Zip archives with pre-built benchmarks in DataStream form: * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/s… (Zip archive using OVAL-5.11.1 language version) * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/s… (Zip archive using OVAL-5.10 language version only) Thank you to everyone who contributed with issues, patches and discussion. Happy hardening! With regards, Watson Sato -- Watson Sato Security Technologies | Red Hat, Inc

2 2

findings not being detected properly.
by alsifius＠gmail.com 30 Mar '17

30 Mar '17

There are several items that are showing failures in spite of remediation. Where is the best place to search/file findings such as these. As an example, the scan fails even though the boot loader password is enabled and the root user is not listed. Thank you. -Al

5 11

troubleshooting with cmake
by Shawn Wells 29 Mar '17

29 Mar '17

still learning how to troubleshoot build processes with the new CMake system (which I do love!). Ran a build, got this: > -- Scanning for dependencies of ubuntu1604 OVAL checks... > -- Scanning for dependencies of wrlinux bash remediations... > -- Scanning for dependencies of wrlinux ansible remediations... > -- Scanning for dependencies of wrlinux puppet remediations... > -- Scanning for dependencies of wrlinux anaconda remediations... > -- Scanning for dependencies of wrlinux OVAL checks... > -- Scanning for dependencies of webmin bash remediations... > -- Scanning for dependencies of webmin ansible remediations... > -- Scanning for dependencies of webmin puppet remediations... > -- Scanning for dependencies of webmin anaconda remediations... > -- Scanning for dependencies of webmin OVAL checks... > -- Configuring incomplete, errors occurred! > See also > "/var/www/html/scap-security-guide/build/CMakeFiles/CMakeOutput.log". The log doesn't tell me much: > $ cat /var/www/html/scap-security-guide/build/CMakeFiles/CMakeOutput.log > The system is: Linux - 3.10.0-514.6.1.el7.x86_64 - x86_64 Is there a verbose mode hiding somewhere?

2 1

xccdf_org.ssgproject URN
by Shawn Wells 28 Mar '17

28 Mar '17

We currently use "xccdf_org.ssgproject" -- should this be changed to "xccdf_io.openscap" or "xccdf_org.open-scap"? Has been bugging me for awhile. For downstream, should we use xccdf_com.redhat?

2 1

RDO Newton Openstack system scan using scap security guide
by shriprakash sikariwal 27 Mar '17

27 Mar '17

Hi, Could you please share brief write up to scan RDO Newton openstack system (deployed with packstack on RHEL 7.3) using scap security guide. Regards Shri Prakash

1 0

Incorporating final DISA STIG / Release
by goobsoft＠gmail.com 24 Mar '17

24 Mar '17

DISA has released a STIG for RHEL 7. redhatrises updated an overlay to account for the final release from DISA of RHEL7 STIG. What additional work, if any, needs to be done to SSG in order for oscap to be able to scan relative to the final DISA STIG for RHEL 7? When I clone the github repository, run cmake and examine build/ssg-rhel7-ds.xml, it shows xccdf_org.ssgproject.content_rule_encrypt_partitions select="true" for profile *STIG for Red Hat Enterprise Linux 7 Server Running GUI*. When I load up the final RHEL7 STIG, I can't find any vulnerability related to unencrypted partitions. Am I missing the vulnerability in the STIG, or is the SSG adding security checks to the profile? Thanks, Chad

3 2

RFC: chef.io Inspec
by nevion＠gmail.com 22 Mar '17

22 Mar '17

Hi folks, I've watched the project for a couple of years now and done some work with it. I'm grateful many of you took the time to get SSG where it's at. Recently I came across chef.io's Inspec and I thought hey, this seems to solve alot of the engineering challenges the SSG project seems to have, especially with multi-distro support. Github: https://github.com/chef/inspec Product: https://www.chef.io/inspec/ Here are some of the benefits my eyes see: * Content is centralized (less mutli-file editing for the same tests aka less XMHell :-) * Content is encouraged to be less distribution specific but allowed to be as specific as it needs, and this is encouraged inside a module, meaning less versions are floating around in the codebase * Declarative/Programmatic as opposed to Declaritive/document oriented - I'd say with the later case has led to somewhat awkward and hard write tests, in some cases * Can test active configuration as well as configuration file state * Looks significantly less verbose - as in saving 10x lines of sourcecode (not counting XML output) and developer productivity would be much higher * and as a possible benefit, I wouldn't be surprised if tests ran much faster - though I have done no extensive tests to show this. Most importantly I believe inspec could pave the way to all distros working off of a common and smaller codebase than the existing SSG implementation and be far less maintenance burden and as such I wanted to raise awareness and get a topic going on the ML. Inspec doesn't seem compatible out right with openscap (or maybe it is - they have bidirectional oval/xccdf consumers/emitters), but it IS aiming to replace OVAL/XCCDF as something more sane and just plain old better for the tasks. They also have tools for running it without scap tools involved of course so it doesn't have to lean on openscap et al, but for some people being seperate from SCAP tools is going to be a con and not a pro.

6 8

RFC: chef.io Inspec
by nevion＠gmail.com 12 Mar '17

12 Mar '17

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2017