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