Looks fine to me, just so long as you'd considered extending the Common profile (and then intentionally chosen not to use it).
Regarding the note about cron permissions ("placeholder"), they may have been removed in favor of the systemwide RPM permissions check, though I'll admit I don't recall precisely. Strategy was documented here: https://fedorahosted.org/scap-security-guide/wiki/STIGfileperms
Also, this is great stuff! Seeing this come together shows how the content can be leveraged for two baselines, which increases quality through vendor coordination, and decreases government waste.
And of course, for any of our friends at NIST, the comments in the profile make clear that this is really just a candidate for submission, and not official yet :) But it's on its way.
Hmmm, do we have a transform that creates a table in line with what's called for in NIST SP 800-70 Appendix E, for proper submission, sans perhaps the "Impact" column (which lacks a corresponding XCCDF element).
On 01/30/2013 09:46 PM, Shawn Wells wrote:
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 1/31/13 3:30 PM, Jeffrey Blank wrote:
Looks fine to me, just so long as you'd considered extending the Common profile (and then intentionally chosen not to use it).
To give us a solid starting point I wanted to create a profile which held *only* the USGCB rules from RHEL5 and did not extend beyond them.
Regarding the note about cron permissions ("placeholder"), they may have been removed in favor of the systemwide RPM permissions check, though I'll admit I don't recall precisely. Strategy was documented here: https://fedorahosted.org/scap-security-guide/wiki/STIGfileperms
The crontab files themselves are user generated, they would not be picked up with RPM verification. There is a section on this within the SSG, however it's been commented out. Over the next few weeks I'll revisit this.
Also, this is great stuff! Seeing this come together shows how the content can be leveraged for two baselines, which increases quality through vendor coordination, and decreases government waste.
And of course, for any of our friends at NIST, the comments in the profile make clear that this is really just a candidate for submission, and not official yet :) But it's on its way.
Hmmm, do we have a transform that creates a table in line with what's called for in NIST SP 800-70 Appendix E, for proper submission, sans perhaps the "Impact" column (which lacks a corresponding XCCDF element).
Not yet.... and you have such amazing xslt skills.... hmm... ;)
The crontab files themselves are user generated, they would not be picked up with RPM verification. There is a section on this within the SSG, however it's been commented out. Over the next few weeks I'll revisit this.
Ah, gotcha, I was thinking of the systemwide ones in /etc/cron*. User crontabs with incorrect permissions sounds like a contrived concern to me, but I'll be happy to discuss.
Hmmm, do we have a transform that creates a table in line with what's called for in NIST SP 800-70 Appendix E, for proper submission, sans perhaps the "Impact" column (which lacks a corresponding XCCDF element).
Not yet.... and you have such amazing xslt skills.... hmm... ;)
Sigh, perhaps. Gary and Brian aren't too shabby either :)
When I have a few cycles to spare, I first want to simplify some of the existing transforms (now that oscap xccdf resolve works) and document the overall build process better on the Wiki.
Thanks again for the updated USGCB profile!
On 2/4/13 12:48 PM, Jeffrey Blank wrote:
The crontab files themselves are user generated, they would not be picked up with RPM verification. There is a section on this within the SSG, however it's been commented out. Over the next few weeks I'll revisit this.
Ah, gotcha, I was thinking of the systemwide ones in /etc/cron*. User crontabs with incorrect permissions sounds like a contrived concern to me, but I'll be happy to discuss.
They've been dropped from the RHEL6 STIG candidate, hopefully the argument will win they should be dropped from USGCB as well. Opened a ticket to remind us of the conversation when the time is right (e.g. when conversations begin between RHT Corporate and NIST).
Hmmm, do we have a transform that creates a table in line with what's called for in NIST SP 800-70 Appendix E, for proper submission, sans perhaps the "Impact" column (which lacks a corresponding XCCDF element).
Not yet.... and you have such amazing xslt skills.... hmm... ;)
Sigh, perhaps. Gary and Brian aren't too shabby either :)
When I have a few cycles to spare, I first want to simplify some of the existing transforms (now that oscap xccdf resolve works) and document the overall build process better on the Wiki.
Thanks again for the updated USGCB profile!
It's a starting point.
FWIW, over the next two weeks I hope to extend the rhel6-stig-server into "RHSS2-stig" (e.g., Red Hat Storage aka Gluster).
- http://xml.garygapinski.com/scap-security-guide/SP800-70-E.xslt is the transform (probably best viewed using Chrome, as not all browsers handle HTML5 details elements well)
- http://xml.garygapinski.com/scap-security-guide/SP800-70-E.xhtml is the output document
Great!
This was not driven by the USGCB Profile. I'll do that next (soon, as I must adapt, undoubtedly augment, the RHEL6 USGCB profile and field a draft variant by Monday, and it will likely address all Rules found in scap-security-guide, including ones that will be deemed optional). Note that not all Rules have CCEs. Perhaps some should.
Yes. David is looking into that now.
It will be rather easy to adapt for submission in the SP800-70 format. Reference is made to a "spreadsheet", which I think is a primitive type of document from a past age. The document name must end in ".xls" or ".xlsx", but no normative specification for document content is provided, so just about anything goes, as was obviously the case with the RHEL5 USGCB content.
Well, it was a first in many ways, and still impressive given all the constraints (cough cough the underlying formats and dearth of authoring tools). But we'll continue forward, and when the time comes for submission, our intention is to use an HTML document which contains a table, and see how receptive our friends at NIST will be to using open standards :)
The names, format, etc. can be changed. I'll push this into version control once it is acceptable.
Fantastic, thanks.
BTW: SP 800-53 rev 4 http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800_53_r4_draft_fpd.pdf is just out in draft.
I wonder if they would be so bold as to put it into a standardized, machine-parseable format. It would be far more useful if it were available in more than just an opaque human-readable format.
The prior rev is available online and as a less-than-straightforward XML-export-capable "database": http://csrc.nist.gov/groups/SMA/fisma/support_tools.html.
I tried this with high hopes, and found its output to be complete garbage. If someone else has gotten it to produce useful output, I'd love to know.
So, cites from the scap-security-guide content should likely target that rather than the rather verbose <reference>s now present.
E.g.,
<reference href=" https://web.nvd.nist.gov/view/800-53/control?controlName=CM-7#enhancement-2">CM-7(2)</reference>
Ah, gotcha. This would be a nicety for the output of the prose (HTML) guide we'll publish, being able to hop directly to these pages...
The goal was to wrap that up by COB today and push it to the list, but that's likely to be handled early (very early) next week.
On 02/07/2013 02:36 PM, Jeffrey Blank wrote:
This was not driven by the USGCB Profile. I'll do that next (soon, as I must adapt, undoubtedly augment, the RHEL6 USGCB profile and field a draft variant by Monday, and it will likely address all Rules found in scap-security-guide, including ones that will be deemed optional). Note that not all Rules have CCEs. Perhaps some should.
Yes. David is looking into that now.
On 2/7/13 8:04 AM, Gary Gapinski wrote:
#
# http://xml.garygapinski.com/scap-security-guide/SP800-70-E.xhtml is the output document
Sitting here, having a beer, catching up on emails after an atrociously long and frustrating day.
Noticed the IMPACT and CATEGORY definitions. Spit my beer up laughing.
Oh man, I needed that :)
scap-security-guide@lists.fedorahosted.org