I find it interesting that DISA is not planning on publishing RHEL7 benchmark content for
use with SPAWAR SCC tool. Most of my DoD customers request non-compliance results in that
format.
As for accreditation the SCA-V teams are typically asking for STIG Viewer manual
checklists for each host during their site visits. I suppose if we can use oscap to
generate the results and then import them successfully into the STIG Viewer that would
suffice. The manual checklists would be painful to complete if you couldn't import
automated scan results.
Lee Meinecke
________________________________
From: Reese, Brian J CTR (US) <brian.j.reese.ctr(a)mail.mil>
Sent: Friday, July 21, 2017 9:04 AM
To: SCAP Security Guide
Subject: Re: Loss of EL7 STIG profiles
Hello,
I can think of a few reasons why DISA would release its own automation content even though
it can be obtained direct from Red Hat, and I'm discouraged by your statement that
DISA does not plan on releasing automation content for RHEL 7.
First, my understanding is that the SSG content is primarily written and tested against
OpenSCAP. However internally within DoD, the primary "approved" SCAP tools are
the SPAWAR SCC and McAfee Policy Auditor (Nessus/Security Center also support it as part
of the ACAS program). I know as long as it's compliant with the spec it
"should" work, but there could always be issues. DISA published content however
is tested with these tools.
Second, does the SSG content have the appropriate metadata to be ingested by DISA tools
and reporting requirements? I'm thinking about things like the Rule ID, Vulnerability
ID, DoD Severity, etc. Can the output from the SSG content be imported into a STIG
checklist using the DISA STIG Viewer
(
http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx)?
Finally, DoD auditors might not accept the results using vendor-provided SCAP
content/tools over content and tools have been officially released and tested by DISA,
which means for RHEL 7, assessors will have to resort to doing manual reviews of the
STIG.
I apologize if some of this has already been discussed, but I've mostly been working
with RHEL 6, which DISA currently releases content for, so I've only casually been
following SSG and have not personally used it.
v/r,
Brian Reese
-----Original Message-----
From: Shawn Wells [mailto:shawn@redhat.com]
Sent: Thursday, July 20, 2017 7:11 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: [Non-DoD Source] Re: Loss of EL7 STIG profiles
All active links contained in this email were disabled. Please verify the identity of the
sender, and confirm the authenticity of all links contained within the message prior to
copying and pasting the address to a Web browser.
________________________________
On 7/20/17 4:13 PM, Moessbauer, David wrote:
All,
Our program is currently working through the architecting of the next release, and
the decision point is upon us WRT OS version - RHEL6 or RHEL7. One significant factor (at
least from a cybersecurity perspective, is the ability to efficiently / effectively
conduct STIG reviews via the SCAP tools.
This said, is there any place I could ascertain the projected release of the RHEL
7 Benchmarks?
I apologize if this is not the appropriate venue for such a question, or if it is
so obviously in front of me I should already know, but honestly I have not closely
monitored this feed of late, since I have been stuck in the RHEL 5 world and trying to
keep the system secure in that context.
RHEL 6.4+ and RHEL7.x ship automation content.
It sounds like your systems are very long-lived, given that you're dealing with RHEL5.
Note that RHEL6 is has entered "Production Phase 3" which means no new features
or hardware enablement [0].
If you're asking for when *DISA* will release automation content: They've stated
they have no intention to release automation content for Red Hat STIGs moving forward.
This isn't terrible... e.g. why should DISA release automation content when it's
delivered natively in the platform (via the SCAP Security Guide)?
[
0]Caution-https://access.redhat.com/support/policy/updates/errata#Product... <
Caution-https://access.redhat.com/support/policy/updates/errata#Productio... >