<< Previous <<         [Session1 Index]            >> Next >>

Having read this far, we hope that a couple of things about security are fairly clear. Certain misunderstandings about security are invariably made by those who come into the security topic without prior knowledge. First, the naive analyst thinks of perimeter security, the Impenetrable Shield, and concludes that this is the whole security topic.

After realizing that there is more to security than just the perimeter, and seeing that he must support security even while permitting diverse interactions among programs, he leaps to the misunderstanding that he can assert full control using access control lists (ACLs). This is usually the last strategic mistake the developer ever gets to make: having committed to a flawed model of security, he finds himself relentlessly hounded by the need to patch, patch, and patch again, every time increasing his sunk cost in a losing strategy. We are all bearing witness to this decision process each time we read about another security flaw found in a popular Internet product, from any of the big software vendors, virtually all of whom have fallen into this trap.

Even in the presence of vast dissatisfaction with the results of ACL, only with great understanding can the developer make the further leap to capability-based security, to achieve the most flexible, clean, reliable form of security known today.

Capability based security can be implemented in the operating system, in the programming language, with cryptography, or with hardware. The EC security system uses a combination of the language and cryptography.