I'm trying to use scap-workbench to run the Upstream STIG for RHEL6 Workstation profile and it explicitly wants the RHEL6 OVAL as a remote resource, http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_6.xml. If I check "Fetch remote resources" then, of course, the scans and remediation work as expected but how can i get the entire benchmark to run offline? Can I download the oval info ahead of time and place it in a specific location?
---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
Hello Chuck,
thank you for checking.
----- Original Message -----
From: "Chuck Atkins" chuck.atkins@kitware.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Monday, August 1, 2016 9:19:14 PM Subject: How do I use remote resources offline?
I'm trying to use scap-workbench to run the Upstream STIG for RHEL6 Workstation profile and it explicitly wants the RHEL6 OVAL as a remote resource, http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_6.xml . If I check "Fetch remote resources" then, of course, the scans and remediation work as expected but how can i get the entire benchmark to run offline?
AFAICT the offline scan with Red_Hat_Enterprise_Linux_6.xml pre-downloaded isn't possible right now. Not like it wouldn't be possible to implement that (maybe it could be possible to specify some expected location, where these files could live and use "file:///" protocol instead of "http://" one, like doing currently).
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).
Unfortunately the way OVAL standard works isn't that flexible it would allow something like:
if timestamp / MD5 sum on "Red_Hat_Enterprise_Linux_6.xml" file differs: use the most recent version else: use the cached version
OVAL only allows to specify URI where the remote content should be retrieved from (but there isn't some timestamp / MD5 sum checking).
Can I download the oval info ahead of time and place it in a specific location?
Not right now. Sorry. See above for the explanation.
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.
Hope this helps.
Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
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.
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?
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.
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.
On Tue, Aug 2, 2016 at 5:15 PM, Shawn Wells <shawn@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
scap-security-guide@lists.fedorahosted.org