From 11761b2908716ac77948574913ae44c2bc568a10 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Tue, 26 Aug 2025 14:48:30 -0700 Subject: [PATCH] TCB --- intro.rst | 45 +++++++++++++++++++++++++++++++-------------- principles.rst | 47 ++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 71 insertions(+), 21 deletions(-) diff --git a/intro.rst b/intro.rst index f01b75e..c229edc 100644 --- a/intro.rst +++ b/intro.rst @@ -198,7 +198,7 @@ pioneers are interviewed. `__. 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 diff --git a/principles.rst b/principles.rst index 96da1e5..be3b9b9 100644 --- a/principles.rst +++ b/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