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 <[email protected]>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: [email protected] [ > [email protected]] on behalf of Shawn > Wells [[email protected]] > Sent: Tuesday, August 20, 2013 1:57 PM > To: [email protected] > 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
