* Noah Meyerhans: > On Wed, Nov 23, 2005 at 12:59:02PM +0100, Florian Weimer wrote: >> Availability is typically considered one aspect of security (and >> arguably the hardest one to get right in networked applications). > > I tend to consider it the other way around. Security is a subset of > availability.
A loss of confidentiality or integrity does not mean you can't use that particular service anymore. This backed by industry practice: potentially compromised systems are taken off the network for detailed analysis only if they aren't too important. 8-/ > Because security is one aspect of availability, I must account for > it when designing and maintaining systems, but it can't be the > ultimate goal, since a truly secure system provides no availability. Well, it's pointless to argue about definitions. But the C/I/A definition of security is consistent with that as well: since availability is part of the goal, you cannot sacrifice it in favor of confidentiality and integrity in a secure system. But of course, your observation is correct that security in the service provider business is mostly measured in terms of availability. That's why those probabilistic "make C safer" approaches (non-executable stack etc.) aren't very effective in the end. A compromise might be worse than a crash, but a potential compromise and a potential remotely triggered DoS condition are similar in severity. (Security of end user systems seems to be very, very different, though.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]