One last point: Signature management at the perimeter appears to be less fraught with peril than the host-based stuff. We could continue to rely on the signatures at the perimeter (in conjunction with other approaches), and move away from them at the host.
-ASB: http://XeeSM.com/AndrewBaker On Fri, May 7, 2010 at 3:14 PM, Crawford, Scott <crawfo...@evangel.edu>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:asbz...@gmail.com] > *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 <kurt.b...@gmail.com> wrote: > > - -------- Original Message -------- > Subject: [Clamav-announce] problem with daily.cvd 10938 > Date: Fri, 7 May 2010 13:06:56 +0200 > From: Luca Gibelli <l...@clamav.net> > Reply-To: nore...@clamav.net > To: ClamAV Announce <clamav-annou...@lists.clamav.net> > > 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, > > - -- > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
