start on chapter 2

Author: drbruced12

index.rst

@@ -19,7 +19,7 @@ The Authors
    :glob:
 
    intro.rst
-   trust.rst
+   principles.rst
    crypto.rst
    key-distro.rst
    authentication.rst

intro.rst

@@ -38,14 +38,16 @@ to log in to a remote computer, you would (usually) need to authenticate
 yourself to that remote system (e.g., with a user name and password) before
 gaining access to any resources on that system.
 
-Ensuring the security of end systems does not come close to addressing the entire set of
-security issues that exist in a computer network. For example, an
-attacker with access to a link, switch or router somewhere in the network
-has the potential to read or modify packets passing
-through that point. Furthermore, by
-connecting computers to a global network, the opportunity to exploit
-vulnerabilities in the code running on those end systems is opened up
-to a much greater---potentially global---set of actors.
+Ensuring the security of end systems, while important, does not come
+close to addressing the entire set of security issues that exist in a
+computer network. For example, an attacker with access to a link,
+switch or router somewhere in the network has the potential to read or
+modify packets passing through that point. Furthermore, failures of
+end system security are exposed when we connect them to networks. By
+connecting computers to a global network such as the Internet, the
+opportunity to exploit vulnerabilities in the code running on those
+end systems is opened up to a much greater---potentially global---set
+of actors.
 
 Thus we can think of network security as having two main
 thrusts. First, we need to address the security challenges of a
@@ -54,8 +56,9 @@ challenges of connecting end systems, which run imperfect software, to
 a global set of actors, some of whom are bound to be malicious.
 
 For an interesting retrospective view on system security, and some
-commentary on how far we still have to go, we recommend
-the paper on Multics from Karger and Schell.
+commentary on how far we still have to go, we recommend the paper
+looking back on the history of security in Multics from Karger and
+Schell.
 
 .. admonition:: Further Reading
 
@@ -70,14 +73,15 @@ highlight the breadth of the challenges included in the term "network
 security". The Morris worm was the first large-scale attack on the
 Internet, launched in 1988 when the Internet was largely limited to
 universities and research institutions. While it was made possible by
-the fact that the Internet of that era generally allowed packets from any source
-to any destination, it was also dependent on a number of
+the fact that the Internet of that era generally allowed packets from
+any source to any destination, it was also dependent on a number of
 vulnerabilities in the software running on the end systems connected
 to the Internet. Like many future attacks, the Morris worm exploited
-multiple vulnerabilities, including weak or default passwords, a buffer
-overflow bug in a then widely-used software tool, and a security hole in
-the sendmail program. There is a comprehensive analysis of the worm's
-operation in the report from Donn Seeley written soon afterwards.
+multiple vulnerabilities. In this case they included weak or default
+passwords, a buffer overflow bug in a then widely-used software tool,
+and a security hole in the sendmail program. There is a comprehensive
+analysis of the worm's operation in the report from Donn Seeley
+written soon afterwards.
 
 .. admonition:: Further Reading
 
@@ -92,8 +96,8 @@ approach requires us to look at the entire system: the network
 components and the end systems connected by the network, both hardware
 and software. 
 
-A Short History of Internet Security
-------------------------------------
+1.1 A Short History of Internet Security
+----------------------------------------
 
 The Internet architecture was initially created with essentially no
 security features. This was not because the inventors, implementors and
@@ -120,10 +124,11 @@ The Morris Worm served as something of a wake-up call to the early
 developers of the Internet by highlighting just how vulnerable it
 was. By the early 1990s the first firewalls had appeared, allowing the
 default "accept any packet from anywhere" behavior of the Internet to
-be changed. These devices filtered packets based on information in the
-TCP and IP headers, and could be implemented in both hosts and
-routers. By 1994 they were common enough that applications such as FTP
-(the file transfer protocol) adapted to work with them.
+be changed in a controlled way. These devices, which remain common
+today, filter packets based on information in the TCP and IP headers,
+and can be implemented in both hosts and routers. By 1994 they were
+common enough that applications such as FTP (the file transfer
+protocol) were adapted to work with them.
 
 Also in the early 1990s, the Internet was growing quickly enough to make it clear
 that IP version 4 (IPv4), with 32-bit addresses, would eventually run
@@ -162,10 +167,10 @@ at the transport layer.
 Another aspect of securing the Internet that started to receive
 attention in this period was the security of its infrastructure. One
 such piece of infrastructure is the domain name system (DNS). DNS
-replaced static host-to-address mapping files in the 1980s and subsequently
+replaced static hostname-to-address mapping files in the 1980s and subsequently
 become critical to the operation of the Internet. Clearly the
 information served up by DNS needs to be robust against manipulation
-by adversaries, and hence there has been an multi-decade effort to add
+by adversaries, and hence there has been a multi-decade effort to add
 security to the DNS. The fact that this continues to roll on
 illustrates some of the challenges in making incremental updates to
 the distributed infrastructure of the Internet.
@@ -182,7 +187,8 @@ This is by no means a complete history of Internet security but it
 gives some sense of the scope of the problems faced. Some further
 perspective on this history, and the factors that contributed to
 Internet's lack of security, can be found in the following series
-of articles from the Washington Post.
+of articles from the Washington Post, in which many of the Internet's
+pioneers are interviewed.
 
 
 .. admonition:: Further Reading
@@ -191,16 +197,21 @@ of articles from the Washington Post.
   <https://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/>`__.
   The Washington Post, May 30, 2015. 
 
-Trust and Threats
------------------
+1.2 Trust and Threats
+----------------------
 
 A discussion of security often begins with an analysis of the *threat
 landscape*. That is, what are the threats that our system is likely to
 be exposed to and which we hope to mitigate. This is one of the great
 challenges in developing a security strategy: how do we know when we
 have identified all the likely threats? Some may be obvious, such as
 eavesdropping on unencrypted traffic sent over a shared medium, but
-less obvious threats are constantly being identified.
+less obvious threats are constantly being identified. Furthermore,
+there are different *threat actors* with different motivations,
+ranging from those who enjoy the technical challenge of finding
+vulnerabilities, to criminals looking to obtain valuable information
+such as credit card details, to government actors looking to perform
+surveillence or interfere in elections.
 
 It is common to talk about security as a "negative goal". That is, we
 are trying to ensure that a set of undesirable things cannot
@@ -247,14 +258,14 @@ applicable to system security.
      Uncertain World. Copernicus Books, 2003.
 
 
-Threats to Network Security
-----------------------------
+1.3 Threats to Network Security
+-------------------------------
 
 
 
 .. from the original book chapter - somewhat edited to follow the above text
 
-Computer networks are, like multi-user computers, invariably a shared
+Computer networks are, as we noted above, invariably a shared
 resource. They are used by many applications representing different
 interests. The Internet is particularly widely shared, being used by
 competing businesses, mutually antagonistic governments, and
@@ -292,8 +303,8 @@ encrypt all messages such that even if an adversary has access to the
 data, they are unable to *understand* the message contents. A protocol that does
 so is said to provide *confidentiality*. Taking the concept a step
 farther, concealing the quantity and destination of communication is
-called *traffic confidentiality* — because merely knowing how much
-traffic is going where can be useful to an adversary in some
+called *traffic confidentiality*---because merely knowing where
+traffic is going, and how much, can be useful to an adversary in some
 situations.
 
 Confidentiality alone is not sufficient. An adversary who can’t read
@@ -305,7 +316,7 @@ detects such message tampering is said to provide
 *integrity*. Similarly, an attacker might capture a message and
 send it again at another time, which might cause a duplicate purchase,
 for example. This is called a *replay attack* and prevention of such
-attacks is a common feature of security protocols.
+attacks is a common requirement of security protocols.
 
 Another threat to the customer is unknowingly being directed to a
 false website. This can result from a Domain Name System (DNS) attack,

principles.rst

@@ -0,0 +1,112 @@
+Chapter 2. Design Principles
+============================
+
+In the preceding chapter we looked at some reasons why network
+security is a never-ending challenge. As security is a negative goal, we can never
+be sure that we have foreseen and prevented every possible
+threat. Nevertheless, there are a number of general principles that
+have been developed over the decades that we can apply to improve the
+overall security of our networks and systems. We will discuss these in
+this chapter and see them in action in subsequent chapters.
+
+In order to take a systematic approach to security it helps to have a
+clear view of our requirements. Once we have defined those we can consider the
+principles that can be applied to help us meet them.
+
+2.1 Requirements
+--------------------
+
+The first requirement that comes to mind when thinking about sending
+data across a shared network is likely to be *confidentiality*. As
+noted in Chapter 1, there are many ways that an adversary might gain
+access to data in transit through a network. Confidentiality is the
+ability to prevent data from being read by anyone other than its
+intended recipient. This, for example, is what is required to prevent
+your credit card details being exposed when you enter then on a
+website.
+
+Related to the confidentiality of data is *traffic
+confidentiality*. This is the idea that we don't want an adversary to
+be able to determine where or to whom we are sending traffic, or in
+what quantity. This presents some distinct challenges from data
+confidentiality; there is no need for network devices to see our data,
+but they generally must look at packet headers, which contain
+destination information, to determine where to
+send traffic.  
+
+An equally important requirement in many cases is
+*authentication*. This is the ability to verify that an item of data
+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.
+
+Closely related to authentication is *integrity*. It is not only important 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?
+
+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
+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
+was repeatedly added again by an attacker. Thus it is a common
+requirement to have some form of *replay prevention*.
+
+A common requirement in computer system security is *access control*:
+the ability to limit who has access to a system and what operations
+they may perform on it. This applies not only to end systems but to
+network devices such as routers and infrastructure components such
+as name servers.
+
+Finally, it is important that networks and the systems attached to
+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
+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.
+
+2.2 Principles for Secure Systems
+---------------------------------
+
+Given how long people have been trying to build secure computing
+systems, including networked systems, there has been plenty of
+time to develop some principles that improve the chances that the
+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.
+
+
+.. working list of ideas
+   
+Least Privilege
+
+Defense in Depth/safety net
+
+Be Explicit
+
+Design for Iteration
+
+Audit
+
+Open Design
+
+Minimize secrets
+
+economy of mechanism
+
+fail-safe defaults
+
+