Adam Shostack here.
I’ve been working on an SDL requirement since a few weeks after I joined the company. For this blog post, what it is matters less than how we’ve gotten here, and for where we are, I must thank and blame Steve Lipner. It has been, at times, a frustrating journey. Wearing my security hat, the destination was (and is) obviously worth achieving. But that’s not enough to bring something into the SDL. To be part of the SDL, it needs to be achievable for the thousands of engineers at Microsoft who will be required to comply.
Yesterday, Steve Lipner was honored by the ISSA and inducted into their hall of fame. We’ve been talking on the SDL team about what we want to say about Steve. A great deal of his career is publicly known, and what he’s done for us here at Microsoft is a little harder to talk about in ways that convey the tremendous value that Steve brings to us.
What he’s done here is guided a substantial chunk of the team that was once the “Secure Windows Initiative” into the Microsoft Security Development Lifecycle. In doing so, he’s helped to take Microsoft from being the butt of security jokes to an exemplar for many organizations setting out on a path to building more secure code.
The first version of a requirement that I tried to shepherd was insufficient. After a conversation with Eric and with Steve, I voted against it myself, despite the many hours of late night phone calls that went into it. I let someone else write the second draft, and it turned out the tooling wasn’t good enough. This is an important point as to why the SDL works for us here, and it’s a point that Steve gently forces on all of us: if we can automate it, we have to automate it. The product groups are often overwhelmed with requests. Threat modeling suffers from this in spades: we ask a huge amount of every engineer in threat modeling their code. We created the “STRIDE per element” approach to make it possible for typical non-security engineers to do it. The tools have to scale to the sorts of products we build, and the diversity of platforms and languages our product teams use.
What Steve taught me in saying no to the second draft was the importance of sufficient tools. In saying no, he forced me to pick that requirement up, and get it to be good enough for our product teams. It’s now prescriptive, with clear entry and exit points. The tool story makes sense. And teams are executing on it after our beta period. We’re finding and fixing real issues. And the things we’re asking are achievable.
Earlier in his career, Steve worked on an A-1 system for DEC. What that meant was big formal mathematical proofs that first the system had been mathematically proven to have certain properties that a few key buyers cared about, and second that it was so late to market that those key buyers bought other stuff in the meantime. (Ironically, those properties were ones that researchers like Anderson, Bell, La Padula and Biba had talked about while working for…well, you can guess, or you could look it up over at Matt Bishop’s collection of classic papers in information security. It’s not for nothing that Steve was brought into a hall of fame.)
But I think that Steve’s most impressive achievement has not been the pragmatism that he’s brought to the SDL. It’s how he’s taught all of us how important it is to temper our security goals with a pragmatism that enables us to achieve them. It’s a lesson that can help not only the information security industry, but also all those companies who are selling non-security products: you can make them secure and trustworthy.
Thanks, Steve, and congratulations on your induction!