Perimeter defense
considered harmful
William Wulf and Anita Jones have written a brief, tantalizing, and important article in Science: “Reflections on Cybersecurity”. They point the way out of a tangle of security problems (not all, of course) that costs billions of dollars in losses billions in countermeasures, and billions more in opportunity costs — some known and some not even imagined.
With current countermeasures, we’ve been losing the war. Wulf and Jones argue that the fundamental approach is wrong:
The current model for most cybersecurity is “perimeter defense”….Hackers try to “break in,” “firewalls” protect the system, “intrusion” must be detected, etc. But is perimeter defense the right underlying model?
They note that
[1] perimeter defense does not protect against the compromised insider….
[2] once the perimeter has been breached, the attacker has free access….
and [3] …it has never worked. It did not work for ancient walled cities or for the French in World War II (at 20 to 25 km deep, the Maginot Line was the most formidable military defense ever built, yet France was overrun in 35 days). And it has not worked for cybersecurity. To our knowledge no one has ever built a secure, nontrivial computer system based on this model.
The authors note the reason for the success and scalability of protocols that form the foundation of the internet:
Dave Parnas, one of the early software engineers, made a provocative and, we think, deeply important observation that helps to explain the success of the TCP/IP protocols. He pointed out that, when doing a design, the hardest decision to change is the one you make first, because all the subsequent ones to some extent depend on it. The decision for the TCP/IP protocols to do so little never had to be reconsidered, because it precluded so little.
They recommend that we deploy a cryptographic protocol of similar generality, one that does little, but does it well, and thereby provides a foundation for systems as complex, diverse, and specialized as the vast superstructure built on TCP/IP:
Is such a minimal mechanism feasible? We think so. In particular, at the network level, an application can use any computable function to decide whether or not to provide its service to a client if it can be absolutely certain who is requesting it. There is a class of algorithms known as “cryptographic protocols” for doing this that require knowing the public key of an object—so we conjecture that by providing just a way of accessing the public key of an object, one could build an arbitrary end-to-end security policy.
Because this minimalist foundation precludes so little, its generality seems assured.
In addition to its other virtues, it would be smoothly compatible with computational methods that can solve crucial vulnerability problems at the level of applications on individual machines (with very lightweight implementations, by the way). Wulf himself led pioneering work in this area, and he is no lightweight in computer science or Federal technology policy.
This proposal deserves more than ordinary attention.
(And here, more than ordinary emphasis.)
{ 8 comments… read them below or add one }
Toby 11.26.09 at 8:57 am UTC
I sympathise with the position that security by perimeter defence is insufficient. However, it doesn’t follow that a general TCP-with-crypto protocol on which services could be built would solve any of the many security failings we face. If it were, then this would imply that most attacks occur because data is not encrypted while in transit. This is completely false.
Most data is stolen while at rest. Many (but not all and perhaps not even most) attacks result because we cannot build bug free software, nor even specify the security properties that the software we build ought to have.
Software engineering is no engineering at all but merely informal craftmanship. Until software construction becomes a rigorous discipline, that rests upon the same applied mathematical foundations as other engineering disciplines, I don’t hold much hope for this situation to change.
Craig Overend 11.27.09 at 3:32 am UTC
CCNX and the security paper for it.
Cristian 11.28.09 at 4:22 pm UTC
I totally adhere to what Toby said.
Transmission or encryption has not been the problem for the last 15 years.
The problems lay in the way in which organisations work with information, sloppy software and ultimately in the liabilities and externalities wa accept only when it comes to software. (We stopped accepting this kind of behaviour in the auto industry in the 30s.)
Things will not get better untill the ones that are really responsible for the different failures (from sloppy software to sloppy prcedures) are the ones that bare the burden of the financial loss derived. As long as these costs are for software companies and the companies responsible for the deployment of this software (ex. banks) an externality (an ID theft is shoulder by the customer for example) no real progress will be made.
Eric Drexler 12.02.09 at 4:45 am UTC
@ Toby, Cristan — I understand and agree with your concerns, but Wulf is making a more subtle point.
It is of course true that crypto has been available for a long time; his concern, however isn’t secrecy, but authentication. What we don’t yet have is a simple, universal protocol for authentication that is as unspecialized, low-level, and universal as TCP/IP is for transmission.
As Wulf notes regarding the range of security policies that a mechanism of this kind could support, “an application can use any computable function to decide whether or not to provide its service to a client if it can be absolutely certain who is requesting it (emphasis added). This addresses a very different problem. It would use “public key cryptographic protocols”, but not necessarily for cryptography.
It is of course true that no proposal can solve all problems in an area as broad and amorphous as “secure computation”, but it is also true that fundamental changes in infrastructure can solve more problems than any 10,000 patches (of patches (of patches…)).
I think we need what Wulf advocates, and I think we need more.
Eric Drexler 12.02.09 at 5:00 am UTC
@ Craig Overend — Thanks for the link!
It’s good to see ongoing efforts to roll out concepts developed at PARC (I have a few in the queue…), and Content-Centric Networking is an extraordinarily valuable and important objective. This functionality — which would free the identity of content from ties to its storage location — was part of what we envisioned when I was involved in hypertext publishing development in the late 1980s, before the world was flooded by the churning sea of the WWW.
This concept is at a level of depth and generality comparable to Wulf’s proposal, and is largely orthogonal (and as is often true in architecting computational systems, “orthogonal” means “synergistic”).
Gavin 12.04.09 at 5:45 pm UTC
I like the authentication concept but it is excessive to dismiss perimeter security. Many attackers are repelled or even better, deterred, by a perimeter. The Maginot line is a famous failure but there are many successful perimeters in military history too. Hannibal never even attempted to attack the city of Rome in spite of roaming Italy for years. He knew its perimeter would hold.
Humans have an impressive internal immune system but the skin is an important defense. We can see this from the number of infections related to breaches of the skin.
Tom Matthews 12.05.09 at 2:53 am UTC
One reason we don’t have truly secure systems is that governments are ambivalent about them. Some organizations are willing to accept the problems of weak security in order to do their own penetrations. The possibility of someone, possibly a bad guy, with a computer and communication system which can not be brokered into is a nightmare to professional paranoids everywhere. Ideally they want everyone to have secure systems, which have a back door only the good guys can enter. This is probably impossible.
Eric Drexler 12.06.09 at 7:49 pm UTC
@ Gavin — Yes, perimeters that require a sharp limitation on “external” access certainly deserve special attention, though what should be done will depend on the nature of the non-perimeter security.
At present, we’re in a bizarre situation where an email attachment is, in effect, given authority over your machine equal to your own; this is, historically, a result of the obsolete assumption that any software you run is your chosen tool, serving your purpose. This makes perimeter security brittle.
A modern approach would give executing software access only to the resources that it needs to perform its function. At a fine grain, this can be done through an especially clean implementation of encapsulated objects, with distinct object references to a file (for example) granting read access and write access, etc., to that file. The present system, in effect, grants general access to the file system together with a request to the program that it operate (only) on the file that you designate. This approach is termed “object capabilities”, an idea that has recently been making progress in the world of software engineering.