by adam on March 19, 2014
“Please note that your password will be stored in clear text in our database which will allow us to send it back to you in case you lost it. Try avoid using the same password as accounts you may have in other systems.” — a security conference’s speaker website
This is a silly pattern. At least these folks realize it’s a bad idea, and warn the person, but that’s the wrong approach, since it relies on people reading text, and then relies on them being willing to make up and recall yet another password.
The origin of this problem is a broken model of what people want from their online accounts. As I discuss in chapter 14 of Threat Modeling: Designing for Security, the right goal is almost always account recovery, not password recovery. It’s irksome to see a security conference get this so wrong.
To be fair, the person who selected the conference management system was likely not a security expert, and had other functional goals on which they were focused. It would be easier to be annoyed if someone had a comprehensive and precise list of security problems which they could look for. But while we’re being fair, this isn’t like a XSS or SQLi issue which require some skill to discover. It’s right there in the primary workflow.
by adam on February 21, 2014
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.)
by adam on February 20, 2014
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.
by adam on February 19, 2014
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 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.
by adam on January 31, 2014
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.
by adam on January 28, 2014
Alan Shimmy has the nominations for the 2014 Social Security bloggers award!
New School has been nominated for most entertaining, while Emergent Chaos has been nominated for best representing the security industry and the hall of fame.
by adam on January 16, 2014
I’d like to nominate Xfinity’s “walled garden” for the worst user experience in computer security.
For those not familiar, Xfinity has a “feature” called “Constant Guard” in which they monitor your internet for (I believe) DNS and IP connections for known botnet command and control services. When they think you have a bot, you see warnings, which are inserted into your web browsing via a MITM attack.
Recently, I was visiting family, and there was, shock of all shocks, an infected machine. So I pulled out my handy-dandy FixMeStick*, and let it do its thing. It found and removed a pile of cruft. And then I went to browse the web, and still saw the warnings that the computer was infected. This is the very definition of a wicked environment, one in which feedback makes it hard to understand what’s happening. (A concept that Jay Jacobs has explicitly tied to infosec.)
So I manually removed Java, and spent time reading the long list of programs that start at boot (via Autoruns, which Xfinity links to if you can find the link), re-installed Firefox, and did a stack of other cleaning work. (Friends at browser makers: it would be nice if there was a way to forcibly remove plugins, rather than just disable them).
As someone who’s spent a great deal of time understanding malware propagation methods, I was unable to decide if my work was effective. I was unable to determine the state of the machine, because I was getting contradictory signals.
My family (including someone who’d been a professional Windows systems administrator) had spent a lot of time trying to clean that machine and get it out of the walled garden. The tools Xfinity provided did not work. They did not clean the malware from the system. Worse, the feedback Xfinity themselves provided was unclear and ambiguous (in particular, the malware in question was never named, nor was the date of the last observation available). There was no way to ask for a new scan of the machine. That may make some narrow technical sense, given the nature of how they’re doing detection, but that does not matter. The issue here is that a person of normal skill cannot follow their advice and clean the machine. Even a person with some skill may be unable to see if their work is effective. (I spent a good hour reading through what runs at startup via Autoruns).
I understand the goals of these walled garden programs. But the folks running them need to invest in talking to the people in the gardens, and understand why they’re not getting out. There’s good reasons for those failures, and we need to study the failures and address those reasons.
Until then, I’m interested in hearing if there’s a worse user experience in computer security than being told your recently cleaned machine is still dirty.
* Disclaimer: FixMeStick was founded by friends who I met at Zero-Knowledge Systems, and I think that they refunded my order. So I may be biased.
by adam on January 8, 2014
I’m on the program committee this year, and am looking forward to great submissions.
by David Mortman on January 7, 2014
Rich Mogul over at Securosis (N.B. I’m a contributing analyst there) has a great post on how, due to human error, some of his AWS credentials got nabbed by some miscreants and abused. We here at the New School love it when folks share how they were compromised and what they did about it. It is this sort of transparency that helps us all. Kudos to Rich for being willing to share his pain for our benefit.
by adam on July 18, 2013
At Light Blue Touchpaper, Ross Anderson says “We have a vacancy for a postdoc to work on the psychology of cybercrime and deception for two years from October.”
I think this role has all sorts of fascinating potential, and wanted to help get the word out in my own small way.