Tvrtko wrote:
>J. Bruce Fields wrote on 05/08/2008 23:55:24:
>> On Mon, Aug 04, 2008 at 05:00:16PM -0400, Eric Paris wrote:
>> > There is a consensus in the security industry that protecting against
>> > malicious files (viruses, root kits, spyware, ad-ware, ...) by the way
>> > of so-called on-access scanning is usable and reasonable approach.
>>
>> Can you point to any helpful explanations of that concensus?
>
>I can't, but everyone is doing it so that is at least an implied
>consensus.
I don't think there is any such consensus, so I'm not expecting a
technical explanation. As best as I can tell, the primary explanation
for why so many A/V vendors are doing it seems to be that it's a damn
effective business model, and that may have as much of an effect on its
widespread use as any technical merits or demerits.
Think about it: you get users to buy your A/V, then you tell them
they need to pay a monthly subscription fee to get the latest virus
signatures updates. It's like crack. Once you convince IT managers that
"every machine needs to run A/V software", it's basically a guaranteed
revenue stream for the A/V industry. It's lucrative stuff, so it's no
surprise that the A/V industry is nursing this for as long as it can go.
And on many Microsoft platforms, the level of pain has been high enough
that IT managers are willing to accept anything that reduces the level of
pain even partially, so it's no surprise that A/V is so widely used today.
It doesn't necessarily mean that it's the right way to go for the future,
or that it's the right model for Linux, though.
>> Off-hand it's surprising. (A defense that depends on cataloging every
>> possible individual attack sounds difficult!)
Of course. Simple signature-based file-scanning has got deep technical
limitations. It can detect copycats and script kiddies but you'd be
foolish to rely upon it to detect any kind of sophisticated attack.
Let's put some numbers on it, for real commercial A/V software.
I was at the Usenix Security conference last week, where one group of
researchers presented a paper that included a chart showing how quickly
McAfee A/V was able to detect new malware samples. The researchers
collected a large set of malware samples, and ran McAfee on it once
a day or so to see how long it took for McAfee's signature database
to be updated so it could detect those malware samples. As I recall,
the basic stats looked like this: about 30% of zero-day malware samples
were detected on the first day they were released (and 70% weren't).
The median number of days until a new malware sample was detected was
about 40 days. If you wanted hundreds of days, asymptotically McAfee was
able to detect about 70% of the samples (and 30% were never detected).
I expect the situation to get worse in the future, not better.
And keep in mind it's easy for an attacker to write a polymorphic or
"metamorphic" virus that is basically undetectable with straightforward
signature-based file scanning, so in an arms race the attackers have
most of the advantages.
On Wed, 6 Aug 2008, David Wagner wrote:
> As I recall, the basic stats looked like this: about 30% of zero-day
> malware samples
> were detected on the first day they were released (and 70% weren't).
> The median number of days until a new malware sample was detected was
> about 40 days. If you wanted hundreds of days, asymptotically McAfee was
> able to detect about 70% of the samples (and 30% were never detected).
> I expect the situation to get worse in the future, not better.
This is similar to the stats published by AusCert a couple of years back
where they claimed that AV software failed to detect 80% of new malware:
<http://www.zdnet.com.au/news/security/soa/Eighty-percent-of-new-malware-defeats-antivirus/0,130061744,139263949,00.htm>
Interestingly, AusCert still describe up-to-date anti-virus software as
being "essential", per http://www.auscert.org.au/render.html?it=6891
In any case, the above relates to Windows desktops -- we are yet to see
a rationale for adding AV support to the Linux kernel.
- James
--
James Morris
<[email protected]>
> In any case, the above relates to Windows desktops -- we are yet to see
> a rationale for adding AV support to the Linux kernel.
s/we/you/
Clearly some people do see a rationale. At least some parts of it also
seem to make sense for picking up stuff in transit and for catching stuff
'in flight' between systems that might be more vulnerable.
It does appear possible to create a meaningful set of functionality for a
subset of the problem space - assuming no local compromise.
- open for write causes some kind of state transition (even
SELinux label change)
- last close notifies a userspace tool of some form (be it an
indexer or a scanner or whatever)
- tool may or may not take some kind of action such as
relabelling.
At that point you can use selinux rules to say things like 'samba cannot
access content in 'change-in-progress' state.
Whether you allow opens to block for a scan really comes down to a risk
tradeoff. The "safe" approach is 'sorry someone has it open for writing
go away'. The lax approach is "yeah whatever, we may be unlucky if
something passes across our file server at the right moment" (allowing
anyone to read change-in-progress files) and somewhere in between is the
"wait a moment while I scan it" case, which reduces the time window of
attack considerably with a very high chance of detection if the attacker
gets it wrong).
Alan
David Wagner wrote on 06/08/2008 23:24:01:
First of all you dropped all CC so I only found this by chance.
> Tvrtko wrote:
> >J. Bruce Fields wrote on 05/08/2008 23:55:24:
> >> On Mon, Aug 04, 2008 at 05:00:16PM -0400, Eric Paris wrote:
> >> > There is a consensus in the security industry that protecting
against
> >> > malicious files (viruses, root kits, spyware, ad-ware, ...) by the
way
> >> > of so-called on-access scanning is usable and reasonable approach.
> >>
> >> Can you point to any helpful explanations of that concensus?
> >
> >I can't, but everyone is doing it so that is at least an implied
> >consensus.
>
> I don't think there is any such consensus, so I'm not expecting a
> technical explanation. As best as I can tell, the primary explanation
> for why so many A/V vendors are doing it seems to be that it's a damn
> effective business model, and that may have as much of an effect on its
> widespread use as any technical merits or demerits.
>
> Think about it: you get users to buy your A/V, then you tell them
> they need to pay a monthly subscription fee to get the latest virus
> signatures updates. It's like crack. Once you convince IT managers
that
> "every machine needs to run A/V software", it's basically a guaranteed
> revenue stream for the A/V industry. It's lucrative stuff, so it's no
> surprise that the A/V industry is nursing this for as long as it can go.
> And on many Microsoft platforms, the level of pain has been high enough
> that IT managers are willing to accept anything that reduces the level
of
> pain even partially, so it's no surprise that A/V is so widely used
today.
> It doesn't necessarily mean that it's the right way to go for the
future,
> or that it's the right model for Linux, though.
You are entitled to your opinion and I am not in a position to get
involved into these kinds of discussions.
> >> Off-hand it's surprising. (A defense that depends on cataloging
every
> >> possible individual attack sounds difficult!)
>
> Of course. Simple signature-based file-scanning has got deep technical
> limitations. It can detect copycats and script kiddies but you'd be
> foolish to rely upon it to detect any kind of sophisticated attack.
So why you deleted my quote where I say signature based detection is not
all we do?
> Let's put some numbers on it, for real commercial A/V software.
> I was at the Usenix Security conference last week, where one group of
> researchers presented a paper that included a chart showing how quickly
> McAfee A/V was able to detect new malware samples. The researchers
> collected a large set of malware samples, and ran McAfee on it once
> a day or so to see how long it took for McAfee's signature database
> to be updated so it could detect those malware samples. As I recall,
> the basic stats looked like this: about 30% of zero-day malware samples
> were detected on the first day they were released (and 70% weren't).
> The median number of days until a new malware sample was detected was
> about 40 days. If you wanted hundreds of days, asymptotically McAfee
was
> able to detect about 70% of the samples (and 30% were never detected).
> I expect the situation to get worse in the future, not better.
Do you have a link to that paper? It is all about the testing methodology
and it would be interesting to read how the actually test in more detail.
To bad they haven't used more than one product. They chose McAfee who,
with all respect - and I am not representig my company but saying this
privately, are not known for their swiftest response times. See here:
http://blogs.pcmag.com/securitywatch/Results-2008q1.htm , they also seem
to be good but not great in proactive detection.
> And keep in mind it's easy for an attacker to write a polymorphic or
> "metamorphic" virus that is basically undetectable with straightforward
> signature-based file scanning, so in an arms race the attackers have
> most of the advantages.
Again this goes back to my quote you deleted. Why is straightforward
signature-based detection relevant? Who is doing only that today? For
example please read this:
http://www.infosectoday.com/Articles/Behavioral_Genotype.htm from where I
quote:
"""
A good example of this is the Storm worm outbreaks that started in October
2006 and continued into February 2007. See figure below. There were many
variants, including Dorf and Dref worms, but one single behavioral
genotype identity detected nearly 5000 different unique variants. Using
traditional signature-based techniques, it would have required reactive
detection, which would have taken a lot of man power and been much less
effective at stopping the first waves of the threat.
"""
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.