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 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.edu<mailto:crawfo...@evangel.edu>> wrote: 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-99&tabid=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<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.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.edu<mailto: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 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<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<mailto: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.com<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<mailto: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<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<mailto: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<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<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<mailto: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. AMD<http://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.org<mailto: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! ~ ~ <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<mailto: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<mailto: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<mailto: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