note for the USGCB tickets
by Jeffrey Blank
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
10 years, 9 months
xsl:attribute: The attribute name 'xmlns' is not allowed.
by Brian Millett
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
10 years, 11 months
scap-security-guide v0.1-10 released -- now with JBossEAP5!
by Shawn Wells
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
11 years
Remediation Scripts
by Shawn Wells
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?
11 years
Signed content purpose question
by Matt Micene
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
11 years, 1 month
