|
| 1 | +Preface |
| 2 | +======== |
| 3 | + |
| 4 | +The field of network security is roughly as old as networking |
| 5 | +itself. Conventional wisdom is that the original Internet was built |
| 6 | +without security features and we have been dealing with the effects of |
| 7 | +those design decisions ever since. And it is not that the Internet's |
| 8 | +designers, implementers and architects were unaware of security |
| 9 | +concerns; many of them were directly involved in developing security |
| 10 | +technologies in early operating systems. But building a |
| 11 | +high-performance network that could scale to global proportions and |
| 12 | +accommodate the heterogeneous set of technologies that existed (and |
| 13 | +those still to come) presented more than enough challenges. To quote |
| 14 | +Internet pioneer Vint Cerf: *"getting this thing to work at all was |
| 15 | +non-trivial.”* |
| 16 | + |
| 17 | +Adding security capabilities to the Internet and the systems connected |
| 18 | +to it has been a multi-decade effort. While there have been some |
| 19 | +notable successes, such as widespread adoption of Transport Layer |
| 20 | +Security (TLS), vulnerabilities continue to be found and exploited. In |
| 21 | +part this is because security is a "negative goal": we are always |
| 22 | +trying to ensure that there are no more cracks in our defenses, and it |
| 23 | +is fundamentally impossible to prove that we are "done". So security |
| 24 | +continues to evolve as new weaknesses are exploited and new mechanisms |
| 25 | +deployed to prevent further exploits. |
| 26 | + |
| 27 | +We have been educating ourselves about network security since we wrote |
| 28 | +the first edition of *Computer Networks: A Systems Approach* |
| 29 | +in 1995. There is an adage in security circles that no-one should |
| 30 | +write their own cryptography code because it is so hard to get right, |
| 31 | +and something similar might be said about trying to write a security |
| 32 | +book. It is very easy to make mistakes, especially if you are not |
| 33 | +deeply immersed in the security world and the "look for every possible |
| 34 | +weakness" mentality. We've had to make a few corrections over the |
| 35 | +years to our security section in the big textbook. |
| 36 | + |
| 37 | +So why did we decide to write the current book? First, we saw an |
| 38 | +opportunity to write about security in a way that would make sense to |
| 39 | +a networking person. Also, we saw an opportunity to take more of a |
| 40 | +systems approach to the topic. While we always try to |
| 41 | +take a system-level view in everything we write, it's easy with |
| 42 | +security to get bogged down in the details of individual components |
| 43 | +such as cryptographic algorithms without really tackling the systems |
| 44 | +issues. Cryptography is cool and interesting (in our view at least) but |
| 45 | +it isn't really the main thing to focus on if you are building secure |
| 46 | +systems. So while we do explain the basics of cryptography here, it's |
| 47 | +not the focus. We're aiming to explain how a system that comprises |
| 48 | +many moving parts, both in the network and the end-system, can be made |
| 49 | +secure. |
| 50 | + |
| 51 | +This question of focus caused us to examine how much we wanted to say |
| 52 | +about end-system security. There are entire books to be written on |
| 53 | +operating system security, processor architecture bugs such as spectre |
| 54 | +and meltdown, and preventing malware on end-systems. We made a |
| 55 | +conscious decision to draw a line around the network and focus there, |
| 56 | +recognizing that, just as TCP is an important network protocol that |
| 57 | +runs in end-systems, protocols like HTTPS and TLS need to be covered |
| 58 | +in a book on network security. In fact TLS provides an excellent case |
| 59 | +study in the system-level issues that come into play when you try to |
| 60 | +secure traffic that flows between end-systems over the Internet, and |
| 61 | +we devote an entire chapter to it. |
| 62 | + |
| 63 | +With the never-ending set of threats and vulnerabilities that need to |
| 64 | +be dealt with, it is all too easy to start thinking of security as |
| 65 | +just a collection of point solutions to the problems that have been |
| 66 | +identified so far. But in fact there is a well-established set of |
| 67 | +principles that have been identified and written down by pioneers in |
| 68 | +the field, such as the principle of least privilege, defense in depth, |
| 69 | +and so on. We have dedicated a chapter to exploring some of the most |
| 70 | +widely accepted principles, and then we see them applied repeatedly |
| 71 | +throughout the book. Perimeter firewalls, for example, can be a part of a defense |
| 72 | +in depth strategy, while *distributed* firewalls have been proposed |
| 73 | +as a way to apply least privilege to datacenter networks. |
| 74 | + |
| 75 | +Inevitably there are security technologies and types of attack that we |
| 76 | +have not covered in this book. What we have tried to do is to give the |
| 77 | +reader a sense of the principles at work and the building blocks that |
| 78 | +exist to build secure systems, and then illustrate how the blocks can |
| 79 | +be assembled to tackle particular problems ranging from securing Web |
| 80 | +traffic to securing the routing system that underpins the |
| 81 | +Internet. Security is a never-ending set of challenges and there will |
| 82 | +always be new threats and solutions. This book aims to lay the |
| 83 | +foundation so you can understand the network security landscape as it |
| 84 | +continues to evolve. |
| 85 | + |
| 86 | + |
| 87 | + |
| 88 | +Acknowledgements |
| 89 | +---------------- |
| 90 | + |
| 91 | +Brad Karp |
| 92 | +Cecilia Testart |
| 93 | +Motonori Shindo |
| 94 | +Nick Feamster |
0 commit comments