<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>ClearNet Security: Tag vulnerability scanning</title>
    <link>http://blog.clearnetsec.com/articles/tag/vulnerabilityscanning</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description></description>
    <item>
      <title>This vulnerability scanner is so fast it must be good!</title>
      <description>&lt;p&gt;I wish that was true, but it is furthest from the truth.  There is an unfortunate conception for many tasked with reviewing or choosing a scanner (a conception espoused by the marketing of several Vulnerability Assessment vendors) which is the quality of a scanner is directly based on how fast it can scan.  In this race for speed, vendors&amp;rsquo; almost always default to performing less than complete checks.  In fact, some vendors shy away from adding checks to their products in an attempt to retain speed (i.e. adding more checks will slow a scanner down).  That is probably not what you want.  I also have yet to see a single commercial scanner default to performing a full TCP port check.  Totally understandable; if a scanner&amp;rsquo;s default policy opted for full coverage then you would surely dismiss the quality after running a test scan and learning you have to wait 40 hours for the results.  Too bad.  In the world of network-based vulnerability scanners there is a trade-off that spans long:  speed and accuracy.  Speed kills accuracy. &lt;/p&gt;
&lt;table width="630" border="0"&gt;
  &lt;tr&gt;
    &lt;td width="440"&gt;&amp;ldquo;Watch this man, I can scan a class B in 10 seconds.&amp;rdquo;&lt;br /&gt;
&amp;ldquo;Really?  How did you do that?&amp;rdquo;&lt;br /&gt;
&amp;ldquo;Oh, well, it is only checking if one port is open.&amp;rdquo;&lt;br /&gt;
&amp;ldquo;Ah, nice.&amp;rdquo;&lt;/td&gt;
    &lt;td width="180"&gt;&lt;img src="http://www.clearnetsec.com/roller/resources/cns/speedKills.jpg" width="100" height="107" alt="speedKills" /&gt;&lt;/td&gt;
  &lt;/tr&gt;
&lt;/table&gt;
&lt;p&gt;So if you want accuracy, then slow it down.  Don&amp;rsquo;t run a thousand threads, allow more time for remote devices to respond, choose complete port coverage, and don&amp;rsquo;t parallelize so much you saturate switch ports or test your operating system's TCP/IP stack limitations. &lt;/p&gt;

</description>
      <pubDate>Sun, 22 Jan 2006 11:11:00 -0700</pubDate>
      <guid isPermaLink="false">urn:uuid:e04f146a-bee3-4d6d-be7c-460eac6409f1</guid>
      <author>tate@ClearNetSec.com (Tate Hansen)</author>
      <link>http://blog.clearnetsec.com/articles/2006/01/22/this-vulnerability-scanner-is-so-fast-it-must-be-good</link>
      <category>scanning</category>
      <category>vulnerability scanning</category>
      <category>ClearNet Security</category>
      <category>Tate Hansen</category>
      <category>vulnerability</category>
    </item>
  </channel>
</rss>
