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
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)
), and determine whether those controls
apply to Arch Linux (The SSG project did that activity for RHEL7 here.
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 Albrecht III, CISSP-ISSEP, GPEN, RHCSA
Cyber Architect, Lockheed Martin RMS
From: bradt(a)signatureresearchinc.com [mailto:firstname.lastname@example.org]
Sent: Monday, April 17, 2017 1:43 PM
Subject: EXTERNAL: Introduction and Questions
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,
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