lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BF1ABD1.1956.71CBD2B4@stuart.cyberdelix.net>
Date: Mon, 17 May 2010 21:49:21 +0100
From: "lsi" <stuart@...erdelix.net>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Windows' future (reprise)

On 17 May 2010 at 0:18, Valdis.Kletnieks@...edu wrote:

> On Mon, 17 May 2010 03:48:36 BST, lsi said:
> 
> > It is mutating at approx 243% per annum, a rate which is more than
> > twice as fast as Moore's Law (200% every 24 months).  I do find this
> > alarming, because I want my CPU back.  So does everyone else I know.
> 
> Unfortunately, you haven't shown that the CPU actually consumed is going up by
> 243% or any significant fraction thereof.  Admittedly, A/V products are slowly
> taking more and more resources, but nowhere near a Moore's Law rate.
> 
> Do some benchmarking.  Time how long it takes to scan a collection of 500 or so
> random files using a 2007 version of your favorite A/V software and signatures,
> and time how long this week's version take. The difference between the two
> numbers is the CPU you can "get back". I guarantee it has no relationship
> to the 243% you're complaining about (for starters, even if it *was* gaining
> 243% a year, that's a 243% grown rate of the 5% or so your anti-virus uses,
> not of your entire CPU capacity.

Indeed.

Although 243% of 5% will get quite large quite soon too.  I think it 
might be less than that right now - 2% maybe.  The problem is really 
that even 0.5% will turn into 42.36% after 5 years, at 243% growth.  
(I have triple checked that, I'm certain it's right, that's 
outrageous, it's because it's an exponential curve, gets steep 
quickly).

(It will be 243% of 5%, divided by the efficiency ratio you mentioned 
earlier.  That ratio is critical.  The smaller it is, the less it 
holds back the 243%.)

> > I'm not analysing infections, I'm analysing "new threats" (as defined
> > by Symantec).
> 
> Read Thor's description of the difference between threats and risks.
> 
> Defending against threats doesn't consume additional CPU.
> Defending against risks *may* consume additional CPU.

My interpretation of risk assessment tells me that if the chances of 
denial-of-service due to malware flooding is small, but the potential 
damage is substantial, despite the improbability, then that risk must 
be mitigated.

I do understand that additional "new threats" (as defined by 
Symantec) may, or may not, impact on CPU due to the efficiency ratio 
you explained earlier.

It's not possible to accurately quantify the risk until key numbers, 
such as the average CPU usage per detection rule, and the average 
efficiency ratio, are known.  What we can say right now is that there 
is a risk, of size unknown, that malware flooding will result in DOS 
conditions.

We cannot say how big the risk is yet.  But also, we cannot say that 
it does not exist.

As numbers such as average CPU usage per detection rule, and the 
average efficiency ratio, are likely to be commercial secrets, that 
will mean we will be forced to navigate blind.  This heightens the 
risk and thus the level of mitigation that is required.  That is why 
my advice remains to evacuate the platform.

Stu

---
Stuart Udall
stuart at@...erdelix.dot net - http://www.cyberdelix.net/

--- 
 * Origin: lsi: revolution through evolution (192:168/0.2)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ