9:04 a.m.
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... >
9:18 a.m.
New subject: Loss of EL7 STIG profiles
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... >
9:50 a.m.
New subject: Loss of EL7 STIG profiles
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 <
lee.meinecke(a)gtri.gatech.edu> 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) <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 <shawn(a)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#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
9:57 a.m.
New subject: Loss of EL7 STIG profiles
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 <smalder73(a)gmail.com> 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.
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 <
lee.meinecke(a)gtri.gatech.edu> 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) <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 <shawn(a)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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> 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
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
10:35 a.m.
New subject: Loss of EL7 STIG profiles
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-wi...
(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.
1:06 p.m.
New subject: Loss of EL7 STIG profiles
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 <shawn(a)redhat.com> wrote:
The profile split started when
On 7/21/17 10:18 AM, Meinecke, Lee wrote:
1:34 p.m.
New subject: Loss of EL7 STIG profiles
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-cu...
And another mapping checks back to DISA OS SRG (aka their STIG stuff):
http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-sr...
And another back to NIST 800-53:
http://people.redhat.com/swells/scap-security-guide/tables/table-rhel7-ni...
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/...
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).
9:43 a.m.
New subject: 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) <
brian.j.reese.ctr(a)mail.mil> 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: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#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
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
9:52 a.m.
New subject: Loss of EL7 STIG profiles
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
(410) 627-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:tvaughan@onyxpoint.com]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
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)
<brian.j.reese.ctr@mail.mil<mailto:brian.j.reese.ctr@mail.mil>> 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:shawn@redhat.com<mailto:shawn@redhat.com>]
Sent: Thursday, July 20, 2017 7:11 PM
To:
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@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... >
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
9:55 a.m.
New subject: 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 <
david.moessbauer(a)progeny.net> 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
(410) 627-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:tvaughan@onyxpoint.com]
*Sent:* Friday, July 21, 2017 10:44 AM
*To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
*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) <
brian.j.reese.ctr(a)mail.mil> 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: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#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
(410) 541-6699 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
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
10:17 a.m.
New subject: [Non-DoD Source] Re: Loss of EL7 STIG profiles
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:tvaughan@onyxpoint.com]
Sent: Friday, July 21, 2017 10:56 AM
To: SCAP Security Guide <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.
________________________________
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 <david.moessbauer(a)progeny.net <
Caution-mailto:david.moessbauer@progeny.net > > 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
(410) 627-5633 < 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:tvaughan@onyxpoint.com <
Caution-mailto:tvaughan@onyxpoint.com > ]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@lists.fedorahosted.org > >
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) <brian.j.reese.ctr(a)mail.mil
< Caution-mailto:brian.j.reese.ctr@mail.mil > > 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:shawn@redhat.com < Caution-mailto:shawn@redhat.com
> ]
Sent: Thursday, July 20, 2017 7:11 PM
To: scap-security-guide(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@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-Caution-https://access.redhat.com/support/policy/updates/errata...
< Caution-https://access.redhat.com/support/policy/updates/errata#Productio...
> <
Caution-Caution-https://access.redhat.com/support/policy/updates/errata#P...
< Caution-https://access.redhat.com/support/policy/updates/errata#Productio...
> >
_______________________________________________
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@lists.fedorahosted.org >
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide-leave@lists.fedorahosted.org >
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788 < tel:(410)%20541-6699 >
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@lists.fedorahosted.org >
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide-leave@lists.fedorahosted.org >
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
3:25 p.m.
New subject: Loss of EL7 STIG profiles
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
(410) 627-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:tvaughan@onyxpoint.com]
Sent: Friday, July 21, 2017 10:56 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
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
<david.moessbauer@progeny.net<mailto:david.moessbauer@progeny.net>> 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
(410) 627-5633<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:tvaughan@onyxpoint.com<mailto:tvaughan@onyxpoint.com>]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide
<scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>>
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)
<brian.j.reese.ctr@mail.mil<mailto:brian.j.reese.ctr@mail.mil>> 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:shawn@redhat.com<mailto:shawn@redhat.com>]
Sent: Thursday, July 20, 2017 7:11 PM
To:
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@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... >
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788<tel:(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
8:32 p.m.
New subject: Loss of EL7 STIG profiles
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 <
david.moessbauer(a)progeny.net> 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
(410) 627-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:tvaughan@onyxpoint.com]
*Sent:* Friday, July 21, 2017 10:56 AM
*To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
*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 <
david.moessbauer(a)progeny.net> 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
(410) 627-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:tvaughan@onyxpoint.com]
*Sent:* Friday, July 21, 2017 10:44 AM
*To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
*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) <
brian.j.reese.ctr(a)mail.mil> 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: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#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
(410) 541-6699 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
(410) 541-6699 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
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
12:48 p.m.
New subject: Loss of EL7 STIG profiles
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 <tvaughan(a)onyxpoint.com>
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 <
david.moessbauer(a)progeny.net> 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
>
> (410) 627-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:tvaughan@onyxpoint.com]
> *Sent:* Friday, July 21, 2017 10:56 AM
>
> *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
> *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 <
> david.moessbauer(a)progeny.net> 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
>
> (410) 627-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:tvaughan@onyxpoint.com]
> *Sent:* Friday, July 21, 2017 10:44 AM
> *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
> *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) <
> brian.j.reese.ctr(a)mail.mil> 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: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#Production_3_Phase < Caution-https://access.redhat.
> com/support/policy/updates/errata#Production_3_Phase >
>
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
> s.fedorahosted.org
>
>
>
>
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> (410) 541-6699 x788 <(410)%20541-6699>
>
>
> -- This account not approved for unencrypted proprietary information --
>
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
> s.fedorahosted.org
>
>
>
>
>
> --
>
> Trevor Vaughan
> Vice President, Onyx Point, Inc
>
> (410) 541-6699 x788 <(410)%20541-6699>
>
>
> -- This account not approved for unencrypted proprietary information --
>
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
> s.fedorahosted.org
>
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 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
12:51 p.m.
New subject: Loss of EL7 STIG profiles
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?
1:03 p.m.
New subject: Loss of EL7 STIG profiles
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 <shawn(a)redhat.com> 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
2:45 p.m.
New subject: Loss of EL7 STIG profiles
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: disa.stig_spt(a)mail.mil.
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!
2466
days inactive
2471
days old
scap-security-guide@lists.fedorahosted.org
16 comments
8 participants
participants (8)
-
Chuck Atkins -
Meinecke, Lee -
Moessbauer, David -
Reese, Brian J CTR (US) -
Sean -
Shawn Wells -
Ted Brunell -
Trevor Vaughan