scap-security-guide June 2014

scap-security-guide@lists.fedorahosted.org

19 participants
36 discussions

NIST 800-53 identifiers
by Kordell, Luke T 30 Aug '14

30 Aug '14

Hello, I noticed that the majority of the rule definitions now have NIST 800-53 identifiers or an empty set of quotes where an identifier will be added. Is there a way to get the already-added identifiers to show-up on the .html scan results? At the moment all I can see is the CCE number. Thanks, Luke K

5 6

Anyone using rhel6 ssg for centos6?
by Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN 22 Aug '14

22 Aug '14

I have been trying to get oscap working on my CentOS6.5 network core, without luck. Everything comes back with "Result notapplicable". I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA). Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS? -- Jeff v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr(a)USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005

17 39

[PATCH 0001-0003] - various ssh and gconf fixes
by Gabe Alford 07 Jul '14

07 Jul '14

Hello, These patches should address a few sshd false positives [Patch 0001] and add support for %gconf-tree.xml [Patch 0002] as well as a recommendation to change remediation for the GDM login banner from a gdm user default to a gconf mandatory setting [Patch 0003]. [Patch 0001]: When initially running the scan, some sshd settings such as PermitRootLogin were showing that they were set correcly. This patch should fix those as well as hopefully address https://fedorahosted.org/scap-security-guide/ticket/434 [Patch 0002]: Adds support to check %gconf-tree.xml. If %gconf-tree.xml exists (such as being deployed through Satellite), it takes precedence over any directory containing a %gconf.xml file under /etc/gconf/gconf.xml.mandatory. Plus having a single configuration file to create/change/modify is always a plus. Could potentially help address https://fedorahosted.org/scap-security-guide/ticket/282 [Patch 0003]: This is a recommendation to move setting the gdm banner and login settings from /var/lib/gdm to /etc/gconf/gconf.xml.mandatory. Reason for this is that the /etc/gconf directory is the location for administrators to set mandatory system policies over user set policies. Plus due to the gconf order of processing/precedance, it would be recommended to set under /etc rather than /var as anything set as a mandatory policy would be the default no matter what was in /var/lib/gdm. If approved, would potentially address https://fedorahosted.org/scap-security-guide/ticket/319 Thanks, Gabe

1 1

Formalizing the release process / schedule
by Jan Lieskovsky 07 Jul '14

07 Jul '14

Hello folks, since the request to give more formalized shape to SSG release process / schedule appeared couple of times in the past already (to mention some example: https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/00541…) and since we are hitting the doubt if already make / not to make yet a new release each time (each couple of weeks), we have decided to share the idea about SSG release process proposal. The proposal is to have release of new tarballs to happen at regular time (each 4 up to 6 weeks), and have a dedicated wiki page listing when the couple of upcoming releases will happen [1]. Something like Mozilla is doing for their products: https://wiki.mozilla.org/Releases https://wiki.mozilla.org/Releases#Upcoming_Releases https://wiki.mozilla.org/RapidRelease/Calendar From the observation period of 6 weeks is enough to have "sufficient count of new bug fixes / features requests" (aka the evolution step) these changes by themselves to form a need of a new release. But since it's difficult to decide if some patchset deserves new release (what's very valuable for someone, might not be that exciting / urgent for someone else etc.) to be fair we decided regular release period might be the best option how to balance out the various requests that might come out. Therefore starting from the next release we would like the release to happen regularly (each 4 up to 6 weeks - this to be decided yet. Feel free to vote for your preferences) at a date listed on the wiki page [2]. This could allow us establish automated functionality which could in sufficiently ahead period of time (for example week ago) notify the list the new release is coming and if someone is planning from their point of view critical patches to be included yet, those should be proposed / reviewed as soon as possible. To express personal opinion I would prefer the releases to happen on per 4 week scenario (while 6 weeks window might produce more changes in the tarball & less releases during the year at the end it also introduces some related inconsistency - one time the release would happen at start of the month, next time in the middle etc.) since it has the advantage the release will happen each time at regular (same) period, so users can update their functionality to better align upgrades with the schedule. Yet, since majority of us works on various / multiple projects, it might happen start of the week might not be the right time for new release (urgent action required somewhere else resulting into delay of a release etc.). Therefore I would propose the release to happen each first Friday in the month (the users could use the upcoming weekend to install the updates if / where appropriate). Feedback, comments, votes, proposals welcome. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team (on behalf of SSG upstream) [1] For now the wiki would contain just dates of past releases & dates of the upcoming ones (possibly also describing the release scheme). In the future it could provide further information what functionality each of the releases introduced (and taking it to the very advanced level hopefully too which functionality the new releases will contain in the future). [2] Once the scheme is clear (the proposal is approved), I will create that wiki page.

6 6

[PATCH] [RHEL] Make new 0.1.18 release
by Jan Lieskovsky 01 Jul '14

01 Jul '14

Hello folks, another 55 changes have been committed in between since the last 0.1.17 release: $ git log --format=%h --since=09-May-2014 | wc -l 56 so made a new 0.1.18 release: [1] http://repos.ssgproject.org/sources/scap-security-guide-0.1.18.tar.gz The attached patch has been (after testing) pushed to master (that's the 56-th change). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

4 3

[PATCH] Added vsftpd OVAL check and modified packages_installed.csv file
by David Smith 30 Jun '14

30 Jun '14

Signed-off-by: David Smith <dsmith(a)secure-innovations.net> --- RHEL/6/input/checks/package_vsftpd_installed.xml | 26 ++++++++++++++++++++ .../input/checks/templates/packages_installed.csv | 1 + 2 files changed, 27 insertions(+), 0 deletions(-) create mode 100644 RHEL/6/input/checks/package_vsftpd_installed.xml diff --git a/RHEL/6/input/checks/package_vsftpd_installed.xml b/RHEL/6/input/checks/package_vsftpd_installed.xml new file mode 100644 index 0000000..e4153a1 --- /dev/null +++ b/RHEL/6/input/checks/package_vsftpd_installed.xml @@ -0,0 +1,26 @@ +<def-group> +  + <definition class="compliance" id="package_vsftpd_installed" + version="1"> + <metadata> + <title>Package vsftpd Installed</title> + <affected family="unix"> + <platform>Red Hat Enterprise Linux 6</platform> + </affected> + <description>The RPM package vsftpd should be installed.</description> + <reference source="swells" ref_id="20130829" ref_url="test_attestation"/> + </metadata> + <criteria> + <criterion comment="package vsftpd is installed" + test_ref="test_package_vsftpd_installed" /> + </criteria> + </definition> + <linux:rpminfo_test check="all" check_existence="all_exist" + id="test_package_vsftpd_installed" version="1" + comment="package vsftpd is installed"> + <linux:object object_ref="obj_package_vsftpd_installed" /> + </linux:rpminfo_test> + <linux:rpminfo_object id="obj_package_vsftpd_installed" version="1"> + <linux:name>vsftpd</linux:name> + </linux:rpminfo_object> +</def-group> diff --git a/RHEL/6/input/checks/templates/packages_installed.csv b/RHEL/6/input/checks/templates/packages_installed.csv index ef6e737..dc0ae21 100644 --- a/RHEL/6/input/checks/templates/packages_installed.csv +++ b/RHEL/6/input/checks/templates/packages_installed.csv @@ -13,3 +13,4 @@ postfix psacct rsyslog screen +vsftpd -- 1.7.1

3 4

Fwd: [gov-sec] Defense in Depth 2014 registration *open*!
by Shawn Wells 27 Jun '14

27 Jun '14

(Cross pollinating to the SSG community) -------- Original Message -------- Subject: [gov-sec] Defense in Depth 2014 registration *open*! Date: Fri, 27 Jun 2014 12:49:53 -0400 From: Shawn Wells <shawn(a)redhat.com> To: gov-sec(a)redhat.com Friends, It's been awhile since originally posting about Defense in Depth 2014, but we've sorted things and registration is now open: http://defenseindepth2014.org/ We'll be hosting the event on Wednesday 30-JULY, 2014, at the Tysons Corner Marriott in Northern VA (full details on website). Last year brought ~200 attendees together, spanning the U.S. Defense, Intelligence and Civilian communities. This year we're planning for a slightly bigger event (likely ~300) and have added several tracks. You'll see everything listed on the webpage, but some highlights: * We've broken things into three primary tracks: - *Deployment Stories: * We've received permission from COTRs to discuss a few ongoing projects within the DoD/IC community. For example, within the DoD community a program has received ATO to perform cross domain super computing. We've plugged in multiple networks, from multiple agencies, into a single host, created a front-end job submission form, and wrapped the whole thing with SELinux. Another session will cover how we pushed KVM through ICD 503 accreditation within the U.S. Intelligence Community. 'Deployment Story' sessions bring together the tech leads on various programs to share their mission, how they're accomplishing it, and hopefully act as a catalyst for information sharing on approaches taken; - *Labs:* These are hands-on technical labs with the instructors being the actual developers of the technology. Steve Grubb will be leading the hands-on Linux Audit lab, with Jeff Blank/Dave Smith/myself leading the SCAP and STIG sessions. The labs will give you hands-on experience with the technologies, and allow for immediate feedback to the developers. Gripes against the RHEL6 STIG? Come to the SCAP session! :-) - *Tech Briefings:* Covering newly released technology, such as RHEL7+Docker integration, and emerging tech, such as forensics for KVM-based environments. Again, the speakers are the upstream developers (such as Dan Walsh) of the technology. While not hands-on labs, generally these sessions have live demos of the technology and not just slides. RHEL7 was released 10-JUNE; come learn all about it. * You may notice some session blocks have been left "TBD" -- this is to afford an opportunity to hear community feedback on any additional session requests, and give potential speakers an opportunity to share what they're working on. If you're interested in presenting, contact me off-list (shawn(a)redhat.com). For those attending the labs, BYOD. We'll be providing wifi and virtual machines; your laptop must support wifi connectivity and have an SSH client installed (you'll be SSH'ing into EC2-hosted virtual machines). For those who couldn't make Red Hat Summit, the Defense in Depth workshops bring many upstream developers to the Washington D.C. area for a single day. Many of the speakers, such as Dan Walsh, were voted the best sessions of Red Hat Summit 2014; other sessions bring out the lead engineers for several of DoD/IC initiatives. It's a very informal, very technical, day. We hope to see you there! Questions? Sound off on Red Hat's government users mailing list, gov-sec [1]! And again, the workshop webpage: http://defenseindepth2014.org/ -Shawn [1] http://www.redhat.com/mailman/listinfo/gov-sec -- Shawn Wells Director, Innovation Programs shawn(a)redhat.com | 443.534.0130 @shawndwells

1 0

Mailling-list footer
by Kayse, Josh 27 Jun '14

27 Jun '14

Hello list, I wonder if we could improve the mailing list footer for scap-security-guide It can be configured in mailing list administration in section “Non-digest options”. Currently the footer looks like: "_______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide” What about something more useful? “-- scap-security-guide(a)lists.fedorahosted.org mailing list https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/wiki/Collateral-and-Referen… The most important change is replacing “_______________________________________________” with “-- " “-- “ is usually interpreted by e-mail clients as “beginning of signature” and automatically stripped from replies. Take note that it is dash dash space. It would help prevent mailing list signatures from accumulating in replies like this: > [blah blah] Good idea > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide” > _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide” Other links in proposed signature were picked from a recent mailing list topic. Thanks, -josh PS: This is transcribed almost verbatim from another mailing list I am on where I thought it sounded like a good idea.

3 7

[PATCH] [RHEL/6] Fix implementation of accounts_password_pam_cracklib_minclass OVAL check. Provide corresponding XCCDF definition & start using the rule.
by Jan Lieskovsky 27 Jun '14

27 Jun '14

The following patch: [1] https://git.fedorahosted.org/cgit/scap-security-guide.git/commit/?id=a38ece… added support for accounts_password_pam_cracklib_minclass OVAL check & corresponding remediation script. But it got never used due to missing XCCDF definition. Therefore: 1) fix the accounts_password_pam_cracklib_minclass actual OVAL check implementation so it would be more aligned with existing accounts_password_* OVAL checks, 2) provide corresponding XCCDF definition for it & start using it. Testing status: --------------- The change has been tested on RHEL-6 & works as expected (=> added the test_attestation timestamp into OVAL definition). Please review. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team P.S.: Will have a look at the corresponding remediation script yet to see if any updates are needed.

2 2

[PATCH] [RHEL/6, RHEL/7, shared] Implement OVAL check & XCCDF definition for package_talk_removed rule
by Jan Lieskovsky 27 Jun '14

27 Jun '14

The proposed patch adds OVAL check & corresponding XCCDF definition for RHEL-6 & RHEL-7 for "package talk removed" rule. Tested on both of RHEL-6 & RHEL-7 (definition works as expected on both products & is displayed properly also in the HTML version[s] of the guide[s]), updated test attestations & moved the OVAL to shared. Please review. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide June 2014