One of the most interesting security books I’ve read in a while barely mentions computers or security. The book is Petroski’s The Evolution of Useful Things.
As the subtitle explains, the book discusses “How Everyday Artifacts – From Forks and Pins to Paper Clips and Zippers – Came to be as They are.”
The chapter on the fork is a fine example of the construction of the book.. The book traces its evolution from a two-tined tool useful for holding meat as it was cut to the 4 tines we have today. Petroski documents the many variants of forks which were created, and how each was created with reference to the perceived failings of previous designs. The first designs were useful for holding meat as you cut it, before transferring it to your mouth with the knife. Later designs were unable to hold peas, extract an oyster, cut pastry, or meet a variety of other goals that diners had. Those goals acted as evolutionary pressures, and drove innovators to create new forms of the fork.
Not speaking of the fork, but rather of newer devices, Petroski writes:
Why designers do not get things right the first time may be more understandable than excusable. Whether electronics designers pay less attention to how their devices will be operated, or whether their familiarity with the electronic guts of their own little monsters hardens them against these monsters’ facial expressions, there is a consensus among consumers and reflective critics like Donald Norman, who has characterized “usable design” as the “next competitive frontier,” that things seldom live up to their promise. Norman states flatly, “Warning labels and large instruction manuals are signs of failures, attempts to patch up problems that should have been avoided by proper design in the first place.” He is correct, of course, but how is it that designers have, almost to a person, been so myopic?
So what does this have to do with security?
(No, it’s not “stick a fork in it, it’s done fer.”)
Its a matter of the pressures brought to bear on the designs of even what (we now see) as the very simplest technologies. It’s about the constant imperfection of products, and how engineering is a response to perceived imperfections. It’s about the chaotic real world from which progress emerges. In a sense, products are never perfected, but express tradeoffs between many pressures, like manufacturing techniques, available materials, and fashion in both superficial and deep ways.
In security, we ask for perfection against an ill-defined and ever-growing list of hard-to-understand properties, such as “double-free safety.”
Computer security is in a process of moving from expressing “security” to expressing more precise goals, and the evolution of useful tools for finding, naming, and discussing vulnerabilities will help us express what we want in secure software.
The various manifestations of failure, as have been articulated in case studies throughout this book, provide the conceptual underpinning for understanding the evolving form of artifacts and the fabric of technology into which they are inextricably woven. It is clearly the perception of failure in existing technology that drives inventors, designers, and engineers to modify what others may find perfectly adequate, or at least usable. What constitutes failure and what improvement is not totally objective, for in the final analysis a considerable list of criteria, ranging from the functional to the aesthetic, from the economic to the moral, can come into play. Nevertheless, each criterion must be judged in a context of failure, which, though perhaps much easier than success to quantify, will always retain an aspect of subjectivity. The spectrum of subjectivity may appear to narrow to a band of objectivity within the confines of disciplinary discussion, but when a diversity of individuals and groups comes together to discuss criteria of success and failure, consensus can be an elusive state.
Even if you’ve previously read it, re-reading it from a infosec perspective is worthwhile. Highly recommended.
[As I was writing this, Ben Hughes wrote a closely related post on the practical importance of tradeoffs, “A Dockery of a Sham.”]
I was irked to see a tweet “Learned a new word! Pseudoarboricity: the number of pseudoforests needed to cover a graph. Yes, it is actually a word and so is pseudoforest.” The idea that some letter combinations are “actual words” implies that others are “not actual words,” and thus, that there is some authority who may tell me what letter combinations I am allowed to use or understand.
Balderdash. Adorkable balderdash, but balderdash nonetheless.
As any student of Orwell shall recall, the test of language is its comprehensibility, not its adhesion to some standard. As an author, I sometimes hear from people who believe themselves to be authorities, or who believe that they may select for me authorities as to the meanings of words, and who wish to tell me that my use of the word “threat” threatens their understanding, that the preface’s explicit discussion of the many plain meanings of the word is insufficient, or that my sentences are too long, comma-filled, dash deficient or otherwise Oxfordless in a way which seems to cause them to feel superior to me in a way they wish to, at some length, convey.
In fact, on occasion, they are irked. I recommend to them, and to you, “You Are What You Speak.”
I wish them the best, and fall back, if you’ll so allow, to a comment from another master of language, speaking through one of his characters:
‘When I use a word,’ Humpty Dumpty said, in rather a scornful tone, ‘it means just what I choose it to mean — neither more nor less.’
‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.’
Bruce Schneier says nice things about my latest book.
For Star Wars day, I’m happy to share this event poster for my talk at Ada’s Books in Seattle
Technical Presentation: Adam Shostack shares Threat Modeling Lessons with Star Wars.
This will be a less technical talk with plenty of discussion and interactivity, drawing on some of the content from “Security Lessons from Star Wars,” adapted for a more general audience.
I am super-excited to announce that my new book, Threat Modeling: Designing for Security (Wiley, 2014) is now available wherever fine books are sold!
The official description:
If you’re a software developer, systems manager, or security professional, this book will show you how to use threat modeling in the security development lifecycle and the overall software and systems design processes. Author and security expert Adam Shostack puts his considerable expertise to work in this book that, unlike any other, details the process of building improved security into the design of software, computer services, and systems — from the very beginning.
- Find and fix security issues before they hurt you or your customers
- Learn to use practical and actionable tools, techniques, and approaches for software developers, IT professionals, and security enthusiasts
- Explore the nuances of software-centric threat modeling and discover its application to software and systems during the build phase and beyond
- Apply threat modeling to improve security when managing complex systems (or even simple ones!)
- Manage potential threats using a structured, methodical framework
- Discover and discern evolving security threats
- Use specific, actionable advice regardless of software type, operating system, or program approaches and techniques validated and proven to be effective at Microsoft and other top IT companies
Threat Modeling: Designing for Security is full of actionable, tested advice for software developers, systems architects and managers, and security professionals. From the very first chapter, it teaches the reader how to threat model. That is, how to use models to predict and prevent problems, even before you’ve started coding.
Threat Modeling: Designing for Security is jargon-free, accessible, and provides proven frameworks that are designed to integrate into real projects that need to ship on tight schedules.
For more information, I’ve set up a small book website: threatmodelingbook.com.
Amazon has Kindle edition, and is saying that the paperback will ship in “9-11 days.” I believe that’s startup issues in getting the books to and through the warehousing system, but don’t know details. I will be having a book signing at RSA, Wednesday at 11 AM in Moscone South. (iCal reminder.)
In light of me celebrating the joyous chaos of what to put on which blog, but more importantly, not wanting readers to have to subscribe to three blogs, I’ll be blogging about threat modeling over on the New School blog.
I blogged yesterday about all the new works that have entered the public domain as their copyright expired in the United States. If you missed it, that’s because exactly nothing entered the public domain yesterday.
Read more — but only commentary, because there’s no newly free work — at “What Could Have Entered the Public Domain on January 1, 2014?”
It’s near-impossible to see how our insanely long copyright terms, or their never-ending extensions encourage Dr. Seuss, Ayn Rand, Jack Kerouac or Ian Fleming to keep producing new work. Those authors have been richly rewarded for their work. But it’s easy to see how keeping those works under copyright reduces creative re-use of our collective cultural heritage.
Recently the kind folks at No Starch Press sent me a review copy of Rich Bejtlich’s newest book The Practice of Network Security Monitoring and I can’t recommend it enough. It is well worth reading from a theory perspective, but where it really shines is digging into the nuts and bolts of building an NSM program from the ground up. He has essentially built a full end to end tutorial on a broad variety of tools (especially Open Source ones) that will help with every aspect of the program, from collection to analysis to reporting.
As someone who used to own security monitoring and incident response for various organizations, the book was a great refresher on the why and wherefores of building an NSM program and it was really interesting to see how much the tools have evolved over the last 10 years or so since I was in the trenches with the bits and bytes. This is a great resource though regardless of your level of experience and will be a great reference work for years to come. Go read it…
I have to start off by apologizing for how very late this review is, an embarrassing long time ago, the kind folks at No Starch Press very kindly gave me a copy of “Super Scratch Programming Adventure” to review. Scratch for those that aren’t familiar is a kids oriented programming language designed by Mitchel Resnick of the MIT Media Lab, the same team that developed the programmable bricks for Lego Mindstorms.
The book is in manga format and very entertaining and I enjoyed it thoroughly. It was so much fun, that when my then ten year old asked to learn how to program with the long term goal of writing his own minecraft mods, I handed him the book and asked him what he thought. To say he whipped through the book is an understatement. He actually finished it in one reading and immediately asked if he could start playing with Scratch on the family laptop.
Over the next few days he worked his way through some of the programs in the book and put the book aside for a long while. Recently we were talking about an upcoming Lego robotics class he had coming up and he remembered that he had the copy of “Super Scratch Programming Adventure” in his room. He dug it out and this time he worked his way through all the programs quite quickly.
I asked him what he thought of the book and said it was very good; that he really liked the comic book format and that he wished more books were done that way. At this point he’s excited enough that we’ll either dig deeper into Scratch together or we’ll switch to a games oriented text like No Starch’s “Realm of Racket” or possibly Sweigarts’s “Invent Your Own Computer Games with Python”.
Regardless of what we decide to do however, I can highly recommend ““Super Scratch Programming Adventure” as a great introduction to programming for kids or even non-kids who want a first very friendly exposure to programming. And again, my apologies to the folks at No Starch Press for taking so long on this review.
The Plateau Effect is a powerful law of nature that affects everyone. Learn to identify plateaus and break through any stagnancy in your life— from diet and exercise, to work, to relationships.
The Plateau Effect shows how athletes, scientists, therapists, companies, and musicians around the world are learning to break through their plateaus—to turn off the forces that cause people to “get used to” things—and turn on human potential and happiness in ways that seemed impossible. The book identifies three key flattening forces that generate plateaus, two principles to guide readers in engineering a plateau’s destruction, and three actions to take to achieve peak behavior. It helps us to stop wasting time on things that are no longer of value and to focus on the things that leverage our time and energy in spectacular ways.
Here at Emergent Chaos, we’re fans of both of the authors of the Plateau Effect. Bob Sullivan is the journalist who got us on a ChoicePoint kick, which might have been something of a Plateau Effect, good and bad, for us.
I look forward to reading the book, and finding out!
You can learn more about it at http://www.plateaueffect.com/.
It is a truism that the Star Wars prequels sucked. (Elsewhere, I’ve commented that the franchise being sold to Disney means someone can finally tell the tragic story of Anakin Skywalker’s seduction by the dark side.)
But the issue of exactly why they sucked is complex and layered, and most of us prefer not to consider it too deeply. Fortunately, you no longer have to. You can simply get “Why the Star Wars Prequels Sucked, and Why It Matters,” a short “Polemic on Aesthetics, Ethics and Politics. With Lightsabers.”
Really, what else do you need to know?
An example? Ok, the diner scene, and how it compares to the cantina scene. The cantina exudes otherness and menace. The diner looks like it was filmed in 1950s and then had a few weird things ‘shopped in. The scene undercuts the world which Star Wars established. Or the casual tossing in that Anakin was a virgin birth, and how after tying to one of the most enduring stories in western culture, the subject is then never referred to again.
Or the utter lack of consequence of anything in the stories, since we already know how they’ll come out, and how, by focusing on characters whose fates we know, Lucas drains any dramatic tension of of the story. The list goes on and on, and if you want to know why you hated the prequels so much, this is a short and easy read, and highly worthwhile.
Oh, and you’ll learn how Lando Calrissian is Faust. So go buy it already.
One last thing. Delano Lopez? That’s a name I hadn’t heard in a very long time. But he and I went to school together.
A friend is trying to track down a science fiction story in which the president had a death sentence at the end of their term.
I know you’re all smart and good looking and at least one of you will know the exact author and title.
You probably know Dennis Fisher because of his writings on Threatpost or his Digital Underground podcast, where I’ve appeared several times. I wanted to help him spread the news that his first novel “Motherless Children” is now available. You should check it out.
I’ll get my review done shortly, but I wanted to help spread the word.
A while back, Kai Roer graciously sent me an electronic copy of the book Cloud Security Rules that he co-authored with an all-start cast including luminaries Wendy Nather and our very own New School’s Alex Hutton. All in all, it’s a solid read covering the gamut of topics from Risk and Compliance to technology versus the human factor and finishes nicely with a section on business models. A few chapters about more about security without being a particular focus on the cloud(tm), but that’s not particularly a problem.
My only real complaint about the book is that with so many authors, things don’t always flow as smoothly as they could when moving from chapter to chapter. This is however made up for by the general high quality of the work. In particular, un addition to the authors mentioned above, you’ll also want to make sure to read the sections by Lori MacVittie, Brian Honan and Kevin Riggins.
This book is targeted at decision makers, managers and othesr who need to understand cloud from business view, so if that’s you, I encourage you to read this book. Definitely worth the price.