Yes, you read that correctly. Microsoft. Writing on information security. They may be the software company who have done the most writing on information security, including many security software companies.
The reason they did it is one of those things that made Bill Gates such a capable and successful business leader. He was not necessarily a product visionary, though he did come up with the “a computer on every desktop” vision that made Windows and Office ubiquitous. No, Windows and Office were not the first examples of products in their field to market. What Bill Gates was great at was seeing what he and his team were not great at, and doing that.
In 2002, this was security. Various worms and viruses plagued the Windows ecosystem. These had names that we recognise now, like Nimda and Code Red, which helped to cement their place in the public consciousness in those as Spectre and Meltdown have elevated the publicity of some CPU design flaws today. The “ILOVEYOU” virus even got debated in the House of Commons of the UK parliament, as a national defence issue.
Microsoft could probably have done nothing, and been OK for a while. Through a combination of an improved product and shady practices—pricing OEM licenses unfavourably if the vendors offered alternative operating systems—Windows 95 had already won an overwhelming share of the desktop computer market, a position which Windows XP had solidified.
When you run the whole market it can be difficult to see a need to change direction, but Bill Gates could do it. He did it in 1995 with his Internet Tidal Wave memo: Microsoft were late to the party, but they were going to show up in a massive stretch Hummer and spike the punch.
He did it again in 2002 with his Trustworthy Computing memo.
Over the last year it has become clear that ensuring .NET is a platform for Trustworthy Computing is more important than any other part of our work. If we do not do this, people simply will not be willing – or able – to take advantage of all the other great work we do. Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness in computing.
Software engineers across the whole of Microsoft downed tools (there was no new development on Windows for two months), learned how to build things in a security-conscious fashion, then invested time into building threat models, identifying risks, and patching their software. Never before or since has a software company so totally—and publicly—admitted its faults, and come to a halt while it addresses them. And along the way, we got some useful information about how to do the same ourselves.
We’ve also published books like “Writing Secure Code,” by Michael Howard and David LeBlanc, which gives all developers the tools they need to build secure software from the ground up.
So BillG even has some recommended reading for us. Shall we take a look?
Recommended for us but required reading for Microsoft engineers, Writing Secure Code explains why secure systems are needed, gives a light touch description of threat modeling, then goes into a load (440 pages) of secure coding techniques. Many of these techniques are still needed today, because they are design-level (access control, execution privilege, appropriate application of cryptography) or because we never learn (buffer overruns, data representation, code injection). For example, their description of “Canonical Representation Issues” covers the various ways in which Unicode text can look like other Unicode text, a problem in 2002 that foreshadows the rise of punycode domain spoofing that still plagues the Firefox browser in 2021.
Why are these things, these important security aspects of application and system design, still a problem two decades later? Why is Anastasiia Vixentael, the guest author in our security issue, still explaining to developers how to do (and that they should do) these things that were known back before many React Native coders were even conceived?
The answer is found in the excellent and evergreen Appendix B to Howard and LeBlanc’s book, “Ridiculous Excuses We’ve Heard”. This covers reasons Microsoft teams gave the authors why they should not need to adopt secure coding practices, along with counter-arguments to each of them. Yes, I have been the information security expert on many a team in the 21st century, and yes, I have heard many of these ridiculous excuses.
Of course the ridiculous excuses are there to cover the vulnerability of the developers, project managers, product owners, testers, and other engineers: they were never taught about information security or secure development practices. Telling them it is the most important thing to the company is telling them their most pressing need is one they are ill-equipped to handle, and they get defensive. In the introduction to Writing Secure Code, Howard and LeBlanc make the simple observation that the most popular MS Press book on programming, Code Complete 2, does not mention security once.
I will save you some trouble by modernising that statement: programmers still are not told a lot about security as part of software development. Succeeding with Agile does not tell you to adopt secure coding practices, or build security into your backlog. Continuous Delivery tells you that “capacity and security requirements” might exist multiple times, but its only specific recommendation is to use a linter to catch common problems. The Pragmatic Programmer does have a topic, “stay safe out there”, explaining basic security principles. The Pragmatic approach, apparently, is to let somebody else worry about it. Let us hope that some engineers never read that book, or we are a generation or two away from everybody hoping that somebody else is “doing security” for them.
Michael Howard also co-authored a book with Steve Lipner, also in the “Microsoft secure software DEVELOPMENT SERIES” as the cover styles it, called SDL: The Security Development Lifecycle. This book could be treated as a timeless guide to designing security into a software development process. There is a list of banned functions that you might want to update, and a Visual C++ solution on a companion CD that will only work in Visual Studio 2005 apparently, but other than that everything in the book is about how you incorporate security thinking into the other thinking you are doing.
Thinking does not change that much. We have already seen that specific code-level problems identified in Writing Secure Code are still problematic today. So, it turns out, are brain-level problems. Even at ISO 27k-certified companies (the standards series for information security management systems) you will find developers who think that because they are using JWTs, they are secure; and product owners who see all that data coming in and ask who it can be sold to.
The authors of the SDL take us through everything we need to do to integrate security thinking into our software efforts. Starting with before the project kicks off (education, awareness, leadership support), to evaluating whether an SDL is needed, designing security requirements, building and testing them, and making sure software is secure in deployment. They even tell you how to integrate the SDL into those new-fangled Agile™®℗© methods everyone was raving about in 2002. The description is golden:
We’ve heard people claim that <insert popular development method> produces bug-free software. This might be true—and of course, it is true if you know nothing about security bugs, because you wouldn’t recognise a security bug if you had no idea what one was.
There is a bit missing from our story, though. We know how to plan the work into our project, and we know how to address code-level issues, but how do we know what the risks are? How do we understand what the security posture of our app is?
For that, we turn to the third and final of today’s readings, Threat Modeling by Frank Swiderski and Window Snyder. Snyder is a bit of a legend in software security circles. She was at Microsoft for the trustworthy computing initiative, and has held security leadership positions at Apple, Square, Fastly, Intel, and Mozilla (where her title was CSSO: “Chief Security Something-or-Other”). She is currently working on a startup, Thistle Technology, working to improve security of IoT.
The benefit of the Threat Modeling approach is that it is easy to understand and apply. Swiderski and Snyder have handy mnemonics for remembering important ideas. Threats are classified based on their effect with the STRIDE acronym: Spoofing, Tampering, Repudiation, Denial of Service, or Elevation of Privilege. Vulnerabilities and risks are ranked based on their DREAD scores: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.
Elsewhere, the threat modeling process uses skills your team probably already has. How do you identify whether an attacker can leverage some asset using some particular entry point? Build a data flow diagram; your engineers probably already do this on a whiteboard whenever they need to discuss the behaviour of some API call. How do you know what is there to be attacked? Create use scenarios: you probably already have these, and they are probably written in the form “AS A journalist, I WANT TO…”.
Unfortunately Microsoft Press does not carry an up to date equivalent of any of these books. The second edition of Writing Secure Code, from 2003, is still the edition you can buy on their store. You will not find the other two at all; not even the SDL book which only needs someone to port the Visual Studio solution to a modern IDE.
We know that security problems have not gone away, so why are not Microsoft still providing leadership here? Maybe they think their online security development lifecycle guide is sufficient, even though nearly half of the resources are in the Legacy Archive. Maybe thinking about security was a fad, and the people involved are now all thinking about reasoning in type systems or shoveling even more unaudited javascript into everybody’s computers at Microsoft subsidiary npm, Inc. Maybe the original Trustworthy Computing push achieved its goal, and moved the heat onto other vendors.
Whatever the case, software security has not gone away, and its discussion should not be limited to black hat nerds and CISSPs in suits opening calc.exe on each other’s laptops in DefCon meetings. Do yourself and your customers a favour, and find copies of these excellent works in your favourite second hand book store.
Image by the author.
