Reflecting on Threats: The Frame
Reflecting on the framing of the Threats book
Now that the Threats book is out and the first reviews are in (thank you!), I want to talk more about the frame of the book and how the subtitle influenced where the book needed to go.
The subtitle, “What every engineer should learn from Star Wars” is very close to “What every engineer should know,” but catchier. When I questioned if something should be there, I asked ‘does every engineer need to know this?’ and so cut elements like ‘how password storage works’ and called it a side-quest.
This is close to popularization as a goal, and I tried to align with common understanding as much as I could. But there were places that didn’t work, and I’ll come to those. Before I do, I want to talk about the importance and challenge of common understandings.
First, common understandings are important to communication in engineering. If we can’t talk about materials in tension or compression, and expect everyone understands those in the same way, then our jobs are far more difficult, and that inhibits how large or complex the projects we undertake can be.
Second, common understandings allow us to divide and conquer. If I ask Alice to assess spoofing threats, and Bob to assess tampering (etc) and we have a common understsanding of those terms, than I can have a degree of assurance that the components have been addressed. (System complexities remain, of course.)
Third, common understandings allow us to talk about what ‘a reasonable engineer’ would do. Today, no reasonable engineer would fail to do a wind-tunnel test of a new bridge design. Many of the flaws we see in real systems are obvious once we know where to look. (I’m drafting this April 9, and the 3 most recent CVEs are: 2023-29475, unauthenticated attackers can run arbitrary commands; 2023-29478, path traversal; and 2023-30450. (I’m not sure what the bug really is. The pull request mentions a YAML file, so maybe it was expansion of authority from a developer user to arbitrary code in prod?) For a subset of these, I think we’re nearing the point where we can ask questions like ‘were tools available that would have found this at a reasonable cost?’ and if so, were those tools in use, but mis-used, or not in use? Without a standard or even a norm, the best we have is opinion and maybe 20/20 hindsight.
So common understandings are important, and as I wrote, there were several places the common understandings failed. The first was ‘elevation of privilege.’ I use the term out of habit, and even writing about 30450 there, I wrote that it was an elevation issue before editing. The trouble is, privilege and permissions are implementation choices. I write about how adding a user on unix is a matter of permissions (on /etc/passwd) and on windows its the netuseradd() privilege. Setting OS-design religious wars aside, that’s a shaky ground on which to explain fundamentals. Another way to say that is if we can have a debate over which of those is ‘right,’ we’re not talking about fundamentals, but design choices.
Two other places where I felt I had to push the envelope were parsing and kill chains. For parsing, some of the work being done by Langsec is excellent, when its feasible to apply. And for kill chains, I really wanted to draw more on the work of others, but the general-use chains I wanted just didn’t exist. But those will be future posts.
Midjourney: a set of sith, floating in a frame, cinematic, dramatic, professional photography, studio lighting, studio background, advertising photography, intricate details, hyper-detailed, ultra realistic, 8K UHD --v 5 --aspect 16:9