Re: Loss of EL7 STIG profiles

[Reese, Brian J CTR (US)]

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:[e-mail]] 
Sent: Thursday, July 20, 2017 7:11 PM
To: [e-mail]
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#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >

Loss of EL7 STIG profiles

[Meinecke, Lee]

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) 
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:[e-mail]]
Sent: Thursday, July 20, 2017 7:11 PM
To: [e-mail]
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#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >

Loss of EL7 STIG profiles

[Sean]

I have spoken on the phone with the person who answer the DISA STIG Support
emails (at least for RHEL 7), and have picked up some interesting
perspectives.

1.  From DISA's point of view, the "G" in STIG really does mean Guideline,
not Policy/Procedure.

2.  That it is not DISA's place to tell you how to skin the cat.  The Fix
Text is an example, and accomplishing the intent of the control is what
should be focused on.

I related to him how we went through a CSA in May and the auditor required
us to benchmark all Unix/Linux systems against DOD's HPCMP's Radix Tool.
Which for RHEL 7, was based on the 2nd Draft at the time, and I discussed
how we configure sysctl rules in /etc/sysctl.d/ files instead of
/etc/sysctl.conf, so all those checks had to be Documented and Explained
for their failures.  I told him the auditors don't read the "G" as meaning
Guidline, they want the system to pass a test that checks against what DISA
publishes as "Gospel".  He told me to have the auditor call him next time.

--Sean

On Fri, Jul 21, 2017 at 10:18 AM, Meinecke, Lee <
[e-mail]> wrote:
> 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) 
> *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:[e-mail] ]
> Sent: Thursday, July 20, 2017 7:11 PM
> To: [e-mail]
> 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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Trevor Vaughan]

You're 100% correct that the G doesn't mean Guideline to the auditors.

I have no idea how to fix this, and I understand their perspective. A
guideline becomes policy when the local authority says it does.

The only policies that I know of that are backed by law, are NIST 800-53
and CNSS 1253 per FISMA and Executive Order.

Trevor

On Fri, Jul 21, 2017 at 10:50 AM, Sean  wrote:
> I have spoken on the phone with the person who answer the DISA STIG
> Support emails (at least for RHEL 7), and have picked up some interesting
> perspectives.
> From DISA's point of view, the "G" in STIG really does mean Guideline,
>
> not Policy/Procedure.
> That it is not DISA's place to tell you how to skin the cat.  The Fix
>
> Text is an example, and accomplishing the intent of the control is what
> should be focused on.
>
> I related to him how we went through a CSA in May and the auditor required
> us to benchmark all Unix/Linux systems against DOD's HPCMP's Radix Tool.
> Which for RHEL 7, was based on the 2nd Draft at the time, and I discussed
> how we configure sysctl rules in /etc/sysctl.d/ files instead of
> /etc/sysctl.conf, so all those checks had to be Documented and Explained
> for their failures.  I told him the auditors don't read the "G" as meaning
> Guidline, they want the system to pass a test that checks against what DISA
> publishes as "Gospel".  He told me to have the auditor call him next time.
>
> --Sean
>
> On Fri, Jul 21, 2017 at 10:18 AM, Meinecke, Lee <
> [e-mail]> wrote:
> > 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) 
> > *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:[e-mail] ]
> > Sent: Thursday, July 20, 2017 7:11 PM
> > To: [e-mail]
> > 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#Production_3_Phase < Caution-https://access.redhat.
> > com/support/policy/updates/errata#Production_3_Phase >
> >
> > scap-security-guide mailing list -- [e-mail]
> > rahosted.org
> > To unsubscribe send an email to scap-security-guide-leave@list
> > s.fedorahosted.org
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Shawn Wells]

On 7/21/17 10:18 AM, Meinecke, Lee wrote:
> 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.

Tools != Content. Usage of SPAWAR SCC does not predicate using vendor
provided content.

From a content perspective, the OpenSCAP/SCAP Security Guide community
has a really good relationship with the SPAWAR SCC team. They give us
pre-release editions of SCC for beta testing to make sure everything is
kosher.

It's generally myself who does the initial testing and writeups. A
fairly recent example:
https://shawnwells.io/2017/02/03/quick-review-of-spawar-scc-4-2-beta-1-with-...

(Note: The issues identified in the SCC tool were fixed prior to public
release)

Like OpenSCAP, SPAWAR SCC is a NIST-validated SCAP configuration scanner
for RHEL6 and RHEL7. Content should be interoperable between the two tools.

From a tooling perspective, both OpenSCAP and SPAWAR SCC are approved
configuration scanners by the US Government:
SPAWAR SCC Validation: https://nvd.nist.gov/scap/validation/140
OpenSCAP Validation: https://nvd.nist.gov/scap/validation/142

Usage boils down to your workflow and report expectations. There are
uses for both, e.g. how SCC works on Windows.
> 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.

Use the vendor-provided content in SPAWAR SCC then import the SCC
results into STIG Viewer.

Loss of EL7 STIG profiles

[Chuck Atkins]

Hi Shawn,

Wow, so this whole thread really took on a life of it's own, far outside
the scope of my original intent.  So to try to bring it back...
> The profile split started when ...

Thanks for the background info, it helps to understand why things are the
way they are.

If having DISA release updated content is important to you ...

Not specifically, that just makes it easier since the auditors know the
DISA STIG and that what they ask about.  So long as I have a good profile
with sound security practices that I can justify to my ODAA auditor then
I'm satisfied.  The OSPP profile should fit that purpose well and if I
explain it to auditors, I'm 70-80% confident I can get them on board with
it.

My main point was that having distinctly separate Workstation and Server
profiles was very helpful, so I was a bit worried when they went away.  If
I understand you correctly, the OSPP / USGCB profile for EL7 is
out-of-the-box intended for a desktop configuration?  Aside from removing
X, is there any difference between the OSPP profile and where a "server"
profile would start from?  Obviously, you'd want to go through and enable
the services that the server is to host and their respective
configurations.  Is that all or are there other core settings that should
change?

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.

On Fri, Jul 21, 2017 at 11:35 AM, Shawn Wells  wrote:
> The profile split started when
> On 7/21/17 10:18 AM, Meinecke, Lee wrote:

Loss of EL7 STIG profiles

[Shawn Wells]

On 7/21/17 2:06 PM, Chuck Atkins wrote:
> Hi Shawn,
>
> Wow, so this whole thread really took on a life of it's own, far
> outside the scope of my original intent.  So to try to bring it back...

But it's a good thread!

(and very representative of open source conversations, which is awesome)
> The profile split started when ...
>
>
> Thanks for the background info, it helps to understand why things are
> the way they are.
> If having DISA release updated content is important to you ...
>
>
> Not specifically, that just makes it easier since the auditors know
> the DISA STIG and that what they ask about.  So long as I have a good
> profile with sound security practices that I can justify to my ODAA
> auditor then I'm satisfied.  The OSPP profile should fit that purpose
> well and if I explain it to auditors, I'm 70-80% confident I can get
> them on board with it.

SSG content contains metadata that maps every configuration check to
corresponding policy. Maybe sharing those policy mapping tables will
help boost confidence?

Here's one for NIST 800-171 (Controlled Unclassified):
http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-cuire...

And another mapping checks back to DISA OS SRG (aka their STIG stuff):
http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-srgma...

And another back to NIST 800-53:
http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-nistr...

The reports can also be sorted by the policy mappings. Here's a sample
report from the 800-171 profile:
http://people.redhat.com/swells/cui-sample-report.html

Under the "Rule Overview" you'll see a drop down called "Group Rules
by". Select the NIST 800-53 drop down and you'll see the report
re-styled like this:
> My main point was that having distinctly separate Workstation and
> Server profiles was very helpful, so I was a bit worried when they
> went away.  If I understand you correctly, the OSPP / USGCB profile
> for EL7 is out-of-the-box intended for a desktop configuration?

That's a fair statement. The profile is intended for attesting bare
metal/virtual/containers, desktop or server. The configuration checks,
such as those for GNOME, will only run if GNOME is actually installed.

Here are the dconf/GNOME control selections in case you're curious:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
> Aside from removing X, is there any difference between the OSPP
> profile and where a "server" profile would start from?  Obviously,
> you'd want to go through and enable the services that the server is to
> host and their respective configurations.  Is that all or are there
> other core settings that should change?

Skimming quickly through the profile, I think the "must remove X11" rule
was dropped. Instead, it's more of "if X11 or GNOME is installed, we
verify the following settings."

Most system settings check if they're applicable before attesting them.
AKA the SSH checks won't run unless SSH is installed (lookin' at you,
Trevor Vaughan).

Loss of EL7 STIG profiles

[Trevor Vaughan]

Hi Brian,

I come at this from a very similar point of view but have a different take
on the situation.

OpenSCAP is a NIST approved SCAP scanner and, though people may have their
preferences, the tool is perfectly capable of performing its duties
appropriately and, in fact, is usually seen as the de facto reference
implementation. If the commercial/internal tools cannot process SCAP spec
compliant information, then a bug report needs to be filed against those
tools as insufficient.

The entire body of SSG content is on GitHub and easily verifiable. Any
auditor that does not approve of the veracity of the information can easily
validate for themselves that the rules are to their standards.

If I remember correctly, DISA is only chartered to create content if there
is no sufficient vendor or public content is available. Obviously, someone
should review the material but that is quite easy to do and, the more
people that do it *and provide feedback*, the better the content gets for
all of us.

Like most people, I have had issues with getting accreditors to look
outside of the walled garden, but they really need to be encouraged to do
so in order to reduce rework across the Government.

Good Luck,

Trevor

On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <
[e-mail]> wrote:
> 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:[e-mail]]
> Sent: Thursday, July 20, 2017 7:11 PM
> To: [e-mail]
> 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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Moessbauer, David]

Trevor,

I appreciate your optimism and view point, but I tend to fall on Brian’s side on this matter – at least for the moment.

Can you confirm that the OSCAP provides the XCCDF formatted xml in the results provided?  If so, the reviewers required completed Checklist as populated via STIG Viewer should be producible, and ultimately, this is the artifact in my experience that EII/SCA/NAO reviewers are in search of, and this will place me to your view point on this matter.

v/r

David Moessbauer
[phone] (M)

The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.

From: Trevor Vaughan [mailto:[e-mail]]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide 
Subject: Re: Loss of EL7 STIG profiles

Hi Brian,

I come at this from a very similar point of view but have a different take on the situation.

OpenSCAP is a NIST approved SCAP scanner and, though people may have their preferences, the tool is perfectly capable of performing its duties appropriately and, in fact, is usually seen as the de facto reference implementation. If the commercial/internal tools cannot process SCAP spec compliant information, then a bug report needs to be filed against those tools as insufficient.

The entire body of SSG content is on GitHub and easily verifiable. Any auditor that does not approve of the veracity of the information can easily validate for themselves that the rules are to their standards.

If I remember correctly, DISA is only chartered to create content if there is no sufficient vendor or public content is available. Obviously, someone should review the material but that is quite easy to do and, the more people that do it *and provide feedback*, the better the content gets for all of us.

Like most people, I have had issues with getting accreditors to look outside of the walled garden, but they really need to be encouraged to do so in order to reduce rework across the Government.

Good Luck,

Trevor

On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <[e-mail]> wrote:
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:[e-mail]]
Sent: Thursday, July 20, 2017 7:11 PM
To: [e-mail]
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#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >

_______________________________________________
scap-security-guide mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

--
Trevor Vaughan
Vice President, Onyx Point, Inc
[phone] x788

-- This account not approved for unencrypted proprietary information --

Loss of EL7 STIG profiles

[Trevor Vaughan]

The ARF data stream output by oscap contains both the XCCDF results and the
OVAL results combined as a single data stream so it should work properly.

On Fri, Jul 21, 2017 at 10:52 AM, Moessbauer, David <
[e-mail]> wrote:
> Trevor,
>
> I appreciate your optimism and view point, but I tend to fall on Brian’s
> side on this matter – at least for the moment.
>
> Can you confirm that the OSCAP provides the XCCDF formatted xml in the
> results provided?  If so, the reviewers required completed Checklist as
> populated via STIG Viewer should be producible, and ultimately, this is the
> artifact in my experience that EII/SCA/NAO reviewers are in search of, and
> this will place me to your view point on this matter.
>
> v/r
>
> David Moessbauer
>
> [phone] (M)
>
> *The Information contained in or attached to this communication may be
> confidential and privileged proprietary intended only for the individual/s
> or entity to whom/which it is addressed. Any unauthorized use,
> distribution, copying or disclosure of this information is strictly
> prohibited. If you have received this communication in error please contact
> the sender immediately and delete from your system.*
>
> *From:* Trevor Vaughan [mailto:[e-mail]]
> *Sent:* Friday, July 21, 2017 10:44 AM
> *To:* SCAP Security Guide 
> *Subject:* Re: Loss of EL7 STIG profiles
>
> Hi Brian,
>
> I come at this from a very similar point of view but have a different take
> on the situation.
>
> OpenSCAP is a NIST approved SCAP scanner and, though people may have their
> preferences, the tool is perfectly capable of performing its duties
> appropriately and, in fact, is usually seen as the de facto reference
> implementation. If the commercial/internal tools cannot process SCAP spec
> compliant information, then a bug report needs to be filed against those
> tools as insufficient.
>
> The entire body of SSG content is on GitHub and easily verifiable. Any
> auditor that does not approve of the veracity of the information can easily
> validate for themselves that the rules are to their standards.
>
> If I remember correctly, DISA is only chartered to create content if there
> is no sufficient vendor or public content is available. Obviously, someone
> should review the material but that is quite easy to do and, the more
> people that do it *and provide feedback*, the better the content gets for
> all of us.
>
> Like most people, I have had issues with getting accreditors to look
> outside of the walled garden, but they really need to be encouraged to do
> so in order to reduce rework across the Government.
>
> Good Luck,
>
> Trevor
>
> On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <
> [e-mail]> wrote:
>
> 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:[e-mail]]
> Sent: Thursday, July 20, 2017 7:11 PM
> To: [e-mail]
> 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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> [phone] x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

[Non-DoD Source] Re: Loss of EL7 STIG profiles

[Reese, Brian J CTR (US)]

Trevor,

Thank you for your responses regarding my concerns. I think your position is entirely reasonably and agree with your points, however the issue is when you have to convince others in the DoD Authorization process. I also realize there's not much you or Red Hat can do about that.

Regarding the XCCDF and metadata issue, I *think* that the DISA STIG Viewer primarily relies on the Rule ID to map the XCCDF results to the checklist when importing. Can anyone on this list confirm that the XCCDF results from either OSCAP or even SPAWAR SCC using the SSG content can be imported into the current DISA RHEL 7 STIG available on the IASE web site? I don't have the means to try it at the moment, but probably will in a few weeks.

v/r,
Brian Reese

-----Original Message-----
From: Trevor Vaughan [mailto:[e-mail]] 
Sent: Friday, July 21, 2017 10:56 AM
To: SCAP Security Guide 
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.

________________________________

The ARF data stream output by oscap contains both the XCCDF results and the OVAL results combined as a single data stream so it should work properly.

On Fri, Jul 21, 2017 at 10:52 AM, Moessbauer, David <[e-mail] < Caution-mailto:[e-mail] > > wrote:

Trevor,

I appreciate your optimism and view point, but I tend to fall on Brian’s side on this matter – at least for the moment.

Can you confirm that the OSCAP provides the XCCDF formatted xml in the results provided?  If so, the reviewers required completed Checklist as populated via STIG Viewer should be producible, and ultimately, this is the artifact in my experience that EII/SCA/NAO reviewers are in search of, and this will place me to your view point on this matter.

v/r

David Moessbauer

[phone] < tel:(410)%20627-5633 >  (M)

The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.

From: Trevor Vaughan [Caution-mailto:[e-mail] < Caution-mailto:[e-mail] > ]
    Sent: Friday, July 21, 2017 10:44 AM
    To: SCAP Security Guide <[e-mail] < Caution-mailto:[e-mail] > >
    Subject: Re: Loss of EL7 STIG profiles

Hi Brian,

I come at this from a very similar point of view but have a different take on the situation.

OpenSCAP is a NIST approved SCAP scanner and, though people may have their preferences, the tool is perfectly capable of performing its duties appropriately and, in fact, is usually seen as the de facto reference implementation. If the commercial/internal tools cannot process SCAP spec compliant information, then a bug report needs to be filed against those tools as insufficient.

The entire body of SSG content is on GitHub and easily verifiable. Any auditor that does not approve of the veracity of the information can easily validate for themselves that the rules are to their standards.

If I remember correctly, DISA is only chartered to create content if there is no sufficient vendor or public content is available. Obviously, someone should review the material but that is quite easy to do and, the more people that do it *and provide feedback*, the better the content gets for all of us.

Like most people, I have had issues with getting accreditors to look outside of the walled garden, but they really need to be encouraged to do so in order to reduce rework across the Government.

Good Luck,

Trevor

On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <[e-mail] < Caution-mailto:[e-mail] > > wrote:

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 (Caution-http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx < Caution-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 [Caution-mailto:[e-mail] < Caution-mailto:[e-mail] > ]
    	Sent: Thursday, July 20, 2017 7:11 PM
    	To: [e-mail] < Caution-mailto:[e-mail] > 
    	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-Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >  < Caution-Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >  >
    	
    	
    	_______________________________________________
    	scap-security-guide mailing list -- [e-mail] < Caution-mailto:[e-mail] > 
    	To unsubscribe send an email to [e-mail] < Caution-mailto:[e-mail] >

--

Trevor Vaughan
    Vice President, Onyx Point, Inc

[phone] x788 < tel:(410)%20541-6699 >

-- This account not approved for unencrypted proprietary information --

_______________________________________________
    scap-security-guide mailing list -- [e-mail] < Caution-mailto:[e-mail] > 
    To unsubscribe send an email to [e-mail] < Caution-mailto:[e-mail] >

Loss of EL7 STIG profiles

[Moessbauer, David]

Trevor,

My Chief Eng just happened to have a RHEL7 he was playing with and conducted scans, and supplied the results to see if STIG Viewer was capable of ingest.

One of the many is listed is an XCCDF xml (ssg-rhel7-xccdf.xml), but when ingested, it does not update my RHEL7 STIG Checklist as it should, though kicks no error as the other results do.

v/r

David Moessbauer
[phone] (M)

The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.

From: Trevor Vaughan [mailto:[e-mail]]
Sent: Friday, July 21, 2017 10:56 AM
To: SCAP Security Guide 
Subject: Re: Loss of EL7 STIG profiles

The ARF data stream output by oscap contains both the XCCDF results and the OVAL results combined as a single data stream so it should work properly.

On Fri, Jul 21, 2017 at 10:52 AM, Moessbauer, David <[e-mail]> wrote:
Trevor,

I appreciate your optimism and view point, but I tend to fall on Brian’s side on this matter – at least for the moment.

Can you confirm that the OSCAP provides the XCCDF formatted xml in the results provided?  If so, the reviewers required completed Checklist as populated via STIG Viewer should be producible, and ultimately, this is the artifact in my experience that EII/SCA/NAO reviewers are in search of, and this will place me to your view point on this matter.

v/r

David Moessbauer
[phone]tel:(410)%20627-5633 (M)

The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.

From: Trevor Vaughan [mailto:[e-mail]]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide <[e-mail]>
Subject: Re: Loss of EL7 STIG profiles

Hi Brian,

I come at this from a very similar point of view but have a different take on the situation.

OpenSCAP is a NIST approved SCAP scanner and, though people may have their preferences, the tool is perfectly capable of performing its duties appropriately and, in fact, is usually seen as the de facto reference implementation. If the commercial/internal tools cannot process SCAP spec compliant information, then a bug report needs to be filed against those tools as insufficient.

The entire body of SSG content is on GitHub and easily verifiable. Any auditor that does not approve of the veracity of the information can easily validate for themselves that the rules are to their standards.

If I remember correctly, DISA is only chartered to create content if there is no sufficient vendor or public content is available. Obviously, someone should review the material but that is quite easy to do and, the more people that do it *and provide feedback*, the better the content gets for all of us.

Like most people, I have had issues with getting accreditors to look outside of the walled garden, but they really need to be encouraged to do so in order to reduce rework across the Government.

Good Luck,

Trevor

On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <[e-mail]> wrote:
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:[e-mail]]
Sent: Thursday, July 20, 2017 7:11 PM
To: [e-mail]
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#Production_3_Phase < Caution-https://access.redhat.com/support/policy/updates/errata#Production_3_Phase >

_______________________________________________
scap-security-guide mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

--
Trevor Vaughan
Vice President, Onyx Point, Inc
[phone] x788tel:(410)%20541-6699

-- This account not approved for unencrypted proprietary information --

_______________________________________________
scap-security-guide mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

--
Trevor Vaughan
Vice President, Onyx Point, Inc
[phone] x788

-- This account not approved for unencrypted proprietary information --

Loss of EL7 STIG profiles

[Trevor Vaughan]

Hmm...sounds like STIG Viewer might need to be fixed. The XML certainly
validates properly.

On Fri, Jul 21, 2017 at 4:25 PM, Moessbauer, David <
[e-mail]> wrote:
> Trevor,
>
> My Chief Eng just happened to have a RHEL7 he was playing with and
> conducted scans, and supplied the results to see if STIG Viewer was capable
> of ingest.
>
> One of the many is listed is an XCCDF xml (ssg-rhel7-xccdf.xml), but when
> ingested, it does not update my RHEL7 STIG Checklist as it should, though
> kicks no error as the other results do.
>
> v/r
>
> David Moessbauer
>
> [phone] (M)
>
> *The Information contained in or attached to this communication may be
> confidential and privileged proprietary intended only for the individual/s
> or entity to whom/which it is addressed. Any unauthorized use,
> distribution, copying or disclosure of this information is strictly
> prohibited. If you have received this communication in error please contact
> the sender immediately and delete from your system.*
>
> *From:* Trevor Vaughan [mailto:[e-mail]]
> *Sent:* Friday, July 21, 2017 10:56 AM
>
> *To:* SCAP Security Guide 
> *Subject:* Re: Loss of EL7 STIG profiles
>
> The ARF data stream output by oscap contains both the XCCDF results and
> the OVAL results combined as a single data stream so it should work
> properly.
>
> On Fri, Jul 21, 2017 at 10:52 AM, Moessbauer, David <
> [e-mail]> wrote:
>
> Trevor,
>
> I appreciate your optimism and view point, but I tend to fall on Brian’s
> side on this matter – at least for the moment.
>
> Can you confirm that the OSCAP provides the XCCDF formatted xml in the
> results provided?  If so, the reviewers required completed Checklist as
> populated via STIG Viewer should be producible, and ultimately, this is the
> artifact in my experience that EII/SCA/NAO reviewers are in search of, and
> this will place me to your view point on this matter.
>
> v/r
>
> David Moessbauer
>
> [phone] (M)
>
> *The Information contained in or attached to this communication may be
> confidential and privileged proprietary intended only for the individual/s
> or entity to whom/which it is addressed. Any unauthorized use,
> distribution, copying or disclosure of this information is strictly
> prohibited. If you have received this communication in error please contact
> the sender immediately and delete from your system.*
>
> *From:* Trevor Vaughan [mailto:[e-mail]]
> *Sent:* Friday, July 21, 2017 10:44 AM
> *To:* SCAP Security Guide 
> *Subject:* Re: Loss of EL7 STIG profiles
>
> Hi Brian,
>
> I come at this from a very similar point of view but have a different take
> on the situation.
>
> OpenSCAP is a NIST approved SCAP scanner and, though people may have their
> preferences, the tool is perfectly capable of performing its duties
> appropriately and, in fact, is usually seen as the de facto reference
> implementation. If the commercial/internal tools cannot process SCAP spec
> compliant information, then a bug report needs to be filed against those
> tools as insufficient.
>
> The entire body of SSG content is on GitHub and easily verifiable. Any
> auditor that does not approve of the veracity of the information can easily
> validate for themselves that the rules are to their standards.
>
> If I remember correctly, DISA is only chartered to create content if there
> is no sufficient vendor or public content is available. Obviously, someone
> should review the material but that is quite easy to do and, the more
> people that do it *and provide feedback*, the better the content gets for
> all of us.
>
> Like most people, I have had issues with getting accreditors to look
> outside of the walled garden, but they really need to be encouraged to do
> so in order to reduce rework across the Government.
>
> Good Luck,
>
> Trevor
>
> On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <
> [e-mail]> wrote:
>
> 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:[e-mail]]
> Sent: Thursday, July 20, 2017 7:11 PM
> To: [e-mail]
> 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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> [phone] x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> [phone] x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Ted Brunell]

I want to clarify something that was mentioned about automation content
earlier in this thread...

I communicate on a regular basis with the people at DISA that are
responsible for STIG and SCAP content.  They have verified that DISA is
planning on releasing automation content (aka benchmark) containing the
necessary files for RHEL 7 in the not too distant future.  I am not sure
exactly when it will be released, but when it is, it will be posted for
consumption at http://iase.disa.mil/stigs/scap/Pages/index.aspx under SCAP
1.2 content.

Currently, they are reviewing the SSG content for use in the benchmark
content.

R/
Ted

On Fri, Jul 21, 2017 at 9:32 PM, Trevor Vaughan 
wrote:
> Hmm...sounds like STIG Viewer might need to be fixed. The XML certainly
> validates properly.
>
> On Fri, Jul 21, 2017 at 4:25 PM, Moessbauer, David <
> [e-mail]> wrote:
> > Trevor,
> >
> > My Chief Eng just happened to have a RHEL7 he was playing with and
> > conducted scans, and supplied the results to see if STIG Viewer was capable
> > of ingest.
> >
> > One of the many is listed is an XCCDF xml (ssg-rhel7-xccdf.xml), but when
> > ingested, it does not update my RHEL7 STIG Checklist as it should, though
> > kicks no error as the other results do.
> >
> > v/r
> >
> > David Moessbauer
> >
> > [phone] (M)
> >
> > *The Information contained in or attached to this communication may be
> > confidential and privileged proprietary intended only for the individual/s
> > or entity to whom/which it is addressed. Any unauthorized use,
> > distribution, copying or disclosure of this information is strictly
> > prohibited. If you have received this communication in error please contact
> > the sender immediately and delete from your system.*
> >
> > *From:* Trevor Vaughan [mailto:[e-mail]]
> > *Sent:* Friday, July 21, 2017 10:56 AM
> >
> > *To:* SCAP Security Guide 
> > *Subject:* Re: Loss of EL7 STIG profiles
> >
> > The ARF data stream output by oscap contains both the XCCDF results and
> > the OVAL results combined as a single data stream so it should work
> > properly.
> >
> > On Fri, Jul 21, 2017 at 10:52 AM, Moessbauer, David <
> > [e-mail]> wrote:
> >
> > Trevor,
> >
> > I appreciate your optimism and view point, but I tend to fall on Brian’s
> > side on this matter – at least for the moment.
> >
> > Can you confirm that the OSCAP provides the XCCDF formatted xml in the
> > results provided?  If so, the reviewers required completed Checklist as
> > populated via STIG Viewer should be producible, and ultimately, this is the
> > artifact in my experience that EII/SCA/NAO reviewers are in search of, and
> > this will place me to your view point on this matter.
> >
> > v/r
> >
> > David Moessbauer
> >
> > [phone] (M)
> >
> > *The Information contained in or attached to this communication may be
> > confidential and privileged proprietary intended only for the individual/s
> > or entity to whom/which it is addressed. Any unauthorized use,
> > distribution, copying or disclosure of this information is strictly
> > prohibited. If you have received this communication in error please contact
> > the sender immediately and delete from your system.*
> >
> > *From:* Trevor Vaughan [mailto:[e-mail]]
> > *Sent:* Friday, July 21, 2017 10:44 AM
> > *To:* SCAP Security Guide 
> > *Subject:* Re: Loss of EL7 STIG profiles
> >
> > Hi Brian,
> >
> > I come at this from a very similar point of view but have a different
> > take on the situation.
> >
> > OpenSCAP is a NIST approved SCAP scanner and, though people may have
> > their preferences, the tool is perfectly capable of performing its duties
> > appropriately and, in fact, is usually seen as the de facto reference
> > implementation. If the commercial/internal tools cannot process SCAP spec
> > compliant information, then a bug report needs to be filed against those
> > tools as insufficient.
> >
> > The entire body of SSG content is on GitHub and easily verifiable. Any
> > auditor that does not approve of the veracity of the information can easily
> > validate for themselves that the rules are to their standards.
> >
> > If I remember correctly, DISA is only chartered to create content if
> > there is no sufficient vendor or public content is available. Obviously,
> > someone should review the material but that is quite easy to do and, the
> > more people that do it *and provide feedback*, the better the content gets
> > for all of us.
> >
> > Like most people, I have had issues with getting accreditors to look
> > outside of the walled garden, but they really need to be encouraged to do
> > so in order to reduce rework across the Government.
> >
> > Good Luck,
> >
> > Trevor
> >
> > On Fri, Jul 21, 2017 at 10:04 AM, Reese, Brian J CTR (US) <
> > [e-mail]> wrote:
> >
> > 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:[e-mail]]
> > Sent: Thursday, July 20, 2017 7:11 PM
> > To: [e-mail]
> > 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#Production_3_Phase < Caution-https://access.redhat.
> > com/support/policy/updates/errata#Production_3_Phase >
> >
> > scap-security-guide mailing list -- [e-mail]
> > rahosted.org
> > To unsubscribe send an email to scap-security-guide-leave@list
> > s.fedorahosted.org
> >
> > --
> >
> > Trevor Vaughan
> > Vice President, Onyx Point, Inc
> >
> > [phone] x788 <(410)%20541-6699>
> >
> > -- This account not approved for unencrypted proprietary information --
> >
> > scap-security-guide mailing list -- [e-mail]
> > rahosted.org
> > To unsubscribe send an email to scap-security-guide-leave@list
> > s.fedorahosted.org
> >
> > --
> >
> > Trevor Vaughan
> > Vice President, Onyx Point, Inc
> >
> > [phone] x788 <(410)%20541-6699>
> >
> > -- This account not approved for unencrypted proprietary information --
> >
> > scap-security-guide mailing list -- [e-mail]
> > rahosted.org
> > To unsubscribe send an email to scap-security-guide-leave@list
> > s.fedorahosted.org
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> [phone] x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Shawn Wells]

On 7/26/17 1:48 PM, Ted Brunell wrote:
> I want to clarify something that was mentioned about automation
> content earlier in this thread...
>
> I communicate on a regular basis with the people at DISA that are
> responsible for STIG and SCAP content.  They have verified that DISA
> is planning on releasing automation content (aka benchmark) containing
> the necessary files for RHEL 7 in the not too distant future.  I am
> not sure exactly when it will be released, but when it is, it will be
> posted for consumption at
> http://iase.disa.mil/stigs/scap/Pages/index.aspx under SCAP 1.2 content.
>
> Currently, they are reviewing the SSG content for use in the benchmark
> content.

Nice! Thanks Ted! Great to hear they've changed their minds. Would be
*fantastic* to bring DISA back into the fold of what DoD, NIST, NSA, the
community, and Red Hat are doing on STIG work!

How goes the work with DISA to align their content to the DoD
recommended settings?

Loss of EL7 STIG profiles

[Ted Brunell]

We are making progress.  Still waiting to hear back on a couple of issues,
but progress is being made.

For others that may not know of the effort that Shawn eluded to..  I work
closely with DISA in my role at Red Hat.  We have a goal to eventually,
align the SSG and STIG content.  The benefit of everyone is that if you use
SSG to do something like lock down the OS while it is being provisioned, or
to periodically scan a system from Satellite server, the results of those
scan will be identical to a scan using ACAS.  The end result is a security
posture that is much easier to maintain and a great chance that any
configuration drift will not occur.

R/
Ted

On Wed, Jul 26, 2017 at 1:51 PM, Shawn Wells  wrote:
> On 7/26/17 1:48 PM, Ted Brunell wrote:
> > I want to clarify something that was mentioned about automation
> > content earlier in this thread...
> >
> > I communicate on a regular basis with the people at DISA that are
> > responsible for STIG and SCAP content.  They have verified that DISA
> > is planning on releasing automation content (aka benchmark) containing
> > the necessary files for RHEL 7 in the not too distant future.  I am
> > not sure exactly when it will be released, but when it is, it will be
> > posted for consumption at
> > http://iase.disa.mil/stigs/scap/Pages/index.aspx under SCAP 1.2 content.
> >
> > Currently, they are reviewing the SSG content for use in the benchmark
> > content.
>
> Nice! Thanks Ted! Great to hear they've changed their minds. Would be
> *fantastic* to bring DISA back into the fold of what DoD, NIST, NSA, the
> community, and Red Hat are doing on STIG work!
>
> How goes the work with DISA to align their content to the DoD
> recommended settings?
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

Loss of EL7 STIG profiles

[Shawn Wells]

On 7/21/17 10:04 AM, Reese, Brian J CTR (US) wrote:
> 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.

DISA publishing content originated because the vendor community was to
immature to do this themselves. Maybe the government market was a small
percentage of global sales, so they didn't care. Maybe it was just to
technically hard. Maybe they got away with waivers. Red Hat certainly
went through these evolutions.

A few years ago DISA started the "Vendor STIG Process" in which vendors
wrote their own STIGs and DISA performed peer review. The logical next
step is for vendors to continue authoring their Vendor STIGs, DISA to
continue providing peer review, and finally for vendors to natively
include the content in their products.

DISA becomes a arbiter of good content, vs having the overhead of
producing it themselves. I think that means STIGs will be developed
faster than before... getting technology into mission faster than before.
> 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.

DISA has publicly stated there are no "approved", or even favored,
tooling. People can use whatever they want. Jason Mackanick (DISA RE71 /
aka "DISA FSO" branch chief) has been very public and vocal about this.
Encourage those who need to hear this directly from the government to
reach out to them: [e-mail].

Local teams may want certain tools, which is entirely fine and certainly
under their authority, but there are no mandates from big DoD or DISA.

In practice we should all admit things get a little.... different...
than "choose your own tool." Most shops do want (demand?) ACAS scans. In
those cases, people can use DoD/NIST/NSA/Vendor supplied content to
perform the ACAS scans.

Tools != Content
> 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)?

Needed mappings can be added if something needed isn't there. Today we
have severity, CCIs, OS SRGs, Rule IDs (e.g. RHEL-07-xxxxxx), NIST
mappings, and some others. Best thing about open source is the ability
to quickly change the content to meet users requirements :)
> 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.

Again - there are no officially released and tested tools by DISA. This
has become urban legend. Nobody seems to know where such statements
originated, but everyone repeats them. Hell, I used to, prior to getting
the opportunity to speak directly with DISA on the matter.

As for the content side, the SCAP content included in RHEL undergoes
NIST and DoD validation. Red Hat has partnered with the US Gov to be the
delivery mechanism, including it natively in Linux, vs having to pull
down things from random websites. NSA spoke about this relationship at
Red Hat Summit this year (as we have every year since 2013).

This partnership also has the added benefit of security baseline content
getting updates aligned to Red Hat Security Errata cycles. If a core
profile, e.g. STIG, contains a bug or needs updates, everyone in DoD
will get them when they "yum update."
> 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.

All this is new and very fast moving. Some statements from even 6-8
months ago are already outdated.

Community members operate across different agencies/dod elements,
different levels within those elements, and IMHO we often get
organizational blinders because of this. Community threads help
communications across all levels of the orgs, help us learn what others
are doing. So thanks for posting and starting the conversation!