TCB

Author: llpeterson

intro.rst

@@ -198,7 +198,7 @@ pioneers are interviewed.
   <https://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/>`__.
   The Washington Post, May 30, 2015.
 
-1.2 Trust and Threats
+1.2 Threats and Trust
 ----------------------
 
 A discussion of security often begins with an analysis of the *threat
@@ -258,29 +258,46 @@ applicable to system security.
   B. Schneier. Beyond Fear: Thinking Sensibly About Security in an
      Uncertain World. Copernicus Books, 2003.
 
-Finally, it is important to recognize that trust and threats are two
-sides of the same coin. A threat is a potential failure scenario that
-you design your system to avoid, and trust is an assumption you make
-about how external actors and internal components you build upon will
+It is also important to recognize that threats and trust are two sides
+of the same coin. A threat is a potential failure scenario that you
+design your system to avoid, and trust is an assumption you make about
+how external actors and internal components you build upon will
 behave. For example, if you plan to transmit messages over Wi-Fi on an
 open campus, you would likely identify an eavesdropper that can
 intercept messages as a threat (and adopt some of the methods
 discussed in this book as a countermeasure). But if you are planning
 to transmit messages over a fiber link between two machines in a
-locked datacenter, you might trust that channel is secure, and so take
-no additional steps.  Every system makes trust assumptions, even if it
-as simple as trusting the computer you just bought from a reputable
-vendor does not forward your data to an adversary. The key is
-to be as explicit as possible about those assumptions, because they
-may change over time.
-
+locked machine room, you might trust that channel is secure, and so
+take no additional steps. Every system makes trust assumptions. The
+key is to be as explicit as possible about those assumptions, because
+they may change over time.
+
+Taking this thought process a step further, trust assumptions aren't
+always as clear-cut as this strawman suggests. For example, most of us
+implicitly trust that the computer we just bought from a reputable
+vendor does not forward our data to an adversary, but for some use
+cases, the hardware supply chain is a consideration. Buying time on
+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?
+
+We revisit this topic in the next chapter, but given that this book
+focuses on network security, a reasonable starting point is to trust
+the hardware/software on the systems you control, and to assume all
+other systems you interact with are untrustworthy. But this definition
+is problematic in a service-based environment like today's Internet,
+where we end up also putting some amount of trust in the network
+providers we connect to, and the cloud services we depend upon. In
+many respects, identifying a TCB that meets our needs is an important
+part of what makes security so challenging.
 
 
 1.3 Threats to Network Security
 -------------------------------
 
-
-
 .. from the original book chapter - somewhat edited to follow the above text
 
 Computer networks are, as we noted above, invariably a shared

principles.rst

@@ -76,15 +76,48 @@ 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.
 
+.. sidebar:: Picking Your Battles
+
+   *Chapter 1 talked about trust and threats being two sides of the
+   same coin, but another way of thinking about it that every secure
+   system design starts with two lists: (1) those elements you trust,
+   and so can build upon; and (2) those elements you do not trust, and
+   so must treat as a threat that you defend against. But this is no
+   different than for any system you build: you first identify the
+   building blocks you plan to take as a given, and then you design a
+   solution that fills the "gap" between those building blocks and the
+   requirements you are trying to meet.*
+
+   *One way in which security is unique is that over time you may
+   discover that you need to move items from the first list to the
+   second list, as new threats emerge. To reduce this possibility, it
+   is best to keep the first list as minimal as possible. On the other
+   hand, if you choose to trust nothing, you may end up "boiling the
+   ocean" (i.e., having to solve so many problems that you are unable
+   to make any progress). Every system must pick its battles.*
+
+   *Because of our focus on network security, this book effectively
+   starts with a list of trusted elements that includes commodity
+   servers and L2/L3 switches, and ignores (i.e., declares
+   out-of-scope) all the vulnerabilities those elements face and the
+   countermeasures that go into securing them.*
+
 As a consequence of these three main requirements—confidentiality,
 integrity, and availability—additional requirements are placed on the
-underlying systems. Foremost among these the need for a mechanism to
-enforce *access control*, a system component that limits who has
-access to data and what operations they may perform on it. Once we can
-securely identify principals, we must then control what objects they
-can read or write. Access control is clearly a mechanism included in
-end systems, such as laptops and web servers, but it also applies to
-network infrastructure, such as routers and name servers.
+underlying systems we build upon, which brings us back to the idea of
+a Trusted Computing Base (TCB) introduced in Chapter 1. We generally
+have three inter-related requirements for these platforms, beyond
+their not being malicious (which is implied by our including them in
+our TCB).  The first we have already seen: they must provide a local
+(component-specific) notion of *identity*, giving us a way to support
+multiple principals (users). The second is they must provide
+*isolation*, protecting information belonging to one user from other
+users on the system. The third is they must enforce *access control*,
+limiting which users have access to what data, along with what
+operations they are allowed to perform on it. Providing these
+mechanisms gives us the foundation we need to then meet the
+confidentiality, integrity, and availability requirements as we
+communicate over the Internet.
 
 
 2.2 Broader System Requirements