2:30 p.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
7:34 p.m.
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... ;)
11:48 a.m.
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!
9:06 p.m.
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).
1:36 p.m.
* 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_fp...
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.
1:52 p.m.
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.
5:42 p.m.
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...
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...
6:52 p.m.
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 :)
4117
days inactive
4125
days old
scap-security-guide@lists.fedorahosted.org
10 comments
6 participants
participants (6)
-
David Smith -
Gary Gapinski -
Gary Gapinski
-
Jeffrey Blank -
Shawn Wells -
Shawn Wells