Hi,
[snip]
I do not subscribe to the theory that remote fetches are a potential
risk. I will be happy to defend this carefree attitude vigorously
and at length.
This is far worse than a potential risk, DNS poisoning is not just theoretical ;-). All it
takes is a one line change of /etc/hosts either on the DNS server that is used locally or
even on the machine. Or setting up a transparent reverse-proxy somewhere in the chain
between you and the content provider. Then all compliance checks can pass forever and ever
without anyone noticing.
It also creates a single point of failure. What if someone takes over the domain that is
used to fetch the files? What if the hosting provider is hacked? Do you think it's
impossible for NIST to have any of these problems? [1]
Even if one warrants that remote fetches offer some risks, these
could be obviated by providing a mode of operation for those who
fear them, as has already been done for href attributes, and an
obverse mode for those who embrace them.
I would dare say that people who do not fear those risks shouldn't be in this
business. After all you are doing security compliance checking. If you are happy to enable
external factors (your ISP, hosting provider, ...) to affect your results it makes no
sense to even check.
It can also expose information about your internal infrastructure to the outside.
I will also (at the risk of citing a document for which I have grave
misgivings) mention that NIST SP 800-126r2 ยง3.10 provides a method
by which document integrity can be assured. Please do not read any
other part of that publication. Prefer the prior version for now.
We are aware of this and efforts have been made to make this work. Unfortunately it gets
very complicated very quickly. There are countless ways to sign the content and there are
countless ways to check. For now we recommend this:
https://www.redhat.com/archives/open-scap-list/2012-December/msg00000.html
Although I do admit that I would prefer to have this in openscap itself and always
enabled.
[1]
http://www.theregister.co.uk/2013/03/14/us_malware_catalogue_hacked/
--
Martin Preisler