Should There Be a Security Industry?

Carl Weinschenk

Comments attributed to well-known security researcher and consultant Bruce Schneier, which were reported upon in CNET coverage of Infosecurity Europe 2007, were either misconstrued, naive, purposefully provocative or taken out of context -- or some combination of all these. Regardless, they raise or hint at important questions.


Schneier is quoted and paraphrased to the effect that products should be secure when they ship, and therefore there should be no need for a security industry. We agree, of course, that products should be secure when they are sold. What the comments -- at least those included in the story -- don't address is how to handle core problems that emerge after the products leave the vendor's facility.


Any product released into the field will be attacked. In most cases, insecurities that are found can be addressed by patches, new virus definitions and other routine downloads.


There are, however, cases in which the problems will be more fundamental. The story doesn't tackle this, and the quotes attributed to Schneier are a bit vague. His point seems to be that products should be constructed so that remediative steps can be taken from within the product itself, and that a separate security software industry shouldn't be necessary.


There are a couple of problems with this.


We acknowledge to his and other experts' opinion if they say that constructing software differently would make it easier to fight new threats from within. However, saying that separate security software shouldn't be necessary isn't the same as saying that a separate group of companies shouldn't exist to develop and deploy those changes. In other words, if Schneier's point is that that the tools to respond to crackers' initiatives should be available within the software, he should say that.


The other point even is more basic. It is impossible to foresee precisely what the bad guys will dream up, and it can't be assumed that everything that crops up can be handled within the framework of a piece of existing software. Thus, a high level of security expertise must always be available. For larger companies, this could involve having security experts on staff. For example, Schneier's own Counterpane security was bought by BT last year. For smaller organizations, however, outside companies such as today's vendors or security service providers likely still will be necessary.


The story hints at interesting questions related to the ways in which software is written and the relationship between companies and the folks who write the software. This issue currently is in play as Microsoft seeks to keep security vendors from accessing the kernel of the 64-bit version of Vista, its new operating system.


How this plays out is important. The key question is whether it is fair for Microsoft's own security business, OneCare, to have access to the kernel that other security vendors do not. From the technical point of view, the relationship between outside companies and Vista's kernel -- and the precedents set by the level of access that eventually is allowed -- speaks to the broader issue of what role discreet security vendors will play in the future.

Add Comment      Leave a comment on this blog post
May 3, 2007 7:40 AM Dan Razzell Dan Razzell  says:
The point that Schneier makes is quite clear: "The primary reason the IT security industry exists is because IT products and services aren't naturally secure."I really can't understand what causes tech journalists to miss this basic point of system design. It's painful to read yet again the misinformed, and logically bizarre, rationale that it's impossible to foresee what the bad guys will dream up. No, to a designer these are simply a set of "edge cases" for testing the system.It's an embarrassment to the designer when edge cases must be fixed in the aftermarket. If they can be fixed, then surely the proper place to do so is in the original product. I don't buy contaminated food and then drop by the drugstore for some antidote before sitting down to dinner. Reply
May 3, 2007 7:54 AM Carl Weinschenk Carl Weinschenk  says:
Dan, I don't think it's logically bizarre to make the assumption I made. To assume that it IS possible to predict what a cracker will come up with rests on the assumption that he or she won't do something new or innovative. Your food analogy doesn't hold up either. Reply
May 4, 2007 2:32 AM Sivakanth Mundru's ramblings Sivakanth Mundru's ramblings  says:
Should there be a separate security industry? While implementing the above idea, we might be able to mitigate the security risks on the whole, but the software world/products will not be devoid of security flaws. It is easy to build smaller s/w product(s) with inherent tools against an exhaustib... Reply
May 8, 2007 7:44 AM Richard Lewis Richard Lewis  says:
In my opinion, both parties to this argument are right. Here's why:1) Bruce is right that suppliers of products and services often pay too little attention to ensuring their products are secure by design. Why? Because they are generally driven by the short-term need to deliver functionality rather than the longer-term goal of low maintenance costs and better customer-perception. That Microsoft now places secure design higher on its implementation agenda is testimony to its recognition that fixing security "after the effect" is inefficient, highly costly and bad for PR.2) The press are right that it will never be possible to design a totally secure solution or service, whether that be due to a slip-up in coding (even with the best practices in place), a configuration issue, an unanticipated or previously unrecognised weakness, or simply human error in utilisation of the solution/service.Security professionals who perform security risk analysis will recognise that short of locking an IT system in a safe and never switching it on, there is always a risk. Our aim is therefore to reduce the risk/impact to an acceptable level with as small an impact on business-as-usual as possible.If one considers the principle of security-in-layers, then the first dominant requirement has to be for solutions and services to be made as secure as possible by design. The second is to add extra layers of security to protect against the unexpected - or even the expected such as denial of service attacks.What worries me is that even implementors of security products are delivering solutions which are insecure by (accidental-but-avoidable) design and, what's more, can be resistant to fixing identified security problems because it costs them money and no-one else has spotted the problem - yet. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.