Re: ? - I don't know where to send this one, so I'm sending i t here...

[Nick FitzGerald <nick () virus-l demon co uk>]

Blue Boar wrote:

> Also don't forget that it's very important to identify things 
> specifcally, by name.  So signatures aren't going away anytime soon, I 
> imagine.

Nah, that's not important at all.

_IF_ the "don't let it run if it's not one of these 'allowed by local 
policy for this (class of) user' files" system is working properly (and 
this really should be deep in the guts of the OS, not something bolted 
on as an afterthought) then it really does not matter what something 
that was blocked was.  In fact, in general (recall, we are talking 
about something that would only ever be viable in a corporate setting 
anyway), it would be best to NOT even tell the user that something had 
been blocked.  WTF is the "benefit" of telling Kim in accounts that 
Spybot.PBQT or svcchost.exe was blocked and prevented from running?  
None.  Absolutely none.  By all means ring the alarms with whoever 
monitors the central reporting and logging of such stuff _if_ they 
really want to be annoyed witless by such alarms, but please leave the 
user out of it.  (This was one of my biggest complaints with "personal 
firewalls" when they were first introduced -- they were far too noisy.  
Basically, in an effort to justify their existence (and often that 
meant "their cost") they continually bombarded the user with "blocked 
ping-of-death attack", "blocked hack attack on port 25 from <IP>", etc, 
etc nonsense.  Never mind they were running on an OS not vulnerable to 
ping-of-death, that there was nothing listening on port 25 on that 
machine, etc, etc...)

Sys-admins do have a prurient "what was that that was blocked" 
interest, but that's partly because they tend to be nit-pickers and/or 
control freaks and also because they are somewhat accustomed to today's 
far from perfect results due mainly to the fact that they run their 
systems in "default allow" mode when it comes to executing code, rather 
than the security-sane "default deny" mode the above enforces.

> I wouldn't want my AV software to (just) say "Hey, we found something 
> bad.  We stopped it.  Probably.  Here's the file if you want a look." 
> And then I spend 8 hours analyzing just another Bagle.  As an end-user, 
> I mean.  Not as an AV employee.  You guys still have to analyze just 
> another Bagle for me. ;)

But if you know it will be stopped regardless of what it is _if_ it is 
not on the "I'll allow that (class of) user to run these applications" 
list, it really doesn't matter that it was a new Bagle, an old Bagle or 
a cranberry and chicken Bagle -- you know it will not be able to run so 
you'll be able to get on with more useful, productive and fulfilling 
(though maybe slightly more mundane than analysing malware) tasks.

Hmmmm -- maybe that last point is actually why so many otherwise 
apparently intelligent and reasonably informed sys-admins stick so 
steadfastly to known-malware detection approaches: when "defences" 
based on such an approach fail -- and they know they will -- the person 
(or team) in charge of malware incident handling knows they will get to 
do something "exciting"; the sys-admin's modern equivalent of riding in 
on a white charger to save the day, and thus enhance some "magical" 
quality they try to exude to justify their jobs?

Nahh -- surely not!  You're all professionals, right, who want the 
absolute best for your employers...


Regards,

Nick FitzGerald

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.