SCC barfing on check systems it can't handle is a problem with SCC. They
were not following the XCCDF specification for processing the available
check systems. I don't know if they've fixed it -- maybe Jack V is lurking
here, and could say so.
I'd look at the OVAL results file if you want to see what openscap is
gathering, in order to determine the overall pass/fail in the XCCDF
results. Look for a few different options for output in `man oscap` --
look for "oval-results". As for all stages of the OVAL evaluation
(including what may be filtered) ... that's pretty complicated and may
require putting oscap into a debug mode, but removing any filters
temporarily may be informative.
On Tue, Aug 20, 2013 at 2:13 PM, Robert Sanders <rsanders(a)trustedcs.com>wrote:
Interesting. I asked because when I last tried the SSG content with
the
SCC3.1rc6 beta on a RHEL6.4 box I thought I saw a whole bunch of stuff pop
out regarding the OCIL-transitional stuff. Might have been just
informational, but I punted then and just ran the oscap stuff. I had hoped
to get the increased verbosity out of the SCC scanner for what failed to
assist tracing down possible issues with what the prose specified vice what
the code was actually doing. So - since I segued into that, is there a
magical incantation to give to oscap to dump what is it *really* looking
for without having to trace through the content? I'll reference the
question I raised last week about the 'Verify File Hashes with RPM' where
it seems that the OVAL may be filtering stuff out based on filepath vice
where the prose doesn't indicate any filtering.
-Rob
________________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org [
scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Shawn
Wells [shawn(a)redhat.com]
Sent: Tuesday, August 20, 2013 1:57 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: SSG line item references
On 8/20/13 10:51 AM, Robert Sanders wrote:
> I had gotten a request from a customer to provide a mapping of what
STIG line items were covered by Security Blanket. I didn't know initially
if my customer meant the officially approved STIG that DISA posted or the
SSG content. The official STIG has the identifiers (such as
RHEL-06-000001) in the actual line item code within the xccdf document.
The SSG content does not, and I was speculating that the references
(x.y.z) in the prose/reports were programmatically generated from the xccdf.
> I should note, that having the references either in-line or available
in a direct mapping makes life much easier for those of us who read the
contents of the files but are doing so somewhat outside the scap/oscap
world. Granted, the content is in a defined format which an associated
spec, and should be read in said fashion.
> Turns out I only need to address the official STIG document for now,
but this raised the questions of how the SSG line items would be mapped
back to the STIG line items, including the concerns on how the issues of
'new entries' and 'deprecated/retired entries' would be handled to
produce
a consistent numbering.
Existing maps are to the CCIs. Do they want the RHEL-06-****** number
for some reason?
> Stupid question of the day as well since I'm on the topic of
numbering. Is the SSG content directly consumable by other SCAP scanners?
I realize this may be a somewhat loaded question with a convoluted answer
(SCAP version number, OVAL version numbers, OCIL .......)
Should be compatible with any SCAP compliant scanner. We've worked with
the Tenable/ACAS folk in the past, and the SPAWAR SCC guys have tested
as well.
_______________________________________________
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