P { MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px }
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.
http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
-Nick
--
Nicholas P. Crawford, Contractor
Senior UNIX Systems Administrator
Manufacturing Techniques, Inc. (MTEQ)
NVESD Network Services Branch, US Army
email: ncrawford@mteq.com
NIPR: nicholas.p.crawford.ctr@mail.mil
SIPR: nicholas.p.crawford.ctr@mail.smil.mil
work: 703.704.2299 dsn: 312.654.2299
cell: 571.225.1283
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.
To ease reading, I converted their XML to HTML: http://people.redhat.com/swells/U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_S...
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: https://www.niap-ccevs.org/pp/pp_os_v4.0.htm#fmt
Those controls are being implemented in the OSPP profile: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
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: 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] https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-7-evaluation-c...
I've started doing my own work on this for my program, so I'd love to be involved in the work delegation.
Thanks!
Sent from my iPhone
On Jan 27, 2016, at 6:55 PM, Shawn Wells swells@redhat.com wrote:
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.
To ease reading, I converted their XML to HTML: http://people.redhat.com/swells/U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_S...
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: https://www.niap-ccevs.org/pp/pp_os_v4.0.htm#fmt
Those controls are being implemented in the OSPP profile: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
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: 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] https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-7-evaluation-c...
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
Great Stuff mate!
Sent from Mick on the move
On 28 Jan 2016, at 09:55, Shawn Wells swells@redhat.com wrote:
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.
http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
To ease reading, I converted their XML to HTML: http://people.redhat.com/swells/U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_S...
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: https://www.niap-ccevs.org/pp/pp_os_v4.0.htm#fmt
Those controls are being implemented in the OSPP profile: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pro...
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: 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] https://www.redhat.com/en/about/blog/red-hat-enterprise-linux-7-evaluation-c... -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
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_S...
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/pro...
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-c... -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org Caution-https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... Caution-https://github.com/OpenSCAP/scap-security-guide/
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) < paul.c.arnold4.ctr@mail.mil> 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_S...
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/pro...
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-c... -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org Caution- https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... 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 scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
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: sue.e.kreigline.civ@mail.mil , 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 leamhall@gmail.com wrote:
Have not started reading the STIG yet. Hopefully they have addressed the following concerns:
- 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) < paul.c.arnold4.ctr@mail.mil> 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_S...
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/pro...
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-c... -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org Caution- https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... 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 scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
-- Mind on a Mission http://leamhall.blogspot.com/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
Well said, thanks for the input. John
-----Original Message----- From: Jeffrey Blank [mailto:jeffrey.d.blank@ugov.gov] Sent: Tuesday, February 02, 2016 9:53 PM To: SCAP Security Guide Cc: gov-sec@redhat.com; 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: sue.e.kreigline.civ@mail.mil mailto:sue.e.kreigline.civ@mail.mil , 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 leamhall@gmail.com 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) paul.c.arnold4.ctr@mail.mil 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_S... 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/pro... 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-c... -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org Caution-https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
-- Mind on a Mission http://leamhall.blogspot.com/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
Community Participants,
Earlier this week a post was made to this forum/thread that made disparaging comments regarding DISA’s leadership over the STIG development process and our contractor’s support in this effort. I want to share with this group that DISA government leadership is fully in charge of our actions/decisions and our contract staff is there to provide support to us.
Having just signed into this forum tonight, I noted the following from Fedora’s Rules of Conduct: “Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one.” To the author of this, WELL SAID!!!!
Shawn Wells, in his post, noted that DISA has been a cooperative partner in the STIG process. DISA greatly values the contributions and recommendations from Red Hat and communities such as this, and it’s welcomed. I would simply ask that everyone please be respectful. If there are concerns outside of the technical area associated with this, please drop me a line and we can discuss. My email address is roger.s.greenwell.civ@mail.mil.
Respectfully, Roger Greenwell Chief, Cybersecurity – DISA
Roger,
I appreciate you making the choice to join this group, and I hope that being exposed to the process the SSG team is using will contribute to your organization making informed decisions.
I need to be honest that your organizations's recent release of the draft Red Hat Enterprise Linux 7 STIG has given me a bit of extra stress at my company, as many programs that I support have been anticipating the STIG (and have identified risks associated with the release and amount of work that could come along with it). It's been tricky trying to explain to those programs how the draft relates to the output that Red Hat and the SSG group has produced.
Could you take some time to explain the big picture on your release strategy for the RHEL7 STIG, and perhaps explain the big picture of the STIG process, the relationship and expectations between DISA and vendors, and what help defense contractors like myself who use vendor tools to produce solutions for the DoD can better work with your organization.
As an aside, it would also be nice if you could open the PKI only areas of the DISA website available to contractor PKI cards.
Tom Albrecht, CISSP-ISSEP, GPEN Cybersecurity Architect Staff Lockheed Martin MST
Sent from my iPhone
On Feb 4, 2016, at 9:47 PM, Roger Greenwell greenwer@fedoraproject.org wrote:
Community Participants,
Earlier this week a post was made to this forum/thread that made disparaging comments regarding DISA’s leadership over the STIG development process and our contractor’s support in this effort. I want to share with this group that DISA government leadership is fully in charge of our actions/decisions and our contract staff is there to provide support to us.
Having just signed into this forum tonight, I noted the following from Fedora’s Rules of Conduct: “Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one.” To the author of this, WELL SAID!!!!
Shawn Wells, in his post, noted that DISA has been a cooperative partner in the STIG process. DISA greatly values the contributions and recommendations from Red Hat and communities such as this, and it’s welcomed. I would simply ask that everyone please be respectful. If there are concerns outside of the technical area associated with this, please drop me a line and we can discuss. My email address is roger.s.greenwell.civ@mail.mil.
Respectfully, Roger Greenwell Chief, Cybersecurity – DISA -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
On Fri, 05 Feb 2016 02:47:03 -0000 "Roger Greenwell" greenwer@fedoraproject.org wrote:
Community Participants,
Earlier this week a post was made to this forum/thread that made disparaging comments regarding DISA’s leadership over the STIG development process and our contractor’s support in this effort. I want to share with this group that DISA government leadership is fully in charge of our actions/decisions and our contract staff is there to provide support to us.
Having just signed into this forum tonight, I noted the following from Fedora’s Rules of Conduct: “Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one.” To the author of this, WELL SAID!!!!
I reread that posting based on this note. To me, it all seems to be a statement of several facts with the exception of one sentence. Typically this guideline is invoked when there are personal attacks. While the post in question is a bit unusual, its not on the scale of the personal attacks that I've seen or recieved on other open source forums.
Shawn Wells, in his post, noted that DISA has been a cooperative partner in the STIG process.
I think the key to the statement is _in the past_. In the past we had an agreement that the stig audit rules would be published in the audit package. This is based on people that are not experts trying to read the rules and come up with audit rules. They typically flood their logs with useless information and eventually wind up on the linux audit mail list asking for help. Since then, there has been no communication to say that the rules need to be changed. Thus I was surprised to see a post like this:
https://www.redhat.com/archives/linux-audit/2015-August/msg00012.html
Having good rules is in everyone's best interest. It reduces support for us and frustration for end users. Typically this is done by participating in a community of like minded individuals where rules can be discussed and a consensus developed. Throwing new rules over the wall to see if anyone will comment is not exactly the open source way.
DISA greatly values the contributions and recommendations from Red Hat and communities such as this, and it’s welcomed.
I would say the reverse is true as well. I think we would rather have a dialog and develop the SCAP content on the mail list.
-Steve
I would simply ask that everyone please be respectful. If there are concerns outside of the technical area associated with this, please drop me a line and we can discuss. My email address is roger.s.greenwell.civ@mail.mil.
Respectfully, Roger Greenwell Chief, Cybersecurity – DISA -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
There are statements of fact (names, email addresses); and there are also opinions. Questioning the capabilities/integrity of people and companies is not conducive to building a spirit of cooperation across the community. Working together and forging relationships through professionalism and respect will net more value for all.
DISA has always strived to work with the vendor community in developing guidance for the DoD and that intent has not changed. I've already scheduled discussions with Red Hat leadership next week regarding what has occurred and ways to improve the relationship. We need to look at how we can better leverage the open source community; but we also need some level of consistent process since we deal with so many vendors, communities, etc. I assure you we'll be looking at what we can do better. Thanks for your feedback.
Respectfully, Roger
All concerned,
We have met with Shawn and the team today to discuss and collaborate on an approach moving forward. Stay tuned for an update to the Draft STIG.
c7-working-export-1.csv https://drive.google.com/file/d/0B7WLqiE0JYrONnZBQ1lZaHBNQWc/view?usp=drive_web All,
I have attached a google drive link to a csv of my groups first run through this new stig. The take away here is the "Comments" column that contains entries with '@@ERROR:' These are items that we have identified wrong with this version of the STIG. I am sure there are plenty more that we have missed, so hope to have more feedback on them here.
I will also send a copy of this directly to DISA as well.
James Feister openjaf@gmail.com
On Wed, Jan 27, 2016 at 2:40 PM, Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) nicholas.p.crawford.ctr@mail.mil 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.
http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
-Nick
--
*Nicholas P. Crawford*, Contractor
*Senior UNIX Systems Administrator*
*Manufacturing Techniques, Inc. (MTEQ)*
NVESD Network Services Branch, US Army
email: ncrawford@mteq.com
NIPR: nicholas.p.crawford.ctr@mail.mil
SIPR: nicholas.p.crawford.ctr@mail.smil.mil
work: 703.704.2299 <+1-703-704-2299> dsn: 312.654.2299
cell: 571.225.1283 <+1-571-225-1283>
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
On 2/8/16 1:32 PM, James Feister wrote:
c7-working-export-1.csv https://drive.google.com/file/d/0B7WLqiE0JYrONnZBQ1lZaHBNQWc/view?usp=drive_web All,
I have attached a google drive link to a csv of my groups first run through this new stig. The take away here is the "Comments" column that contains entries with '@@ERROR:' These are items that we have identified wrong with this version of the STIG. I am sure there are plenty more that we have missed, so hope to have more feedback on them here.
I will also send a copy of this directly to DISA as well.
This is great -- and thorough! I've integrated your comments into a master list: http://bit.ly/1QtvF6v
scap-security-guide@lists.fedorahosted.org