On Tue, Aug 2, 2016 at 5:15 PM, Shawn Wells <shawn(a)redhat.com
<javascript:_e(%7B%7D,'cvml','shawn@redhat.com');>> wrote:
On 8/2/16 10:09 AM, Chuck Atkins wrote:
Hi Jan,
Thanks for taking the time to respond.
But the issue is right now there isn't motivation to do that. Let me
> explain -
> the Red Hat Enterprise Linux 6 CVE OVAL changes pretty quickly (to my
> knowledge
> it's updated every 12 hours). So instructing oscap / scap-workbench tools
> to
> use cached XML file from some chosen location would be prone to "false
> sense
> of security" (suppose 2 weeks outdated
"Red_Hat_Enterprise_Linux_6.xml"
> file
> that would be used to scan the system in question rather than more recent
> one -
> this could result in state the system wouldn't be reported as vulnerable
> to
> pretty lot of CVE issues).
>
The motivation in our case is to have regular scans of machines on an air
gapped network using up-to-date (within som reasonable time frame) scanning
content. Given that the machines will be offline from the internet there
is an acceptable limitation that tey can only be as up to date in packages
and scanning content as the frequency of the scheduled maintenance window.
+1. Almost all users of the DoD STIG profile will be offline/disconnected
from the internet. DoD only requires them to perform patches every 30 days,
so a delay is widely accepted.
+1 from me too. More folks will want this than users of the DOD STIG
profile too.
Maybe we could consider enhancing the current implementation (to honour
> remote OVAL timestamps / MD5 sums and use cached version if possible).
> But this:
> * First needs scap-workbench RFE ticket,
> * Itself is subject of upstream discussion, and can be closed as hard /
> impossible to implement properly.
>
What might be easier is to allow the "save as RPM" option in the SCAP
Workbench for saving customizations to fetch any remote resources and
package them in the resulting RPM and have the resulting tailoring file
point to them with file:// instead. Thoughts?
Some users may be importing the OVAL feeds on a cron job, or downloading
periodically. So additionally/alternatively, perhaps we could check if the
OVAL definitions exist somewhere (e.g. /usr/share/xml/scap/RedHat/OVAL/feed.xml)
locally.
I've been scanning vulnerabilities separately like this... Saw it in some
doc somewhere.
wget
https://www.redhat.com/security/data/metrics/com.
redhat.rhsa-all.xccdf.xml
wget
https://www.redhat.com/security/data/oval/com.redhat.rhsa-all.xml
oscap xccdf eval com.redhat.rhsa-all.xccdf.xml
--
Andrew Shewmaker
--
Andrew Shewmaker