Skype Skuppered

It turns out that it was Microsoft that brought down Skype for two days earlier this month. Microsoft's monthly software update (known as Patch Tuesday) triggered millions of computers to reboot at the same time, which always puts an unusual strain on major Internet companies such as Skype.

Source: The Register, August 20th 2007.
See also TechCrunch August 20th 2007.

As Alex from RiskManagement Insight points out, this is equivalent to a form of DDOS (distributed denial of service) attack. From a risk management perspective, it may not matter very much whether an attack is deliberate and malicious, or merely an accidental side-effect of some entirely innocent action.

Although Skype had survived previous Patch Tuesdays without incident, it seems that this month's Patch Tuesday triggered a previously unknown bug in Skype's software. As Alex points out, it is practically impossible to construct a test environment large and complex enough to simulate this scenario.

I haven't seen any figures, but I have little doubt that Skype's competitors (including Microsoft) must have experienced an unusually high level of new registrations during Skype's misfortune. Now that we have become accustomed to free voice calls over the Internet, it seemed outrageous to return to the almost mediaeval practice of paying real money for talking over the telephone, so my colleagues and I signed up to Yahoo Messenger.

It's an ill wind ...

IT Security Industry

Lots of people (e.g. Gunner Petersen, Pete Lindstrom) are attacking Bruce Schneier for asking Do we really need a security industry?

Obviously Bruce doesn't expect the IT security industry to disappear any time soon. He points to some of the structural reasons for the economic viability of stand-alone products and services for IT security (including legal liability - or the lack of it), as well as the vested interests of software companies.

In some ways, the global security situation is getting worse with the increasing fragmentation of functionality and responsibility, and the increased interconnectedness of human and automated systems. This phenomenon isn't just an IT problem: it exists in other domains as well.

Bruce's argument is that security should be (increasingly) embedded into the infrastructure. This is the logic underlying the acquisition of Bruce's own company by BT last year. (See my comment: BT enters the Blogosphere.)

Pete is scornful, and and there are some similar comments on Bruce's own blog:

"The notion of 'natural' security in the face of an intelligent adversary is so fundamentally ignorant that the whole thing must be a charade. It isn't even a pipe dream - it is an impossibility. Throw in the fact that IT resources are increasing in value and function and there is no doubt of that impossibility."

Gunnar's criticisms are more moderate. He also questions the notion of natural security, but acknowledges the problems with the present situation:

"The way the IT security industry is presently constituted, is not effective, focuses WAY too much on network security instead of app and data security, and is incredibly reactive and tactically focused."

For my part, I think it's always useful to ask provocative questions. Questions like "Do we really need X?" (or the equally provocative "Does Y matter?") shouldn't be dismissed with a simple Yes/No answer. Such questions call for an exploration of the true actual or potential value of X and Y, and perhaps a search for better (more innovative, more intelligent) alternatives to the current state-of-the-art.

Do we need an IT security industry? Probably yes, but not the one we've got at the moment.

Problem-Solving

There are two contrasting patterns of problem-solving behaviour in the software industry.

• Solving problems on a one-off basis
  
• Solving an entire class of problems in a single move.

Many of the important innovations in software have resulted from successfully tackling major classes of problem rather than isolated instances. And there are many people in the software industry for whom this way of problem-solving has become an ingrained habit.

I therefore find it odd that some classes of recurring problem continue to be tackled on a one-off basis. For example, the industry still doesn't seem to have found a reliable way to eliminate software code "overflows" - even though this is a regular cause of software bugs and security vulnerabilities.

Another common example of this pattern occurs in user support. When a user reports a problem, this probably indicates that a number of other users have a similar problem. And it is probably not good enough to fix the problem only for the users who report the problem. In fact it may be more important to fix the problem for those users who haven't noticed that there is a problem at all.

But if the response is to solve the problem as if it belonged to a single user, then this seems to deny the existence of a broader problem.

Take blog feeds for example. A couple of times recently I've noticed problems with blog feeds, and I've gone to the trouble to notify the blog author. What I'd expect the blog author to do is fix the feed. What happens instead is that the blog author sends me back a helpful email telling me how to redirect my newsreader. Actually I can work that out for myself thanks.

Perhaps some blog authors assume that their subscribers are all fluent in RSS. Because I'm the one identifying a problem, they might imagine I am positioning myself at the incompetent end of the spectrum. And the problem is my problem.

Actually, it's precisely because I'm not at the incompetent end of the spectrum that I can see there is a problem. And it's not my problem if the blog author loses some of his subscribers because his feed is broken. It's his problem.

Jericho

Fortress Security

Back in 2002, Aidan Ward and I wrote some reports for the CBDI Forum on Web Services Security, which among other things lay siege to the Fortress Model of security. We were ahead of our time. The Fortress walls are not crumbling yet, but we are now joined by some serious allies.

Jan 2002	Web Service Security	Journal Article
July 2002	Component-Based Security for Web Services	Special Report

See also brief note on Autonomous Computing: Fiefdoms & Fortresses

Jericho Forum

Jericho Forum (part of the Open Group) is a non-profit security standards group, led by user organizations. This is leading the push towards more agile and interoperable security models.

Press Release: Executives Agree that Interoperability, Deperimeterization of Data and Horizontal Integration Are Essential (April 2004)
News Story: New boundaries and new rules (John Sterlicchi, SC Magazine, Jan 2005)
News Story: Vendors line up to see Jericho vision (Ron Condon, SC Magazine, Feb 2005)
News Story: The Future of IT Security is Fewer Walls, Not More (Dan Ilett, ZDNet, April 2005)

dePerimeterization

This essentially means tearing down the Fortress model.

Definitions: Whatis.com, Word of the Day

Security Vendors

nCipher	Cryptographic IT Security	See press release (April 2005), on joining the Jericho Forum.
Vordel	XML Web Services Security	See weblog postings (March 2004, July 2004) by CTO Mark O'Neil

Update

CBDI Report Agile Security for SOA

Technorati Tags: deperimeterization fortress jericho security

Consolidation

Several commentators see the recent merger of Actional and Westbridge as a harbinger of industry consolidation among web service players.

• David Sprott (CBDI Forum) discusses whether the industry is now "Crossing the Chasm".
• Phil Wainewright (Loosely Coupled) thinks we are now entering the "Acceleration" phase. (He tells us we're still some way short of the "EndGame" phase, and then provides evidence that this phase has already started!)
  

From an economic perspective, this merger can be understood as a response to a given set of economic forces. In general terms it is easy to predict more mergers, and we may be able to identify likely targets by looking at such economic indicators as revenue, growth, funding, cashflow, cashburn and so on.

This merger can also be understood from a technological perspective, as an statement about the viability of stand-alone security products. The technological logic of the merger is to integrate security products into management platforms. The same logic can be seen in CA's acquisition of Netegrity. It is also implicit in IBM's Tivoli brand, which covers a collection of security and management products.

This reflects a growing recognition of the complexity and dynamic nature of security requirements. While many stand-alone security products do an excellent job at guarding against a specific class of threat, what is needed is an agile security architecture capable of rapidly mobilizing a range of effective responses to newly emerging threats.

Let's return to the economic perspective. Security attacks are designed to achieve the maximum penetration for the minimum effort. Many attackers are motivated not by technical ego but by results (criminal or political). If a given style of attack ceases to be effective, we can expect a new style of attack to appear. If the attackers are more agile than the defenders, then this gives them a natural advantage. Against an agile attacker, it is not wise to invest all your resources in fixed defences.

Security Note

Microsoft has announced a critical vulnerability in Windows, which allows malicious code in JPEG files to be executed.

Source: BBC News

Like many security problems, this arises because of a failure of encapsulation. With a reasonable architecture, your photos could contain all sorts of secret messages and malicious code but these would not leak out. The software platform would only execute the code inside some sort of sandbox. But I don't want to have to go to this trouble. The problem only arises because someone had the clever idea that JPEG files could contain code, and programs reading JPEG files would execute the code. (JPEG is an industry standard: we can't blame all this on Microsoft.) That clever idea only works safely if we assume a much more sophisticated sofware architecture and an much higher level of software quality than we are likely to see in the foreseeable future. Otherwise, such clever ideas are dangerous.

Lesson One: Clever ideas often increase complexity, and have a negative impact on security.

If even an innocent JPEG file can be crawling with malware, what are the implications for advanced middleware, such as web services? SOAP messages can carry all sorts of payloads, including compressed, fragmented and encrypted ones. An XML document can contain data or code, and the code can be in any language you choose. We know that passenger frisking and baggage screening doesn't always detect weapons, so how do we expect a firewall to detect dangerous data packages? The firewall (and the fortress model which depends on it) are made irrelevant by these advanced technologies.

Lesson Two: If we are using open distributed technologies, we must expect security to be managed in an open and distributed way, not by building a false illusion of central control.