scap-security-guide March 2013

scap-security-guide@lists.fedorahosted.org

30 participants
63 discussions

note for the USGCB tickets
by Jeffrey Blank 11 Jul '13

11 Jul '13

Shawn (et al), The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency. A few notes: 1) I've been able to close some of the tickets as "fixed", providing explanation as to why. Some of them are being handled through other mechanisms for RHEL 6. 2) If anybody starts executing on the other tickets, the goal is NOT to add new rules as the ticket says, but rather to conduct investigation to see if the Rule is applicable to RHEL 6 in the same way it was applicable to RHEL 5. 3) In the ticket titles, there is some of the odd CCE language which talks about disabling/enabling things "as appropriate". That's fine as an identifier (and the RHEL 6 USGCB did use some of this language). However, this style of language, which is intended for neither a human nor a machine, should never appear in the project's XCCDF. (Just in case anybody gets any ideas.) Thanks, Jeff -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance

5 10

xsl:attribute: The attribute name 'xmlns' is not allowed.
by Brian Millett 05 Jun '13

05 Jun '13

Hello, I'm trying to get started with making the latest clone from the git repository and I get the following error: [bpm]$ git clone http://git.fedorahosted.org/git/scap-security-guide.gitscap-security-guide Cloning into 'scap-security-guide'... remote: Counting objects: 14016, done. remote: Compressing objects: 100% (5257/5257), done. remote: Total 14016 (delta 10574), reused 10664 (delta 7718) Receiving objects: 100% (14016/14016), 3.18 MiB | 2.17 MiB/s, done. Resolving deltas: 100% (10574/10574), done. [bpm]$ cd scap-security-guide/RHEL6/ [bpm]$ make all xsltproc -o output/rhel6-shorthand.xml input/guide.xslt input/guide.xml xmllint --format --output output/rhel6-shorthand.xml output/rhel6-shorthand.xml xsltproc -o output/unlinked-noprofiles-rhel6-xccdf.xml transforms/shorthand2xccdf.xslt output/rhel6-shorthand.xml compilation error: file transforms/shorthand2xccdf.xslt line 19 element attribute xsl:attribute: The attribute name 'xmlns' is not allowed. make: *** [shorthand2xccdf] Error 5 I've a fedora 18 , x86_64 installation. Any ideas? Thanks. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

4 6

scap-security-guide v0.1-10 released -- now with JBossEAP5!
by Shawn Wells 01 May '13

01 May '13

Friends, A rebase of the scap-security-guide RPM was *long* overdue! Please see the "Consume" section of the project wiki for download information: https://fedorahosted.org/scap-security-guide/ Highlights of SSG v0.1-10 include: - JBossEAP5 content! Utilizing content from the SCAP Security Guide project, on 29-JAN-2013 Red Hat corporately submitted paperwork to DISA FSO to begin the JBossEAP5 STIG process. SSG v0.1-10 reflects the OCIL, OVAL, and XCCDF content of this submission. Please refer to /usr/share/xml/scap/ssg/guide/JBossEAP5_Guide.html for details. We look forward to your feedback via the SSG mailing list! [1] - `man scap-security-guide` now provides sample usage of the content. - Several bugfixes relating to OVAL content. Many thanks to Brian Millet, Kenneth Stailey, Logan Rodrian, and all other members of the SSG community for the reports and patches! - The RHEL6 STIG profile was renamed "stig-rhel6-server" - A RHEL6 checklist has been included (/usr/share/xml/scap/ssg/guidestig-rhel6-server-guide.html). This outlines what specific rules are currently part of the profile. - A number of updates against NIST 800-53 mappings has been completed. Please see files under /usr/share/xml/scap/ssg/policytables/. [1] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

1 1

Remediation Scripts
by Shawn Wells 07 Apr '13

07 Apr '13

I've been taking a few off-list questions around remediation lately, namely from interested parties asking "where do we start?" Wanted to move those conversations to on-list. Here's a few of the common questions and my thoughts to get us started. (1) What language(s) should be used? IMO, bash. I'm leaning this way because it's included in *every* RHEL release, whereas puppet modules would require the installation of 3rd party software. I'd like to see as much done through 'native' tools as possible. There's certainly advantages to Perl (e.g., potential speed) however I don't think we want to assume Perl is installed on all RHEL machines. (2) Do we perform checking in the scripts? Defined further, should the scripts contain conditional checks to see if they should be ran? IMO, no. That's what OVAL is for. (3) Where do we begin? - Name remediation scripts after corresponding XCCDF rule - Build process includes them into final ssg-rhel6-xccdf.xml Known challenge on passing XCCDF variables through to the scripts, however I wouldn't let this hold us up. Still *tons* of work to be done while this gets sorted. There's a good bit of RHEL6 content in the Aqueduct project that (I believe) Tresys committed. Perhaps we could reuse those scripts?

12 33

Signed content purpose question
by Matt Micene 04 Apr '13

04 Apr '13

A follow up from the SCAP workshops that Shawn and Jeff hosted this week (great job guys) on the topic of signed content. What is the intent for having DISA / NIST / AuthorityX signing SCAP content for delivery? Are people looking for full attestation or validation? Neither addresses the challenge of what to do with local content for waivers, but each poses different options for the local maintainer. The tooling also has different challenges if there's a need to validate a digital signature versus verifying a digest. Disjointed ancillary thought, is there an include function in the XCCDF? I haven't been able to find one in the spec so far but it could be useful for local waiver overrides while preserving the official content. There's an obvious issue (as I type this) that any sort of standard include statement would allow someone to completely override policy for a scan while still mimicking the appropriate results. Having a reporting tool that can do diffs of the results and the policy settings could catch that, but that may not be sufficient for reporting or detection time. Regards, Matt Micene Engineering Team Lead RHCA #100-002-435 DLT Solutions Direct 703-773-1195

3 4

[PATCH 21/21] Renamed OVAL no_empty_passwords.xml to match XCCDF rule name
by Shawn Wells 02 Apr '13

02 Apr '13

4 6

[PATCH 03/21] Updated package_screen_installed
by Shawn Wells 02 Apr '13

02 Apr '13

2 1

[PATCH 02/21] Updated package_aide_installed
by Shawn Wells 02 Apr '13

02 Apr '13

2 1

[PATCH 01/21] Updated create_package_installed template process
by Shawn Wells 02 Apr '13

02 Apr '13

2 1

[PATCH 18/21] Renamed OVAL in restrict_root_console_logins to match XCCDF rule name
by Shawn Wells 02 Apr '13

02 Apr '13

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2013