For our latest debate – Android vs. iOS – there are three sets of numbers that have recently come into play for evaluation:

1. Number of vulnerabilities: A recent blog post on TheVerge.com highlights that iOS and its 238 vulns from 2007-2013 has 8.8x more vulnerabilities than Android’s 27 from 2009-2013.
2. Number of malware samples: In April, a Symantec report [PDF] pointed out that Apple’s 387 vulns in 2012 dwarfs Android’s 13 and yet Android had 103 “mobile threats” (malware) compared with Apple’s 1. Importantly, they also point out that “most mobile threats have not used software vulnerabilities.”
3. Percent of traffic: A paper presented at NDSS ’13 [PDF] monitored actual smartphone traffic and found that a) “The mobile malware found by the research community thus far appears in a minuscule number of devices in the network: 3,492 out of over 380 million (less than 0.0009%)” and b) “users of iOS devices are virtually identically as likely to communicate with known low reputation domains as the owners of other mobile platforms, calling into question the conventional wisdom of one platform demonstrably providing greater security than another“

Now, since we all know that security is the number one priority for IT decisions (heh), the CIO is waiting to hear from us on which platform is more secure. How do you answer?

Here’s my analysis, just using the numbers provided*

First, number of vulnerabilities as a measure is often thought of as a leading indicator of risk even though we all recognize that more vulns found equals fewer vulnerabilities remaining. The perception, however, is that there are actually even more vulns left. Absent of any other information, however, it is worth considering the notion that a higher number here is a measure of stronger security going forward (that is, #vulns is a lagging indicator). It doesn’t help matters that at least one of the sets of numbers inexplicably uses different time periods in its analysis. This measure would be much more useful if we had a way to normalize the numbers across platforms – the two most obvious ways would be with 1) a measure of complexity or size of the code base or 2) a measure of the personhours expended in looking for vulns. While I favor this latter option, it is not very practical.

The second measure, number of malware samples, is interesting because it is closer to the actual compromise. In addition, as Symantec points out many of them don’t exploit software vulnerabilities (this is another knock against using vuln counts). The challenge here is that there is essentially unlimited ability to create more malware samples. Moreover, the notion of a “mobile threat” is fairly broad and not always threatening to the extent that legitimate apps have some similar characteristics. Given the (somewhat) restricted methods for distribution and installation of apps on smartphones, a better measure would be to identify the distribution and accessibility to the population of these malware apps. In this case, getting an understanding of the number of downloads would get significantly closer to understanding the relative risk.

The final measure, compromised smartphones, provides a historical measure of actual infected phones. Aside from the really, really low number, we must decide whether these values are a good reflection of (future) risk or not. Since this number identifies compromised systems, it gets us closest to that which we are trying to prevent, which is useful. Ultimately, I believe this measure is the best of the three in helping us understand “risk” in the mobile world. And right now, it’s a tossup.

A better measure for determining which platform is more secure, in my opinion, would involve a measure of attack surface combined with one of devices sold (as a placeholder for activity volume and popularity).

This is an important announcement because it highlights the very real problem of “in-the-wild-exploits of undercover vulnerabilities.” This strain of “0day” is the most significant given that active exploits are already happening when they are discovered. In these scenarios, the threats (malicious actors) and vulnerabilities have already collided in the real world and losses are being actively incurred. Thus, this type of situation is the most important type that technology risk (techrisk) managers must deal with in their environments.

The announcement itself highlights some important, underappreciated aspects of the techrisk profession:

- That exploits/breaches/incidents are the fundamental “unwanted outcome” that we are trying to prevent. It is not uncommon for techrisk pros to focus efforts on software quality, control weaknesses, or compliance violations – all useful intentions to the extent that they address the aforementioned incidents.

- That techrisk professionals can identify attacks even when the vulnerability is unknown. Much of our profession’s focus revolves around the notion that we must find vulnerabilities in order to protect ourselves, yet time and again we succeed in identifying these types of attacks using behavioral analysis and other techniques. With the growth in popularity of forensic archiving, we can now also determine to what extent we have been victims in the past to assist with understanding the risks of the future.

• That much of the profession’s effort associated with vulnerability management is ineffective. Our efforts to identify each vulnerability prior to exploit are simply overwhelmed by scale and can simply be shown through a thought exercise – consider how many vulnerabilities are created every day (in the aggregate) as compared with how many are found. Perhaps more importantly, it is worth noting that the vast majority of vulnerabilities that are found are never known to be actively exploited [pdf].
• That there is a variance in how different types of attacks – namely, targeted vs. opportunistic – manifest themselves online. Google’s primary cited reason for its new policy involves political activists as victims of targeted attacks that may lead to physical harm. The history of infosec and techrisk highlight other scenarios – the NIMDA worm, WMF exploit, WebDAV, etc – that involve opportunistic exploits across a multitude of targets.
• That the most significant way to “move the marker” in security is through the identification of exploits and not vulnerabilities. As with Code Red and Nimda in the Fall of 2001 leading to Bill Gates’ well-known “Trustworthy Computing Memo,” active exploits are the best drivers of change in the techrisk profession.

 While Google’s new policy offers and opportunity to assess the state of security on the Internet overall, it also demonstrates significant deficiencies in its approach:

• The 7-day deadline has no risk basis. With the significant variance in number of affected parties and speed of compromise associated with opportunistic attacks versus targeted ones, the number is an arbitrary one. In the primary example cited (activists at risk of physical harm), speed is highly unlikely to have a significant impact on risk reduction.
• The capabilities of enterprises and/or users to protect themselves can vary significantly. There are many reasons why some parties choose to remain vulnerable to certain types of attacks – system complexities, legacy support needs, lack of technical skill, competitive priorities, etc. Through the years some security researchers (including some employees of Google) have expressed disdain for those that cannot protect themselves. A company the size of Google should be held to a higher standard in its willingness to protect those online that can’t always protect themselves.
•  No consideration of economics. The policy completely ignores tradeoffs like the risk of breaking systems when taking precautionary measures (e.g. patch failures), the well-known increase in exploits that occur after the disclosure of many new vulnerabilities [Arbaugh, McHugh, 2000 pdf; Bilge, Dumitras 2013 pdf], and the opportunity costs associated with new requirements. When Google says, for example, “each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised” they neglect the significant likelihood that computers will be compromised regardless of the state of disclosure to the public and fall back on the age-old myth that only patches can protect systems.
•  It can lead to even more exploitations and incidents. Anyone paying close attention to the vulnerability research community knows that there is wide variance in how researchers disclose their information and some decisions are made based on annoyance, frustration, spite and sometimes even malice. If a vulnerability will get “noticed” more quickly, researchers may be tempted to “test” it in the wild in order to increase its priority level.

A company with the talent and resources at Google can do better. Here are some opportunities for improving the state of security on the Internet and addressing the real, significant risk associated with actively exploited 0days:

• Encourage and train political activists in obfuscation and evasion techniques. It is challenging to discuss a blanket policy across all scenarios simply by highlighting arguably the most important one – that involving physical harm. It seems highly unlikely that this case is a common one and the best way to discuss the overall implications of the policy itself is to remove this scenario from the discussion as it tends to cause an emotional reaction. As many of us know, there are many ways political activists can protect themselves online that would be much more effective than a 7-day disclosure policy which comes after they have been compromised.
•  Increase focus on actively exploited 0days. Since these are the most important scenarios the techrisk profession has to deal with, Google should be making every effort to identify these exploits and employ or invent new ways to protect against them. Google researchers still participate in random, ineffective vulnerability research that simply distracts from this very real problem.
•  Provide more insight into the “dozens” of 0days identified “through the years” that was mentioned in the blog announcement. If there is one thing Google has, it is great data. As evidenced by past reports [Provos, 2008 pdf], Google could very easily provide more specific evidence on the number of 0days they have identified, the volume of exploits, and their disposition by vendors. The fact that they haven’t yet, especially in the face of this policy announcement, is disappointing and makes it difficult to evaluate the measure.
•  Take a risk-based approach to disclosure. Fast-moving worms do most of their damage in hours and days – in those cases, seven days is too long. Targeted attacks are unlikely to get repeated in a way that demands immediate attention for most environments – in those cases, seven days is too short. A risk-based approach would take into account the frequency of exploit, probability of future exploit within a target population, and impact of the exploit while evaluating the changes to these variables over time – in particular before and after disclosure.
•  Monitor the situation closely. Google’s unique ability to gather data in this regard is worth mentioning again as a function of its ability to assess its own policy. Collecting and publishing data on actual 0days throughout their exploit lifecycle would be a boon to the entire profession.
•  Initiate or participate in discussions to create new ways to address this very real problem. Commercial, community, and government mechanisms already exist for sharing data publicly and privately that could be used as models for minimizing the risks associated with these types of attacks. For example, a (private) process similar to federal wiretap capabilities in secrecy and opportunity may be more effective in addressing targeted attacks. There are countless other approaches that could be leveraged to address this problem.

Make no mistake, the Google 7-day policy announcement sheds light on a real and significant issue in technology-related risk. While it highlights some of the challenges techrisk professionals face on a daily basis, it also demonstrates significant deficiencies in its approach to address the problem. This is a great opportunity to evaluate the existing state of the Internet from a risk and security perspective to determine where inconsistencies or weaknesses lay and map out a risk-based program that has the highest likelihood of success.

“If you want a bug fixed quickly, sell it on the Russian black market. It’ll be so heavily abused that the vendor will patch out of cycle.”

Now, it could be the joke’s on me and the 126 people who retweeted this message (a large number for security tweets) were in on it. Or, they all don’t realize how ludicrous this is. In the infosec/techrisk field, this kind of thinking is not unheard of so I will treat this as if it is legitimate.

The tweet highlights just how biased people can be when they get caught up in a notion without understanding the implications. Apparently, this tweeter wants bugs fixed quickly. At first blush this seems like a simple enough concern, shared by many. But peel one small layer deeper and the statement often ends up being “want bugs that you know about (or worse, that you discovered) fixed quickly after your discovery?” It becomes easier to see how certainty bias and the focusing illusion come into play.

there is plenty of evidence to demonstrate that it is unlikely that the bug in question is the only bug that remains unfixed – we have any number of bugs in various stages of discovery and disclosure all the time. If we assume that the average bug takes 120 days from discovery (or at least vendor notification) to patch release, and vendors generally release patches on a monthly cycle, then there are four months of undisclosed (typically) vulns on your systems that remain upatched.

Now, you might assert that this makes the point – of course we want them patched “quickly.” But that completely ignores the tradeoffs. If your patch is prioritized, that means another one must be de-prioritized. I suppose you could say that security developers aren’t operating at capacity and therefore can absorb the workload for both bugs, but that seems farfetched to me and doesn’t scale in any case.

Of course, the worst part of the tweet is the part that purposely increases risk by increasing the threat of compromise. No need for a soapbox/high horse here to recognize that purposely inflating risk to get attention in spite of how detrimental it is to Internet users is certainly unprofessional and really kind of pathetic.

Too often, folks get caught up in some perceived solution to a problem and neglect the bigger picture. Many times, the bugfinder is sincerely concerned. But it is important to understand the cost/benefit and risk dynamics involved if you really want to positively affect Internet risk.

It turns out the target this time is “SASO,” a company that must be making headway in driving legislation towards third party code reviews.

“ I’ve opined in previous blogs on the importance of defining what problem you want to solve, specifying what “it” is that you want to legislate, understanding costs – especially those pertaining to unintended consequences – and so on.”

-> Hear, hear (or is that here, here?). In any case, we should all be finding ways to understanding exactly what we want. For example, do you simply want “more secure software” or do you really want “fewer incidents?” I am utterly against legislation because we haven’t defined the problem and more importantly we haven’t scoped out the solution.

This includes legislative mandates on suppliers – who, as we all know – [sarcasm] are busy throwing crappy code over the wall with malice aforethought. Those evil suppliers simply cannot be trusted…[/sarcasm]

-> I had to emphasize the sarcasm here because some security folks actually believe this. However, Mary Ann seems to insinuate that simply because developers are not trying to write write crappy code, they aren’t creating it. And there is good reason to believe (ahem) that software ships with vulnerabilities. The code isn’t necessarily crappy, per se, but it is hard to refute the evidence that it does have vulnerabilities – sometimes many.

Though I understand the frustration and strong emotions here, on both sides, I am not a fan of setting this up as some sort of moral, “good vs. evil” argument. In my experience, most folks really are trying to “do the right thing” even though the approaches conflict.

Having to plow through 1000 alleged vulnerabilities to find the three that are legitimate is way too expensive for any company to contemplate doing it.

-> In my opinion, this is the real problem with this entire space. The tools do not provide high quality, which makes security expensive. And I immediately segue into most vulns aren’t exploited and there are no defined bounds to how long you can look for vulnerabilities.

“creating a market for themselves.”

-> Reference to “demand creation,” one of a handful of conflicts of interest in the security world (really, everywhere). Another is the conflict between security and shipping products.

“ they analyze the binaries to do static analysis”

-> I wonder who this could be. Oh, that’s right, it’s “SASO.”

And thus, suppliers are out of business if they screw it up, because their competitors will be ruthless. Competitors are ruthless.

-> This is standard far “it’s not us, it’s them” mentality that is extremely tricky. Vendors think “competitors” are ruthless which implies they are some sort of exception. Enterprises believe “everyone” is ruthless – there are no “competitors” only prospective suppliers. And again, in a very ambiguous space, it is rare to find a software company that doesn’t have something to say about the quality of their security program.

Of course, of much more importance in all of this – and perhaps Oracle can attest to this as well – is the value the software product provides to the company.

Whom do you think is more trustworthy? Who has a greater incentive to do the job right – someone who builds something, or someone who builds FUD around what others build? Did I mention that most large hardware and software companies run their own businesses on their own products so if there’s a problem, they – or rather, we – are the first ones to suffer? Can SASO say that? I thought not.

-> A strawman that seems a bit of a stretch based on the evidence. I agree wholeheartedly that developers really do try to write secure software, and that companies really do try to ship secure products. Unfortunately, in today’s world there is plenty of evidence that it isn’t good enough. And, to be honest, I think the answer is that SASO has more incentive to do the job “right” – it is their core business.

…why SASO will never darken our code base…

-> I can’t help but think of a CFO asserting that external auditors will never “darken” his financial statements… umm, yeah. Moving on, now.

This next section is the “manifesto” part:

1) We have source code and we do our own static analysis.

-> It is very hard not to be trite here with a “and how is that working out for the industry?” line. This is true of every significant software developer. It seems like vulnerabilities are still missed (ahem).

2) Security != testing

-> Agreed! There is much more to it. But vulnerabilities are where the rubber meets the road. The good news is that the corollary to this statement also refutes Mary Ann’s earlier point that she would never outsource “security.” It really isn’t security, it is testing that is (potentially) being outsourced.

3) Precedent… 4) Fixability…

-> I worry a lot about Precedent. Just not in this case. And fixability is simply a truism that is irrelevant as far as I can tell.

5) Equality as public policy.

-> The more vulnerabilities you fix, the more every customer benefits. I don’t see how this is unfair or unequal.

6) Global practices for global markets.

-> Aha! Finally, we get to the real argument, which is that they already use Common Criteria labs to evaluate security, and Oracle believes it is more comprehensive. A much stronger argument, I believe. Buried.

7) All tools are not created equal.

-> Wow. Lots of nuances to this one. I agree that you shouldn’t mandate a tool, or even approach. That runs the risk of ambiguity and leads to the reason why there shouldn’t be legislation in this regard. But that doesn’t mean there is no value to third-party reviews. The biggest value I see is not independence as if developers are colluding in producing bad code, but independence in that another set of eyes can provide new ways to look at the code and, as has been shown by public disclosures (which I generally don’t support), find more vulnerabilities.

[man, this Oracle post goes on forever!]

[A "cautionary tale"] I told the product group that they absolutely, positively, needed in-house security expertise, that “outsourcing testing” would create an “outsourcing security” mentality that is unacceptable.

-> If I had a dollar for every “cautionary tale” I’ve heard, I would be a rich man. The notion that there aren’t a thousand ways to address “mentality” issues is simply wrong.

By way of contrast, consider another company that does static analysis as a service.

-> So, that contrasting story doesn’t really contrast. It seems to indicate that you *can* outsource security testing, if you do it “ethically,” which I am sure everyone would suggest that is how they work, and, as with the other arguments about what is in the best interests of companies, is certainly in the testing companies’ best interests.

I recently heard that SASO has hired a lobbyist. (I did fact check with them and they stated that, while they had hired a lobbyist, they weren’t “seriously pursuing that angle” – yet.)

-> Ugh. Just ugh.

I have to wonder, what are they going to lobby for?

-> A great, important question that really should be answered by the industry.

In my opinion, neither SASO – nor any other requirement for third party security testing – has any place in a supply chain discussion. If the concern is assurance, the answer is to work within existing international assurance standards, not create a new one. Particularly not a new, US-only requirement to “hand a big fat market win by regulatory fiat to any vendor who lobbied for a provision that expanded their markets.” Ka-ching.

-> Though I think Mary Ann is a bit too confident in her in-house setup, I believe this is a reasonable approach and agree more than I disagree with it. And I find myself agreeing with the rest of the post (minus the book recommendations ).

After reading the entire article (!) I find myself missing something. The assertions about how much security there is seems to conflict with the evidence in the public. I am no fan of public disclosures, but that is the way software security world operates today, and to leave the challenges in the entire software world unacknowledged is missing the point.

The only thing worse than the market is government. So I choose the lesser of two evils, almost every time. But it is worth noting that the amount of “demand creation” in the security space is reprehensible as well. Regardless of that, the software security profession as a whole completely ignores

THE MOST IMPORTANT QUESTION IN SOFTWARE TODAY: For any given application, how many vulnerabilities should be tolerated?

If your answer is none, please follow the yellow brick road to the emerald city. We have to get away from working to perfection and set standards as an industry that define a reasonable level of attention to the vulnerable state of software. This reasonability or vuln tolerance measure could be based on effort, code base churn, size, complexity, age, etc.

Obviously, this is a complex problem with many options, perhaps none of which is perfect. But if we don’t want another “compliance” state regarding software, we really need to address this problem with something other than “we try really hard.”

Culture and consciousness is all a distraction and very malleable. What really matters at the end of the day is the relative number of vulns in the software.

Also, worth noting that “secure software” is a derivative goal of less risk – that is, fewer incidents. We often opt for the former in the face of the latter, which is counterproductive.

Liability is a horrible idea. Here are some reasons why:

1. It’s unenforceable.
2. It will destroy innovation.
3. It will destroy open-source.
4. It will create an Xbox Internet.
5. It will double prices.
6. It will force lock-in.
   
7. And, finally — it won’t work.

Those come circa 2005 from my commentary here: To Sue is Human; To Err Denied

Related:

Software Liability = Our Worst Nightmare

The Death of Open Source and Xboxes for Everyone

Software Liability Redux

Who Should be Liable?

At the time, I wrote a rebuttal in Information Security Magazine. I can’t find it at the original online link, so have copied the version I have below (this might differ slightly from the published version). Let me know what you think.

ALL TOGETHER NOW

I’m sick and tired of having to be a farmer, car manufacturer, avionics expert and biologist to do my job. This whole analogy business has gone way to far. Nowadays, we spend more time making comparisons to security than we do solving security problems. Hello! Get over it!

The latest analogy everyone’s using is comparing Microsoft to a farming monoculture. This all started in late September when Dan Geer, Bruce Schneier, Becky Bace and other security mavens released “CyberInsecurity: The Cost of Monopoly,” a white paper that argued that Microsoft’s dominance in client-server computing posed a serious risk to global IT security.[1]

Now, I have no idea whether monoculture is bad to farmers. I know nothing about pesticides, fertilization methods or crop rotation. But I do know that the charges waged against Microsoft in this paper are a bit silly–at most inconsequential, and potentially destructive.

The authors argue that the solution to the dangers posed by monoculture is diversification. In a nutshell, a diversified computing base will limit the number of potentially vulnerable and exploitable systems, no matter what specific system (or systems) is targeted.

I’d suggest that this basic philosophy sounds great in theory, but is totally impractical when you get down to specifics.

The first victim of diversification is simplicity. In defining complexity, one must look at the overall computing infrastructure and all the resources in use. Every day thousands of new programmers code millions of new lines of code in an uncoordinated fashion (under competition).

The integration of many varied components further increases complexity. What are the costs of supporting a diversified base of applications and platforms, or of training half of the end users in the world on new client systems? What about the productivity losses during this transition period? What about the trillions in business that doesn’t get done?

OK, for the sake of argument, let’s assume for a minute that monoculture really is bad. What do we do about it? One suggested alternative is to purposely control market forces by limiting any vendor to 50 percent of the desktops in use. That brings 600 million desktops down to 300 million. Great, except that the most prevalent virus/worm to date has only affected a couple million systems. Even limiting 10 operating systems to equal market share gives any attacker a target of 60 million systems. And hackers have a history of adapting to new environments anyway. With the growing popularity in blended threats, a virus could bundle many different attacks against different platforms.

Perhaps the greatest problem in the push for mandatory diversification is the fact that most IT shops have spent the last 10 years pushing for “monocultural” computing environments. Monocultural is merely a synonym for “standardized.” To suggest that the risk is too great for a standard desktop is to suggest that the 20-year effort to standardize systems and systems support processes was a bad idea.

The final test of the monoculture argument is in the consequences of its adoption:

• Application software vendors who focus on Windows operating systems will see their markets halved and their costs doubled.
• Enterprises double their costs in providing technical support, retraining highly skilled professionals, and modifying and supporting internal applications that work on the Windows platform.
• Attackers will focus on another lucrative target–for example, Cisco. Don’t know about you, but I’m a lot more worried about Cisco vulnerabilities creating a “cascading failure.”
• The government sets a precedent that it will control the Internet. Innovation dies.
• The problem doesn’t get solved. The Internet will be just as prone to cascading failure as it is today. Are 300 million vulnerable systems really better than 600 million?

I confess that I really don’t like being a Microsoft apologist. Redmond has significant problems to address if it really wants to strengthen our computing environments. But I’m constantly surprised that security professionals let their emotions get in the way of reason and intellectual rigor.

It is time to put this Microsoft bashing to bed and move on. Diversification is foolish amidst all of the other needs of an IT organization. Security professionals need to play the cards they are dealt. There are many, many different approaches to security that can be successful in securing Windows et. al. To spend life in an alternate reality that doesn’t include Microsoft is a copout.

[1] See www.ccianet.org/papers/cyberinsecurity.pdf.

PETE LINDSTROM, CISSP (petelind@spiresecurity.com), is the founder and research director of Spire Security, an IT security analyst firm. He also is a member of Information Security’s editorial board.

(originally published in Information Security Magazine and no longer available online, but referenced here)

I am not clear whether this list of disclosed vulnerabilities is intended to represent vulnerabilities created or fixed (it is neither), but it certainly does its job in highlighting the problem. It is worth first understanding that vulnerabilities can exist in various states after creation – undiscovered/discovered; undisclosed/disclosed (publicly); and unfixed/fixed, giving us 8 different possible state combinations (though 2 are impossible) for vulnerabilities:

undiscovered, undisclosed, unfixed (latent)

undiscovered, undisclosed, fixed (due to code upgrade, for example)

undiscovered, disclosed, unfixed (impossible)

undiscovered, disclosed, fixed (impossible)

discovered, undisclosed, unfixed (true zero day; undercover vulnerability)

Security Strategies – January 31, 2002

Why Check Point should buy RSA

By: Pete Lindstrom, Director — Reply to:plindstrom@hurwitz.com [not active anymore]

It is no secret that the security space is highly fragmented. Hundreds of companies vie for market share and mindshare amidst hundreds of others, all with a bit of a unique spin – operating within the Four Disciplines of security management (Identity, Configuration, Threat, and Trust Management). Even within Operational Security (Authentication, Access Control) choices and configurations abound. There is no true “security” company because there is so much to do and so many ways to do it.

THE HURWITZ TAKE

The company that can consolidate solutions and provide broad coverage in the areas described above will own the security market. But who will that be? Right now, Symantec has a strong story in the Threat Management and Configuration Management space, with ISS close behind. Tivoli has a strong presence in Access Control and is working on mindshare in Identity Management and Threat Management. Netegrity and Verisign have interesting plays in Access Control and Trust Management, respectively. CA has products in just about all of these areas, but no solid mindshare. That leaves Check Point and RSA.

Check Point and RSA – at its most basic level, there doesn’t seem to be too much in common. But a second look reveals plenty of similarities, in both their businesses and solutions:

n Both Check Point and RSA own the markets and the minds in firewalls and authentication, respectively.

n Both have strong indirect channels. In fact, they share many of the same resellers.

n There are two basic prerequisites to selling a security solution – if you support authentication, you must support RSA’s SecurID; if you have a network security solution, you must join Check Point’s OPSEC Alliance.

n Check Point provides Access Control at the network layer. RSA provides Authentication at the network and application layers. Authentication and access control are always linked, with the common denominator for networks being the VPN.

But wait, there’s more. From that position, they could roll up the authentication space by adding biometrics and dedicating effort toward smart cards and single sign-on (with RSA’s RADIUS server). They can take the Securant solution that RSA acquired and integrate it with firewalls –increasingly important in the continual blend of the network and application layers.

There are other reasons to consider this, but the end result is the same: A Check Point – RSA merger would result in an operational security powerhouse that could own and define the security space in years to come.

There is really nothing new here, as evidenced by the Google folks referencing a 9-year-old Bruce Schneier essay on the topic. I have written extensively on the topic and the related software liability in previous years (some highlighted below) and get castigated quite a bit when pointing out some fairly obvious points. I believe these points are important and are sometimes ignored, so I will go ahead and point some of them out again, as there is a big elephant in this room and I think it is the real reason that folks are constantly at odds with one another.

So, here’s the elephant: Vulnerability disclosure of any kind (full, responsible, irresponsible, coordinated, uncoordinated, whatever) is not working and hasn’t been working since Bill Gates’ Trustworthy Computing memo of 2002. If you think about it, the remarkable thing about that memo is that it effectively neutralized all that was to follow in disclosure (and even the debate where it stands today) because it was a major acknowledgement of the problem from a huge company. Ever since then, nobody has been able to articulate the long-term strategic benefit of vulnerability disclosure (and for good reason). Even worse, there is no evidence of benefits anywhere, other than to the bugfinders themselves (though certainly this can work both ways). Let’s face it, the truth of this matter, and the reason for all the debate revolves around respect, fame, and competitive advantage and not around bringing about a safer Internet. Please let me explain.

The reason something as simple as a memo could have such an effect is that bugfinders never really had a strategic mission to begin with. Let’s face it, the only thing a bugfinder wants is for his or her particular bug that they happened to find at any given time fixed in whatever they believe is a timely manner. I don’t know where this fits in Maslow’s hierarchy of needs, but it ranks very low unless of course you factor in self-esteem (in the form of respect and fame). In any case, finding and fixing a single vulnerability is an extremely minor exercise (relatively speaking) with a huge downside relating to the scalability of the threat.

Perhaps the more interesting development in this arena is that we have an independent who works for a large company and therefore has heavy influence due to both his technical skill and his employment status. The circumstances where large companies target each other (and I assume that everyone agrees with the Google Security statement that even if Tavis Ormandy was working independently they fully supported his actions) is even more complicated. The most interesting problems relates back to this lack of strategic purpose for disclosure – if a company the size of Google is spending time finding vulnerabilities in its competitors’ products, it seems reasonable to me that they should have found every single vulnerability in their own products. The principle of comparative advantage should be put to work here. In addition, large companies should have a better sense for their altruistic objectives, unless there aren’t any.

Although we know that the lack of cohesion in participants muddies the waters for strategy (and thus we are stuck spinning our wheels dealing with the whims of bugfinders), the most obvious reason for finding vulnerabilities is to enhance software quality and increase security. Amidst this noble goal, the second half of the statement often gets ignored. I think this is because people assume a correlation where there is none. That is, enhanced software quality with respect to vulnerability discovery and disclosure does NOT increase security, at least in the short-term. The objective is really a derivative of an interest in reducing the number of compromises.

So, how can disclosing a vulnerability (followed presumably by the availability of a patch) reduce security? Simple – although the opportunity exists for individuals to reduce their vulnerable state, so many people can’t or don’t that the increase in threat significantly multiplies the number of incidents that occur. That is, vulnerability disclosure completely ignores the threat component of the risk equation in the short run.

This short run focus on vulnerabilities and not threat might seem okay because we have much less control of that aspect of risk, but we have significant indirect influence. That is, clearly the risk to unpatched (or otherwise unprotected) systems goes way up because disclosure significantly reduces the “costs” to any attacker and we know from history that incidents increase dramatically after disclosure. One quick aside: With the evolution of today’s technical architectures to SaaS and other cloud-based applications, it is worth pointing out that the circumstances of increased risk are not applicable to environments where one entity can guarantee that every instance of a software program has been properly patched.

As for the long run, there are many more developers than there are bugfinders and every day we are creating many more vulnerabilities than we are finding. It does not appear that developers are creating fewer vulnerabilities as a result of the disclosure effort, nor does the world have fewer vulnerabilities. One approach to address this is to assert that we should significantly increase our bugfinding efforts… except that we have done that as well, with the introduction through the years of newer and better automated solutions. No, the real way to address these problems is to think outside the box for a solution – all manner of trusted computing and its derivatives, for example.

Perhaps the biggest failing of vulnerability disclosure is that we completely ignore the externalities in this situation – the billion or so users of these various products. This spiteful approach is often justified with a wolves/sheep kind of reasoning that is quickly brought to its knees by considering all the good people in our own networks of friends and neighbors that shouldn’t need to be software engineers just to surf the Internet. These users are frequently victims of the increased risk we are artificially creating in their environments, unbeknownst to them.

One thought exercise that might be interesting here is to try to imagine what would happen if all of a sudden nobody disclosed any vulnerabilities. In fact, nobody (at least none of the good guys) even looked for vulnerabilities. The typical response here is to suggest that software would get even shoddier and the bad guys would have their way with us and we would never even know about it. I would suggest to you that this is complete and utter rubbish.

My version of this thought exercise is that people would work harder to further the goals of trusted computing because the stakes were higher and more funds were available. They would develop better monitoring tools to catch even more undercover exploits than are already being caught. They would put even MORE pressure on software manufacturer’s when compromises were discovered. Even now, we discover and respond to “undercover exploits” more quickly than we do publicly disclosed vulnerabilities, and I think we can get even better at it. Make no mistake, given that we are only finding a small fraction of existing vulnerabilities, there is nothing keeping the bad guys from finding and exploiting unknown vulnerabilities today, so it isn’t like our current process is helping there.

I have the utmost respect for many bugfinders. I believe many of them have great intentions. But they are attempting to haphazardly run across the battlefield while the bad guys pick them off from sniper posts, infiltrate their ranks, or simply choose another battle field that is unoccupied. There is no chance at victory fighting the battle this way.

[Here is a list of previous posts, essays, and articles I have written about vulnerability disclosure. It is worth mentioning that though I stand by my facts and opinions, I am not always proud of the emotional pieces - I hold the utmost respect for a number of the folks I took shots at. I still disagree with their opinions, though ]

10/11/04: The Folly of Vulnerability Seeking

11/13/04: The Folly of Vulnerability Seeking (follow-up to my searchsecurity article of the same name)

4/1/05: The Dead Horse Lives

8/8/05: More, more, more (Vuln Research)

8/17/05: The Long-Term Impact of Vulnerability Research: Public Welfare

10/30/05: I’ll bite: Feel free not to be so helpful

11/2/05: To sue is human, to err denied (one of my favorite titles )

11/7/05: A New Litmus Test for Security Companies

2/20/06: I waffle slightly (I think)

3/7/06: More Turtles!

3/24/06: Why Bugfinding is Irresponsible and Increases Risk

3/31/06: More on Bugfinding

8/3/06: How Microsoft Reduces Risk (where I introduce a new risk equation)

9/6/06: It Ain’t Over ’til it’s Over

9/6/06: Now it’s Over (For Now)

5/16/07: More Sex is Safer Sex

9/24/08: On Vulnerability Rediscovery

7/13/09: Exploiting Undercover Vulnerabilities

2/25/09: The Disclosure Race Condition

3/4/09: The Other Side of Full Disclosure