scap-security-guide July 2017

scap-security-guide@lists.fedorahosted.org

14 participants
10 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

Re: [SSG] unlicenced and public domain
by Fen Labalme 29 Jul '17

29 Jul '17

On Fri, Jul 28, 2017 at 12:23 PM, Shawn Wells <shawn(a)redhat.com> wrote: > > On 7/27/17 12:38 AM, Fen Labalme wrote:... > > ...Red Hat legal or a private attorney, such as SFLC, might be able to > tell him how this all applies to his situation." > > > So he's saying the DoD legal guidance is wrong? I don't understand. > I'm not sure where you saw a suggestion that the DoD guidance was incorrect.

1 0

[SSG] unlicenced and public domain
by phil＠reseau-libre.net 28 Jul '17

28 Jul '17

Hi All, I'm sending you that little e-mail because i'm confronted to a specific license constraint while i have to declare my personal work as i'm working for French government. My manager told me that in France i can't declare my contribution as being in the public domain as the french civil code doesn't permit an author to completely loose all the copyright of a given content (not for the public domain, which can be reach only after years). What is possible is to use a very permissive license such as BSD-2 clause license for my work. Do you think, as it's already done for some of the SSG files copyrighted by Red-Hat, to set a BSD-2 clause copyright to the Debian/ and Ubuntu/ dir ? Maybe reducing them to the lonely content i write (and not the whole dir content, which contains files that have also be written by others) would be better ? Thanks ! -- Philippe THIERRY Software Engineer, Phd RT and hardened Embedded Systems

6 12

Re: Loss of EL7 STIG profiles
by Reese, Brian J CTR (US) 26 Jul '17

26 Jul '17

Thank you for the update Ted. That had been my expectation, so it's good to hear it confirmed. I figured it was just a matter of time because the first revision of the RHEL 7 STIG was only released in March earlier this year. I assume that DISA does something similar for the RHEL 6 content because I occasionally see SSG referenced in the Revision History for RHEL 6 STIG updates. v/r, Brian -----Original Message----- From: Ted Brunell [mailto:tbrunell@redhat.com] Sent: Wednesday, July 26, 2017 2:04 PM To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> Subject: [Non-DoD Source] Re: Loss of EL7 STIG profiles All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ We are making progress. Still waiting to hear back on a couple of issues, but progress is being made. For others that may not know of the effort that Shawn eluded to.. I work closely with DISA in my role at Red Hat. We have a goal to eventually, align the SSG and STIG content. The benefit of everyone is that if you use SSG to do something like lock down the OS while it is being provisioned, or to periodically scan a system from Satellite server, the results of those scan will be identical to a scan using ACAS. The end result is a security posture that is much easier to maintain and a great chance that any configuration drift will not occur. R/ Ted On Wed, Jul 26, 2017 at 1:51 PM, Shawn Wells <shawn(a)redhat.com < Caution-mailto:shawn@redhat.com > > wrote: On 7/26/17 1:48 PM, Ted Brunell wrote: > I want to clarify something that was mentioned about automation > content earlier in this thread... > > I communicate on a regular basis with the people at DISA that are > responsible for STIG and SCAP content. They have verified that DISA > is planning on releasing automation content (aka benchmark) containing > the necessary files for RHEL 7 in the not too distant future. I am > not sure exactly when it will be released, but when it is, it will be > posted for consumption at > Caution-http://iase.disa.mil/stigs/scap/Pages/index.aspx < Caution-http://iase.disa.mil/stigs/scap/Pages/index.aspx > under SCAP 1.2 content. > > Currently, they are reviewing the SSG content for use in the benchmark > content. Nice! Thanks Ted! Great to hear they've changed their minds. Would be *fantastic* to bring DISA back into the fold of what DoD, NIST, NSA, the community, and Red Hat are doing on STIG work! How goes the work with DISA to align their content to the DoD recommended settings? _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org < Caution-mailto:scap-security-guide@lists.fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org < Caution-mailto:scap-security-guide-leave@lists.fedorahosted.org >

2 1

Re: Loss of EL7 STIG profiles
by Reese, Brian J CTR (US) 26 Jul '17

26 Jul '17

Hello, I can think of a few reasons why DISA would release its own automation content even though it can be obtained direct from Red Hat, and I'm discouraged by your statement that DISA does not plan on releasing automation content for RHEL 7. First, my understanding is that the SSG content is primarily written and tested against OpenSCAP. However internally within DoD, the primary "approved" SCAP tools are the SPAWAR SCC and McAfee Policy Auditor (Nessus/Security Center also support it as part of the ACAS program). I know as long as it's compliant with the spec it "should" work, but there could always be issues. DISA published content however is tested with these tools. Second, does the SSG content have the appropriate metadata to be ingested by DISA tools and reporting requirements? I'm thinking about things like the Rule ID, Vulnerability ID, DoD Severity, etc. Can the output from the SSG content be imported into a STIG checklist using the DISA STIG Viewer (http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx)? Finally, DoD auditors might not accept the results using vendor-provided SCAP content/tools over content and tools have been officially released and tested by DISA, which means for RHEL 7, assessors will have to resort to doing manual reviews of the STIG. I apologize if some of this has already been discussed, but I've mostly been working with RHEL 6, which DISA currently releases content for, so I've only casually been following SSG and have not personally used it. v/r, Brian Reese -----Original Message----- From: Shawn Wells [mailto:shawn@redhat.com] Sent: Thursday, July 20, 2017 7:11 PM To: scap-security-guide(a)lists.fedorahosted.org Subject: [Non-DoD Source] Re: Loss of EL7 STIG profiles All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ On 7/20/17 4:13 PM, Moessbauer, David wrote: All, Our program is currently working through the architecting of the next release, and the decision point is upon us WRT OS version - RHEL6 or RHEL7. One significant factor (at least from a cybersecurity perspective, is the ability to efficiently / effectively conduct STIG reviews via the SCAP tools. This said, is there any place I could ascertain the projected release of the RHEL 7 Benchmarks? I apologize if this is not the appropriate venue for such a question, or if it is so obviously in front of me I should already know, but honestly I have not closely monitored this feed of late, since I have been stuck in the RHEL 5 world and trying to keep the system secure in that context. RHEL 6.4+ and RHEL7.x ship automation content. It sounds like your systems are very long-lived, given that you're dealing with RHEL5. Note that RHEL6 is has entered "Production Phase 3" which means no new features or hardware enablement [0]. If you're asking for when *DISA* will release automation content: They've stated they have no intention to release automation content for Red Hat STIGs moving forward. This isn't terrible... e.g. why should DISA release automation content when it's delivered natively in the platform (via the SCAP Security Guide)? [0]Caution-https://access.redhat.com/support/policy/updates/errata#Productio… < Caution-https://access.redhat.com/support/policy/updates/errata#Production_… >

8 16

Logos and other materials for SCAP projects
by Martin Preisler 22 Jul '17

22 Jul '17

Hi, I have gathered all the logos and other graphics and put them into a GitHub repository to make sure they don't get lost. Most of these (if not all) have been created by Lenka Horakova. https://github.com/OpenSCAP/promo If you have any other materials we'd appreciate pull requests. I'd also appreciate tips and recommendations how to make nice and reasonably priced sticker sheets . Maybe we could even try to get t-shirts done with these. -- Martin Preisler

3 3

Loss of EL7 STIG profiles
by Chuck Atkins 21 Jul '17

21 Jul '17

I've been using the SCAP Security Guide for the past two years to manage the lock down and deployment of EL7 machines in our lab and one of the best features I've seen is the move from a single "STIG for Red Hat Enterprise Linux" profile targeting servers to three separate profiles for Server, Server with GUI, and Workstation. I just used the EL7 STIG Workstation profile this week with the SSG in the EL7 repos. It's extremely useful to me since all of our machines are used as workstations, not servers, so to have a profile that works out of the box without needing to do excessive customization, and in turn, justification of said customizations is very handy. So imagine my surprise and dismay when I used the most recent release from the Copr repo and discovered that my convenient separate profiles were now all gone to align with the recently released singular DISA server profile. Are there any plans with the various contributors involved (RH, DoD, others, etc.) to re-work the server STIG profile again to have a separate upstream-supported STIG profile for Workstation usage? Having it in previous releases has proven to be an extremely useful feature and I would hate to see it regress back to "Linux is just for servers". ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc.

4 4

Re: GitHub Org Membership --> public
by Shawn Wells 19 Jul '17

19 Jul '17

On 7/18/17 7:40 AM, Fen Labalme wrote: > Hi Shawn, > > I would like to be added to the OpenSCAP people list - my github > account is "openprivacy". Done!

2 3

Re: [OpenSCAP/scap-security-guide] SSG updates for NIST 800-53 rev4? (#2135)
by Shawn Wells 19 Jul '17

19 Jul '17

On 7/18/17 5:53 AM, Gary Gapinski wrote: > > References attached. Input was RHEL7 XCCDF build from master branch. > refs.zip > <https://github.com/OpenSCAP/scap-security-guide/files/1155357/refs.zip> > > The origins of these are found subordinate to |shared/xccdf| (there > are 853 occurrences, many of which have no NIST citation, with 5 > others in |RHEL/7/input/auxiliary/nist_support.xml|). The "raw" > citations reference only controls, not revision+control, so any > cleanup accommodating multiple 800-53 revisions would require altering > not only the |<ref>|s but the build logic. > (taking this to mailing list, since not directly related to PR) Gary - Your stylesheet is way better than existing SSG one. Can you share the code used to generate this?

1 0

GitHub Org Membership --> public
by Shawn Wells 18 Jul '17

18 Jul '17

Was demoing OpenSCAP on a webinar today and someone noticed our OpenSCAP crew looks like it's only three people on GitHub: For those willing, can you mark your GitHub group membership as public? Lets show the world there are more than 3 people here :) 1) Login to GitHub 2) Find your name @ https://github.com/orgs/OpenSCAP/people 3) On the left-hand side, select "public" under membership: It may sound silly, but people (apparently) notice these things.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide July 2017