typos

Author: drbruced12

infra.rst

@@ -1078,7 +1078,7 @@ anomalous behavior, but individual servers can also limit the impact
 by encoding connection state in the sequence number included in the
 SYN+ACK they send back to the client—a "SYN cookie" of sorts—and then
 allocate connection state locally only after the client goes to the
-trouble of correctly ACK'ing that packet. This is a variant of the
+trouble of correctly ACKing that packet. This is a variant of the
 first countermeasure in that it forces the attacker to use additional
 resources.
 

intro.rst

@@ -203,7 +203,7 @@ pioneers are interviewed.
 
 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
+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
@@ -281,8 +281,8 @@ virtual machines in a cloud only complicates this decision. Even when
 you trust the hardware, you might or might not trust the firmware or
 the OS (or you might trust it only when certain security enhancements
 are enabled). This illustrates a common design question that every
-system must face: What do you accept to be the *Trusted Computing Base
-(TCB)*; that is, what hardware and software components do you trust?
+system must face: what do you accept to be the *Trusted Computing Base
+(TCB)*? That is, what hardware and software components do you trust?
 
 We revisit this topic in the next chapter, but given that this book
 focuses on network security, a reasonable starting point is to trust

preface.rst

@@ -41,7 +41,7 @@ opportunity to write about security in a way that would make sense to
 a networking person. Also, we wanted to take more of a systems
 approach to the topic. While we always try to take a system-level view
 in everything we write, it's easy with security to get bogged down in
-the details of individual components such as cryptographic algorithms
+the details of individual components, such as cryptographic algorithms,
 without really tackling the systems issues. Cryptography is cool and
 interesting (in our view at least) but it isn't really the main thing
 to focus on if you are building secure systems. So while we do explain

principles.rst

@@ -157,7 +157,7 @@ or we'd simply secure a system by denying access to all users.
 
 For our purposes, the main takeaway is that security is unique in that
 it is not just a requirement *for* a system, but it is often best
-viewed as a system in an of itself, one that must be usable,
+viewed as a system in and of itself, one that must be usable,
 scalable, manageable, evolvable, observable, available, reliable, and
 so on.
 
@@ -174,19 +174,20 @@ those principles are applied in practice.
 
 2.3.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.
+layer of defense, so that even if one layer is penetrated, there are
+multiple layers of defense still in place. 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
@@ -227,7 +228,10 @@ 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.
+resources needed to do their jobs. The concept of zero trust, which
+has started to gain popularity as an approach to network security in recent years,
+follows closely the idea of least privilege. We return to this topic
+in a later chapter. 
 
 .. feel like there is more detail to provide here.
 
@@ -298,7 +302,7 @@ 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.
+zero trust architectures.  We will discuss these developments in a later chapter.
 
 2.3.5 Least Common Mechanism
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~