“EPC RFID Tags in Security Applications”

I just finished an interesting paper, K. Koscher, A. Juels, T. Kohno, and V. Brajkovic. “EPC RFID Tags in Security Applications: Passport Cards, Enhanced Drivers Licenses, and Beyond.”

In the paper, they analyze issues of cloning (easy) read ranges (longer than the government would have you believe) and `design drift’ (a nice way of saying that the Washington State EDL can be read in its protective sleeve). But that’s not what I wanted to talk about. What I want to talk about is the strikingly experimental nature of the paper, and how unfortunately rare that seems to be. Throughout the paper, the authors describe what they did and what they observed. (“..we used an Inpinj Speedway R1000 reader with a Cushcrash S9028PCL circularly polarized antenna..” “The TID reported by our Passport Card is E2 00 34 11 FF B8 00 00 00 02…”)

In far too many papers which purport to be about computer security, there’s a lack of hard detail. Take for example, my own “Experiences Threat Modeling at Microsoft.” While I’m happy with the paper, and it explains a great deal about what we’ve learned, it doesn’t contain nearly as much measurement of threat models as I would have liked. (Of course, figuring out what to measure about threat models was one of the goals of the paper.)

For another example, take the widely reported apon “Overwriting Hard Drive Data: The Great Wiping Controversy,” which doesn’t so much as report what equipment they used. I would not rely on that paper not only for their lack of detail or their wearing their bias on their shoulder, but because demonstrating that Wright, Kleiman and Sundhar can’t figure out how to read a disk is not the same as saying that no one could figure it out. Had they explained how to figure it out, that would be far more conclusive and interesting.

I shouldn’t be struck by descriptions of experiments and facts reported.

Photosynth and the inauguration

So what do you do with the million photos everyone took of the inauguration? Here at Emergent Chaos, we believe that we should throw them all in a massive blender, and see what emerges. A massive blender isn’t a very technical description of Photosynth, but it’s not a bad analogy. The project cleverly figures out what information is available from all the photos, creates a massive, three dimensional model, and makes it available. Here’s “The Moment,” hosted by CNN and Microsoft Live Labs, pixelated by my shrinking it down and adding the frame from a screenshot:

Photosynth-inauguration.jpg

I think it’s tremendously cool. There’s no pre-organization. It’s not some massive machine stitching together a gigapixel image from one place. People take photographs chaotically, submit them sporadically, and what emerges is amazing. Why not go explore?

(Disclaimer: I’m pretty sure I’d say the same thing even if I didn’t work for Microsoft.)

Gary McGraw and Steve Lipner

Gary McGraw has a new podcast, “Reality Check” about software security practitioners. The first episode features Steve Lipner. It’s some good insight into how Microsoft is approaching software security.

I’d say more, but as Steve says two or three good things about my threat modeling tool, you might think it some form of conspiracy.

You should go listen.

SDL Announcements

I’m in Barcelona, where my employer has made three announcements about our Security Development Lifecycle, which you can read about here: “SDL Announcements at TechEd EMEA.”

I’m really excited about all three announcements: they represent an important step forward in helping organizations develop more secure code.


But I’m most excited about the public availability of the SDL Threat Modeling Tool. I’ve been working on this for the last 18 months. A lot of the thinking in “Experiences Threat Modeling at Microsoft” has been made concrete in this new tool, which helps any software engineer threat model.

SDL-Threat-Modeling-Tool-v3.jpg

I’m personally tremendously grateful to Meng Li, Douglas MacIver, Patrick McCuller, Ivan Medvedev and Larry Osterman. Each of them has contributed tremendously to making the tool what it is today. I’m also grateful to the many Microsoft employees who have taken the time to give me feedback, and I look forward to more feedback as more people use the tool.

CTOs, Product Management and Program Management

In “The product manager’s lament,” Eric Ries writes about his view of product managers:

Let’s start with what the product manager does. He’s supposed to be the person who specifies what the product will do. He writes detailed specs which lay out exactly what features the team should build in its next iteration. These specs are handed to a designer, who builds layouts and mockups of all the salient points. Then the designs are handed to a team of programmers with various specialties.

When I met this team, some acrimony had built up. The last few features came out pretty different from what was origianlly spec’d, and took far too long, to boot. The programmers keep asking for more say in the designs and direction that they work on.

I think Eric is almost right about what a product manager should do. I want to provide two disparate perspectives on what that almost entails, and why it’s important. First, I’d like to talk about the role of the program manager at Microsoft (my current day job) and then about the role of the startup CTO (my previous day job).

The program manager’s job is to understand the market and customer pain, shape consensus around what a solution looks like, spec that solution, then drive implementation and the inevitable tradeoffs and ship a solution which makes customers happy.* I do all of that in creating the SDL threat modeling tool.

Some people think the market approach is strange because inside Microsoft, the SDL requires threat modeling. But most markets are distorted in some way by legal requirements. I treat threat modeling as a market with pain that I need to address, and do my best to win in that market. I’m fairly pedantic about talking about our customers, rather than our users, because we give them better tools, and make them more successful when we treat them as valued customers.

Note that that is a super-set of Eric’s description of what a product manager does. He has some interesting suggestions, but the real fix is to get the guy who owns the spec deeply involved in the software process, from start to finish. Which brings me to the role of the CTO.

The role of a good CTO is to understand the market and customer pain, shape consensus around what a solution looks like, spec that solution, then drive implementation and the inevitable tradeoffs and ship a solution which makes customers happy. There’s also a responsibility to be a company leader, hiring, shaping the culture, and participating in the executive decisions the company makes. Sometimes, there’s a need to step in and build. But a large part of the CTO role is that of the program manager. I think this is why I’m able to succeed as a program manager—I’ve been at it for a while.

In Eric’s post last month, “What does a startup CTO actually do?,” he provided a different list: platform selection and technical design; seeing the big picture; providing options; finding the 80/20 and growing technical leaders. I think that’s a good list, but it’s missing a key piece, which is the vision to bits to customer experience scope that is at the core of the program management mindset.

[Update: The * was going to be a footnote citing an internal doc which I'm paraphrasing, but I decided to cut it, and forgot to remove the *. Oops!]

SDL Press Tour Announcements

Steve Lipner and I were on the road for a press tour last week. In our work blog, he writes:

Last week I participated in a “press tour” talking to press and analysts about the evolution of the SDL. Most of our past discussions with press and analysts have centered on folks who follow security, but this time we also spoke with publications and analysts who write for software development organizations. I was struck by the extent to which the folks who focus on development have been grappling with many of the issues about developing secure software that we’ve focused on here at Microsoft.

The announcements are here. I am particularly excited about the third announcement, the availability of the SDL Threat Modeling Tool v3.

The Hazards of Not Using RFC 1918

ie8_smartscreen.jpg

RFC 1918 is a best-current-practicies RFC that describes network address ranges that we all agree we won’t use globally. They get used for private networks, NAT ranges and so on. There are three ranges:

10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255

They are thus the Internet equivalent of the American phone system not using the exchange 555, only more useful. If you need to give an example IP address, you can use one of those without causing anyone consternation or irritation.

An example of why you want to use one of these addresses can be found (at least for the next few minutes) at Microsoft’s site for the IE 8 beta. One of the IE 8 features is the “SmartScreen Filter” which can tell you IP addresses you’re best not going to. An example is the picture accompanying my post.

If you check out that address, 207.68.196.170, at ARIN Whois, you find out that it’s owned by Microsoft themselves.

I suppose that using one of your own addresses as a hazardous address is better than using someone else’s, but immature people like Your Friendly Author will titter over it and point it out to other people as well.

There’s a reason RFC 1918 exists, and this is one of them. Oh, by the way, be sure to look at RFC 2606, which reserves the domains example.com, example.net, and example.org. It also reserves the top-level domains .test, .example, .invalid, and .localhost. Remember them.

What do you want to know about SDL Threat Modeling?

Over on my work blog, I asked:

I’m working on a paper about “Experiences Threat Modeling at Microsoft” for an academic workshop on security modeling. I have some content that I think is pretty good, but I realize that I don’t know all the questions that readers might have.

So, what questions should I try to answer in such a paper? What would you like to know about? No promises that I’ll have anything intelligent to say, but I’d love to know the questions you’re asking. So please. Ask away!

Comment here or there.