subject:"RE\: Intel developing security 'game\-changer'"

Re: Intel developing security 'game-changer'

2011-02-07 Thread Kurt Buff

NIST has downloadable ISOs of hashes for whitelists:

http://www.nsrl.nist.gov/

That ought to help a great deal...

On Mon, Feb 7, 2011 at 18:01, Marc Maiffret mmaiff...@eeye.com wrote:
 Apologies in advanced for the stream of conscious flow of this email as I am
 pressed for time.



 The way systems are being compromised right now really comes from one of two
 main ways:



 1.   The “fake av” problem – This is along the lines of what you
 described below. A user is convinced to run code in a way that is completely
 legitimate. I.E. The user runs an executable from their web browser without
 the attacker leveraging a software based vulnerability. This is a common
 problem especially as it relates to the various fake anti-virus software out
 there. In this case whitelisting would help as the only thing going on here,
 typically, is a malicious executable being launched via a web browser.

 2.   Software vulnerabilities – This is different and a much bigger
 problem than the first. In this case, which I believe to be more common,
 users do not have to do anything but simply view a website and once viewing
 a website there is attack code which will leverage an unpatched/unknown
 vulnerability within some software on that machine
 (IE,FireFox,Reader,Java,Flash,Quicktime,etc…). A lot of these attacks are
 being delivered through completely legitimate websites through malicious
 advertisements or hackers using SEO methods to have their malicious website
 show up in “legitimate” Google search results.



 We see the second case happening even more often because it is so simple and
 reliable. In the second case since your leveraging a vulnerability in a
 known good application it means your now executing code (in the case of a
 buffer overflow) within that known good applications process space which
 means your part of the good white list and can do what you please. So unlike
 today where typically you would start executing code within Adobe Reader
 just enough to download somemalware.exe and execute it. You would have an
 intermediary step to either a) Have your malicious code that executes within
 Adobe Reader kill what process control security software is running (i.e.
 kill bit9) and then execute your malware just as normal b) Make yourself
 persistent on the system in one of a number of ways that do not actually
 require an executable. Think Operation Aurora and it using a services.dll
 style to backdoor the system which means your now just a .dll running within
 svchost.exe which is a process that has to be white listed. Or you’re a .dll
 running within rundll32.exe which is also white listed. Now the good guys
 become required to also white list control all .dll’s and if you thought
 trying to manage what processes you should or should not be running was hard
 with just executables it becomes a nightmare, i.e. an IT time sink, to do it
 for every .dll. And then of course the .dll example I gave is just the
 simple bypass, there are more sophisticated things that again raise the bar
 to make whitelisting worthless pretty fast.



 So is whitelisting not worth it at all? I.E. Should you not look into a
 whitelisting solution or an endpoint security solution that has whitelisting
 as a component? No, I would not go that far, I think some level of process
 control can be helpful but as a feature of a good endpoint solution rather
 than an entire solution itself. For example in the endpoint security product
 I help create we use process execution control but rather than trying to
 figure out all that you should and should not be white listing we are
 controlling known good behavior around the more commonly attacked
 applications (web browser, office, adobe, etc…) Then we fill in the white
 listing gaps by doing in process memory monitoring to more generically
 prevent exploits that are actually leveraging the more common classes of
 application vulnerabilities such as buffer overflow attacks etc so that when
 an attacker goes to initially execute malicious code within Adobe we deny
 that from happening in the first place which means we don’t have to worry
 about the after fact of trying to control processes and other things that
 become a losing battle.



 I forget if it is this week’s VEF or the next one that one of my researchers
 is covering some data we dug up on most common locations for malware to
 reside on a system etc… http://www.eeye.com/VEF



 -Marc



 From: Crawford, Scott [mailto:crawfo...@evangel.edu]
 Sent: Monday, February 07, 2011 1:54 PM
 To: NT System Admin Issues
 Subject: RE: Intel developing security 'game-changer'



 Well stated.

 Do you have any opinion on the volume of malware we’d see in a strictly
 white-list environment as opposed to a strictly black-list environment?
 Right now, the “vulnerability” is predominately the user who can be
 convinced to run code to see the dancing pigs. It seems that white-listing
 effectively plugs that hole, but then we’d move

RE: Intel developing security 'game-changer'

2011-02-02 Thread Crawford, Scott

I don't think you understand what I'm saying because I mostly agree with 
everything you've said here as well as most of Andrew's points. I also agree 
with Marcus's dumb ideas.



I'm not saying that whitelisting is bad or pointless. I'm not saying that 
blacklisting is better. Nor am I saying that whitelisting is ineffective.



My main and original point has always been that whitelisting is a piece of the 
solution, but not a panacea against malware and will not stop all malware from 
being executed. This was in direct response to Michael B. Smith's statement - 
I’m still of the opinion that the only real solution is white-listing.



The link you sent, (which I largely agree with and have read a few times over 
the years) seems to assume the same thing:



In fact, if I were to simply track the 30 pieces of Goodness on my machine, and 
allow nothing else to run, I would have simultaneously solved the following 
problems:

Spyware

Viruses

Remote Control Trojans

Exploits that involve executing pre-installed code that you don't use regularly



and



The cure for Enumerating Badness is, of course, Enumerating Goodness.



When you say things like SOLVED the following problems and the CURE and 
real SOLUTION, it implies eradication and a panacea.



Again, maybe I'm misunderstanding them, but it seems to be a common 
misperception that whitelisting will block all malware because now you only 
specify what you want to run and since nobody wants to execute malware, it will 
be stopped. This simply isn't true UNLESS you also whitelist all data files as 
well.



If we flipped a magic switch and changed to a predominately whilte-list 
environment, would malware be less prevalent? I don't know. Probably less 
overall, but there would still be a significant amount. It would just have 
morphed into exploiting a different vector - namely flaws in the whitelisted 
.exe that allow code hidden in data files to execute.



Ideally, we'd have BOTH white and black lists. Whitelists for executables and 
blacklists for data files. The presupposition is that there are more bad files 
than good, therefore we need whitelists. This is true. BUT, there are more good 
DATA files than bad, so in that case, we need blacklists.



In the current environment? Absolutely, white-list is more effective than 
black-list. But, let's be careful with our assumptions so that we don't get 
caught with a false sense of security. You seem to dismiss the .WMF and .JPG 
vulnerabilities based on how the malware executed in today's environment. 
Absolutely, whitelisting would have made it ineffective.



You said, What I mean by isn't such a big deal is that (almost always) the 
reason for an elevated prompt is to run a malicious app. If your system won't 
run any but whitelisted apps, you've mitigated the impact of the 0-day, even if 
you haven't completely negated it.

Ahh, but this is the point you're missing - Whitelisting is ignoring .jpg files 
because they're not supposed to be executable. If my malware IS a jpg and that 
jpg is executed by a whitelisted .exe WITH a 0-day, whitelisting does nothing 
to help.



So, to sum up

1. Whitelist is a definite improvement.

2. Malware will still exist in a whitelist environment.

3a. Blacklists will still be needed.

3b. OR all data files will need to be whitelisted as well.



Really, those are my only 3 points. Everything else simply serves to illustrate 
these.




From: Kurt Buff [kurt.b...@gmail.com]
Sent: Monday, January 31, 2011 6:37 PM
To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

I'm going to agree very strongly with Andrew here.

To bolster the case, I'll point you to some words of wisdom from the man who 
write the first firewall implemented at the White House:
http://www.ranum.com/security/computer_security/editorials/dumb/

Dumb ideas one and two, specifically...

While what you say is true, Andrew (and I, of course) also understand that 
risk, and that risk is not something covered by blacklists, at least initially. 
It takes time to get the signatures out for a blacklist, just as it takes time 
to get patches out for your AV/IDS/IPS/HIDS/Whatever. What's worse is that the 
signature writers simply can't keep up.

However, the universe of 0-days for whitelisted apps is far smaller than the 
universe of stupid/malicious apps.

And, in most cases, just because a 0-day hits you, it doesn't mean that your 
machine is compromised. Why? Because all that usually gets you is an elevated 
command prompt - and that in and of itself isn't such a big deal.

 Wait for it..


What I mean by isn't such a big deal is that (almost always) the reason for 
an elevated prompt is to run a malicious app. If your system won't run any but 
whitelisted apps, you've mitigated the impact of the 0-day, even if you haven't 
completely negated it.

It's rare that a machine gets hit by a 0-day with a live human being on the 
other end

Re: Intel developing security 'game-changer'

2011-02-01 Thread Andrew S. Baker

Scott,

Your response points out things that I already pointed out in my response.
Yes, there are specific scenarios where whitelisting does not prevent an
attack. Even then, it still affords additional opportunities to mitigate
exploitation of the vulnerability. Additionally, there are many other
scenarios where whitelisting addresses a weakness of blacklisting.

So you still come out ahead.Please note my comments about vendor
facilitation of granular feature control to mitigate the types of problems
that you are focusing on.

Now, let's look at how the vulnerabilities you mention are actually
exploited.

- http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability
- http://isc.sans.edu/diary.html?storyid=992
- http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx

By getting someone to open up a specially crafted data file (via web, email,
file share, etc), you can cause the primary application to spawn your
executable (which is hidden in the data file) -- typically with all the
rights of the spawning app.

Now, depending on how such an application is initiated, it may not spawn as
a child process, but as its own process. If it spawns as a child process,
then whitelisting may or may not help. But, as its own process, it would
fail to be initiated -- even in a zero day scenario for which no signatures
exist.

Even if this is only in 50% of the zero-day situations, you're still
protected to a much greater degree than via signatures alone.

*Antimalware signatures are generally produced much more rapidly than an
application patch. So, while a zero day flaw may take a week (optimistic) to
patch, the AV vendors could be blocking all .txt files containing the
offending string of bits.*

Which doesn't take into account all the effort that malware writers put into
their work to ensure that offending string of bits is obfuscated.

Even if it takes the signature writers a mere 24 hours to:

- figure out all the combinations of bad bits
- test and validate the fix
- make the fix available to their distribution mechanisms
- get your systems to pick them up

That's still a long time for a zero-day infection to do its work. And,
having worked with a number of AV vendors on zero-day scenarios, 2-3 days is
not unreasonable for reverse engineering a good exploit.

Where does that leave your systems which are only relying on a list of bad
things to block?

*Agreed…for the time being. But, if we were to flip a magic switch and
swap to a predominantly white-list based environment, the most common
exploitation vectors would switch to exploiting white-listed .exes through
buffer overflows or other methods of tricking an .exe to doing more than
displaying data in a data file.*

I'm not sure where you have gotten this idea that buffer overflow and
executable data exploits involve making the parent application do new
tricks. All they do is get the parent application to run new code of the
attackers choice, and in many cases, that code is subject to running in its
own environment -- thus, blockable in a whitelisting scenario.

I've experienced several examples of this during my testing of what later
became Cisco's CSA product, and eEye's Blink!

Here's a good article to read:
http://www.intelligentwhitelisting.com/blog/problem-vulnerable-whitelisted-application-part-ii

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

*
*

On Mon, Jan 31, 2011 at 7:12 PM, Crawford, Scott crawfo...@evangel.eduwrote:

Inline, but here’s some opening comments J

White-listing .exes does nothing to stop attacks like .wmf and .jpg
vulnerabilities below.

http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid=21526

http://www.symantec.com/security_response/writeup.jsp?docid=2004-091516-5119-99tabid=2

While these may be currently patched and/or low risk, I think they server
to illustrate my point. Note that AV signatures detect the badness in them
before Microsoft patched the offending executable. Also note that under all
but the most restrictive white-listing campaign, the code that processes
.wmf and .jpg would be allowed.

Again, please don’t misunderstand me. I’m not saying white-listing is
without its advantages. I’m simply saying that it’s not a solution to stop
malware. Impair it? Yes. Stop some of it? Yes. But, the primary reason it
stops some and even most current malware is because it’s not very popular
yet.

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Monday, January 31, 2011 2:47 PM

*To:* NT System Admin Issues
*Subject:* Re: Intel developing security 'game-changer'

*There are MORE good files that I want to use than bad that I want to
block. *

Except that most of those good files won't get executed if you stop a more
limited number of other executables from launching.

My concern is infected data files that are associated

RE: Intel developing security 'game-changer'

2011-01-31 Thread Crawford, Scott

No one here has suggested panacea

Perhaps not, but that's not my perception. I see lots of statements like I'm 
still of the opinion that the only real solution is white-listing. - MBS  
Maybe I'm misreading that, but that hints at a panacea and I'm simply saying 
that it's not.

All of your other points - I agree.

From: Andrew S. Baker [mailto:asbz...@gmail.com]
Sent: Wednesday, January 26, 2011 4:35 PM
To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

No one here has suggested panacea, but consider how effective it would be in a 
white-listing environment to add most apps to the list in the event of a 
zero-day to an EXISTING app.  You wouldn't have to do anything for an app that 
wasn't already allowed in your environment.

It is akin to the change in firewall rule-set made in ages gone by from 
Allowed-by-Default to Denied-by-Default.

Likewise, look at all the environments that have moved towards some form of 
locked down user desktop and see how much of a benefit has resulted.

Reducing problems by 50-80% off the bat, with little overhead, is always 
desirable.



ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...




On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
My point is that neither signatures, nor white-listing are a panacea. The fact 
that we've been sig based for so long while malware continues to be effective 
leads many to think that white-listing would solve all our woes. I'm simply 
saying that many *current* vulnerabilities circumvent a white-list so it can't 
be a panacea...unless of course you white-list each individual data file.

From: Andrew S. Baker [mailto:asbz...@gmail.commailto:asbz...@gmail.com]
Sent: Wednesday, January 26, 2011 1:55 PM

To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

Just as network anomaly detection devices don't eliminate the use of 
signatures, whitelisting solutions can still make use of several mechanisms for 
avoiding bad stuff.

It is the complete RELIANCE on signatures that is troublesome.

Oh, and btw, I try to avoid Adobe Acrobat altogether.  There are plenty of 
viable alternatives at the moment...



ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...



On Wed, Jan 26, 2011 at 2:51 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
Unless you're going to white-list every doc/jpg/pdf/mp3 you're going to open, 
that's not a panacea either.  Documents = 1's and 0's = code. The only 
difference is what layer its executed at.  Assume you white-list 
AdobeReader.exe. The next time a flaw is found that is exploited through a 
malformed PDF, it will march right through your white-list.

From: Michael B. Smith 
[mailto:mich...@smithcons.commailto:mich...@smithcons.com]
Sent: Wednesday, January 26, 2011 1:38 PM

To: NT System Admin Issues
Subject: RE: Intel developing security 'game-changer'

I'm still of the opinion that the only real solution is white-listing.

But that raises its own set of issues.

Regards,

Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com

From: Andrew S. Baker [mailto:asbz...@gmail.commailto:asbz...@gmail.com]
Sent: Wednesday, January 26, 2011 2:35 PM
To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

Since a whole lot of allegedly legitimate software acts just like malware, 
they'd have their work cut out for them.

Try installing a host-based IPS on your system in monitoring mode, and look at 
what it would block -- and why.

There are certain classes of zero-day that can be blocked by software or 
hardware.  There are others that cannot be, simply because of what passes for 
functionality these days.

Oh, and I agree with Ben and Jonathan...



ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...



On Wed, Jan 26, 2011 at 1:47 PM, Sean Martin 
seanmarti...@gmail.commailto:seanmarti...@gmail.com wrote:
Most important statement

If Intel has hardware technology that can reliably stop zero-day attacks, that 
would be a huge win in the war against malware, Olds said. The key is that 
it's reliable. It has to have the ability to discern legit software from 
malware. But if they can pull this off, it would give them quite a competitive 
advantage vs. 
AMDhttp://www.computerworld.com/s/article/9204580/AMD_could_better_fight_Intel_with_new_CEO_.

- Sean

On Wed, Jan 26, 2011 at 9:37 AM, David Lum 
david@nwea.orgmailto:david@nwea.org wrote:
What say you, Alex, et all.

http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85

Hype?
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 503.548.5229 // (Cell) 503.267.9764



~ Finally, powerful endpoint security that ISN'T a resource hog

Re: Intel developing security 'game-changer'

2011-01-31 Thread Andrew S. Baker

Here are my full thoughts on the subject, as a security mechanism:

http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspx

http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspxNo,
it is not a panacea, because no security mechanism ever is. Yes, there are
drawbacks, but focusing on these technologies will provide a bigger bang for
the buck and allow us to mitigate the weaknesses sooner. Either way, your
ROI is greater in most scenarios which use whitelisting vs blacklisting.

Also, check out the following:
http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html

*ASB *(Find me online via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

*
*

On Mon, Jan 31, 2011 at 12:48 PM, Crawford, Scott crawfo...@evangel.eduwrote:

“No one here has suggested panacea”

Perhaps not, but that’s not my perception. I see lots of statements like
“I’m still of the opinion that the only real solution is white-listing. -
MBS” Maybe I’m misreading that, but that hints at a panacea and I’m simply
saying that it’s not.

All of your other points – I agree.

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Wednesday, January 26, 2011 4:35 PM

*To:* NT System Admin Issues
*Subject:* Re: Intel developing security 'game-changer'

No one here has suggested panacea, but consider how effective it would be
in a white-listing environment to add most apps to the list in the event of
a zero-day to an EXISTING app. You wouldn't have to do anything for an app
that wasn't already allowed in your environment.

It is akin to the change in firewall rule-set made in ages gone by from
Allowed-by-Default to Denied-by-Default.

Likewise, look at all the environments that have moved towards some form of
locked down user desktop and see how much of a benefit has resulted.

Reducing problems by 50-80% off the bat, with little overhead, is always
desirable.

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott crawfo...@evangel.edu
wrote:

My point is that neither signatures, nor white-listing are a panacea. The
fact that we’ve been sig based for so long while malware continues to be
effective leads many to think that white-listing would solve all our woes.
I’m simply saying that many **current** vulnerabilities circumvent a
white-list so it can’t be a panacea…unless of course you white-list each
individual data file.

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Wednesday, January 26, 2011 1:55 PM

*To:* NT System Admin Issues

*Subject:* Re: Intel developing security 'game-changer'

Just as network anomaly detection devices don't eliminate the use of
signatures, whitelisting solutions can still make use of several mechanisms
for avoiding bad stuff.

It is the complete RELIANCE on signatures that is troublesome.

Oh, and btw, I try to avoid Adobe Acrobat altogether. There are plenty of
viable alternatives at the moment...

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)

*Exploiting Technology for Business Advantage...*

On Wed, Jan 26, 2011 at 2:51 PM, Crawford, Scott crawfo...@evangel.edu
wrote:

Unless you’re going to white-list every doc/jpg/pdf/mp3 you’re going to
open, that’s not a panacea either. Documents = 1’s and 0’s = code. The only
difference is what layer its executed at. Assume you white-list
AdobeReader.exe. The next time a flaw is found that is exploited through a
malformed PDF, it will march right through your white-list.

*From:* Michael B. Smith [mailto:mich...@smithcons.com]
*Sent:* Wednesday, January 26, 2011 1:38 PM

*To:* NT System Admin Issues

*Subject:* RE: Intel developing security 'game-changer'

I’m still of the opinion that the only real solution is white-listing.

But that raises its own set of issues.

Regards,

Michael B. Smith

Consultant and Exchange MVP

http://TheEssentialExchange.com

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]

*Sent:* Wednesday, January 26, 2011 2:35 PM

*To:* NT System Admin Issues

*Subject:* Re: Intel developing security 'game-changer'

Since a whole lot of allegedly legitimate software acts just like malware,
they'd have their work cut out for them.

Try installing a host-based IPS on your system in monitoring mode, and look
at what it would block -- and why.

There are certain classes of zero-day that can be blocked by software or
hardware. There are others that cannot be, simply because of what passes
for functionality these days.

Oh, and I agree with Ben and Jonathan...

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

On Wed, Jan 26, 2011 at 1:47 PM, Sean Martin seanmarti...@gmail.com

RE: Intel developing security 'game-changer'

2011-01-31 Thread Crawford, Scott

Application whitelisting is a good idea, because for every environment, there 
are less items that fall into the known good category than bad code that you 
don't want to run.

This assumption simply isn't true. Data = 1's and 0's = code. There are MORE 
good files that I want to use than bad that I want to block. If there was some 
magic bullet that ensured data files could never contain executable bits, 
then I would agree whole heartedly. But, I don't believe such bullet will ever 
exist. Therefore data = 1's and 0's = code and its up to the whitelisted .exe 
to interpret them correctly. If there's a chance that said application will 
make a mistake, then we also need something signature based to block the bad 
bits.

From: Andrew S. Baker [mailto:asbz...@gmail.com]
Sent: Monday, January 31, 2011 12:25 PM
To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

Here are my full thoughts on the subject, as a security mechanism:

http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspx

No, it is not a panacea, because no security mechanism ever is.  Yes, there are 
drawbacks, but focusing on these technologies will provide a bigger bang for 
the buck and allow us to mitigate the weaknesses sooner.  Either way, your ROI 
is greater in most scenarios which use whitelisting vs blacklisting.

Also, check out the following:  
http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html




ASB (Find me online via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...




On Mon, Jan 31, 2011 at 12:48 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
No one here has suggested panacea

Perhaps not, but that's not my perception. I see lots of statements like I'm 
still of the opinion that the only real solution is white-listing. - MBS  
Maybe I'm misreading that, but that hints at a panacea and I'm simply saying 
that it's not.

All of your other points - I agree.

From: Andrew S. Baker [mailto:asbz...@gmail.commailto:asbz...@gmail.com]
Sent: Wednesday, January 26, 2011 4:35 PM

To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

No one here has suggested panacea, but consider how effective it would be in a 
white-listing environment to add most apps to the list in the event of a 
zero-day to an EXISTING app.  You wouldn't have to do anything for an app that 
wasn't already allowed in your environment.

It is akin to the change in firewall rule-set made in ages gone by from 
Allowed-by-Default to Denied-by-Default.

Likewise, look at all the environments that have moved towards some form of 
locked down user desktop and see how much of a benefit has resulted.

Reducing problems by 50-80% off the bat, with little overhead, is always 
desirable.



ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...



On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
My point is that neither signatures, nor white-listing are a panacea. The fact 
that we've been sig based for so long while malware continues to be effective 
leads many to think that white-listing would solve all our woes. I'm simply 
saying that many *current* vulnerabilities circumvent a white-list so it can't 
be a panacea...unless of course you white-list each individual data file.

From: Andrew S. Baker [mailto:asbz...@gmail.commailto:asbz...@gmail.com]
Sent: Wednesday, January 26, 2011 1:55 PM

To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

Just as network anomaly detection devices don't eliminate the use of 
signatures, whitelisting solutions can still make use of several mechanisms for 
avoiding bad stuff.

It is the complete RELIANCE on signatures that is troublesome.

Oh, and btw, I try to avoid Adobe Acrobat altogether.  There are plenty of 
viable alternatives at the moment...



ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...



On Wed, Jan 26, 2011 at 2:51 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
Unless you're going to white-list every doc/jpg/pdf/mp3 you're going to open, 
that's not a panacea either.  Documents = 1's and 0's = code. The only 
difference is what layer its executed at.  Assume you white-list 
AdobeReader.exe. The next time a flaw is found that is exploited through a 
malformed PDF, it will march right through your white-list.

From: Michael B. Smith 
[mailto:mich...@smithcons.commailto:mich...@smithcons.com]
Sent: Wednesday, January 26, 2011 1:38 PM

To: NT System Admin Issues
Subject: RE: Intel developing security 'game-changer'

I'm still of the opinion that the only real solution is white-listing.

But that raises its own set of issues.

Regards,

Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com

From

Re: Intel developing security 'game-changer'

2011-01-31 Thread Andrew S. Baker

*There are MORE good files that I want to use than bad that I want to
block. *

Except that most of those good files won't get executed if you stop a more
limited number of other executables from launching.

You don't necessarily have to track every version of every known DLL that
might ever get executed, if you can simply track the far more limited number
of executables that would spawn them.

It would appear that you're looking at whitelisting in a very different way
than is typically implemented. What is your understanding of how a
whitelisting solution would need to work?

*If there’s a chance that said application will make a mistake, then we
also need something signature based to block the bad bits.*

Except that the scenario you're presenting is exactly what we call Zero Day
attacks. Vulnerability is discovered in an approved app (no matter how you
chose to identify approved app) and it gets exploited. How is a signature
helping there when the attack is new?

If the vulnerability is one that requires no new executables, then a
zero-day attack is equally damaging to a whitelist or blacklist approach.
If the vulnerability is one that spawns a new executable, then a zero-day
attack is not effective in a whitelist scenario, but just as damaging as
always in a blacklist scenario.

I address the need for vendors to allow features and functionality to be
enabled or disabled independently (in the very next paragraph), which would
provide even more security. In the meantime, blacklisting at the host level
as the primary means of protection is a game of increasing risk with
diminishing returns...

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

*
*

On Mon, Jan 31, 2011 at 2:36 PM, Crawford, Scott crawfo...@evangel.eduwrote:

“Application whitelisting is a good idea, because for every environment,
there are less items that fall into the “*known good*” category than bad
code that you don’t want to run.”

This assumption simply isn’t true. Data = 1’s and 0’s = code. There are
MORE good files that I want to use than bad that I want to block. If there
was some magic bullet that ensured “data” files could never contain
executable bits, then I would agree whole heartedly. But, I don’t believe
such bullet will ever exist. Therefore data = 1’s and 0’s = code and its up
to the whitelisted .exe to interpret them correctly. If there’s a chance
that said application will make a mistake, then we also need something
signature based to block the bad bits.

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Monday, January 31, 2011 12:25 PM

*To:* NT System Admin Issues
*Subject:* Re: Intel developing security 'game-changer'

Here are my full thoughts on the subject, as a security mechanism:

http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspx

No, it is not a panacea, because no security mechanism ever is. Yes, there
are drawbacks, but focusing on these technologies will provide a bigger bang
for the buck and allow us to mitigate the weaknesses sooner. Either way,
your ROI is greater in most scenarios which use whitelisting vs
blacklisting.

Also, check out the following:
http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html

*ASB *(Find me online via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

On Mon, Jan 31, 2011 at 12:48 PM, Crawford, Scott crawfo...@evangel.edu
wrote:

“No one here has suggested panacea”

All of your other points – I agree.

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Wednesday, January 26, 2011 4:35 PM

*To:* NT System Admin Issues
*Subject:* Re: Intel developing security 'game-changer'

It is akin to the change in firewall rule-set made in ages gone by from
Allowed-by-Default to Denied-by-Default.

Likewise, look at all the environments that have moved towards some form of
locked down user desktop and see how much of a benefit has resulted.

Reducing problems by 50-80% off the bat, with little overhead, is always
desirable.

*ASB *(My Bio via About.Me http://about.me/Andrew.S.Baker/bio)
*Exploiting Technology for Business Advantage...*

On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott crawfo...@evangel.edu
wrote:

My point is that neither signatures, nor white-listing are a panacea

RE: Intel developing security 'game-changer'

2011-01-31 Thread Crawford, Scott

Inline, but here's some opening comments :)

White-listing .exes does nothing to stop attacks like .wmf and .jpg 
vulnerabilities below.

http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid=21526
http://www.symantec.com/security_response/writeup.jsp?docid=2004-091516-5119-99tabid=2

While these may be currently patched and/or low risk, I think they server to 
illustrate my point. Note that AV signatures detect the badness in them before 
Microsoft patched the offending executable. Also note that under all but the 
most restrictive white-listing campaign, the code that processes .wmf and .jpg 
would be allowed.

Again, please don't misunderstand me. I'm not saying white-listing is without 
its advantages. I'm simply saying that it's not a solution to stop malware. 
Impair it? Yes. Stop some of it? Yes. But, the primary reason it stops some and 
even most current malware is because it's not very popular yet.

From: Andrew S. Baker [mailto:asbz...@gmail.com]
Sent: Monday, January 31, 2011 2:47 PM
To: NT System Admin Issues
Subject: Re: Intel developing security 'game-changer'

There are MORE good files that I want to use than bad that I want to block.

Except that most of those good files won't get executed if you stop a more 
limited number of other executables from launching.

My concern is infected data files that are associated with a white-listed .exe.

You don't necessarily have to track every version of every known DLL that might 
ever get executed, if you can simply track the far more limited number of 
executables that would spawn them.

Understood

It would appear that you're looking at whitelisting in a very different way 
than is typically implemented.  What is your understanding of how a 
whitelisting solution would need to work?

Yes, I am becoming aware that I'm looking at it very differently :). That is 
basically my point. The way it's typically implemented is to specify an allowed 
list of executables using multiple ways of compiling that list - publisher, 
path, hash, filename, etc. This is basically the only practical way it can 
work. However, to be *truly* stop all malware from executing, it would also 
have to include all documents/data files that a user would want to use.


If there's a chance that said application will make a mistake, then we also 
need something signature based to block the bad bits.

Except that the scenario you're presenting is exactly what we call Zero Day 
attacks.   Vulnerability is discovered in an approved app (no matter how you 
chose to identify approved app) and it gets exploited.  How is a signature 
helping there when the attack is new?

Antimalware signatures are generally produced much more rapidly than an 
application patch. So, while a zero day flaw may take a week (optimistic) to 
patch, the AV vendors could be blocking all .txt files containing the offending 
string of bits.


If the vulnerability is one that requires no new executables, then a zero-day 
attack is equally damaging to a whitelist or blacklist approach.

If the vulnerability is one that spawns a new executable, then a zero-day 
attack is not effective in a whitelist scenario, but just as damaging as always 
in a blacklist scenario.

I address the need for vendors to allow features and functionality to be 
enabled or disabled independently (in the very next paragraph)

Right. The ability to turn off javascript/macros in Word, Reader, IE, etc. is 
certainly a beneficial addition, but it doesn't prevent other forms of malware 
that may be present in a .doc or .pdf, just the malware that exploits the 
built-in execution engine.

, which would provide even more security.  In the meantime, blacklisting at the 
host level as the primary means of protection is a game of increasing risk with 
diminishing returns...


Agreed...for the time being. But, if we were to flip a magic switch and swap to 
a predominantly white-list based environment, the most common exploitation 
vectors would switch to exploiting white-listed .exes through buffer overflows 
or other methods of tricking an .exe to doing more than displaying data in a 
data file.

ASB (My Bio via About.Mehttp://about.me/Andrew.S.Baker/bio)
Exploiting Technology for Business Advantage...




On Mon, Jan 31, 2011 at 2:36 PM, Crawford, Scott 
crawfo...@evangel.edumailto:crawfo...@evangel.edu wrote:
Application whitelisting is a good idea, because for every environment, there 
are less items that fall into the known good category than bad code that you 
don't want to run.

This assumption simply isn't true. Data = 1's and 0's = code. There are MORE 
good files that I want to use than bad that I want to block. If there was some 
magic bullet that ensured data files could never contain executable bits, 
then I would agree whole heartedly. But, I don't believe such bullet will ever 
exist. Therefore data = 1's and 0's = code and its up to the whitelisted .exe 
to interpret them correctly. If there's a chance

Re: Intel developing security 'game-changer'

2011-01-31 Thread Kurt Buff

I'm going to agree very strongly with Andrew here.

To bolster the case, I'll point you to some words of wisdom from the man who
write the first firewall implemented at the White House:
http://www.ranum.com/security/computer_security/editorials/dumb/

Dumb ideas one and two, specifically...

While what you say is true, Andrew (and I, of course) also understand that
risk, and that risk is not something covered by blacklists, at least
initially. It takes time to get the signatures out for a blacklist, just as
it takes time to get patches out for your AV/IDS/IPS/HIDS/Whatever. What's
worse is that the signature writers simply can't keep up.

However, the universe of 0-days for whitelisted apps is far smaller than the
universe of stupid/malicious apps.

And, in most cases, just because a 0-day hits you, it doesn't mean that your
machine is compromised. Why? Because all that usually gets you is an
elevated command prompt - and that in and of itself isn't such a big deal.

*Wait for it..*

What I mean by isn't such a big deal is that (almost always) the reason
for an elevated prompt is to run a malicious app. If your system won't run
any but whitelisted apps, you've mitigated the impact of the 0-day, even if
you haven't completely negated it.

It's rare that a machine gets hit by a 0-day with a live human being on the
other end running native OS tools to exfiltrate data or do other malicious
things. The one relatively recent bit of maliciousness that I can remember
that did anything like that was the Slammer worm, and all that did was
propagate itself.

Is it 100%? Nope, and Andrew (nor anyone else taking this position) never
said that.

Is it easy to set up? Nope, and nobody ever said it was, either.

But, if I had to choose, I'd take whitelisting over blacklisting every
damned day.

Kurt

On Mon, Jan 31, 2011 at 16:12, Crawford, Scott crawfo...@evangel.eduwrote:

Inline, but here’s some opening comments J

White-listing .exes does nothing to stop attacks like .wmf and .jpg
vulnerabilities below.

http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid=21526

http://www.symantec.com/security_response/writeup.jsp?docid=2004-091516-5119-99tabid=2

*From:* Andrew S. Baker [mailto:asbz...@gmail.com]
*Sent:* Monday, January 31, 2011 2:47 PM
*To:* NT System Admin Issues
*Subject:* Re: Intel developing security 'game-changer'

*There are MORE good files that I want to use than bad that I want to
block. *

Except that most of those good files won't get executed if you stop a more
limited number of other executables from launching.

My concern is infected data files that are associated with a white-listed
.exe.

You don't necessarily have to track every version of every known DLL that
might ever get executed, if you can simply track the far more limited number
of executables that would spawn them.

Understood

It would appear that you're looking at whitelisting in a very different way
than is typically implemented. What is your understanding of how a
whitelisting solution would need to work?

Yes, I am becoming aware that I’m looking at it very differently J. That
is basically my point. The way it’s typically implemented is to specify an
allowed list of executables using multiple ways of compiling that list –
publisher, path, hash, filename, etc. This is basically the only practical
way it can work. However, to be **truly* *stop all malware from executing,
it would also have to include all documents/data files that a user would
want to use.

***If there’s a chance that said application will make a mistake, then
we also need something signature based to block the bad bits.*

Antimalware signatures are generally produced much more rapidly than an
application patch. So, while a zero day flaw may take a week (optimistic) to
patch, the AV vendors could be blocking all .txt files containing the
offending string of bits.

If the vulnerability is one that requires no new executables, then a
zero-day attack is equally

RE: Intel developing security 'game-changer'

2011-01-27 Thread Alex Eckelberry

Well, since the vast majority of infections occur because of social 
engineering, I don't think it will mean much at all.

An analogy might be DEP, which did make some difference - that was something at 
the kernel.  But not a huge difference.

I would put this in the same pot.

At the end of the day, your users will still demand downloading their favorite 
crapware, surf porn, and fill out lottery sites online, while giving all of 
these places their credit card numbers.

Alex


From: David Lum [mailto:david@nwea.org]
Sent: Wednesday, January 26, 2011 1:37 PM
To: NT System Admin Issues
Subject: Intel developing security 'game-changer'

What say you, Alex, et all.

http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85

Hype?
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 503.548.5229 // (Cell) 503.267.9764



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: Intel developing security 'game-changer'

2011-01-27 Thread David Lum

You mean I'm not supposed to enter my Visa number at a site that will give me 
winning lottery numbers on an animated stripper card that includes a free 
registry and spyware scan and install AntiVirus 2069?

Who knew?

Dave

From: Alex Eckelberry [mailto:al...@sunbelt-software.com]
Sent: Thursday, January 27, 2011 1:46 PM
To: NT System Admin Issues
Subject: RE: Intel developing security 'game-changer'

Well, since the vast majority of infections occur because of social 
engineering, I don't think it will mean much at all.

An analogy might be DEP, which did make some difference - that was something at 
the kernel.  But not a huge difference.

I would put this in the same pot.

At the end of the day, your users will still demand downloading their favorite 
crapware, surf porn, and fill out lottery sites online, while giving all of 
these places their credit card numbers.

Alex


From: David Lum [mailto:david@nwea.org]
Sent: Wednesday, January 26, 2011 1:37 PM
To: NT System Admin Issues
Subject: Intel developing security 'game-changer'

What say you, Alex, et all.

http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85

Hype?
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 503.548.5229 // (Cell) 503.267.9764



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: Intel developing security 'game-changer'

2011-01-27 Thread Rankin, James R

I had a home user recently showing all the signs of malware. I told him not to 
use his pc till I could look at it. And he went and made a purchase with his 
debit card. Against that sort of idiocy, we admins are doomed to fail.

Typed frustratingly slowly on my BlackBerry® wireless device

-Original Message-
From: David Lum david@nwea.org
Date: Thu, 27 Jan 2011 13:55:37 
To: NT System Admin Issuesntsysadmin@lyris.sunbelt-software.com
Reply-To: NT System Admin Issues 
ntsysadmin@lyris.sunbelt-software.comSubject: RE: Intel developing security 
'game-changer'

You mean I'm not supposed to enter my Visa number at a site that will give me 
winning lottery numbers on an animated stripper card that includes a free 
registry and spyware scan and install AntiVirus 2069?

Who knew?

Dave

From: Alex Eckelberry [mailto:al...@sunbelt-software.com]
Sent: Thursday, January 27, 2011 1:46 PM
To: NT System Admin Issues
Subject: RE: Intel developing security 'game-changer'

Well, since the vast majority of infections occur because of social 
engineering, I don't think it will mean much at all.

An analogy might be DEP, which did make some difference - that was something at 
the kernel.  But not a huge difference.

I would put this in the same pot.

At the end of the day, your users will still demand downloading their favorite 
crapware, surf porn, and fill out lottery sites online, while giving all of 
these places their credit card numbers.

Alex

From: David Lum [mailto:david@nwea.org]
Sent: Wednesday, January 26, 2011 1:37 PM
To: NT System Admin Issues
Subject: Intel developing security 'game-changer'

What say you, Alex, et all.

http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85

Hype?
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 503.548.5229 // (Cell) 503.267.9764

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
listmana...@lyris.sunbeltsoftware.commailto:listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: Intel developing security 'game-changer'

2011-01-27 Thread Steven Peck

We all have our share of special users. Those are interesting stories.
Some of us have our share of educational victories as well. Those that
learn after getting the right information after only one or two bad
experiences.

For instance, I have this thing in my kitchen that makes things hot (my wife
calls it an oven). If I have a recipe that I follow I can get an
approximation of edible food. Sometimes I get lucky and it's really good,
other times it's merely a lesson in what doesn't work. In the cooking world
I am that 'special user'. Fortunately my wife does not mock me for it,
although I am beginning to suspect a correlation between my attempts to bake
and her loud sighs, I may have to chart the occurrences.

For our special users (even our general ones), we must remember that people
learn differently and often we must craft our educational message to fit our
users ability to comprehend. Educating people on social engineering is a
rather time consuming task. Lot's to be learned from the advertising fields
in how to present the same overall message in different formats for user
consumption.

Steven Peck
http://www.blkmtn.org

On Thu, Jan 27, 2011 at 2:00 PM, Rankin, James R kz2...@googlemail.comwrote:

Typed frustratingly slowly on my BlackBerry® wireless device
--
*From: * David Lum david@nwea.org
*Date: *Thu, 27 Jan 2011 13:55:37 -0800
*To: *NT System Admin Issuesntsysadmin@lyris.sunbelt-software.com
*ReplyTo: * NT System Admin Issues
ntsysadmin@lyris.sunbelt-software.com
*Subject: *RE: Intel developing security 'game-changer'

You mean I’m not supposed to enter my Visa number at a site that will give
me winning lottery numbers on an animated stripper card that includes a free
registry and spyware scan and install AntiVirus 2069?

Who knew?

Dave

*From:* Alex Eckelberry [mailto:al...@sunbelt-software.com]
*Sent:* Thursday, January 27, 2011 1:46 PM
*To:* NT System Admin Issues
*Subject:* RE: Intel developing security 'game-changer'

Well, since the vast majority of infections occur because of social
engineering, I don’t think it will mean much at all.

An analogy might be DEP, which did make some difference – that was
something at the kernel. But not a huge difference.

I would put this in the same pot.

At the end of the day, your users will still demand downloading their
favorite crapware, surf porn, and fill out lottery sites online, while
giving all of these places their credit card numbers.

Alex

*From:* David Lum [mailto:david@nwea.org]
*Sent:* Wednesday, January 26, 2011 1:37 PM
*To:* NT System Admin Issues
*Subject:* Intel developing security 'game-changer'

What say you, Alex, et all.

http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85

Hype?

*David Lum** **// *SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 503.548.5229 *// *(Cell) 503.267.9764

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin