scap-security-guide February 2016

scap-security-guide@lists.fedorahosted.org

16 participants
9 discussions

DISA STIG Release: What's purpose of "stig_refs.sh"?
by Mike Kuhnkey 09 Mar '16

09 Mar '16

Has someone checked out the script in DISA's STIG Release? ->U_Red_Hat_Enterprise_Linux_7_V1R0-1_Manual_STIG/Test/stig_refs.sh I find the instructions alarming on how to use the script. It is to be placed in the RHEL 5 folder (scap-security-guide project) and run..... ....am I off in left field here? What happens during make rhel7-dist -> content? Is this where/how the DRAFT was created?

4 4

Save the date - SCAP Security Guide Q/A Contributor WorkShop Volume #3 (2016-03-14 10:00am - 12:00pm EDT) is approaching
by Jan Lieskovsky 25 Feb '16

25 Feb '16

Hello folks, we are pleased to announce the exact date of the upcoming SCAP Security Guide Questions / Answers Contributor WorkShop Volume #3 is now known: Monday, 14-th March 2016, 10:00am - 12:00pm EDT Topic: "Customizing SSG for the purposes of Satellite, Spacewalk, and Foreman". Agenda for the upcoming session: * Lecture covering SSG customization in Spacewalk / Satellite 5 (~30 min) * Space for feedback / questions (~15 min) * Lecture covering SSG customization in Foreman / Satellite 6 (~30 min) * Space for feedback / questions (~15 min) * Additional questions / open discussion in remaining time (~30 min) Note: This session will NOT be recorded. Further details: https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-Co… Subscription form (many thanks to Martin Preisler with this): http://goo.gl/forms/p2jPy1kccl Looking forward to see you there. Regards, Jan. -- Jan iankko Lieskovsky (on behalf of SCAP Security Guide upstream)

1 1

CNSSI-1253 low/low/low Profile Review Effort
by Mike Kuhnkey 25 Feb '16

25 Feb '16

I hope sharing this effort might be useful in some small way.... Attached Spreadsheet reflects current documentation of SP-800-53r4 controls with CNSSI-1253 Profile of low/low/low. Entries have been color-coded (Red -> elements called out in scap-security-guide as "Procedural") (Green -> N/A to Operating System). No Overlays have been included, nor have I paid any attention to Privacy requirements. The remaining entries reflect what is believed to be relevant entries for Profile "nist-cl-il-al" (ssg-rhel6-ds.xml). These entries would also appear to support ssg-rhel7-ds.xml. Some "nist-cl-il-al" appear to have shifted into "medium" category, while some are no longer applicable according to current documentation. Would it be useful to extend Profile to med/med/med and produce low/low/low Profile via tailoring? https://docs.google.com/spreadsheets/d/1TXDI4M_ecxOAhj7KDIydiqaeuwlnACKLpYz…

1 0

RHEL 7 Draft STIG release
by Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) 23 Feb '16

23 Feb '16

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(a)mteq.com NIPR: nicholas.p.crawford.ctr(a)mail.mil SIPR: nicholas.p.crawford.ctr(a)mail.smil.mil work: 703.704.2299 dsn: 312.654.2299 cell: 571.225.1283

12 14

Rules missing from the C2S Profile
by S, Gautam 22 Feb '16

22 Feb '16

Hello folks, I was going through the C2S profile for Red Hat Enterprise Linux 6 and I see that some of the sections mention new rules are needed to address them. I was wondering if it made sense to write them or are they left unimplemented since most of them are not scored anyhow? Thank you! Regards, Gautam.

2 1

FYI: "scap-security-guide-pull-requests" Jenkins CI job has been configured to test the specific PR on all three slaves (el6, el7, and fedora23)
by Jan Lieskovsky 21 Feb '16

21 Feb '16

Hello folks, jFYI I have recently configured the Jenkins 'scap-security-guide-pull-requests' CI job to be always running in parallel on all three of the following Jenkins slaves: * el6, * el7, and * fedora23 Why? * OVAL-5.11 / OVAL-5.11.1 is not an official SCAP-1.2 standard => we still need to produce valid OVAL-5.10 files (IOW "make validate" target still needs to pass with openscap-1.0.x), * OVAL-5.11.1 might become a SCAP-1.3 part => we need to produce valid OVAL-5.11 files (IOW "make validate" target need to pass with openscap-1.2.x), * The "ShellCheck" test (remediation scripts bash syntax verification) is performed only on Fedora systems. In the past it happened "make validate" target stopped to PASS due the ShellCheck executable syntax change / expectations. Therefore the only way how to satisfy all three of the above requirements and not to introduce regressions in the future SSG content, we need to test PRs on all three of the aforementioned systems (in the past we experienced PRs that succeeded only e.g. with "OVAL-5.11", but due to random nature how Jenkins schedules the tests on the slaves, this PRs were improperly reported as passing, even when they didn't met the condition the "make validate" target to pass also with OVAL-5.10. This kind of PRs is making e.g. "scap-security-guide-nightly-oval510-zip" to fail: https://jenkins.open-scap.org/job/scap-security-guide-nightly-oval510-zip/) Therefore to prevent these regressions in the future, from now on every "scap-security-guide-pull-requests" CI job will be tested on all three of the above systems. Example PR where this happened already is: https://github.com/OpenSCAP/scap-security-guide/pull/1048 The particular testing jobs then being: * https://jenkins.open-scap.org/job/scap-security-guide-pull-requests/394/ (el6) * https://jenkins.open-scap.org/job/scap-security-guide-pull-requests/395/ (el7) * https://jenkins.open-scap.org/job/scap-security-guide-pull-requests/396/ (fedora23) Right now "All checks have passed" section is not able to report results of all three tests though (and possibly fail of at least one of those three jobs has failed). I have filed: https://github.com/OpenSCAP/jenkins/issues/11 This to be possible to inspect in the future. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

1 0

RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release
by Wei N Chen (CENSUS/OIS FED) 20 Feb '16

20 Feb '16

Putting the so called personal attacks aside, I think what most of us want to know is what does the support vendor in question know that we, the SSG community and maker of the software, don't know about RHEL7 security configuration that warrants the additional checks being put into the draft. Regards, Wei Chen ________________________________________ ---------------------------------------------------------------------- Date: Fri, 05 Feb 2016 02:47:03 -0000 From: "Roger Greenwell" <greenwer(a)fedoraproject.org> Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release To: scap-security-guide(a)lists.fedorahosted.org Message-ID: <20160205024703.21572.23440(a)mailman01.phx2.fedoraproject.org> Content-Type: text/plain; charset="utf-8" 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(a)mail.mil. Respectfully, Roger Greenwell Chief, Cybersecurity – DISA

3 2

STIGs, DISA,, and the Open Source Process
by leam hall 06 Feb '16

06 Feb '16

I'm not involved in the STIG making "process" but I deal with the "product" on a daily basis. There are at least seven problems with the product that make me think the process does not include "thoughtful review". Malformed XML -- When I opened a ticket with DISA on the STIGs having thinkg like "<" or ">" characters written as "&lt" or "&gt", the response seemed to be "Well, the tools all work with it." Well, that means people have to code around your code. Bad characters in the text -- Better response from them on the ticket where I noted non-ASCII type characters in the text. "We'll get to it." Incorrect commands -- V-38660 in RHEL 6 V1R12. The command "grep 'v1\|v2c\|com2sec' /etc/snmp/snmpd.conf" might work as an "egrep". Unclear language -- For parameters in files like "system-auth", don't put the entire line when you only mean one parameter. Otherwise an unskilled auditor or admin will just use that one line, which might not be what's needed. Often even more stringent commands can be used but the admin could get ding'd because the line does not match exactly. Different VIDs for the same thing in different STIGs -- The precedent is established for using the same Vulnerability ID (VID) in different OS STIGs when the issue and fix are the same. However, this good idea seems to come and go, there are many VIDs for the same thing in different OS STIGs. Different VIDs for the same thing in the same STIG -- In the early RHEL 6 STIG there were 6 different VIDs for the exact same problem. I haven't checked lately but I think there are still a few duplicates. Partially automated tools -- There are ~264 VIDs in RHEL 6 V1R12, of which ~97 get marked as "Not Reviewed" because the benchmark file doesn't automate the checks. I'm not a great coder and I've spent a little time automating about 75-85% of those checks. Why can't the benchmarks do a better job than I? The Open Source process prioritizes "better product" over "good feelings". I'm glad DISA is looking at using the process to improve the product. When it comes right down to it, the STIGs are written to help protect the war fighter and our national security. It might get a little heated but our nation and our service members deserve our absolute best effort. Leam p.s. Watch me make a mistake in checking this. I have an excuse though, flu.

1 0

Jenkins Building Content at least 3 times
by Gabe Alford 01 Feb '16

01 Feb '16

Hello, Using the Jenkins build target, I noticed that the build process goes through building the SCAP content at least 3 times. It builds it once for `all`, once for 'dist`, and finally once for `validate`. I wonder if this is by design? It would be nice to consolidate it down to building it once for a faster Jenkins run. Maybe the Jenkins target could be the following: jenkins: clean all instead of: jenkins: clean all dist validate This would greatly reduce Jenkins tests and the amount of time those tests are run. Gabe

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide February 2016