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