<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Security --> <!--X-From-R13: X Q Znjerapr <pynjNxnatn.ah> --> <!--X-Date: Mon, 14 Feb 2000 23:42:26 -0800 --> <!--X-Message-Id: 3589.950600541#kanga,nu --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Security</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#kanga,nu"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00321.html">Previous</a> | <a href="msg00324.html">Next</a> ] Thread: [ <a href="msg00350.html">Previous</a> | <a href="msg00310.html">Next</a> ] Index: [ <A HREF="author.html#00322">Author</A> | <A HREF="#00322">Date</A> | <A HREF="thread.html#00322">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Security</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Security</LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#kanga,nu">claw#kanga,nu</A>></LI> <LI><em>Date</em>: Mon, 14 Feb 2000 23:42:21 -0800</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> A wonderfully applicable Bruse Schneir quote: <A HREF="http://slashdot.org/interviews/99/10/29/0832246.shtml">http://slashdot.org/interviews/99/10/29/0832246.shtml</A> Especially given that game worlds and their controls, data structures, and dependencies are inherently complex (whcih tends to leak over into protocol and system complexity): --<cut>-- The real problem with protocols, and the thing that is the hardest to deal with, is all the non-cryptographic dressing around the core protocols. This is where the real insecurities lie. Security's worst enemy is complexity. This might seem an odd statement, especially in the light of the many simple systems that exhibit critical security failures. It is true nonetheless. Simple failures are simple to avoid, and often simple to fix. The problem in these cases is not a lack of knowledge of how to do it right, but a refusal (or inability) to apply this knowledge. Complexity, however, is a different beast; we do not really know how to handle it. Complex systems exhibit more failures as well as more complex failures. These failures are harder to fix because the systems are more complex, and before you know it the system has become unmanageable. Designing any software system is always a matter of weighing and reconciling different requirements: functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. The unspoken requirement is often simplicity. If the system gets too complex, it becomes too difficult and too expensive to make and maintain. Because fulfilling more of the other requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementers can reasonably handle. (Other systems end up with a design that is too complex to handle, and the project fails accordingly.) Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again. Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems. This process of making fairly complex systems and implementing them with a try-and-fix methodology has a devastating effect on security. The central reason is that you cannot easily test for security; security is not a functional aspect of the system. Therefore, security bugs are not detected and fixed during the development process in the same way that functional bugs are. Suppose a reasonable-sized program is developed without any testing at all during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform any of the desired functions correctly. Yet this is exactly what we get from the try-and-fix methodology with respect to security. The only reasonable way to "test" the security of a system is to perform security reviews on it. A security review is a manual process; it is very expensive in terms of time and effort. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure. The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact grow much faster. For the sake of simplicity, let us assume the system has n different options, each with two possible choices. Then, there are about n^2 different pairs of options that could interact in unexpected ways, and 2^n different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several options is huge. We therefore expect that the number of actual security weaknesses grows very rapidly with increasing complexity. The increased number of possible interactions creates more work during the security evaluation. For a system with a moderate number of options, checking all the two-option interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often options that are "orthogonal" in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in the communication system, and the layers are separated by a well-defined interface that does not "show" the options on either side. For this very reason, such a separation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramatically reduce the effective complexity of a system without the need to eliminate important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other. A more complex system loses on all fronts. It contains more weaknesses to start with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation. This increase in the number of security weaknesses interacts destructively with the weakest-link property of security: the security of the overall system is limited by the security of its weakest link. Any single weakness can destroy the security of the entire system. Complexity not only makes it virtually impossible to create a secure system, it also makes the system extremely hard to manage. The people running the actual system typically do not have a thorough understanding of the system and the security issues involved. Configuration options should therefore be kept to a minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously, resulting in a loss of security. There are many stories throughout history that illustrate how management of complex systems is often the weakest link. I repeat: security's worst enemy is complexity. The most serious protocol problem is how to deal with complex protocols (or how to strip them down to the bone). --<cut>-- -- J C Lawrence Home: claw#kanga,nu ----------(*) Other: coder#kanga,nu --=| A man is as sane as he is dangerous to his environment |=-- _______________________________________________ MUD-Dev maillist - MUD-Dev#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00321.html">Re: [MUD-Dev] distributed objects</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00324.html">Re: [MUD-Dev] distributed objects</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00350.html">Re: [MUD-DEV] a shrinking pool of players?</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00310.html">Re: [MUD-Dev] code base inquiry</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00322"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00322"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><strong><A NAME="00344" HREF="msg00344.html">commercial muds and cable TV (was RE: [MUD-Dev] code base inquiry)</A></strong>, Sellers, Michael <a href="mailto:MSellers#maxis,com">MSellers#maxis,com</a>, Wed 16 Feb 2000, 00:02 GMT <UL> <LI><strong><A NAME="00348" HREF="msg00348.html">Re: commercial muds and cable TV (was RE: [MUD-Dev] code base inquiry)</A></strong>, Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Wed 16 Feb 2000, 01:05 GMT </LI> <LI><strong><A NAME="00349" HREF="msg00349.html">[MUD-DEV] a shrinking pool of players?</A></strong>, Johan J Ingles-le Nobel <a href="mailto:xvf61#dial,pipex.com">xvf61#dial,pipex.com</a>, Wed 16 Feb 2000, 01:25 GMT <UL> <LI><strong><A NAME="00350" HREF="msg00350.html">Re: [MUD-DEV] a shrinking pool of players?</A></strong>, Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Wed 16 Feb 2000, 01:50 GMT </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00322" HREF="msg00322.html">[MUD-Dev] Security</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Tue 15 Feb 2000, 07:42 GMT <LI><strong><A NAME="00310" HREF="msg00310.html">Re: [MUD-Dev] code base inquiry</A></strong>, Colin Coghill <a href="mailto:C.Coghill#auckland,ac.nz">C.Coghill#auckland,ac.nz</a>, Mon 14 Feb 2000, 20:44 GMT <UL> <LI><strong><A NAME="00326" HREF="msg00326.html">Re: [MUD-Dev] code base inquiry</A></strong>, Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Tue 15 Feb 2000, 19:57 GMT <UL> <LI><strong><A NAME="00329" HREF="msg00329.html">Re: [MUD-Dev] code base inquiry</A></strong>, Richard Woolcock <a href="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</a>, Tue 15 Feb 2000, 20:59 GMT <UL> <LI><strong><A NAME="00334" HREF="msg00334.html">Re: [MUD-Dev] code base inquiry</A></strong>, Miroslav Silovic <a href="mailto:silovic#zesoi,fer.hr">silovic#zesoi,fer.hr</a>, Tue 15 Feb 2000, 21:44 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>