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.
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
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.
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?
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 =/
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
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
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
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.orgopenscap.comopenscap.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.
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:
