As Kurt mentioned, Application Whitelisting is one approach to this problem.
You bring up a good point about rogue data files. I think we really have to weigh the disadvantage of code-enabled data files and either abandon them outright, or at least ensure that there are configuration options for enabling the automation features that can be set centrally. For instance, consider how low the threat of macro-embedded documents has become since Microsoft enabled much better controls over macro security, including turning them off by default, and allowing them to be set via policies. It's not just about what apps can run, but in what context and with what functionality. If we can get vendors to provide us with controls around each of the features they provide such that they can be controlled centrally and fairly easily, then each person and each organization can determine what level of risk to assume for any given app, and in the event of an emergency, can disable or impair the problematic feature. All of these options will sufficiently mitigate external risks without simultaneously increasing risks from errors. And they will consume less processing power and generate less application conflicts than current solutions. -ASB: http://XeeSM.com/AndrewBaker On Fri, May 7, 2010 at 3:14 PM, Crawford, Scott <[email protected]>wrote: > I agree and I for one would like to hear your suggestions. It seems to me > that some form of white-listing is the most obvious alternative. However, I > really don’t see how that is guaranteed to be effective. Assume that it’s > possible to actually keep up with all of the software that you DO want to > run. What happens when there’s a PDF exploit, or a quicktime exploit, or an > IE exploit. All of these apps are likely to be on a list of allowed > applications, but if the data that they’re processing contains the > “malness”, the point of detection needs to change. Instead of white-listing > applications, we now find ourselves needing to white-list the actual data > that they process. > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Friday, May 07, 2010 1:59 PM > *To:* NT System Admin Issues > *Subject:* Re: Sunbelt, McAfee, Symantec - now Clam > > > > First off, the ClamAV issue was somewhat mitigated by them telling everyone > to be off of v96 for a few weeks. :) > > > > But, the reality of this situation is that signature-based host-level > protection is getting to the point where the human error factor is too high. > (I feel a blog entry coming up soon) > > > > In order to attack the threats that are out there, signatures need to be > updated frequently, and increasing the frequency places greater burden on > the QA process, and increases the risk of a self-inflicted DoS. > > > > What this signifies is that we need to start demanding a different approach > to host-based protection *as the norm*, because there is now as great a > chance that your system can be made ineffective from an AV update as from an > actual piece of malware. > > > > AV in its current form really has to die, as there is no way for the good > guys to keep up with the bad guys, leaving us vulnerable to even more > foolishness from creative bad guys. > > > -ASB: http://XeeSM.com/AndrewBaker > > On Fri, May 7, 2010 at 1:27 PM, Kurt Buff <[email protected]> wrote: > > - -------- Original Message -------- > Subject: [Clamav-announce] problem with daily.cvd 10938 > Date: Fri, 7 May 2010 13:06:56 +0200 > From: Luca Gibelli <[email protected]> > Reply-To: [email protected] > To: ClamAV Announce <[email protected]> > > Dear ClamAV users, > > about 15 mins ago we released daily.cvd 10938. This update apparently > caused a segmentation fault in all ClamAV versions older than 0.96 > on 32 bit systems. > > We just released daily.cvd 10939 which removes the faulty signature and > we have taken measures to ensure that this problem won't happen again. > > We recommend using a monitor tool like clamdwatch or clamdmon to > automatically restart clamd whenever it dies. > > If you are already using a similar solution, your clamd will be > restarted automatically as soon as freshclam downloads the daily.cvd > 10939 update. > > We apologise for the inconvenience. > > Regards, > > - -- > Luca Gibelli (luca _at_ clamav.net) ClamAV, a GPL anti-virus toolkit > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
