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: [email protected]. 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! _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
