scap-security-guide November 2016

scap-security-guide@lists.fedorahosted.org

11 participants
11 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.31
by Watson Yuuma Sato 29 Nov '16

29 Nov '16

Hi folks, We have the pleasure to announce that SCAP Security Guide release 0.1.31 has been created. Highlights of this release: * New Wind River Linux profiles, * Various STIG profile enhancements, * Ubuntu Xenial product has been added, * Support for Ansible remediations, * Refactored build process, with more shared content * The build system for RPM is simpler now, * SCAP benchmark for Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 passes official NIST SCAP Content Validation Tool 1.2.1.15 requirements. 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.31 Full changelog at: * https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.31 Zip archives with pre-built benchmarks in DataStream form: * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.31/s… (Zip archive using OVAL-5.11.1 language version) * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.31/s… (Zip archive using OVAL-5.10 language version) As this is one of the biggest SSG releases ever made, the team would like to give a great thank you to all contributors. Happy hardening! With regards, Watson Sato (on behalf of the SCAP Security Guide upstream team)

3 3

How should we expand commit access to SSG?
by Shawn Wells 29 Nov '16

29 Nov '16

SSG originated from NSA. They collaborated with Red Hat to help build a community and author content for RHEL. The community has since expanded -- both in terms of people from across the world and content beyond Red Hat related things. Success! As our community and content expands, we should figure out how to handle commit access to the SSG repo. Some 95 people have submitted code patches to SSG [0]. 18 of them have currently have commit/merge access. The vast majority of the merge-access group are Red Hat staff, followed by trusted partners like Gabe/redhatrises and Joe/joenall, a then smidge of government (NSA, DISA FSO). With content being developed and maintained for Ubuntu and WRLinux, I think it makes sense to those "core maintainers" commit access. These are the people who care most deeply for that body of content and have shown good judgement to determine what's best for the overall code base, their particularly content of interest, and broader community. These individuals would still follow normal PR processes for their own code, but could merge PRs of others. IMHO, the "Managing Participants" section of Karl Fogel's 'Producing Open Source Software' book has a well thought out approach: http://producingoss.com/en/committers.html In short: /It's not about complexity or frequency or code contributions because there are many non-programmer contributors. Elevate privileges of those who show good judgement and community stewardship.// / Then there's the procedural side. Who has a say in who gets commit access? Where does deliberation happen? Having a 'public vote' on the mailing list risks turning into a popularity contest. Having a 'secret council' risks loosing community trust. Both situations are equally unappealing. I'm not really sure to handle this. And I recognize I'm likely over thinking this! Historically, it has been fairly apparent who should get merge access and when. Generally these decisions were met by the community with "yeah, $person totally makes sense!" Access was granted by Jeff Blank or myself after we ran it by a few other communicate members. Simon (now Martin) maintain appropriate accesses for the full-time Red Hat engineers. This model has worked well for us so I propose keeping with it. The guiding principal remains good judgement and community stewardship. We now have many new community members and several new bodies of content being developed. Even if we remain on the same process it seems healthy to revisit the conversation on-list. [0] http://people.redhat.com/swells/gitstats/ssg/

4 6

Fwd: [OpenSCAP/scap-security-guide] Removed the old JBossFuse6 content, this content is obsolete and does… (#1594)
by Shawn Wells 28 Nov '16

28 Nov '16

Moving this on-list. I don't believe Jason and Bryan are tracking GitHub. Bryan, Jason: Some time ago you guys (+Kenny Peeples) wrote SCAP code for Fuse6. Is that still in use? -------- Forwarded Message -------- Subject: [OpenSCAP/scap-security-guide] Removed the old JBossFuse6 content, this content is obsolete and does… (#1594) Date: Mon, 28 Nov 2016 13:03:49 -0800 From: Martin Preisler <notifications(a)github.com> Reply-To: OpenSCAP/scap-security-guide <reply+00572f5aba2d6714bd7d20536a1674d0e64db90bd8eb679a92cf0000000114545db592a169ce0b73771b(a)reply.github.com> To: OpenSCAP/scap-security-guide <scap-security-guide(a)noreply.github.com> …n't work. It has been replaced by |JBoss/Fuse/6| content. The XCCDF of the old content has been broken by 99361a0 <https://github.com/OpenSCAP/scap-security-guide/commit/99361a005b8738bd9463…> and nobody ever complained -- the |Benchmark| element was removed. Therefore I think nobody is using this. The OVAL doesn't validate either... *THIS IS CONTROVERSIAL, PLEASE WAIT A BIT BEFORE MERGING* If nobody speaks out in a week I think it's safe to merge. Do we want to remove the JBossEAP5 content as well? It has been obsoleted by |JBoss/EAP/5|. ------------------------------------------------------------------------ You can view, comment on, or merge this pull request online at: https://github.com/OpenSCAP/scap-security-guide/pull/1594 Commit Summary * Removed the old JBossFuse6 content, this content is obsolete and doesn't work * Do not put JBossFuse6 in the tarball with `make tarball` File Changes * *D* JBossFuse6/LICENSE <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-0> (24) * *D* JBossFuse6/README <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-1> (12) * *D* JBossFuse6/build.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-2> (20) * *D* JBossFuse6/docs/JBossFuse6_Guide.html <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-3> (771) * *D* JBossFuse6/docs/guide_content.xls <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-4> (0) * *D* JBossFuse6/docs/jboss_logo.png <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-5> (0) * *D* JBossFuse6/docs/rule_template.vt <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-6> (59) * *D* JBossFuse6/ssg-fuse6-cpe-dictionary.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-7> (10) * *D* JBossFuse6/ssg-fuse6-cpe-oval.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-8> (68) * *D* JBossFuse6/ssg-fuse6-ocil.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-9> (33) * *D* JBossFuse6/ssg-fuse6-oval.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-10> (33) * *D* JBossFuse6/ssg-fuse6-xccdf.xml <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-11> (1583) * *D* JBossFuse6/xsl/requirements.html <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-12> (12) * *D* JBossFuse6/xsl/steps_to_run.html <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-13> (30) * *D* JBossFuse6/xsl/xccdf2xhtml.xsl <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-14> (279) * *M* Makefile <https://github.com/OpenSCAP/scap-security-guide/pull/1594/files#diff-15> (1) Patch Links: * https://github.com/OpenSCAP/scap-security-guide/pull/1594.patch * https://github.com/OpenSCAP/scap-security-guide/pull/1594.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/OpenSCAP/scap-security-guide/pull/1594>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFcvWsZ00_mJ67IQPfNvYCqY-…>.

1 0

Ansible playbooks to setup OpenSCAP workshop
by Shawn Wells 17 Nov '16

17 Nov '16

I've been giving a few OpenSCAP/SSG workshops lately, and with the help of Brad Sollar (Red Hat colleague), published customized Ansible playbooks to provision student environments on EC2: https://github.com/OpenSCAP/workshop-ansible-setup The README should have everything needed to get started. Admittedly, it's likely that mostly Red Hatters may be excited about this. Wanted to get the code published though. Hope this is useful to others! shawn

2 2

Integration Etiquitte
by Trevor Vaughan 14 Nov '16

14 Nov '16

Hi All, After much delaying, we're hoping to start integrating our SIMP-specific methods for meeting the various policy requirements directly into the SSG. Unfortunately, this is providing to be a bit hairy and I'd like to know what you would prefer. ## Option 1: Fork the Entire RHEL base into SIMP/{6,7} etc... - We're not another OS, we're a specific (flexible) configuration set for RHEL and/or CentOS - I'd really like to avoid this ## Option 2: Muck about directly in the RHEL space - This is my preference and I can 100% start with a set of profiles that mirror the existing profiles. I guess this would be prefaced with 'simp'. So, simp-C2S.xml, simp-pci-dss.xml, etc... - We will also need to add alternate OVAL checks that are specific to SIMP. For instance, per policy, our auditd file is optimized, this means that none of the included checks will pass and we need alternate checks. And no, in general, there is no way to determine if you're on a SIMP system unless it's the Puppet Server. It's just RHEL. Advice appreciated. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

2 5

Adding rules for SUSE.
by S, Gautam 08 Nov '16

08 Nov '16

Hello, I am trying to test how new rules can be added to SUSE. I could not find any documentation so this is what I have done so far: 1) Added a new file input/xccdf/system/permissions/files.xml with a couple of rules to check file ownership and permissions of the passwd file. These are copies on the same in RHEL/6 folder. 2) Updated the guide.xslt file for including this group. 3) Added "<platform>multi_platform_sle</platform>" to the appropriate OVAL checks in shared/oval. 4) Added "# platform = multi_platform_sle" to the appropriate fix scripts in /shared/templates/static/bash. 5) Modified Make to remove CentOS related operations from derivatives, guide and validate because they were breaking and are possibly not relevant to SUSE anyhow. With this I am able to complete the build without errors and generate the output files. [Make fails for the latest sources fetched from the git repo] I would like to start contributing the rules into SUSE directory. Would the above process be alright? Also, I do not know what needs to be done for the reference and ident tags in XCCDF. Please advise. Thank you. Regards, Gautam.

5 7

RE: VMs, containers vs. bare-metal machines in SSG
by Radzykewycz, T (Radzy) 07 Nov '16

07 Nov '16

________________________________________ > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> Mon, 7 Nov 2016 17:45:42 +0000 > > Hi Radzy. > > Are you trying to bundle everything into one XCCDF? If so, > you may be making the problem harder than it needs to be. Hi Brent No, I'm not trying anything yet. I'm just looking ahead to what I expect my next task will be, and trying to make sure I understand enough background information to be able to proceed when I get to it. I'll interpret your comment as a recommendation that I plan on using multiple XCCDFs. And probably multiple OVALs as well. I do want to minimize the amount of cut-n-paste duplication. So it would be nice if some of the minor differences can be handled by a single file with selectable options. If that won't work, or if it's too difficult, then I'll go ahead with the cut-n-paste. But I think it's worth spending some time to avoid it. Enjoy! -- radzy > -----Original Message----- > From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] > Sent: Friday, November 4, 2016 4:52 PM > To: scap-security-guide(a)lists.fedorahosted.org > Subject: RE: VMs, containers vs. bare-metal machines in SSG > > > ________________________________________ > > -----Original Message----- > > From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] Friday, > > October 21, 2016 1:16 PM > > > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> As opposed to > > > writing one XCCDF, why not write one XCCDF per point of interest > > > (inside the container of interest, inside the OS but outside the > > > container of interest, ...) - until upstream standards address > > > Origin, Point (in SpaceTime), Frame of Reference, ... for a > > > cyber-physical assembly? > > > > When I start working on our container environment, I expect I need to > > write custom XCCDF and custom OVAL for some of the checks. > > Some of the management may be done in the container, but I expect most > > to be done in the underlying host. So paths may be different, which > > would lead to either more complex OVAL with parameterization, or > > duplication of the OVAL content. > > > > And as implied elsewhere, the XCCDF needs to be modified to indicate > > the correct information for the environment. > > > > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> Wed, 2 Nov 2016 > > 19:52:29 +0000 (edited) Hi Radzy. > > Assuming a strawman consisting of: one OS(i.e. apps, libraries, > > OSxContainer-Interface, etc.); and one container(i.e. app, libraries, > > ContainerxOS-Interface, etc.). > > > > There is > > one XCCDF for the OS (baseline) > > one XCCDF for the container (delta) > > one XCCDF for OS + container (net) > > one XCCDF for OS union net (max) > > one XCCDF for max - (OS intersection net ) (min) > > > > The last XCCDF is: > > one XCCDF for OS intersection net (min) > > > > Whereas functionality at risk of eclipse is > > max - (OS intersection net ) > > Hi Brent > > Right. Thanks for the enumeration. > > I still need to look into two questions: > > - Can I use docker to support what I need to do ? Since OpenSCAP > does have some kind of docker support built-in, and I haven't > looked at it, this might be less work. But I need to look > into it. > > - Can I use some kind of a prefix variable to minimize the amount > of duplication. Then I could have a profile for the OS and one > for each container, and specify a procedure where both profiles > are run with independent oscap commands. Then some XCCDF for > the other cases not covered by those two, possibly in a third > oscap invocation.. > > And of course, there's always the possibility that some aspects of both will be useful. And the likelyhood that I'll need to do something custom. > > Enjoy! > > -- radzy

2 1

RE: VMs, containers vs. bare-metal machines in SSG
by Radzykewycz, T (Radzy) 07 Nov '16

07 Nov '16

________________________________________ > -----Original Message----- > From: Radzykewycz, T (Radzy) [mailto:radzy@windriver.com] Friday, October 21, 2016 1:16 PM > > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> As opposed to > > writing one XCCDF, why not write one XCCDF per point of interest > > (inside the container of interest, inside the OS but outside the > > container of interest, ...) - until upstream standards address Origin, > > Point (in SpaceTime), Frame of Reference, ... for a cyber-physical > > assembly? > > When I start working on our container environment, I expect I > need to write custom XCCDF and custom OVAL for some of the checks. > Some of the management may be done in the container, but I expect > most to be done in the underlying host. So paths may be different, > which would lead to either more complex OVAL with parameterization, > or duplication of the OVAL content. > > And as implied elsewhere, the XCCDF needs to be modified to > indicate the correct information for the environment. > > From: Brent Kimberley <Brent.Kimberley(a)Durham.ca> Wed, 2 Nov 2016 19:52:29 +0000 (edited) > Hi Radzy. > Assuming a strawman consisting of: one OS(i.e. apps, libraries, > OSxContainer-Interface, etc.); and one container(i.e. app, > libraries, ContainerxOS-Interface, etc.). > > There is > one XCCDF for the OS (baseline) > one XCCDF for the container (delta) > one XCCDF for OS + container (net) > one XCCDF for OS union net (max) > one XCCDF for max - (OS intersection net ) (min) > > The last XCCDF is: > one XCCDF for OS intersection net (min) > > Whereas functionality at risk of eclipse is > max - (OS intersection net ) Hi Brent Right. Thanks for the enumeration. I still need to look into two questions: - Can I use docker to support what I need to do ? Since OpenSCAP does have some kind of docker support built-in, and I haven't looked at it, this might be less work. But I need to look into it. - Can I use some kind of a prefix variable to minimize the amount of duplication. Then I could have a profile for the OS and one for each container, and specify a procedure where both profiles are run with independent oscap commands. Then some XCCDF for the other cases not covered by those two, possibly in a third oscap invocation.. And of course, there's always the possibility that some aspects of both will be useful. And the likelyhood that I'll need to do something custom. Enjoy! -- radzy

2 1

Fwd: fedorahosted.org retirement 2017-02-28
by Shawn Wells 04 Nov '16

04 Nov '16

Had an EMail exchange with Kevin Fenzi of FedoraHosted. While the git+svn repos are being shutdown, the mailing list is being sustained for the forseable future. We should not be impacted by the FedoraHosted-->Pagure changes. -------- Forwarded Message -------- Subject: fedorahosted.org retirement 2017-02-28 Date: Thu, 03 Nov 2016 23:32:36 +0000 From: kevin(a)fedoraproject.org To: shawndwells(a)fedoraproject.org Greetings. You are getting this email because your Fedora account has TRAC_ADMIN on one or more trac projects at fedorahosted.org. We are planning to retire fedorahosted.org on 2017-02-28. See the announcement at: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.… You are listed as TRAC_ADMIN on the following fedorahosted.org projects: (If you have already moved your projects, please disreguard this email) satellite-security-guide scap-security-guide If you have any questions or concerns please feel free to reply to this email or: file a ticket: https://pagure.io/fedora-infrastructure/issues/ ask on irc: #fedora-admin on irc.freenode.net ask on list: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… Thanks, kevin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide November 2016