*>>Surely that’s entirely dependent on the application that is hosting the script to support such functionality?*
I thought we were talking about the *principle *of whitelisting vs blacklisting, not necessarily specific implementations... If an application or OS does not support it, it cannot be implemented. But, to the extent that it becomes enough of a burden, alternatives will be pursued, whether that means new apps or a whole new OS. Microsoft Office suffered from a tremendous number of macro virus issues. These have largely diminished -- and not due to blacklisting. Adobe Acrobat and Flash are key vectors today. Either Adobe will make it easier to control these types of issues, then people will find alternatives to their products. They've already begun to take some step, but much of the damage has been done. *>>I get your point that you can close off loopholes. But I fear that it’s just another “whack a mole” exercise. Threats will still be there, but we now have the relatively large overhead of whitelisting.* ** ** Such is the nature of information security. We chase on many levels, and we try to get ahead on some levels. Threats do remain, but with better education, tools and practices, we are better able to manage our risks. Whitelisting is ultimately a better approach for most issues than is blacklisting, even though blacklisting has provided significant benefits over time, because at some point there is too much overhead to track all of the bad, and it is easier to track all of the good. *>>Tools like IPSec (for whitelisting network traffic) have existed for years. Yet hardly anyone is using it. It’s just too hard to implement and maintain. I see the same with applications (except in the smallest of environments)* ** The pain of blacklisting is not felt by all -- but it is growing. Yes, some of the tools are hard to use or limited in scope. Like everything else, the tipping point has to be crossed for most people to want to embrace a different approach, and then when more vendors and administrators are using that approach, the tools get simpler, more robust, and more affordable. Regardless of the level of difficulty inherent in many of the implementations *today*, the concept of whitelisting is better than the concept of blacklisting once the number of items that one has to blacklist becomes massive and/or the items on the list need to change frequently. That's all this discussion is about. We came to that conclusion years ago with firewall rules, and it has been to our collective benefit. We're going to continue to see more problems managing today's blacklists, and greater effort put into not having to do that. Yes, the bad guys will move on to something else, because that's what they do, but we will better be able to manage that entire class of threat. Regards, *ASB* http://about.me/Andrew.S.Baker* * *Solutions Architect -- InfoSec & Infrastructure* On Wed, Apr 18, 2012 at 1:28 AM, Ken Schaefer <[email protected]> wrote: > Surely that’s entirely dependent on the application that is hosting the > script to support such functionality?**** > > ** ** > > If I develop an arbitrary application: KensSuperCADProgram, and I provide > a basic IDE that allows users to develop custom extensions/actions, then > your whitelisting application isn’t going to know anything about it (unless > it’s been specifically coded to examine KensSuperCADProgram extensions).** > ** > > ** ** > > I get your point that you can close off loopholes. But I fear that it’s > just another “whack a mole” exercise. Threats will still be there, but we > now have the relatively large overhead of whitelisting.**** > > ** ** > > Tools like IPSec (for whitelisting network traffic) have existed for > years. Yet hardly anyone is using it. It’s just too hard to implement and > maintain. I see the same with applications (except in the smallest of > environments)**** > > ** ** > > Cheers**** > > Ken**** > > ** ** > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Tuesday, 17 April 2012 7:10 PM > > *To:* NT System Admin Issues > *Subject:* Re: Whitelisting**** > > ** ** > > Yes, it can address that scenario.**** > > ** ** > > You can sign the scripts you want to run, and disallow unsigned scripts.** > ** > > ** ** > > Does whitelisting solve world hunger, cure cancer or find livable space on > Mars? No. But it does address, more effectively, a huge range of threats > that are inadequately addressed by the traditional blacklisting approach of > current AV products. It's even used within Windows directly to make the OS > more secure. As a result, I will continue to use and recommend it to > reduce my threat landscape, leaving more time to intelligently address the > threats that it does not handle well. > **** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Tue, Apr 17, 2012 at 12:46 AM, Ken Schaefer <[email protected]> > wrote:**** > > Let’s try another one: I use an exploit (or even just VBA automation) in > Word to password protect all your files. You need to pay me to get them > back (or maybe I don’t care whether you get them back, I just like > inflicting pain – aka like most mass market viruses)**** > > **** > > Does whitelisting address this scenario? No. **** > > Are exploits just going to move from the problem space solved by > whitelisting and to a new area that is not addressed by this technology? Yes > **** > > **** > > It’s just like spam (and every other area where we have a constantly > escalated war of technology). Yet for some reason we don’t seem to be > learning that lesson.**** > > **** > > Cheers**** > > Ken**** > > **** > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Tuesday, 17 April 2012 11:07 AM**** > > > *To:* NT System Admin Issues > *Subject:* Re: Whitelisting**** > > **** > > For any given environment, there will be less known good items that I want > to run, than known bad ones that I don't, not to mention all the unknown > bad ones that I don't know about yet.**** > > **** > > Managing the smaller list is *better*, not *perfect*.**** > > **** > > I haven't missed the point. A flawed example is just that -- flawed. > But, going beyond that and focusing on the principle itself, the blacklist > is ALSO vulnerable to the same issue.**** > > **** > > So, do you settle for the us both sharing your example problem, plus you > having a host of other ones that are greater than mine? Or do you > acknowledge that the approach I favor creates a smaller attack surface area? > **** > > **** > > **** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > ** ** > > On Mon, Apr 16, 2012 at 3:33 PM, Ben Scott <[email protected]> wrote:** > ** > > On Mon, Apr 16, 2012 at 12:11 PM, Andrew S. Baker <[email protected]> > wrote: > >>> If it's an exploit, it's going to launch code. The code > >>> won't run in a whitelisting environment unless it's approved by the > admin. > >> > >> CMD /C DEL C:\*.* /S /Q /F /A > >**** > > > A - Wouldn't work so nicely in 2008 and above, due to lack of elevated > > rights > > > > B - Limited use infection (since it destroys itself)**** > > You're missing the point. You're arguing against the example, > rather than the principle. Namely: It's possible to use a whitelisted > application as an attack vector.[1] > > You're also making another mistake -- you're seeing protection of > the system as an end, rather than a means. Nobody cares if the OS is > intact if all the data is gone. We protect the OS because we use the > OS to protect the assets, not just for the sake of having a protected > OS. > > -- Ben > > [1] To the original question: This doesn't mean blacklisting, i.e., > trying to identify and exclude "known bad" software, is the better > alternative.**** > > > ** > ~ 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 [email protected] with the body: unsubscribe ntsysadmin
