SCC will log errors when it finds a check system it doesn't understand but those errors will not stop the processing of OVAL or valid OCIL content. It will process all it can and generate results. Rules that used check systems other than OVAL or OCIL are marked appropriately as NOTCHECKED.
Jim From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Blank Sent: Tuesday, August 20, 2013 11:12 PM To: [email protected] Subject: Re: SSG line item references 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]<mailto:[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]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Shawn Wells [[email protected]<mailto:[email protected]>] Sent: Tuesday, August 20, 2013 1:57 PM To: [email protected]<mailto:[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]<mailto:[email protected]> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected]<mailto:[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
