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:[email protected]]
Sent: Friday, July 21, 2017 10:44 AM
To: SCAP Security Guide <[email protected]>
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) 
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Thursday, July 20, 2017 7:11 PM
To: 
[email protected]<mailto:[email protected]>
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 -- 
[email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to