Threat Modeling and Operations

One very important question that’s frequently asked is “what about threat modeling for operations?” I wanted to ensure that Threat Modeling: Designing for Security focused on both development and operations. To do that, I got help from Russ McRee. For those who don’t know Russ, he’s a SANS incident handler as well as a collegue at Microsoft, where he beat me about the head and shoulders made the case for the importance of threat modeling for operations. Those conversations led to me helping out on the “IT Infrastructure Threat Modeling Guide.”

Russ had an official role as “Technical Proofreader,” but that understates what he did. What he did was make sure that infrastructure and operations got a full and fair treatment, and the book is better for his help.

There’s an important interplay between threat modeling for developers and threat modeling for operations. The threats are the same, but the mitigations are functionally different. There are mitigations which are easy for developers which are hard or impossible for the operations, and vice versa. The simplest example is logging. It’s really hard to add logging without changing the source. But reading the logs? There’s no way for a developer to ensure that that happens. Someone in operations has to decide what logs are important and relevant. Good threat modeling can elicit the threats, and lead to the early creation of a security operations guide, making explicit who needs to do what.

(I don’t mean to ignore the rise of devops, but even in that world, it can help to think of different types of mitigations.)

My Technical Editor: Chris Wysopal

When Wiley asked me about a technical editor for Threat Modeling: Designing for Security, I had a long list of requirements. I wanted someone who could consider the various scenarios where threat modeling is important, including software development and operations. I wanted someone who understood the topic deeply, and had the experience of teaching threat modeling to those whose focus isn’t security.

More, I wanted someone who I respected for their depth of experience, where I wouldn’t be tempted to ignore comments which were tough to address or required me to rewrite a chapter late in the process.

And Chris Wysopal was the perfect guy for that. His background includes time at the L0pht, so he knows how to think like an attacker. While he was at @Stake, he delivered threat modeling as a consultant, and helped companies (including Microsoft) learn to threat model. And at his most venture, Veracode, he’s bringing secure development technology and services to a wide range of companies.

So I’m thrilled that we were able to work together on this book.

Threat Modeling: Designing for Security

Threat modeling book 300

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.

Availability

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.)

Future blogging

In light of me already spending time on 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 here on New School.

Threat Modeling: Designing for Security

Threat modeling book 300

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.

Availability

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.)

Future blogging

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.

P0wned! Don't make the same mistake I did

I fell victim to an interesting attack, which I am recounting here so that others may avoid it.

In a nutshell, I fell victim to a trojan, which the malefactor was able to place in a trusted location in my search path. A wrapper obscured the malicious payload. Additionally, a second line of defense did not catch the substitution. I believe the attackers were not out to harm me, but that this trojan was put in place partially for lulz, and partially to allow a more-important attack on the systems RBAC mechanisms to succeed.

Attack Details

I was attempting to purchase a six pack of New Belgium Rampant IPA, shown immediately below.

IMG_2242.JPG

I obtained the six pack from the canonical location in the system – a reach-in refrigerator in the supermarket’s liquor aisle. I proceeded to the cashier, who rang up my purchase, bagged it, and accepted payment.

I realized upon arrival home, that this was a trojan six pack, as seen below:

IMG_2243.JPG

Clearly, the attacker to care to make his payload look legitimate. What I noticed later, was the subtle difference I zoom in on below

IMG_2245.JPG

:

IMG_2244.JPG

Yes, the attacker had substituted root beer for real beer.

Needless to say, this was a devious denial of service, which the perpetrators undoubtedly laughed about. However, this was likely not just “for the lulz”. I think this was the work of juvenile attackers, whose motives were to defeat the RBAC (real beer access control) system. Knowing that a purchase of real beer would be scrutinized closely, I believe they exfiltrated the target beer by hiding it in a root beer package.

Mitigations put in place by the system did not catch this error – the cashier/reference monitor allowed the purchase (and likely, the offsetting real beer as root beer purchase).

Possible Countermeasures

The keys to this attack were that the trojan was in the right place in the search path, and that it appeared legitimate. Obviously, this location must be readable by all, since items need to be fetched from it. However, allowing items to be placed in it by untrusted users is a definite risk. Technical constraints make the obvious countermeasure — allowing only privileged stocking, while permitting “world” fetching — presents serious usability concerns, and increases system cost, since the privileged stocker must be paid.

Nonetheless, such countermeasures are in place for certain other items, notably where the cost to the system — as opposed to the user — of an illicit item substitution is quite high.

Lessons learned

Ultimately, system usability and cost tradeoffs put the onus on the end-user. Before taking a non-idempotent step, inspect the objects closely!

On Bitcoin

There’s an absolutely fascinating interview with Adam Back: “Let’s Talk Bitcoin Adam Back interview.”

For those of you who don’t know Adam, he created Hashcash, which is at the core of Bitcoin proof of work.

Two elements I’d like to call attention to in particular are:
First, there’s an interesting contrast between Adam’s opinions and Glenn Flieshman’s opinions in “On the Matter of Why Bitcoin Matters.” In particular, Glenn seems to think that transaction dispute should be in the protocol, and Adam thinks it should be layered on in some way. (Near as I can tell, Glenn is a very smart journalist, but he’s not a protocol designer.)

Secondly, Adam discusses the ways in which a really smart fellow, deeply steeped in the underlying technologies, can fail to see how all the elements of Bitcoin happened to combine into a real ecash system. Like Adam, I was focused on properties other systems have and Bitcoin does not, and so was unexcited by it. There’s an interesting lesson in humility there for me.

This is also interesting “How the Bitcoin protocol works.”

Adam’s Mailing List and Commitment Devices

Yesterday, I announced that I’ve set up a mailing list. You may have noticed an unusual feature to the announcement: a public commitment to it being low volume, with a defined penalty ($1,000 to charity) for each time I break the rule.

You might even be wondering why I did that.

In the New School, we study people, and their motivations. Knowing that introspection is a fine place to start, a poor place to end and an excellent source of mis-direction, I talked to several people who seem like the sort I want on my list about their experience with mail lists.

The first thing I heard was fairly unanimous: people don’t subscribe because they get spammed.
The perception is that many people who create lists like this abuse those lists. So to address that, I’m using a commitment device: a promise, made publicly in advance. By making that promise, I give myself a reason to hold back from over-mailing, and I give myself a way to constrain helping others with my list. (But not eliminate such help — perhaps that’s a bad idea, and it should be just about those new things where I’m a creator. Would love your thoughts.)

The second issue I heard is that unsubscribing tends to feel like an interpersonal statement, rather than a technical one (such as “I get too much email.) So I promise not to be offended if you unsubscribe, and I promise to be grateful if you tell me why you unsubscribe. This is why I love Twitter: I control who I listen to. It’s also why I think the “unfollow unsubscribe bug” (real or imagined) was such a good thing. It provided a socially acceptable excuse for unfollows.

Are there other factors that hold you back from signing up for a mailing list like mine? Please let me know what they are, I’d love to address them if I can.

Getting Ready for a Launch

I’m getting ready for to announce a new project that I’ve been working on for quite a while.

As I get ready, I was talking to friends in PR and marketing, and they were shocked and appalled that I don’t have a mailing list. It was a little like telling people in security that you don’t fuzz your code.

Now, I don’t know a lot about marketing, but I do know that look which implies table stakes. So I’ve set up a mailing list. I’ve cleverly named it “Adam Shostack’s New Thing.” It’ll be the first place to hear about the new things I’m creating — books, games or anything else.

People who sign up will be the first to hear my news.

[Update: Some people are asking why I don’t just use Twitter or blogs? I plan to, but there are people who’d like more concentrated news in their inbox. Cool. I can help them. And much as I love Twitter, it’s easy for a tweet to be lost, and easy to fall into the trap of retweeting yourself every hour to overcome that. That’s annoying to your followers who see you repeating yourself.]

Navigation