Well said, thanks for the input. John -----Original Message----- From: Jeffrey Blank [mailto:[email protected]] Sent: Tuesday, February 02, 2016 9:53 PM To: SCAP Security Guide Cc: [email protected]; Kreigline, Sue E CIV DISA RE (US); Sipes, Jacquelyn A CTR DISA FSO (US) Subject: Re: [Non-DoD Source] Re: RHEL 7 Draft STIG release
Representatives of the National Security Agency will file a complaint with the DoD Inspector General if this is not resolved to our satisfaction. Appropriate resolution involves direct use of the fully-automated security guidance provided by the vendor-supported Scap-Security-Guide project, which meets all DoD requirements. This is also provided as part of the RHEL product -- an obvious benefit to all customers, including DoD. The fundamental issue is that leadership at DISA RE71 in Chambersburg PA have established a contract firm (Tapestry Technologies) to compete with industry. This includes development of security implementation guidance that is duplicative to that provided by the vendor. Sue Kreigline (CC'ed) is the government authority at DISA RE71 who is accountable for this situation. She is responsible for STIG development. Her email address is: [email protected] <mailto:[email protected]> , if you wish to correspond with her about this. In theory Sue is in charge of the contract team. But all of our interactions indicate quite clearly that Tapestry Technologies runs the show there. Sue cannot even attend planning meeting without her contractors. Jacquie Sipes (CC'ed) is the CEO of Tapestry Technologies, who has billed the government for many hours of duplicative work, including this sham of a RHEL baseline which basically breaks systems. Jeff ___________________________ Jeffrey Blank [GS-15] 410-854-8675 Technical Director Operating Systems and Applications Division Systems and Technologies Analysis Group NSA Information Assurance On Thu, Jan 28, 2016 at 9:45 AM, leam hall <[email protected]> wrote: Have not started reading the STIG yet. Hopefully they have addressed the following concerns: 1. Malformed XML. Some findings look like they can't tell htmlentities output from "<". 2. Duplicating VIDs. If V-12345 addresses a concern on RHEL 6, and you want it on RHEL 7, use the same VID number. 3. Duplicating tasks. If the fix is "do <this>" for V-12345, don't list V-12346 with the same fix action. Leam On Thu, Jan 28, 2016 at 9:28 AM, Arnold, Paul C CTR USARMY PEO STRI (US) <[email protected]> wrote: I'm slightly relieved to hear portions of this STIG blindsided the SSG community, too. I'd certainly be willing to help -- I have issues or concerns with many of the items relating to SELinux, confinement, audits of MAC, audits of various privileged command items. And the items that are just outright wrong or make a system/service inaccessible. On 01/27/2016 06:55 PM, Shawn Wells wrote: 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 1/27/16 2:40 PM, Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) wrote: FYI, In case any interested parties missed it during the inclement weather event, DISA has released the Draft STIG for RHEL 7 on 21 Jan. The comment period is open until 12 Feb. Caution-http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx To ease reading, I converted their XML to HTML: Caution-http://people.redhat.com/swells/U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_STIG/html_edition.html There's a high chance members of the OpenSCAP community will click that link and have a serious case of "WTF is this?" The RHEL7 STIG and USGCB baselines are to be based on the ~20 configuration requirements from "Management of Security Functions Behavior" in the NIAP Operating System Protection Profile: Caution-https://www.niap-ccevs.org/pp/pp_os_v4.0.htm#fmt Those controls are being implemented in the OSPP profile: Caution-https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/ospp-rhel7-server.xml Prior to the formal recognition/issuance of a STIG or USGCB, a vendor must complete their Common Criteria Certification. RHEL7 began that process in June 2014 [0] and is expected to finish shortly. In preparation for completion of Common Criteria, we sent our configuration guide (derived from SSG's OSPP profile) to NIST and DISA FSO. Akin to RHEL6, the arrangement was to use SCAP Security Guide as the upstream for the STIGs. You can imagine the surprise when FSO published their draft STIG, which seems to include the 129 configuration checks from our OSPP profile, but also tacks on 279 net-new controls. DISA FSO has been a cooperative partner in opening the STIG process, and establishing open source principals for STIG development. We're working with them to see why their draft STIG various so dramatically from the content that was submitted to them. In the mean time, it's incredibly important to start reviews of the DISA draft STIG. This is an opportunity for you to express that you want DISA to keep using open source developed content, and also to directly address the random 279 new rules that mysteriously were dropped in. Some are just blatantly wrong, and appear to be copy/pasted from RHEL5 content! To facilitate comments, I've shared an edition of the DISA FSO comment matrix: Caution-http://bit.ly/1QtvF6v This will become Red Hat's formal feedback to DISA FSO on their draft. If we all work on a single feedback form, submitted independently through our own companies, our independent voices for change would be greatly amplified. There are ~400 controls in DISAs draft. Perhaps we could segment this up, and take ownership of small chunks? This would ensure the OpenSCAP community is able to provide feedback by the 12-FEB deadline. Once we're done with smaller sections, we could review as a whole in a week or two. Would anyone be up for this? -Shawn [0] Caution-https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-7-evaluation-common-criteria-certification -- SCAP Security Guide mailing list [email protected] Caution-https://lists.fedorahosted.org/admin/lists/[email protected] Caution-https://github.com/OpenSCAP/scap-security-guide/ -- Paul Arnold IT Systems Engineer Cole Engineering Services, Inc. Classification: UNCLASSIFIED Caveats: NONE -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/ -- Mind on a Mission <http://leamhall.blogspot.com/> -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
smime.p7s
Description: S/MIME cryptographic signature
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
