Mark Stamp - Information Security

June 2021

I've been active in information security since dinosaurs roamed the earth, computing‐wise. My real‐world experience includes more than seven years at the National Security Agency followed by two years at a Silicon Valley startup company. While I can't say too much about my work at NSA, I can tell you that my job title was Cryptologic Mathematician. In industry I helped design and develop a digital rights management security product. This real‐world experience was sandwiched between academic jobs. While in academia, my research has dealt with a wide variety of security‐related topics, frequently including various aspects of machine learning and deep learning.

When I returned to academia in the early years of this century, there were few security books available, and none seemed to have much connection with the real world. I felt that I could write a textbook that would fill this gap, and that the resulting book could serve a dual purpose as both a textbook and a useful resource for working IT professionals. Based on the feedback I've received, the first two editions seem to have been reasonably successful in both aspects.

I believe that this third edition will prove even more valuable in its dual role as a textbook and as a resource for working professionals, but, of course, I'm biased. I can say that many of my former students who are now at leading Silicon Valley technology companies (some having started their own such companies) tell me that the material they learned in my courses has been useful to them. And I certainly wish that a book like this had been available when I worked in industry, since my colleagues and I would have benefitted greatly from it.

I do have a life outside of information security. 1 My family includes my lovely wife, Melody, and two excellent sons, Austin (whose initials are AES), and Miles (whose initials are not DES, thanks to Melody). We enjoy the outdoors, with regular local hiking trips, among many other activities. I spend much of my free time kayak fishing and sailing in the Monterey Bay, or working on my perpetual fixer‐upper house in the wildfire‐and‐earthquake prone Santa Cruz mountains.

1 1Well, sort of.

My work in information security began when I was in graduate school. First and foremost, I want to thank my thesis advisor, Clyde F. Martin, for introducing me to this fascinating subject.

In my seven‐plus years at NSA, I learned more about security than I could have learned in a lifetime anywhere else. From my time in industry, I want to thank Joe Pasqua and Paul Clarke for giving me the opportunity to work on a fascinating and challenging project.

For the first edition, Richard Low, a colleague here at SJSU, provided helpful feedback on an early version of the manuscript. David Blockus (God rest his soul) deserves special mention for providing detailed comments on each chapter at a particularly critical juncture in the writing of that first edition.

For the second edition, many of my SJSU students “volunteered” to serve as proofreaders, and many other people provided helpful comments and suggestions. Here, I would like to call out John Trono (Saint Michael's College) for his many detailed comments and questions.

For this third edition, students too numerous to list have made positive contributions to virtually every aspect of the book. But, I would like to single out Vanessa Gaeke and Sravani Yajamanam for special thanks. Both of these outstanding students carefully read the manuscript and asked thoughtful and thought‐provoking questions that significantly improved the book that you see before you.

Like any big software project, no amount of debugging will uncover all bugs in a book of this size and scope. Any remaining flaws are, of course, your humble author's responsibility alone.

“Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.”

—Lewis Carroll, Alice in Wonderland

Following tradition, Alice and Bob, are the good guys. Alice and Bob, who are pictured in Figure 1.1(a) and (b), respectively, generally try to do the right thing. Occasionally, we'll require an additional good guy or two, such as Charlie or Dave. A recurring theme of this book is that stick people often make dumb mistakes, just like real people.

Figure 1.1 The main actors

Trudy, pictured in Figure 1.1(c), is our generic bad guy who is trying to attack the system in some way. Some authors employ a team of bad guys where the name implies the particular nefarious activity. In such usage, Trudy is an “intruder,” Eve is an “eavesdropper,” and so on. To simplify things, we'll let Trudy be our all‐purpose bad guy, although Eve might make a brief cameo appearance. Just like the bad guys in classic Hollywood Westerns, our bad guys always wear a black hat.

Alice, Bob, Trudy, and the rest of the gang need not be humans. For example, one of many possible permutations would have Alice as a laptop, Bob a server, and Trudy a human.

Suppose that Alice starts an online banking business, appropriately named Alice's Online Bank, 1 or AOB. What are Alice's information security concerns? If Bob is Alice's customer, what are his information security concerns? Are Bob's concerns the same as Alice's? If we look at AOB from Trudy's perspective, what security vulnerabilities might we see?

First, let's consider the traditional triumvirate of confidentiality, integrity, and availability, or CIA, 2 in the context of Alice's Bank. Then we'll point out some of the many other possible security concerns.

Confidentiality deals with preventing unauthorized reading of information. AOB probably wouldn't care much about the confidentiality of the information it deals with, except for the fact that its customers certainly do. For example, Bob doesn't want Trudy to know how much money he has in his savings account. Alice's Bank would also face legal problems if it failed to protect the confidentiality of such information.

Integrity deals with preventing, or at least detecting, unauthorized “writing” (i.e., changes to data). Alice's Bank must protect the integrity of account information to prevent Trudy from, say, increasing the balance in her account or changing the balance in Bob's account. Note that confidentiality and integrity are not the same thing. For example, even if Trudy cannot read the data, she might be able to modify it, which, if undetected, would destroy its integrity. In this case, Trudy might not know what changes she had made to the data (since she can't read it), but she might not care—sometimes just causing trouble is good enough for Trudy.

Denial of service, or DoS, attacks are a relatively recent concern. Such attacks try to reduce access to information. As a result of the rise in DoS attacks, data availability has become a fundamental issue in information security. Availability is a concern for both Alice's Bank and Bob—if AOB's website is unavailable, then Alice can't make money from customer transactions and Bob can't get his business done. Bob might then take his business elsewhere. If Trudy has a grudge against Alice, or if she just wants to be malicious, she might attempt a denial of service attack on AOB.