VMs, containers vs. bare-metal machines in SSG
by Martin Preisler
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.
6 years, 3 months
CCE status
by 面和毅
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
6 years, 7 months
Anyone going to Summit next week?
by Shawn Wells
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.
6 years, 7 months
OVAL+remediations for SELinux booleans
by Shawn Wells
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?
6 years, 7 months
utility to check what rules do not have remediations?
by Shawn Wells
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 =/
6 years, 7 months
references in shared rules
by 0x2a
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
6 years, 7 months
Introduction and Questions
by bradt@signatureresearchinc.com
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
6 years, 7 months
Arch Linux STIG ( was RE: Introduction and Questions)
by Albrecht, Thomas C
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-...). 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
6 years, 7 months