At 02:40 AM 2/9/99 -0000, you wrote: > >I may have misunderstood the problem, but it seems to me that, if you can't >communicate with the device (you mention trying via SNMP & logging in), then >you should report it as "not tested completely, due to inability to connect" or >some such message. > >Does the tool do this, or does it report the device as being ok?? We _never_ say that it is OK. We just say if it isn't. In terms of the GUI and reports, we just tell you what we found, not what we didn't. If you're astute enough to read the logs, you can often find out why we didn't find it. Something we've been kicking around that would be a _lot_ of work would be to report checks as positive, negative, or unable to test. It would be a good improvement, but a real nightmare to implement. You have to take things like that and put them with everything else you'd like to do, then make decisions about which get done. Would you rather have that, or another 30 checks? >The example someone else gave of an NT box that has been patched with SP4, but >then has the TCP/IP drivers off of the original CD re-installed is an example >of a different potential problem. You *must* check something on the machine >being examined that can tell you *conclusively* whether or not the hole >exists. Checking whether SP4 was installed is not sufficient -- you have to >check the DLLs, registry settings, or whatever. If you can't perform this >check due to lack of access, you should report it as such, or report that the >machine "appears to not be vulnerable," and define what that means in the >documentation. >How does ISS handle the NT example referenced above?? We get that one right. All the NT patch checks are based on file timestamps, not service pack numbers. We have seperate checks for just service pack numbers, since you need less access to get the SP level than to get timestamps on system files. David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:36 PDT