On Sun, August 17, 2008 10:58, [email protected] wrote:
> On Sun, 17 Aug 2008, Peter Dolding wrote:
>> Instead swap across to the shorter white list to process and sort.
>> Quarantining for black list scanning so performance of machine is hit
>> with the least ammount. Some areas like email, p2p for people using
>> formats that should not contain macros or executable code white list
>> scanning there is all that is needed before either blocking or asking
>> user if black list scanning should be preformed or the file just
>> deleted. Lets close the door's on these malware writers without hurt
>> end users any more than we have to. What is the point of running a full
>> black list across a file the user will delete because it was not what
>> they thought it was.
>
> you are arguing with the wrong people here. we are not trying to define
> the future of anti-virus technologies, we are trying to figure out how to
> provide the hooks so that people and companies can go off and do the
> research and experimentation and try different approaches.
Given recent demonstrations that show how easy it apparently is to bypass
blacklist base approaches, providing hooks to allow these blacklist
approaches may I feel be rather futile. Focusing only on hooks for white
list approaches in combination with hooks for least authority approaches
like the powerbox would IMHO seem like a much more reasonable approach
given the current state of things and knowledge concerning the blacklist
technologies. Explicitly adding support for technology that is quickly
becoming obsolete would seem like a waste of time and resources.
Rob
On Sun, 17 Aug 2008, Rob Meijer wrote:
> On Sun, August 17, 2008 10:58, [email protected] wrote:
>> On Sun, 17 Aug 2008, Peter Dolding wrote:
>>> Instead swap across to the shorter white list to process and sort.
>>> Quarantining for black list scanning so performance of machine is hit
>>> with the least ammount. Some areas like email, p2p for people using
>>> formats that should not contain macros or executable code white list
>>> scanning there is all that is needed before either blocking or asking
>>> user if black list scanning should be preformed or the file just
>>> deleted. Lets close the door's on these malware writers without hurt
>>> end users any more than we have to. What is the point of running a full
>>> black list across a file the user will delete because it was not what
>>> they thought it was.
>>
>> you are arguing with the wrong people here. we are not trying to define
>> the future of anti-virus technologies, we are trying to figure out how to
>> provide the hooks so that people and companies can go off and do the
>> research and experimentation and try different approaches.
>
> Given recent demonstrations that show how easy it apparently is to bypass
> blacklist base approaches, providing hooks to allow these blacklist
> approaches may I feel be rather futile. Focusing only on hooks for white
> list approaches in combination with hooks for least authority approaches
> like the powerbox would IMHO seem like a much more reasonable approach
> given the current state of things and knowledge concerning the blacklist
> technologies. Explicitly adding support for technology that is quickly
> becoming obsolete would seem like a waste of time and resources.
we are not providing hooks for blacklists or whitelists, we are providing
hooks for scanning. it's up to the software that doesn the scanning to
implement the blacklist or whitelist.
David Lang
Hi!
> >>you are arguing with the wrong people here. we are not trying to define
> >>the future of anti-virus technologies, we are trying to figure out how to
> >>provide the hooks so that people and companies can go off and do the
> >>research and experimentation and try different approaches.
> >
> >Given recent demonstrations that show how easy it apparently is to bypass
> >blacklist base approaches, providing hooks to allow these blacklist
> >approaches may I feel be rather futile. Focusing only on hooks for white
> >list approaches in combination with hooks for least authority approaches
> >like the powerbox would IMHO seem like a much more reasonable approach
> >given the current state of things and knowledge concerning the blacklist
> >technologies. Explicitly adding support for technology that is quickly
> >becoming obsolete would seem like a waste of time and resources.
>
> we are not providing hooks for blacklists or whitelists, we are providing
> hooks for scanning. it's up to the software that doesn the scanning to
> implement the blacklist or whitelist.
Actually, I don't think so.
If we wanted to whitelist permitted binaries, approach would be
something like "lets sign them"... and it seems IBM is working on
something like that with TPM infrastructure.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 17 Aug 2008, Pavel Machek wrote:
>>>> you are arguing with the wrong people here. we are not trying to define
>>>> the future of anti-virus technologies, we are trying to figure out how to
>>>> provide the hooks so that people and companies can go off and do the
>>>> research and experimentation and try different approaches.
>>>
>>> Given recent demonstrations that show how easy it apparently is to bypass
>>> blacklist base approaches, providing hooks to allow these blacklist
>>> approaches may I feel be rather futile. Focusing only on hooks for white
>>> list approaches in combination with hooks for least authority approaches
>>> like the powerbox would IMHO seem like a much more reasonable approach
>>> given the current state of things and knowledge concerning the blacklist
>>> technologies. Explicitly adding support for technology that is quickly
>>> becoming obsolete would seem like a waste of time and resources.
>>
>> we are not providing hooks for blacklists or whitelists, we are providing
>> hooks for scanning. it's up to the software that doesn the scanning to
>> implement the blacklist or whitelist.
>
> Actually, I don't think so.
>
> If we wanted to whitelist permitted binaries, approach would be
> something like "lets sign them"... and it seems IBM is working on
> something like that with TPM infrastructure.
the structure I proposed would support this as well.
your 'scanner' program would do the signature and store it somewhere and
mark the file as being scanned.
on access the checking software would see that you have marked it as being
scanned and can avoid the overhead of reading the entire file to check
it's signature (or you can configure it to do the full check again)
if the file gets written to the tag would get cleared and the file would
not be used without being blessed by your scanner again (and your scanner
my bless it if what happened was an OS update where the new file matches a
known signature)
not quite as straightforward as you were probably thinking (you were
probably thinking somthing like 'store the signature and have the kernel
check it each time the file is opened'), but this would have the option of
being faster by skipping the signature check if the file was tagged as
already being checked.
David Lang