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 < [email protected]> 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:[email protected]] > *Sent:* Friday, July 21, 2017 10:56 AM > > *To:* SCAP Security Guide <[email protected]> > *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 < > [email protected]> 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:[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]> 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]] > Sent: Thursday, July 20, 2017 7:11 PM > To: [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 -- 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 --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
