<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Evaluating malware from a network perspective</title>
	<atom:link href="http://mcwresearch.com/archives/469/feed" rel="self" type="application/rss+xml" />
	<link>http://mcwresearch.com/archives/469</link>
	<description>Things I think I've thought about</description>
	<lastBuildDate>Thu, 16 Feb 2012 16:52:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: mcwresearch.com &#187; Micro defense in depth</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-4422</link>
		<dc:creator>mcwresearch.com &#187; Micro defense in depth</dc:creator>
		<pubDate>Mon, 11 Jun 2007 16:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-4422</guid>
		<description>[...] *I had a run-in with an IRCBot a short while ago, delivered by a similar Big Yellow worm, that uses custom commands when joining the IRC server. Instead of issuing the standard &#8220;/join&#8221; and &#8220;/nick&#8221; commands, it simply uses &#8220;join&#8221; and &#8220;nick&#8221;, which sailed right past my IPS. The reason I caught it was because by default I block ports 6661-7000 outbound at the firewalls. I got curious what it was and opened the firewall temporarily while running a packet capture to see what it was. [...]</description>
		<content:encoded><![CDATA[<p>[...] *I had a run-in with an IRCBot a short while ago, delivered by a similar Big Yellow worm, that uses custom commands when joining the IRC server. Instead of issuing the standard &#8220;/join&#8221; and &#8220;/nick&#8221; commands, it simply uses &#8220;join&#8221; and &#8220;nick&#8221;, which sailed right past my IPS. The reason I caught it was because by default I block ports 6661-7000 outbound at the firewalls. I got curious what it was and opened the firewall temporarily while running a packet capture to see what it was. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-2258</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Tue, 08 May 2007 13:57:15 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-2258</guid>
		<description>No offense taken.  I was just surprised to hear someone say we have over-engineered security, which is certainly a concern.</description>
		<content:encoded><![CDATA[<p>No offense taken.  I was just surprised to hear someone say we have over-engineered security, which is certainly a concern.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cd-MaN</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-2073</link>
		<dc:creator>Cd-MaN</dc:creator>
		<pubDate>Fri, 04 May 2007 06:52:59 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-2073</guid>
		<description>In my opinion (and I&#039;m by no means an expert in this), AV and IDS are both reactive technologies, in the sense that they need continious update to their engines / signatures so that they can function at their full potential. From a conceptual view they are very similar so I see no reason for one of them to be declared superior to the other. In fact they both rely on blacklisting which is (to put it mildly) not a very good security practice.

As for heuristics: they are an often misunderstood aspect of AV technology (again, mostly because of the marketing). They are not magic and are equivalent to a more permissive signature (for example one heuristic might be to flag executables which contain the algoritm to use \Device\PhysicalMemory to remove themselves from the process list). They detect &quot;new&quot; malware only in the sense that the detected malware wasn&#039;t seen by a human virus analyst, but it is still based on &quot;old&quot; and well understood technologies. This means that heuristics can be evaded at least in two ways: (a) using new technologies or (b) hiding the usage of old technologies.

AV on company desktops is really overkill (IMHO) and also less secure than a good whitelisting product. Whitelisting is a simple and efficient way to provide a 99.99% protection and is easily applicable in a corporate environment where there is an IT department. AV products are more suitable for home users who don&#039;t have the necesarry knowledge to decide if a piece of software is legit or not and want to run a wide variety of code on their machines.

Finally I would like to apologize if I offended you with the word &quot;overengineered&quot;. The truth is that I don&#039;t have experience in managing / supporting large corporate networks, but I imagine that if I had to I could sleep sound knowing that a whitelisting solution is in place and not complicating myself if IDS&#039;s/IPS&#039;s.</description>
		<content:encoded><![CDATA[<p>In my opinion (and I&#8217;m by no means an expert in this), AV and IDS are both reactive technologies, in the sense that they need continious update to their engines / signatures so that they can function at their full potential. From a conceptual view they are very similar so I see no reason for one of them to be declared superior to the other. In fact they both rely on blacklisting which is (to put it mildly) not a very good security practice.</p>
<p>As for heuristics: they are an often misunderstood aspect of AV technology (again, mostly because of the marketing). They are not magic and are equivalent to a more permissive signature (for example one heuristic might be to flag executables which contain the algoritm to use \Device\PhysicalMemory to remove themselves from the process list). They detect &#8220;new&#8221; malware only in the sense that the detected malware wasn&#8217;t seen by a human virus analyst, but it is still based on &#8220;old&#8221; and well understood technologies. This means that heuristics can be evaded at least in two ways: (a) using new technologies or (b) hiding the usage of old technologies.</p>
<p>AV on company desktops is really overkill (IMHO) and also less secure than a good whitelisting product. Whitelisting is a simple and efficient way to provide a 99.99% protection and is easily applicable in a corporate environment where there is an IT department. AV products are more suitable for home users who don&#8217;t have the necesarry knowledge to decide if a piece of software is legit or not and want to run a wide variety of code on their machines.</p>
<p>Finally I would like to apologize if I offended you with the word &#8220;overengineered&#8221;. The truth is that I don&#8217;t have experience in managing / supporting large corporate networks, but I imagine that if I had to I could sleep sound knowing that a whitelisting solution is in place and not complicating myself if IDS&#8217;s/IPS&#8217;s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-2054</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Thu, 03 May 2007 15:07:47 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-2054</guid>
		<description>Thanks for the link.  I&#039;ll definitely check it out.

Regarding AV; I agree that in its current state it is a reactive technology and that is the whole problem.  Its time that intrusion prevention gets their peanut butter stuck in AV&#039;s chocolate.  &#039;Heuristics&#039; or similar technology in AV is key to the future of the product.  

Regarding our security infrastructure being over-engineered, I haven&#039;t heard that one before!  I might understand your thinking the home-brewed IDS backing up the retail IPS might be overkill but it isn&#039;t simply because they perform similar duties in different ways:

1.  The retail IPS is a best-in-class solution that does deep-packet inspection and protocol analysis and has the ability to act on packets.

2.  The home-brewed IDS monitors for deny statements based on firewall rules (configured as you said, default deny) and alerts on 3 pre-defined thresholds of X, Y and Z events. 

The home-brewed IDS is much faster than the IPS because it is doing much less.  

Not to mention the fact that the IPS doesn&#039;t block a worm&#039;s scan, only the payload delivery.  Therefore with the IDS, we get a warning at the scanning phase of the worm (as long as the scans are blocked by the firewall).</description>
		<content:encoded><![CDATA[<p>Thanks for the link.  I&#8217;ll definitely check it out.</p>
<p>Regarding AV; I agree that in its current state it is a reactive technology and that is the whole problem.  Its time that intrusion prevention gets their peanut butter stuck in AV&#8217;s chocolate.  &#8216;Heuristics&#8217; or similar technology in AV is key to the future of the product.  </p>
<p>Regarding our security infrastructure being over-engineered, I haven&#8217;t heard that one before!  I might understand your thinking the home-brewed IDS backing up the retail IPS might be overkill but it isn&#8217;t simply because they perform similar duties in different ways:</p>
<p>1.  The retail IPS is a best-in-class solution that does deep-packet inspection and protocol analysis and has the ability to act on packets.</p>
<p>2.  The home-brewed IDS monitors for deny statements based on firewall rules (configured as you said, default deny) and alerts on 3 pre-defined thresholds of X, Y and Z events. </p>
<p>The home-brewed IDS is much faster than the IPS because it is doing much less.  </p>
<p>Not to mention the fact that the IPS doesn&#8217;t block a worm&#8217;s scan, only the payload delivery.  Therefore with the IDS, we get a warning at the scanning phase of the worm (as long as the scans are blocked by the firewall).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cd-MaN</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-2046</link>
		<dc:creator>Cd-MaN</dc:creator>
		<pubDate>Thu, 03 May 2007 07:12:09 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-2046</guid>
		<description>Hello.

First a suggestion: &lt;a href=&quot;http://hype-free.blogspot.com/2007/03/how-to-submit-suspected-malware-samples.html&quot; rel=&quot;nofollow&quot;&gt;there are two other sites out there (that I know of) similar to Virustotal&lt;/a&gt; (although VirusTotal is the coolest and most actively developed one). You can use them if VirusTotal has an outage.

Second of all, in my opinion you seem to fall in the trap of the marketing people of the security vendors when you blame AV&#039;s for not caching the given bot. AV technology is a reactive one by its nature and the whole &quot;you can be safe just by installing our product&quot; is propagated by the marketing department with no real technological foundation (as you just found out). Congratulation to you for having such detailed detection mechanisms which made possible to (a) find out that there is a problem and (b) get detailed data about it, but isn&#039;t it a little overengineered? By creating a default deny policy for everything not sanctioned by the IT department these things can be easily avoided. While I realize that creating a whitelist might sound complicated and in some cases very difficult (how do you tell the CEO that s/he cant install games on her/his laptop?), ultimately it is the safest approach and will prevent 99% of the malware out there.</description>
		<content:encoded><![CDATA[<p>Hello.</p>
<p>First a suggestion: <a href="http://hype-free.blogspot.com/2007/03/how-to-submit-suspected-malware-samples.html" rel="nofollow">there are two other sites out there (that I know of) similar to Virustotal</a> (although VirusTotal is the coolest and most actively developed one). You can use them if VirusTotal has an outage.</p>
<p>Second of all, in my opinion you seem to fall in the trap of the marketing people of the security vendors when you blame AV&#8217;s for not caching the given bot. AV technology is a reactive one by its nature and the whole &#8220;you can be safe just by installing our product&#8221; is propagated by the marketing department with no real technological foundation (as you just found out). Congratulation to you for having such detailed detection mechanisms which made possible to (a) find out that there is a problem and (b) get detailed data about it, but isn&#8217;t it a little overengineered? By creating a default deny policy for everything not sanctioned by the IT department these things can be easily avoided. While I realize that creating a whitelist might sound complicated and in some cases very difficult (how do you tell the CEO that s/he cant install games on her/his laptop?), ultimately it is the safest approach and will prevent 99% of the malware out there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: www.andrewhay.ca &#187; Suggested Blog Reading - Wednesday May 2nd, 2007</title>
		<link>http://mcwresearch.com/archives/469/comment-page-1#comment-2025</link>
		<dc:creator>www.andrewhay.ca &#187; Suggested Blog Reading - Wednesday May 2nd, 2007</dc:creator>
		<pubDate>Wed, 02 May 2007 12:01:32 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/469#comment-2025</guid>
		<description>[...] Evaluating malware from a network perspective - Good find, process, and reporting. Today while looking through my HIPS log like a good sec analyst, I see an interesting event logged on one of the hosts. The file c:windowssystem32wbemunsecapp32.exe (MD5: 60f8ea044b96b7ae8c1a55571d7e2c70) tried to contact 211.22.66.246 on port 7654. Google searching for the file name produced little help beyond this (the fact that AhnLabâ€™s AV engine didnâ€™t detect this one leads me to believe itâ€™s a relatively new variant) [...]</description>
		<content:encoded><![CDATA[<p>[...] Evaluating malware from a network perspective &#8211; Good find, process, and reporting. Today while looking through my HIPS log like a good sec analyst, I see an interesting event logged on one of the hosts. The file c:windowssystem32wbemunsecapp32.exe (MD5: 60f8ea044b96b7ae8c1a55571d7e2c70) tried to contact 211.22.66.246 on port 7654. Google searching for the file name produced little help beyond this (the fact that AhnLabâ€™s AV engine didnâ€™t detect this one leads me to believe itâ€™s a relatively new variant) [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

