further work on general principles

Author: drbruced12

principles.rst

@@ -39,23 +39,24 @@ An equally important requirement in many cases is
 was sent by the entity that claimed to have sent it. In the example of
 e-commerce, this is what allows us to know we are connected to, say,
 the website of the vendor we wish to patronize and not handing over
-our credit card to some imposter.
+our credit card to some impostor.
 
-Closely related to authentication is *integrity*. It is not only important that
+Closely related to authentication is *integrity*. It is important not only that
 we know who we are talking to, but that we can verify
 that the data sent across our connection has not been modified by some
 adversary in transit.
 
-The preceding requirements also suggest a fourth: *identity*. That is,
-we need a system by which the entities involved in communication,
-often called *principals*, can be securely identified. As we will
-discuss later,
-this problem is harder to solve than it might first appear. How can we
-know that a website we are communicating with actually represents the
-business with whom we wish to communicate?
+The preceding requirements also suggest that we must have a concept of
+*identity*. That is, we need a system by which the entities involved
+in communication, often called *principals*, can be securely
+identified. As we will discuss later, this problem is harder to solve
+than it might first appear. How can we know that a website we are
+communicating with actually represents the business with whom we wish
+to communicate? Or how does a banking system know that the person
+behind a particular request is actually the account holder?
 
 Just as we are concerned that an adversary might access our data in
-transit to eavesdrop on or modifiy it, we also need to be concened
+transit to eavesdrop on or modify it, we also need to be concerned
 about *replay attacks* in which data is captured and then
 retransmitted at some later time. For example, we would want to
 protect against an attack in which an item added to a shopping cart
@@ -73,7 +74,7 @@ them can be protected against *denial-of-service* (DoS) attacks. The
 Morris Worm was an early example of an unintentional DoS attack: as
 the worm spread to more and more computers, and reinfected computers
 on which it was already present, the resources consumed by the worm
-rendered those computers unable to function. Networks provide a meands
+rendered those computers unable to function. Networks provide a means
 by which data can be amplified by replication, allowing large volumes
 of traffic to be sent to the target of a DoS attack; thus it has
 become necessary to develop means to mitigate such attacks.
@@ -88,25 +89,155 @@ system remains secure. We will outline some of the most well-known
 principles here and the following chapters contain examples of how
 those principles have been applied in practice.
 
+2.2.1 Defense in Depth
+~~~~~~~~~~~~~~~~~~~~~~
+As we have noted, one of the central challenges in security is that we
+never know if we have done enough. Much as we try to defend against
+all possible attacks, there is no way to be sure that we've thought of
+everything. This is what we mean by saying that security is a negative
+goal: we aim to be sure that a set of things cannot happen, but we can
+never quite be sure that all vulnerabilities have been found and
+mitigated. This leads to the idea of *defense in depth*: layer upon
+layer of defense, so that even if one layer is penetrated, the next
+layer is unlikely to be. Only by getting through all the layers of
+defense will an attacker be able to achieve their goal (of stealing
+our data, for example). The hope is that with enough layers of
+defense, the odds of an attacker penetrating all of them becomes
+vanishingly small.
+
+As a simple example, a corporation might make use of a VPN (virtual
+private network) to ensure that only authorized users can access
+corporate servers, and that when they do so over the Internet, their
+traffic is encrypted. However, this single layer of defense is prone
+to several forms of attack, such as the presence of malware on the
+remote user's computer, or compromise of the remote user's
+credentials. Thus, additional layers of defense are needed, such as
+internal firewalls between different corporate systems; tools to
+detect, remediate, and prevent malware on the remote users' systems;
+and multi-factor authentication to protect against compromised user
+credentials. This is just a short list of defensive measures that are
+commonly used, and would not on their own be considered
+sufficient. But the point to note here is the use of many overlapping
+layers of defense to raise the bar high enough to thwart the majority
+of attacks.
+
+The fact that we read about breaches in which attackers succeed in
+gaining access to corporate systems and data on a regular basis might
+suggest that the battle is being lost. Certainly the challenges in
+defeating determined attackers are substantial. However, it is surprising how
+frequently it turns out that a well-publicized attack has succeeded
+because some relatively common defensive measure, such as multi-factor
+authentication, was not put in place correctly.
+
+2.2.2 Principle of Least Privilege
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The principle of least privilege has a long history in computer
+science, having been proposed by Saltzer and Schroeder in 1975. The
+principle states:
+
+  "Every program and every user of the system should operate using the
+  least set of privileges necessary to complete the job."
+
+A common example of this principle in practice is to avoid running
+anything as root on Unix-like systems unless absolutely necessary.
+
+In the context of networking, this principle implies that applications
+which access the network should only have access to the set of
+resources needed to do their jobs.
+
+.. feel like there is more detail to provide here.
+
+Interestingly, Saltzer and Schroeder explicitly mention "firewalls" in
+the section of their paper on least privilege, using the analogy from
+the physical world (a wall to prevent the spread of fire) before the
+concept of network firewalls had been invented. As we will discuss
+later, it turns out that the widespread use of network firewalls for
+most of their history *failed* to follow the principle of least
+privilege, in that it is common to find large "zones" of a network
+where all machines have access to each other, even though this access
+is not actually required for the machines to do their jobs. Addressing
+this shortcoming required some innovations in the design of firewalls
+that arrived only in the last decade or so.
+
+2.2.3 Open Design
+~~~~~~~~~~~~~~~~~
+
+Another principle codified by Saltzer and Schroeder is that of open
+design. It states that the mechanisms and
+algorithms that are used to implement security should be open, not
+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
+  we have discussed, difficult. Thus it is better to have wide
+  scrutiny of these mechanisms to expose weaknesses that may then be
+  rectified.
+
+The history of computer security is filled with cautionary tales
+related to this principle. In the cases where the principle is
+followed, subtle bugs in protocol design or implementation have been
+exposed and patches rolled out to mitigate them. Heartbleed, a bug in
+the widely used open source implementation of SSL, is a famous
+example. The consequences of the bug were serious, with as many as
+half a million Web servers being impacted, but it was a positive thing
+that the bug was found, reported, and remediated quickly.
+
+If this principle is not followed, a design that is believed to be
+secret may in fact have been compromised (e.g. by reverse
+engineering), or may have flaws that have gone unreported but are
+nevertheless being exploited.
+
+Another way to state this principle is "minimize secrets".  For
+example, rather than trying to keep an entire algorithm secret, only
+keep secret the key that is used to decrypt with the algorithm. It is
+much easier to replace a key that has been compromised than to replace
+an entire algorithm.
+
+2.2.4 Fail-safe defaults
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The idea behind this principle is the default settings of a system are
+the ones most likely to be used, so by default, undesired access
+should be disabled. It then takes an explicit action to enable
+access. This is a principle that dates back at least to 1965 according to
+the Saltzer and Schroeder paper. 
+
+It turns out that the design of the Internet really doesn't follow
+this approach. The datagram delivery model of the Internet, by
+default, allows packets from anywhere to be sent anywhere. So to the
+extent that sending a packet to a system can be defined as accessing
+the system, the Internet's default behavior does not provide fail-safe
+defaults. Efforts to revert to a more secure default behavior include
+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.
+
+
+
+.. admonition:: Further Reading
+
+  Jerome Saltzer and Michael Schroeder. `The Protection of Information
+  in Computer Systems
+  <http://web.mit.edu/Saltzer/www/publications/protection/index.html>`__. In
+  Proceedings of the IEEE, 1975.
+
 
-.. working list of ideas
-   
-Least Privilege
 
-Defense in Depth/safety net
+.. working list of ideas
+safety net
 
 Be Explicit
 
 Design for Iteration
 
 Audit
 
-Open Design
 
-Minimize secrets
 
 economy of mechanism
 
-fail-safe defaults