---------- Forwarded message ---------- Date: Sat, 26 Jan 2002 18:49:55 -0800 From: Bill Frantz <frantzat_private> To: R. A. Hettinga <rahettingaat_private>, cryptographyat_private Subject: Re: [ISN] What Billg's new security effort will cost A serious attempt to address the many security flaws in current systems will result in major changes to Microsoft software or its culture. Microsoft has always been a features oriented company. In the early days, this orientation served the company well. Microsoft achieved its early successes by selling software to the corporate market. This market is characterized by a desire to have company wide standard software packages to minimize support costs, and maximize the ability to transfer information. When a company was deciding which package is to be anointed the corporate standard, one of the measures used was a feature comparison chart. The chart was used to ensure the chosen package has the features needed by all the users in the company. Unfortunately, in general the people who selected the package did not know which features would be required in obscure corners of their company. As a result, they tended to pick the package with the most features. Being the "firstest with the mostest" provider established Microsoft products such as Windows, Word, and Excel in the corporate market. When people purchased computers for their homes, they tended to buy what they knew from work, and these packages then migrated to the home. Now Microsoft is attempting to make security a new feature of their software. However, security is different from all the other features they have implemented. It is not about what you can do, which can be implemented and demonstrated, but about what you can't do, which is usually the absence of implementation, and ducedly hard to demonstrate. It is not about showing there is a path to achieve a result, but about showing that no such path exists. One of the things that makes security assurance much harder is having a complex set of features, which interact to effect the security of the system. There are many more possible paths, and much more code where a flaw can bring the whole system down. Microsoft can chose to simplify by removing features, which will require a tidal shift in their culture, or they can make drastic changes in their implementation strategy in an attempt to maintain their feature set. My bet is they try to maintain their feature set. The first step is to attack the easy problems. Bruce Schneier and Adam Shostack, in their paper, "Results, Not Resolution, A guide to judging Microsoft's security progress" came up with an excellent list of areas to address first. Presumably Microsoft will also address the simple coding problems, like buffer overruns, with improved languages or development procedures. Even with these changes, they will still have a system where a bug in one feature can still break the security of the entire system. To maintain its feature set, and have a reasonable degree of security, Microsoft will have to adopt architectures where bugs in most of the features can not effect security. These architectures will need much smaller and more flexible security compartments than systems such as Windows and Unix provide. These compartments need to isolate the privileges given to feature implementations from those given to the users and those given to other parts of the application system. This kind of compartment supports the principle of least privilege, which is the best path to limit the effect of bugs. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. frantzat_private | fair use. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomoat_private - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Mon Jan 28 2002 - 04:07:47 PST