In my dealings with them we have been able to document their false
positives ("No, we don't run Bind 5, we run fully patched Bind 9",
etc.) and they have accepted it- eventually- sometime a conference
call with [they who shall not be named] and the customer/victim is
required. I doubt anyone on the web scanning team understand the
concept of "compensating controls", but that might be worth a try.
Good luck
Jack
On Mon, Jan 25, 2010 at 2:05 AM, gameman733
<[email protected]> wrote:
> Sorry for bringing up an older topic, but this is one I've run into. One of
> our clients was using Security Metrics (definitely agree with Jack Daniel as
> far as the quality/results of the scan) who would continuously fail. Some of
> the reasons were things like "Version X.Y.Z of $softwarepackage has a
> security hole in this configuration. Please update." The problem was two
> fold however, 1) they weren’t using that configuration (example being a
> specific module in Apache for example). 2) Redhat, from what I have
> researched, backports all of their security updates. For example, Verison
> 2.1.4 of apache has some vulnerability, it gets fixed in 2.1.5. Red hat will
> then take that fix, patch 2.1.4, and leave the version number alone. The
> scan sees version 2.1.4, and flips out, making you as failing. Short of
> completely moving to a totally different distribution (to my knowledge..),
> there isn't much you can do short of compiling your own version.
>
> I was curious, in this situation, what would be the proper method of
> resolving the issue? I assume there's a better way than fooling the scanner
> (hackish solution, just needed it to pass as quickly as possible, etc.).
_______________________________________________
Pauldotcom mailing list
[email protected]
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
