I came across, via healtcareinfosecurity this morning, coverage of a recent report entitled “The True Cost of Compliance“.  From the coverage:

What the study finds, says Rekha Shenoy, vice president of strategy for Tripwire, is that across the board, regardless of industry or standard, companies that consistently comply with security requirements and standards save three times more in security-related expenses annually than companies that are categorized as non-compliant.

Hmm…  Interesting, if true.  But I have to say, I’m dubious about the conclusion here. Ordinarily, I’d go to the original source material to investigate the methodology for how they arrived at this conclusion, but I can’t figure out where it is.  Maybe I’m totally missing the actual text of this report (please link it if you know where I can find it), but I’m giving up since 15 minutes of fruitless hunting is my upper bound.

So, in absence of the original report, we only have to go on what’s in the coverage.  In which case, I’d ask if this data representative of decreased costs associated with breaches alone?  I’d argue that we’d tend to see correlation between decreased breach-related costs and compliance (positing that compliance does, in fact, reduce breaches…).  So we’d expect breaches to cost less right?

But the interviewee doesn’t stop with that; she says, “…companies that consistently comply… save three times more in security-related expenses annually”.  In absence of the methodology, we have to assume they mean less cost on security across the board – breaches, operating cost for controls, staffing, etc.

Now, this doesn’t jive with my personal experience, but let’s assume that every company I’ve worked with in getting compliant are outliers.  Let’s assume that to meet the standards we deploy security controls where there used to be gaps and robustify controls that are deficient…. say we also audit ourselves for compliance (since really, that’s the only way to conclude that we are in fact compliant)… So a company that does this.. that takes on the cost of deploying controls and auditing saves 3x.  Um… Where? By spending more an organization spends less?  That makes my head hurt.

The cost savings are apparently also deliberately unqualified here – in other words, “…regardless of industry or standard…”, the company sees the savings.  Can that be true?  No matter what a company complies with, they get the benefit of 3x reduced spending?  Again, I doubt it.  If I’m a hospital and our lab complies with CAP accreditation requirements (which arguably have a security component), I see reduced security-related costs?  Nah.  Maybe just that one requirement isn’t enough for “consistent compliance”… so what if we comply with CAP as well as the Joint Commission Environment of Care standard (again, a security component).  Does that give me the cost savings?  Again… unlikely.

Clearly there is more going on here than what’s being reported on the surface…  In general, I’m skeptical about arbitrary compliance as a panacea for high security costs.  I could be totally wrong (in which case I’ll gladly eat the proverbial crow), but I’m going to need to see the documented evidence before I’ll believe the numbers cited.

Kudos to HP on their 2010 Top Cyber Security Risks Report.  It’s interesting, transparent, and open about how they’ve derived conclusions.  Point being, it’s a very useful, well-written, and well-presented report.

Of particular interest to me is the fact that the overall number of vulnerabilities has continued to go down for yet another year – and it’s doing so in a way that implies a parabolic curve.  I’m not saying it *is* a parabolic curve by the way, I’m just saying that it looks like it could be (although past performance is not indicative of future results.)

So either that will continue, meaning less vulns again next year – *or* it could be that it’s tied to some other factor that we can’t necessarily see from the chart (like economic conditions.)  Anyway, point being that it is interesting data and there’s all kinds of detail in the report where they break it down by threat type, date of occurrence, etc.

They do go into detail on some of the specific attacks in case you’re curious.  Totally worth a read.

Folks out there know I’ve been critical of Apple when it comes to product security.  I’ve criticized Apple on two counts primarily:

1. #1) for giving the user base (particularly the non-technical user base) a false sense of security
2. #2) for  stacking up poorly relative to the competition on response time to fix vulnerabilities

What’s interesting to me about the discussion is the degree to which the popular wisdom continues to persist in light of data directly to the contrary.  Apple still continues to beat on its “better security” marketing drum, despite the fact that they are almost always slower to the table on issuing patches – sometimes by a factor of more than 100%.

But today, we get another data-point that suggests that Apple isn’t all that their marketing would suggest from a product security perspective.  Secunia published their 2010 half-year report where they spell out how vendors compare relative to each by mining publicly-available vulnerability data.  And, in what might come as a little bit of a surprise to some, Apple is #1: meaning, they have the most bugs – just ahead of Oracle (number 2) and Microsoft (number 3).

This is a good data point in and of itself.  Now, you can’t conclude necessarily on this alone that Apple’s security is any worse or better than the others, but it’s useful to note.  However, I think there’s potentially another question to ask from the same data-set.  Specifically, what would we expect the size of the discovered vulnerability pool to be given the size of a vendor’s particular product portfolio?  In other words, if we normalize the data to come up with a “average number of vulnerabilities per product”, how would the vendors fare?

The Secunia report doesn’t answer that, and  I don’t know that we can either.  But going by instinct, I think we can maybe put up some blurry speculation.  My contention is this:

Premise #1: The list represents the sum total of all a vendor’s products
Premise #2:  Apple has fewer products represented in the list
Conclusion: Apple has more vulnerabilities per product relative to peers

If both premises are true, the conclusion has to follow.  But are they true?

Premise #1:  Are these vulnerability numbers aggregate across the complete product set? The report doesn’t say it in a way that’s unambiguous, but it comes darn close:

To gain more insight into the security ecosystem we identify the group of the ten vendors with the most

vulnerabilities (in all their products) in any given year.

Premise #2 is where it gets speculative.  What we would expect the size of the product profile to be?  While Apple has some prominent user-facing technologies (Safari, QuickTime, iTunes, and OS X – all very popular technologies), both Microsoft and Oracle have a large number of “behind the scenes” technologies – for example, server platforms and middleware.  Microsoft has the Office product line while Oracle has their database line, their OS line (don’t forget about Solaris – still in use), and everything related to Java.  It seems like the product catalog is bigger…  but I don’t think we can say for certain that it is.  Somebody would need to go through the list of vulnerabilities and see how many products are represented and put out a per-product vulnerability metric.

Just some food for thought…

I really didn’t want to continue on this topic again, but I find that I am unable to control myself.

I was reading through David Harley’s recent comments about the difference between ISO and AMTSO and Kurt Wismer’s well-reasoned post on AMTSO generally and I started musing about the role of AMTSO, my particular beef with it, and why this seems to stick in my craw.

So, to briefly recap, David makes a good point about the function of AMTSO in his post.  He says (paraphrasing) that the function of AMTSO is not to set standards… but instead to provide guidance that will (ideally) increase the quality of testing overall.  I have no problem with this.  In fact, I wouldn’t even be against it if it were like ISO (necessarily).  After all, we have standards and even accreditation when it comes to real-world pathogens (and the laboratories that handle them).  Maybe it’s a good idea to do the same thing with malware.

But that’s beside the point.  The point is, no matter what AMTSO goals actually are, that’s not how it’s perceived in the industry.   Here’s what I mean.

It’s about perception

I contend that folks out there in the public at large (particularly journalists) think the AMTSO is a standards body.  It may not be accurate… it may not be based on anything concrete… it may be total horse-puckey.  But it kind of doesn’t matter…  Joe Average security practitioner probably isn’t going to read the AMTSO blog… or this blog… or the Securiteam blog…  they’re not going to understand (or care) how the AMTSO is different from a standards body like ISO. All they’ll probably see are news reports – and those seem to suggest that AMTSO is an independent standards body – like ISO.

Pulled randomly from around the web, take a look at the AMTSO coverage that’s hitting folks in IT at large (all non-link underlining mine to illustrate the point):

From ComputerWeekly, “AMTSO standardises security software testing”:

A group of security software firms has agreed a set of testing procedures. Members of the Anti-Malware Testing Standards Organisation have published standards for testing security software.  The standards have been developed and agreed by more than 40 security experts, product testers and members of the media around the world. The creation and publication of these standards is the first step in Anti-Malware Testing Standards Organisation (AMTSO)’s mission to improve anti-malware product testing.

From InformationWeek, “Computer Security Companies Agree To Testing Standards”:

“AMTSO brings together the industry’s leading security and risk academics, vendors, and testers to provide testing methodologies and standards better suited to evaluate the protection available to combat today’s malware and related security threats,” said Vernon Jackson, manager of virus prevention systems at IBM Global Technology Services, in a statement. “This will in turn benefit end users, who will be empowered to make more informed decisions about the particular security solutions that match their needs.”

From eWeek, “Anti-virus Testing Standards Come to the Cloud“:

Last week, the two-year-old industry standards body adopted a paper setting forth best practices for testing in-the-cloud security products. The six-page document, available here, touches on subjects such as virtualization, connection filtering and the repeatability of the tests.

See what I mean?  Now, did I cherry-pick these?  A little bit… at least in that I got to choose what keyphrases to put into Google…  But does it matter?  The point is that at least some people in the industry perceive AMTSO as a standards body; and as Dave points out in his post, having “Standards Organization” in the name doesn’t help.

So is AMTSO doing the wrong thing?  Are they deliberately cultivating a false perception?  I doubt it.  But the fact is that there is a mis-perception, and that matters.

Slappin’ the labs

So if it’s not the role of AMTSO to standardize, it’s also clearly not their role to accredit.  But aren’t they doing just that?  Take a look at the review board report related to the NSS “socially-engineered malware” bakeoff from 2009.  The backstory:  NSS did a bakeoff as is their remit.  Sophos, AVG and Panda challenged NSS as to whether the test was in line with the published guidelines.  The review board evaluated the test and concluded that the test didn’t meet the Fundamental Principles of Testing.  Why not?  At issue were two points:

6. Testing methodology must be consistent with the testing purpose.
7. The conclusions of the test must be based on the test results.

Let’s review what the issues were from the report.  Pardon the long block-quote, but I wanted to put the relevant sections in verbatim so as to give the whole context.  For point 6:

Does the methodology align with the purpose or objective of the test? No. If you want to test “the protection of the products against socially?engineered malware”, you should also test products against this situation. It was not taken into account how the URLs actually reached the endpoint system. This might happen through spam, for example. If a product uses a spam?filtering, the spam message might have never appeared on the system, therefore the user would be protected as well.

Conclusion: The report does not comply with this principle. The reviewers agreed that missing infection vectors (e.g. spam) can mislead the result. Nevertheless, they also thought that the test still did better than a lot of tests out there right now, since at least the malware was coming from the “real world” and also was executed afterwards in a dynamic test.

So, here’s how I read this: the test attempted to validate the degree to which products protected against hostile links. But because the testing didn’t address spam filtering or other mechanisms to prevent the hostile link from entering the system, the review board concluded that the methodology doesn’t address the purpose of the test.

I’d argue that no matter what other features a product might have, if you test all the products the same way, you get a benchmark.  Could it be a better benchmark?  Sure.  Could you test other features?  Sure.  But when creating a benchmark, my opinion is you need to stick to testing one feature at a time.  A benchmark is not necessarily the way a product will be used in the “real world”, but  a “real world” test is impossible.  Why?  Because no benchmark can account for context – after all, if a person doesn’t use email and communicates solely through facebook, testing the combination of Sophos’ spam filter + URL blocker doesn’t represent anything akin to how the product will be used in that case.  What do you do?  Create a bogus usage scenario only to test against it?  Do that and any difference between the test usage and the real world usage would obviate the test.

By way of analogy, if I wanted to test anti-lock brakes, what would I test?  If I designed a test case where a car went into a skid, would the test case be invalid because I didn’t also test the dynamic stability control? After all, DSC could prevent the car from going into a skid in the first place…  But no matter how sophisticated the DSC is, it’s not the same as anti-lock brakes.

But don’t take my word for it.  Check out what Sophos says about it.   On their website, Sophos lists the features of their endpoint product.  Of the features they list, they list URL filtering and spam control as two different features:

Sophos Live URL Filtering: SophosLabs’ instant in-the-cloud lookups check a database of millions of compromised sites. We keep it current by adding and identifying up to 40,000 newly infected sites each day.

Sophos Live Anti-Spam: Before one of your users opens a potentially threatening email or attachment, Sophos Live Anti-Spam conducts a fast check of sender IPs, message and attachment fingerprints, destination URLs, and checksums. This keeps your users’ inboxes free from the latest spam campaigns and your email servers running smoothly.

If Sophos advertises these as two different features, shouldn’t they be evaluated that way?  In fact, I argue that it’s more fair to gauge the performance of a product against the standard they themselves advertise.  So when a lab tests the functionality, I think it’s actually more fair if they test these two features under two different benchmarks:  a spam benchmark and a URL filtering benchmark.  I for one would argue that the test methodology was flawed if the lab did conflate the benchmarks in analyzing the products… AMTSO says it’s flawed because they didn’t.

How about point 7?  From the AMTSO report:

Does the conclusion reflect the stated purpose? No. The report’s Executive Summary states that test’s purpose was to determine the protection of the products tested against socially-engineered malware only. Later in the report (Section 4 -product assessments) it says: “Products that earn a caution rating from NSS Labs should not be short-listed or renewed.” This is clearly a conclusion that you can’t make out of the detection for socially?engineered malware only, as the products have other layers of protection that the test did not evaluate.

Ok.  Let’s unpack that.  That sounds like they’re saying that because the test cautions purchasers on the basis of this feature, that the conclusion doesn’t fit the purpose… because the product has other features?  Wait… what?  So, if Consumer Reports authored a report on “Green-Friendly Refrigerators”, the methodology would be flawed if they only tested power consumption and didn’t also test the refrigerators’ ability to make ice?  After all, the ice making feature could be so whiz-bang great that it makes up for the fact that the thing causes brownouts when you turn it on.

No.

But let’s put all that aside for the moment.  Let’s ignore the merits of the challenge and look at the complaint itself.  Consider this question: should the AMTSO allow vendors to publicly challenge (and potentially discredit) an independent test from an independent lab?  If so, what are acceptable parameters?

I’d argue that if you are going to do that, there are some circumstances that are inappropriate.  For example, this didn’t happen in this case, but would it be appropriate if Sophos challenged the test methodology in which their product performed poorly and the entire review committee was made up of employees of Sophos?  That’d probably pass the sniff-test, right?  What about if all of the reviewers were employed by vendors?  Sniff test on that one?  Again, didn’t happen here.  But my point is, where’s the line?

It’s hard to draw one.   That’s why Consumer Reports accepts no advertising and there are no vendors involved in the test.  So that when they get sued, there is no appearance of bias.  Note that, appearance of bias.  It doesn’t matter if there really is bias or not – it’s the perception thereof that matters.

There’s a bunch of press today out on the interwebs about a new vulnerability in Windows 7.  Actually, let me rephrase.  It’s not actually a vulnerability according to the researchers – instead, they’re calling it a “fundamental flaw”.

Here’s the short story:  you see, there’s a apparently some issue with the way Windows 7 handles DMA – DMA (direct memory access) is a performance feature that’s been with us since 1999-ish, so it’s not like this is something new out of the wild blue yonder.

What’s the issue, you might ask?  Well, the researchers aren’t saying.  They don’t want to give the bad guys an advantage, you see – so they’re going to hold off on putting the details out there until an upcoming security conference where they will present their issue.

But here’s what tweaks me about this: they won’t release the details so that we the general public can validate the issue, but yet they took the story to the press where it was syndicated to every corner of the earth.  Don’t you suppose it’s in the realm of possibility that some bad guy somewhere – reading this article in one of the many languages it’s been translated into – will get an inkling of where they might go to turn this into an attack?

And even if by some miracle the bad guys don’t leverage it right away, what’s the point?  Why get everyone all fired up about the issue without giving enough details to actually evaluate whether it’s a concern or not?  They won’t tell us what the problem is, but instead tell us to disable DMA?  WTF!?  Have you ever used a machine w/o DMA.  ”Performance hit” is an understatement.  ”Someone replaced my CPU with blackstrap molasses” is an understatement.  Nobody’s going to do it.

Anyway, I think these researchers should have gone one way or the other – either release the issue or don’t.    But this sitting in the middle and putting out a teaser?  While it works for their apparent goal of general press-houndery, I’m not sure it does the public any favors.

If you’ve been following my meanderings over the past few months, you know about the Rootkit report where they say that rootkit incidents have risen 2300 percent over the past two years, and you’ve seen their assertion that we’re on the “cusp” of a phone-borne malware attack. Of course, I don’t subscribe to any of that. However, I came across this article today citing the McAfee OS X Malware paper where McAfee warns Apple users about the possibility of “chip-based” malware. Sigh.

Needless to say, I don’t think this is a real possibility. We haven’t seen malware propagation via a hardware vector ever and I don’t think we’re likely to see it start happening now. As any programmer will tell you, as more time goes by, operating systems offer fewer mechanisms for a developer to interact directly with system hardware. Since the introduction of the HAL in Windows NT, there are fewer and fewer ways for a developer to directly address hardware components from the application layer. Not to mention the fact that the number of different permutations of components makes it almost impossible to ensure compatability even on the same model system. One has to ask the question why some virus or worm would interact directly with hardware components, when it is a million times easier to propogate without doing that. So they can infect OS X? Not likely.

Remember when we went through the McAfee “Rootkit Report” and pointed out that their “statistics” were merely reflective of their product rather than actually reflective of what’s going on in the real world? Well, today I stumbled across the headline Virus emails drop to record low informing us that virus-laden emails are at the “record low” figure of 1.5%:

…total number of virus-laden emails fell by 56 per cent compared to March’s figures, with infected mail now making up just 0.79 per cent of inbound emails…

Bull. Why is it bull? Because this number (and others like them) don’t reflect the reality, they only reflect a particular vendor’s product – essentially the same point that I raised with McAfee’s the rootkit numbers. These numbers reflect the unique nuances of the instrument used to take the measurements – they do not necessarily tell us much about what’s going on outside of that. How do we know? Because the .79 percent figure is from the Blackspider statistics; but they’re not the only people publishing this stuff.

According to some of their “peers”, the April virus numbers were: Messagelabs – 1.5%, MX Logic – 3.8% (7 day window, not all of April), Sophos – 0.7%, EmailSystems – 0.42%, and so on. Look, these may sound like small percentages at first, but when we’re talking about 60 billion emails a day, the difference between .8 percent and 3.8% is 180 million emails per day. Over the month, that’s a range of error for these numbers +/- 5.5 billion. See what I mean? In my opinion, we would need to see all these different vendor numbers plotted out against each other over time in order to really make guesses about what’s really going on under the hood.

I noticed this morning a brief article over at Xatrix about rootkits on the rise, which sounded interesting. As it turns out, McAfee has put together some research indicating that “In the first quarter of 2006, the number of rootkits increased by 700 percent” and “Windows-based stealth components dominate the landscape, with an increase of 2,300 percent from 2001 to 2005″. Wow! 2300 percent? Double-wow! Needless to say, these numbers seemed so astronomically high that I just had to dig into the methodology to see why that is.

After deliving pretty deep, I’m convinced that this whitepaper, like much of the research coming out of the AV industry, suffers from a common flaw: namely, results that are reflective of a given vendor’s product are being used as a benchmark for interpreting broad events. What do I mean by that? Let me take you through an example of what I mean; take a look for a moment at the following startling graph from the McAfee whitepaper:

Seems pretty straightforward, right? Maybe, maybe not. Look closely at where the majority of the rootkit “growth” is coming from and you’ll see that the lion’s share is due to a relative small handfull of programs including “Backdoor-CKB”, “Backdoor-BAC”, and “W32/Feebs”. To illustrate, let’s do some digging on that huge spike of rootkit activity – the biggest one of the bunch – “Backdoor-CKB”. Looking at the details, we find out that McAfee added detection capability for this rootkit somewhere between 10/2004 and 2/2005*. Looking again at the graph, we see that in 2005 we see an astronomical spike in the number of infections during that time period. It goes from nothing to the most popular rootkit (by far) within that same time window. Coincidence?

So which is it? Did this rootkit came out in 2004 and spread across the Internet faster than any other rootkit before or since *OR* was this rootkit there all along and the spike on the chart is reflective of when McAfee added the ability to detect it? To find out, we need to do a bit of backtracking to try and estimate when the rootkit came out. “Backdoor-CKB” is, of course, not called that by the folks writing and using it; they call it “PCShare” of which the current version seems to be PCShare 3.11. The earliest reference I can find on the Internet to a version of PCShare that we can be sure was classified as “Backdoor-CKB” (using the presence of pcclient.dll in the rootkit to make sure) is from late 2003 (“PCShare 2.0 Beta1″.) We don’t have a file listing for earlier versions to ensure that they would still fall under the same McAfee classification, but even so – since rootkits are not generally available on major hacker sites for a few months after being written, we can conservatively estimate that this rootkit was around at least since late 2002.

Late 2002 – two full years before it appears on the McAfee chart. For two years, it’s gaining in popularity, getting more and more users, more and more infections. Then McAfee adds detection capability, bringing with it a tremendous spike in detection volume. Now, two years after that, McAfee is using this spike as part of the evidence to make the claim that rootkit infections are up 2300 percent. Hmmm… If I deleted half the signatures from the AV product on my laptop and I used that AV product’s output to collect data for a report entitled “50% less malware this year”, would that be accurate? Look, I’ve no beef with McAfee, and really it’s good that vendors are making this type of research available for free – but I really think we need to approach vendor-sponsored research with clear eyes. Especially if the instrument that they are using to collect the data is their own commercial product.

* The “discovered date” is Feb 2005 while the “minimum dat” was published in Oct 2004. Since it’s unlikely that protection was offered before it was discovered, we can assume that one of these dates is probably inaccurate.

The Register had an article today, “As Emperor of Security, I hereby decree…” It caught my attention since it was so atypical in style. The author spends some time discussing the things that he would decree if made emperor of security. Neat concept, right? I thought so too.

The mandates were totalitarian and restrictive; purposefully so (that’s sort of the point, right?) Some of them were good ideas (mandatory education for all new computer users), some were bad ideas (fines for insecure software), and some had both good points and bad points (mandatory anti-virus, anti-spyware, and firewall software). However, what really got me thinking was the discussion about “mandatory monocultures” :

It’s pretty well been proven that operating system monocultures are a bad thing. In a biological population, the introduction of a disease into a monoculture can spell doom for the entire group: since everyone is the same, everyone is vulnerable in similar ways. This is analogous to computing monocultures: if everyone is running Windows (or Mac OS X, or Linux, or whatever) and a serious compromise enters that population, then there is the danger that everyone in that group will suffer devastating losses.

This reference, of course, points back to the one and only Dan Geer “CyberInsecurity” paper that caught so much attention when it was published because of the ramifications of it’s release.

Now, I know better than to contradict Dan Geer. And I won’t, because I believe his paper to be absolutely true. But there’s a limit to how far the analogy holds; my laptop is not a Rhesus Monkey, a Lemur, or even a bacteria. While populations of machines can (and do) share a number of similarities with a population of organisms, that doesn’t mean that everything that’s true about organisms is true of laptops. For example, don’t put a bunch of laptops in a box and expect them to start making little laptops. In other words, just because certain threats are more virulent in a monoculture world, don’t assume that all of them are. And why not? First: because nobody has to manage a population of organisms, and Second: because there are more bad things than plague…

Consider two environments: one has a thousand machines each with identical OS, architecture, patch level, etc. The other also has one thousand machines but each one has different operating systems, architectures, and patch levels. Say (for the sake of argument) that two full time administrators manage that environment – a reasonable number, right? Dan’s paper points out that the first environment is much more likely to be impacted by worms; and that’s true. But which envrionment is more manageable? Which one is more likely to have automated security tasks like patch management, central monitoring, coordinated audity, etc? See what I mean?

Take the OS and application patches alone. Say that the operating systems in the second environment (the non-uniform one) each require an average of two vendor patches per week for all installed services and apps (a ridiculously low number.) Say each of those patches require 5 minutes to download, prepare, and install (another ridiculously low number.) Guess what: that patching process would take 166 full-time hours. If you had a more MANAGEABLE environment, you could have deployed something to automate that. You could start focusing on something more strategic than patches application with all the time you’d save.

Look – monoculture does increase the risk of population-level catastrophic events. However, diversity decreases the ability to manage the environment. Reduced manageability directly increases the risk of individual-level events like targeted attack. It’s not a traditional curve where the optimal position is maximum diversity; instead, it’s a bell curve: the optimal position is diversity – but manageable diversity.

This morning, I came across the excellently written post by Pete Lindstrom “Why Bugfinding is Irresponsible and Increases Risk”. As always, Pete is succinct, considered, and lays out his argument in exceptional clarity. That’s not to say that I agree with the entirety of what he says – just that I think he’s studying the problem in a comprehensive way, and I think his (non-mainstream) approach is thought provoking.

Pete’s position is that vulnerability research – more specifically for-disclosure research (“bugfiding”) – increases overall IT risk, and is therefore undesirable. I won’t dispute whether it does or does not increase risk; I think we can only speculate as to what kind of relationship risk and research might or might not have. Sure, there’s anecdotal evidence on both sides of the issue, but we don’t have any empirical evidence – we don’t have any way to test how research impacts risk – and we have a fairly equal number of smart people arguing for both sides. So, maybe it increases risk and maybe it doesn’t.

However, I think debaters on both sides of this issue are somewhat guilty of security-centrism. In other words, although risk is very important as part of doing business, there are other factors to consider; security is a means, not an end. When considering the value of vulnerability research, shoudn’t we also consider the broader ramifications that don’t directly relate to risk? In fact, some of these broader issues are things that we can actually get some data about; for example, the economic impact on vendors and others, like the impact on overall software quality, etc.

I guess my point is, why ignore all the other potential benefits of vulnerability research because of a potential (but not necessarily definite) increase in overall IT risk? Shouldn’t the discussion be broader than that?