On Tue, Aug 2, 2016 at 5:15 PM, Shawn Wells <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
