Security Principles in 2023
Principles are lovely, but do they lead us to actionable results?
Security principles are one of those secure design approaches that are so obvious that it’s hard to argue with them. Twenty years ago, I used Star Wars to illustrate Saltzer and Schroeder’s principles.
Right now, I want to talk about the evolution of my thinking to contribute to a dialog about how and when to use principles in security engineering.
In 2005, my view of security engineering was centered on adversarial reviews. I felt the best reviews had the most cutting insights, and conflict was a natural, even desirable result of quality findings, often ones that were hard to address. Principles are an excellent tool for that. “Your (software) is not (principle) enough!”
Fast forward to when we cleaned up the Microsoft SDL in 2008 or so (maybe v2?), I had an argument with several people because I really wanted to keep the principles in our developer education. They made the case that the principles were imprecise, hard to evaluate, and almost never came up in engineering discussion. Those were all fine reasons to stop. The only reason to keep them was to avoid giving outside critics ammo. But critics are going to critique, and we wanted to focus on the highest return tools we had. (In hindsight, there was another choice we might have made, to improve either our teaching or the principles themselves. But I don’t think that came up, because there wasn’t enough evidence that we should invest in principles.)
My views on design principles have evolved. Since writing my Principles illustrated with Star Wars posts nearly twenty years ago and teaching thousands of developers about threat modeling and security design. By 2023, I’ve observed that design principles are harder to learn and apply than threat modeling techniques. It’s not that the principles are bad — I think most have stood the test of time — but I’ve seen that applying principles in design analysis requires careful analysis, abstraction, and the ability to conceive and compare a set of designs. It’s both a more nuanced skillset, and the results are harder to assess. If you ask two experts to apply the principles, you may get very different results. For example, is “Run as a normal user, not Administrator” a good application of Least Privilege? Does it require running as a sandboxed “Modern” app? More segmentation? The choice about how far to take a principle makes it both harder to teach and harder to apply.
Today, I think of principles as one of the types of design tool that can be used to evaluate or improve a design. That set also includes formal methods, security patterns, root cause analyses, and threat modeling. Formal methods are finally making a transition to practice. Security patterns seem stuck as another approach that’s so obvious that they’re hard to argue with, but developing useful patterns seems empirically hard. Root cause analysis is helping us deal with families of memory corruption by showing the need to improve platforms and languages.
Above, I said that principles are excellent tools for “Your X is not Y enough!” That’s true, but incomplete. Senior engineers can and should use principles as rubrics, as distillations of wisdom, and as reminders of properties their systems should have. All else being equal. Which it never is, and that’s what makes principles more useful to more senior practitioners. Their experience leads them to be more willing and able to consider alternative designs. That’s what makes them more worth teaching in a college course than a two or three day training.
I also said that most of the Principles had stood the test of time, and that begs the question, which haven’t? I think the worst faring is Least Common Mechanism. We’ve learned it’s hard to get software right, and the principle seems to lead people to re-invent the wheel. (I think the principle could possibly be restated today to “Isolate system components”, but it’s only about that when you get to the explanation. The principle itself is misleadingly named/summarized.) The second worst faring is Least Privilege. Privilege is simply a hard concept, and as I discuss at length in Threats, Authority is a good replacement.
For all those issues, I think that understanding principles and how to use them is part of what makes a senior engineer. Today in my Masters-level, quarter-long Security Engineering course, I teach both their work and those of Paul Van Oorschot (in Chapter 1 of his excellent Computer Security and the Internet: Tools and Jewels from Malware to Bitcoin).
Lastly, as an aside, a principle is “a fundamental truth or proposition that serves as the foundation for a system of belief.” A principal is “first in order of importance; main” or “the person with the highest authority or most important position.”
Image by Midjourney, “stone tablets displayed on tall pedastals under spotlight in a museum, professor giving a lecture. The room is brightly lit with sunlight streaming in.”