scap-security-guide April 2017

scap-security-guide@lists.fedorahosted.org

16 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

CCE status
by 面和毅 28 Apr '17

28 Apr '17

Folks, I'm not sure this ML is correct place to ask or not, but I'm wondering the status of CCE. https://nvd.nist.gov/config/cce/index It seems these CCE quite old, so does somebody know how is the status for new version of CCE? Kind Regards, OMO -- Kazuki Omo: ka-omo(a)sios.com OSS &Security Evangelist OSS Business Planning Dept. CISSP #366942 Tel: +81364015149

2 4

Anyone going to Summit next week?
by Shawn Wells 28 Apr '17

28 Apr '17

Figured there would be more than a few OpenSCAP community members at Summit next week. Anyone want to meetup for food/drinks at some point? I know Martin, Robin and myself will be there all/most of the week.

5 4

OVAL+remediations for SELinux booleans
by Shawn Wells 25 Apr '17

25 Apr '17

We have several sebool XCCDFs in shared/xccdf/system/selinux, however it appears OVAL and remediations are not being generated. For example from shared/xccdf/system/selinux.xml : > <Rule id="sebool_fips_mode" severity="medium" prodtype="rhel7"> > ...... > <oval id="sebool_fips_mode" /> > </Rule> Which has an entry in the selinux_booleans.csv file: > $ grep -rin fips_mode shared/templates/selinux_booleans.csv > 52:fips_mode,enable After running a make, no OVAL gets attached in the datastream: > <ns0:Rule > id="xccdf_org.ssgproject.content_rule_sebool_fips_mode" > selected="false" severity="medium"> > ..... > <ns0:ident > system="https://nvd.nist.gov/cce/index.cfm">CCE-80418-7</ns0:ident> > <ns0:check system="http://scap.nist.gov/schema/ocil/2"> > <ns0:check-content-ref href="ssg-rhel7-ocil.xml" > name="ocil:ssg-sebool_fips_mode_ocil:questionnaire:1"/> > </ns0:check> > </ns0:Rule> So I cleaned out my build directory and re-ran 'make -j4 rhel7' and saw some errors: > WARNING: OVAL check 'sebool_abrt_upload_watch_anon_write' was not > found, removing <check-content> element from the XCCDF rule. > WARNING: OVAL check 'sebool_antivirus_can_scan_system' was not found, > removing <check-content> element from the XCCDF rule. > WARNING: OVAL check 'sebool_auditadm_exec_content' was not found, > removing <check-content> element from the XCCDF rule. > WARNING: OVAL check 'sebool_cron_userdomain_transition' was not found, > removing <check-content> element from the XCCDF rule. Is there a reason the seboolean checks aren't getting build into datastreams?

2 2

utility to check what rules do not have remediations?
by Shawn Wells 24 Apr '17

24 Apr '17

IIRC there once was a python script laying around that generated a list of rules that do not have remediations. Does that still exist? Dug through the directory tree with no love. Probably staring me in the face =/

2 2

references in shared rules
by 0x2a 24 Apr '17

24 Apr '17

Hello, I noticed that the shared XCCDF rules are mainly used for RHEL7 and are missing references for other OSs, so I would like to add them. Could you give some examples for the correct syntax? adding e.g. <ref prodtype="debian8" cis="9.3.2"/> has no effect if there is an element for rhel present. regards, 0x2a

1 0

Introduction and Questions
by bradt＠signatureresearchinc.com 19 Apr '17

19 Apr '17

Hello, My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems. We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval. Thanks for your help, Tim

7 9

Arch Linux STIG ( was RE: Introduction and Questions)
by Albrecht, Thomas C 17 Apr '17

17 Apr '17

Tim, Such a simple question has so much complexity behind it. :-) SCAP is really just a language for verifying and imposing a defined configuration baseline on a specific target. From a Linux standpoint, there are two major elements for "getting SCAP up and running". One is running a SCAP engine (OpenSCAP, SCC, etc.) to test a baseline, and the other is identifying the baseline you're using to test against. So, if you're simply charged with getting a SCAP engine running on your system, you could do the work needed to convert OpenSCAP or SCC to run on Arch. There is an AUR project for this that seems to still be maintained (https://aur.archlinux.org/packages/openscap/). The more complicated question is about STIGing Arch. As far as I know, it hasn't been done. There has been work on getting the RHEL6/7 STIGs SSG ported over to CentOS6/7, but that's a less complicated endeavor, since the baselines are almost identical. Arch is a different beast entirely, and would involve hundreds of hours of work. The concern, though, is at the end of the day, even if you did the work, you'd need to be careful what you're asserting to your customer. Any conversion you did would not be an official STIG, but a derivative work to meet the intention of the STIG. DISA has a process creating a STIG for a new operating system (which is what this activity would be), and it would involve starting with the Control Correlation Identifiers (CCIs) (http://iase.disa.mil/stigs/cci/Pages/index.aspx), and determine whether those controls apply to Arch Linux (The SSG project did that activity for RHEL7 here. https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Settings-Re…). Once that's completed, you would then create a STIG that maps to the OS configurations to the CCIs, including how to audit a configuration, and how to set a configuration. DISA does have a process once you've done that work to have the STIG submitted for inclusion in their repositories. (PostgreSQL is an open source project that just had a STIG approved by DISA.) The other (easier) option if your customer already understands the position you're in with using Arch Linux is to use the General Purpose Operating System STIG instead of going back to the CCIs. If you start with the General Purpose STIG, you can create your own derivative STIG that identifies how to configure Arch to meet each of those different items. It's a bit of work, and you'd still have to get some sort of validation from your customer that the STIG you author is valid for your systems. The other complexity is that even if you go through either of those processes (CCI --> Arch STIG, or GPOS STIG --> Arch STIG), you still only have a document for manual evaluation. Creating SCAP benchmarks for automated SCAP testing would be the next step you're looking for, and involves the hundreds of hours of time that I mentioned above. It's not an easy task to undertake. Hope this doesn't discourage you too much. If I were in your shoes, I would do the work to create an approve Arch STIG based on either of those options, and then create your own means for applying and verifying those configurations on your system, using some method of configuration automation, rather than trying to tackle the steep learning curve that is SCAP. Tom A. -- Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA Cyber Architect, Lockheed Martin RMS thomas.c.albrecht(a)lmco.com -----Original Message----- From: bradt(a)signatureresearchinc.com [mailto:bradt@signatureresearchinc.com] Sent: Monday, April 17, 2017 1:43 PM To: scap-security-guide(a)lists.fedorahosted.org Subject: EXTERNAL: Introduction and Questions Hello, My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems. We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval. Thanks for your help, Tim _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org

1 0

ssgproject.org URN
by Shawn Wells 10 Apr '17

10 Apr '17

A recent PR on GitHub that called out how datastreams use ssgproject.org, but that domain doesn't exist. Registered it and extended the renewal on existing domains. Means the following redirect to open-scap.org: openscap.org openscap.com openscap.net openscap.io ssgproject.org Don't believe the community ever used scapsecurityguides.{com net org}, so planning to let them expire unless anyone has objections.

4 3

Tracking towards OpenSCAP/SSG--DISA alignment
by Shawn Wells 03 Apr '17

03 Apr '17

Was speaking to some of the SSG development community this morning. We talked through how to track what's needed to align SSG content to that released by DISA. To help keep track of things, here is the GitHub Milestone view that outlines all open tickets: https://github.com/OpenSCAP/scap-security-guide/milestone/29 Alternatively expressed as kanban-style: https://github.com/OpenSCAP/scap-security-guide/projects/7 As we go through the DISA content, we'll want to keep track of any errors noticed. A dashboard to keep track: https://github.com/OpenSCAP/scap-security-guide/projects/8 If you enter a ticket against the DISA-provided content, label it with "DISA Content Issues" and it'll be added to the dashboard:

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide April 2017