Mozilla is hierop met een officiele reactie gekomen:Volgens het tiende Internet Security Threat Report van Symantec
Virus / worm / veiligheidslek / security / hackers (klein)Tijdens de afgelopen zes maanden heeft Symantec naar diverse aspecten van het toegenomen gevaar gekeken. Zo zouden zwakke plekken in webapplicaties verantwoordelijk zijn voor 69 procent van het totale aantal gerapporteerde veiligheidsgaten. Ook in browsers zijn in vergelijking met het vorige rapport flink wat meer lekken gevonden. Zo zag Mozilla de teller stoppen op 47, terwijl deze het vorige half jaar niet verder kwam dan 17. Ook Internet Explorer zag in dezelfde periode meer meldingen voorbijkomen en steeg van 25 naar 38, terwijl Apples Safari een verdubbeling van 6 naar 12 moest tolereren. Daar staat tegenover dat de meeste makers wel sneller met oplossingen komen. De reparatietijd van Internet Explorer, de Mozilla-browsers, Safari en Opera bedraagt respectievelijk 9, 1, 5 en 2 dagen, terwijl de vorige periode deze tijden nog 25, min 2, 0 en 18 bedroegen. Ook keek Symantec naar het aantal dagen dat er nodig was voordat problemen in Microsoft Windows (13), Apple OS X (37), Red Hat Linux (13), HP (53) en Sun (89) opgelost werden.
Bron http://tweakers.net/nieuws/44536/Symant ... evaar.htmlBetter Metrics for Security - Understanding the Symantec Internet Security Threat Report
The Symantec Internet Security Threat Report came out yesterday. Of all the metrics that they are using, number of vulnerabilities gets top billing. This is possibly because this concept is easiest for people to understand: Count up the number of bugs. Product with the least bugs is declared to be more secure.
It is, of course, much more complex than that.
Looking at the number of vulnerabilities does not tell you much at all. The number of bugs that are counted for a commercial product is the number of bugs that are reported externally and fixed in a security update. Any bugs that are found through the QA process or by vendors engaged to find security vulnerabilities are fixed in service packs or in major product revisions. It makes sense for a commercial vendor to do it this way since those fixes will get the benefit of the longer test pass. Those bugs do not appear in security updates are not included in the overall count.
At Mozilla, you can see all of our bugs. The process is open, by design. You see the bugs found by internal testing and those reported to us externally, everything. Just counting up the number of bugs between products will never be an apples-to-apples comparison.
Nothing is secure. If all software has vulnerabilities, then the most important metric is really how long it takes the vendor to fix a bug once it is identified. That’s the measure of how long the user is at risk.
The report does talk about days of risk (they call it “time to patch,”) but it’s deep in the analysis sections, not in the summary. The highlights only mention the number of vulnerabilities and that’s the easiest story for the press to run. If you look at the other metrics you begin to get a much clearer picture.
On “time to patch”:
The time period between the disclosure date of a vulnerability and the release date of an associated patch is known as the “time to patch.” If exploit code is created and made public during this time, computers may be immediately vulnerable to widespread attack. It should be noted that this metric includes all patched vulnerabilities affecting the browser, regardless of their severity. During the current reporting period, Apple Safari had an average patch development time average of five days, up from zero days in the second half of 2005 (figure 22).76 In the first six months of 2006, Microsoft had an average patch development time of ten days for Internet Explorer vulnerabilities, down from the 25 days in the second half of 2005. Between January and June 2006, Mozilla had an average patch development time of three days, slightly lower than the five-day average during the second half of 2005. During this reporting period, Opera had an average patch development time of two days. In the second half of 2005, it was 18 days.
On “window of exposure”:
The window of exposure is the difference in days between the time at which exploit code affecting a vulnerability is made public and the time at which the affected vendor makes a patch available to the public for that vulnerability.
And…
In the first half of 2006, Internet Explorer had a window of exposure of ninedays, down considerably from 25 days in the second half of 2005 (figure 4). Apple Safari had a window of exposure of five days, up from zero days in the second half of 2005.12 In the first half of 2006, Opera had a window of exposure of two days, down considerably from 18 days during the second half of 2005. In the first half of this year, Mozilla had a window of exposure of one day. In the second half of 2005, Mozilla had a window of exposure of negative two days, meaning that exploit code in that period was generally released after patches were available.
Looking at “time to patch” and “window of exposure” you begin to see the real success story for Mozilla security. We’re able to keep the time to patch so low because of the incredible contributions of the Mozilla community. Every time you run nightly builds you are creating a more secure web experience for millions and millions of people.
This entry was posted on Tuesday, September 26th, 2006 at 12:14 pm and is filed under General, Security
Bron http://developer.mozilla.org/devnews/in ... at-report/