Merge pull request #3 from SystemsApproach/principles

First pass on principles.rst

Author: llpeterson

intro.rst

@@ -358,5 +358,7 @@ from Saltzer and Kaashoek.
 .. admonition:: Further Reading
 
   J. Saltzer and F. Kaashoek. `Principles of Computer System Design: An
-     Introduction. Chapter 11 <https://ocw.mit.edu/courses/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/pages/online-textbook/>`__.
+     Introduction. Chapter 11
+     <https://ocw.mit.edu/courses/res-6-004-principles-of-computer-system-design-an-introduction-spring-2009/pages/online-textbook/>`__. Morgan
+     Kaufmann Publishers, 2009.
 

principles.rst

@@ -169,6 +169,7 @@ secret. The idea is that rather than trying to keep something as large
 and complex as an encryption algorithm secret, it is better for that
 algorithm to be published and only the key(s) be secret. There are two
 reasons for this principle:
+
 * It is hard to keep an algorithm secret, especially if it is in
   widespread use as is the case with encryption on the Internet;
 * Making security mechanisms robust against all forms of attack is, as
@@ -215,7 +216,89 @@ such old ideas as network firewalls and virtual private networks,
 along with more modern approaches such as microsegmentation and
 zero-trust architectures.  We will discuss these developments in a later chapter.
 
-
+2.2.5 Least Common Mechanism
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This principle states that the amount of mechanism that is common to
+more than one user should be minimized. In operating systems, this
+would imply that a piece of mechanism should not be baked into the
+kernel if it could be provided in some other way, e.g., as a
+library. This principle, applied in the context of network security,
+shows up in the end-to-end argument: we avoid putting functions such
+as encryption into the network when the user is likely to need
+end-to-end encryption anyway.
+
+
+2.2.6 Design for Iteration
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Given what we have said about the difficulty of knowing that a system
+is secure, a useful design principle is to accept that we will need to
+iterate, and design for it. A good example of this is in the choice of
+particular cryptographic algorithms for integrity protection or
+encryption. These algorithms are often found to be insufficiently
+strong after some number of years, perhaps due to a weakness in the
+underlying mathematics, or breakthroughs in algorithms, or just the
+steady improvement in computing power that happens over time. Thus,
+any protocol that is developed that depends on such an algorithm
+should be designed such that a change of algorithm is an expected
+behavior. We see this in protocols such as Transport Layer Security
+(TLS) which includes a set of procedures by which two participants
+negotiate the cryptographic algorithms to be used.
+
+Recent developments in quantum computing have raised the issue that
+many existing forms of cryptographic algorithm may need to be
+replaced. While the timeframe in which such a change will be needed
+remains a subject of debate, the safe choice is to accept that
+cryptographic algorithms will periodically need to be replaced.
+
+2.2.7 Audit Trails
+~~~~~~~~~~~~~~~~~~
+
+Part of dealing with the impossibility of covering all possible
+security threats is to accept that sometimes we need to analyze what
+has gone wrong. This leads to the idea that security needs to be
+auditable. For example, it will be easier to conduct a post-mortem of
+a breach involving compromised login credentials if every login
+attempt is logged, along with information such as whether the login
+came over a VPN, what IP address was used, and so on. Similarly it is
+very hard to prevent insider attacks, but suitable logging might both
+make it easier to detect such attacks quickly and to deter those who
+might undertake them.
+
+In a different vein, consider the design of secure protocols. The
+specification for TLS (transport layer security) describes a large
+number of error conditions that may trigger alerts, and recommends the
+logging of all such alerts. Such logging would help in understanding
+if the protocol was subject to an attack that involved incorrect or
+unexpected messages. Given the complexity of negotiations that go on
+in security protocols (to establish cryptographic algorithms and
+parameters, for example) it is wise to assume that these may have
+subtle bugs, and a good set of audit tools will enable any such bugs
+to be detected and then remedied.
+
+Of course, the audit mechanisms themselves must be designed to be
+secure. A determined attacker will, in all likelihood, try to erase their tracks,
+so logging for audit purposes cannot just be an afterthought; it has
+to be part of the design of a secure system.
+
+
+
+
+2.3 Summary
+-----------
+
+
+Just as we can never be quite sure that we have covered all possible
+vectors of attack against a system, there is no hard limit to the set of
+principles that can be applied to developing secure systems. The
+principles covered above include several that were drawn from the
+influential paper by Saltzer and Schroeder from 1975. That is the same
+Saltzer whose book (with Kaashoek) we referred to in Chapter 1. The
+fact that many of the principles from the 1975 paper reappear in the
+2009 is probably a sign that Saltzer had some confidence that these
+principles have stood the test of time. We recommend reading the
+entire paper. 
 
 .. admonition:: Further Reading
 
@@ -226,18 +309,7 @@ zero-trust architectures.  We will discuss these developments in a later chapter
 
 
 
-.. working list of ideas
-safety net
-
-Be Explicit
-
-Design for Iteration
-
-Audit
-
-
 
-economy of mechanism