Category: threat modeling

The Architectural Mirror (Threat Model Thursdays)

A few weeks ago, I talked about “reflective practice in threat modeling“, thinking about how we approach the problems we face, and asking if our approaches are the best we can do. Sometimes it’s hard to reflect. It’s hard to face the mirror and say ‘could I have done that better?’ That’s human nature.

Sometimes, it can be easier to learn from an analogy, and I’ll again go to physical buildings as a source. (I last discussed this in “Architectural Review and Threat Modeling“.)

Here, we see 91 units of housing delayed for 3-4 months about the color of the exterior:

A project to create 91 units of microhousing on First Hill will take a second try at getting final sign-off from the board…In June, the board asked that the project return for a second pass citing unhappiness with the choice of cement fiber panel finish to step down at the upper levels of the northern edge of the building and echoing public comment that the color of bricks selected for the building was too dark for the neighborhood’s existing “context.” (Capitol Hill Seattle blog)

Now, Seattle has a very visible crisis of housing and homelessness. These 91 units will likely help 91 people or families get off the street. But…the color of the bricks is wrong, so stay on the streets for an extra few months? I exaggerate for effect and consideration, not of this choice, but to ask for reflection — are there choices imposed by security that make such a tradeoff in your organization?

Are you holding back revenue or customer satisfaction for goals that might wait, or might simply not be as important from an executive standpoint?

And if you have a tracking system for projects, it has to work.

The number of Seattle permit applications completing initial review plummeted 75 percent from April to May, from 266 to 66. Builders say problems with the system are setting their projects back by weeks or months…Soon after launch, the new system repeatedly stalled and permit documents appeared to go missing. Tempers grew so hot that at one point the city called the police on a livid customer… In May, less than 11 percent of medium-complexity projects hit the two-week target. (“Rocky launch of Seattle’s new construction-permit system causes delays, anger.“)

Security can be the reason projects are consistently randomized or miss their deadlines, and when it is, other teams work around us, ignore us, or question why they’re paying for a security function that doesn’t function.

The world is a fine source of opportunities to reflect, if only we take advantage.

Reflective Practice and Threat Modeling (Threat Model Thursday)

Lately, I’ve been asking what takes threat modeling from a practice to a mission. If you’re reading this blog, you may have seen that some people are nearly mad about threat modeling. The ones who say “you’re never done threat modeling.” The ones who’ve made it the center of their work practice. What distinguishes those people from those who keep trying to teach developers about the difference between a hactivist and a script kiddie?

A book I’ve read recently, “The Reflective Practitioner: How Professionals Think In Action,” gives some useful perspective. It’s about how practitioners use the cases and issues before them to grapple with questions like ‘is this the best way to approach this problem?’ It’s not an easy read by any stretch. It engages in analysis of both what makes a profession, and how several professions including architect, psychologist, and town planner engage with their work.

They may ask themselves, for example, “What features do I notice when I recognize this thing? What are the criteria by which I make this judgment? What procedures am I enacting when I perform this skill? How am I framing the problem that I am trying to solve?” Usually reflection on knowing-in-action goes together with reflection on the stuff at hand. There is some puzzling, or troubling, or interesting phenomenon with which the individual is trying to deal. As he tries to make sense of it, he also reflects on the understandings which have been implicit in his action, understandings which he surfaces, criticizes, restructures, and embodies in further action. It is this entire process of reflection-in-action which is central to the “art” by which practitioners sometimes deal well with situations of uncertainty, instability, uniqueness, and value conflict.

Those seeking to advance their practice of threat modeling would do well to pick up a copy and use it as a lens into reflecting on their practice of the arts.

After the jump, I’m going to quote more bits that struck me as I read, and offer some reflection on them.

Continue reading “Reflective Practice and Threat Modeling (Threat Model Thursday)”

Threat Model Thursday: Legible Architecture

The image above is the frequency with which streets travel a certain orientation, and it’s a nifty data visualization by Geoff Boeing. What caught my attention was not just the streets of Boston and Charlotte, but the lack of variability shown for Seattle, which is a city with two grids.

But then there was this really interesting tidbit, which relates to threat modeling:

Kevin Lynch defined “legible” cities as those whose patterns lend themselves to coherent, organized, recognizable, and comprehensible mental images. These help us organize city space into cognitive maps for wayfinding and a sense of place.

One of the questions I get all the time is ‘what’s the right way to model this system?’ And the answer is the right way is the way that helps you find threats. A good system model balances detail with abstraction. It’s laid out in a way that uses space and relative position to help the viewer follow a story.

Sometimes the underlying physical or logical reality makes that easy. Other times, the reality is more like the streets of Boston, and the official map draws a simple picture with the southern Red Lines being the same length, and similar visual portrayal of the Green Line. But the second map, from http://www.urbanrail.net/am/bost/boston.htm, shows a very different picture.

Boston Subway Map official
Boston map geographic

What’s the right model? What’s the legible architecture of a system?

Modeling a system that’s grown organically over decades is a very challenging task. That’s true of Windows, that’s true of many large enterprise systems, that’s true of the air traffic system. One of the advantages that cloud architectures bring is the opportunity to sweep away some of that historical complexity, and to create comprehensible models. That simplification carries value in terms of architectural consistency, makes it easier to impose checkpoints, and will be augmented over time with the accretion of complexity, inflexibility and eventually need to be swept away itself. That’s rarely easy even when computers are like crops, rather than like pets.

As your threat modeling evolves, it’s important to ask: what’s the legible architecture of these systems?

That’s emphatically not because legible architecture is a goal. It’s a tool. Having understandable models of your systems makes it easier for everyone to interact with them, and that makes design easier, it makes evolution easier. Legible architecture is a property that makes other properties easier to achieve.

Threat Modeling Thursday: 2018

Since I wrote my book on the topic, people have been asking me “what’s new in threat modeling?” My Blackhat talk is my answer to that question, and it’s been taking up the time that I’d otherwise be devoting to the series.

As I’ve been practicing my talk*, I discovered that there’s more new than I thought, and I may not be able to fit in everything I want to talk about in 50 minutes. But it’s coming together nicely.


The current core outline is:

  • What are we working on
    • The fast moving world of cyber
    • The agile world
    • Models are scary
  • What can go wrong? Threats evolve!
    • STRIDE
    • Machine Learning
    • Conflict

And of course, because it’s 2018, there’s cat videos and emoji to augment logic. Yeah, that’s the word. Augment. 🤷‍♂️

Wednesday, August 8 at 2:40 PM.

* Oh, and note to anyone speaking anywhere, and especially large events like Blackhat — as the speaker resources say: practice, practice, practice.

Threat Modeling Thursday: 2018

So this week’s threat model Thursday is simply two requests:

  1. What would you like to see in the series?
  2. What would you like me to cover in my Blackhat talk, “Threat Modeling in 2018?”

“Attacks always get better, and that means your threat modeling needs to evolve. This talk looks at what’s new and important in threat modeling, organizes it into a simple conceptual framework, and makes it actionable. This includes new properties of systems being attacked, new attack techniques (like biometrics confused by LEDs) and a growing importance of threats to and/or through social media platforms and features. Take home ways to ensure your security engineering and threat modeling practices are up-to-date.”

Threat Model Thursdays: Crispin Cowan

Over at the Leviathan blog, Crispin Cowan writes about “The Calculus Of Threat Modeling.” Crispin and I have collaborated and worked together over the years, and our approaches are explicitly aligned around the four question frame.

What are we working on?

One of the places where Crispin goes deeper is definitional. He’s very precise about what a security principal is:

A principal is any active entity in system with access privileges that are in any way distinct from some other component it talks to. Corollary: a principal is defined by its domain of access (the set of things it has access to). Domains of access can, and often do, overlap, but that they are different is what makes a security principal distinct.

This also leads to the definition of attack surface (where principals interact), trust boundaries (the sum of the attack surfaces) and security boundaries (trust boundaries for which the engineers will fight). These are more well-defined than I tend to have, and I think it’s a good set of definitions, or perhaps a good step forward in the discussion if you disagree.

What can go wrong?

His approach adds much more explicit description of principals who own elements of the diagram, and several self-check steps (“Ask again if we have all the connections..”) I think of these as part of “did we do a good job?” and it’s great to integrate such checks on an ongoing basis, rather than treating it as a step at the end.

What are we going to do about it?

Here Crispin has assessing complexity and mitigations. Assessing complexity is an interesting approach — a great many vulnerabilities appear on the most complex interfaces, and I think it’s a useful strategy, similar to ‘easy fixes first’ for a prioritization approach.

He also has “c. Be sure to take a picture of the white board after the team is done describing the system.” “d. Go home and create a threat model diagram.” These are interesting steps, and I think deserve some discussion as to form (I think this is part of ‘what are we working on?’) and function. To function, we already have “a threat model diagram,” and a record of it, in the picture of the whiteboard. I’m nitpicking here for two very specific reasons. First, the implication that what was done isn’t a threat model diagram isn’t accurate, and second, as the agile world likes to ask “why are you doing this work?”

I also want to ask, is there a reason to go from whiteboard to Visio? Also, as Crispin says, he’s not simply transcribing, he’s doing some fairly nuanced technical editing, “Collapse together any nodes that are actually executing as the same security principal.” That means you can’t hand off the work to a graphic designer, but you need an expensive security person to re-consider the whiteboard diagram. There are times that’s important. If the diagram will be shown widely across many meetings; if the diagram will go outside the organization, say, to regulators; if the engineering process is waterfall-like.

Come together

Crispin says that tools are substitutes for expertise, and that (a? the?) best practice is for a security expert and the engineers to talk. I agree, this is a good way to do it — I also like to train the engineers to do this without security experts each time.

And that brings me to the we/you distinction. Crispin conveys the four question frame in the second person (What are you doing, what did you do about it), and I try to use the first person plural (we; what are we doing). Saying ‘we’ focuses on collaboration, on dialogue, on exploration. Saying ‘you’ frames this as a review, a discussion, and who knows, possibly a fight. Both of us used that frame at a prior employer, and today when I consult, I use it because I’m really not part of the doing team.

That said, I think this was a super-interesting post for the definitions, and for showing the diagram evolution and the steps taken from a whiteboard to a completed, colored diagram.

The image is the frontspiece of Leviathan by Thomas Hobbes, with its famous model of the state, made up of the people.

Continuum Interview

Continuum has released a video of me and Stuart Winter-Tear in conversation at the Open Security Summit:

“At the recent Open Security Summit we had the great pleasure of interviewing Adam Shostack about his keynote presentation “A seat at the table” and the challenge of getting security involved in product and application design. We covered numerous topics from the benefits brought to business by threat modeling to pooping unicorns.”

Threat Model Thursday: Architectural Review and Threat Modeling

For Threat Model Thursday, I want to use current events here in Seattle as a prism through which we can look at technology architecture review. If you want to take this as an excuse to civilly discuss the political side of this, please feel free.

Seattle has a housing and homelessness crisis. The cost of a house has risen nearly 25% above the 2007 market peak, and has roughly doubled in the 6 years since April 2012. Fundamentally, demand has outstripped supply and continues to do so. As a city, we need more supply, and that means evaluating the value of things that constrain supply. This commentary from the local Libertarian party lists some of them.

The rules on what permits are needed to build a residence, what housing is acceptable, or how many unrelated people can live together (no more than eight) are expressions of values and priorities. We prefer that the developers of housing not build housing rather than build housing that doesn’t comply with the city’s Office of Planning and Community Development 32 pages of neighborhood design guidelines. We prefer to bring developers back after a building is built if the siding is not the agreed color. This is a choice that expresses the values of the city. And because I’m not a housing policy expert, I can miss some of the nuances and see the effect of the policies overall.

Let’s transition from the housing crisis here in Seattle to the architecture crisis that we face in technology.

No, actually, I’m not quite there. The city killed micro-apartments, only to replace them with … artisanal micro-houses. Note the variation in size and shape of the two houses in the foreground. Now, I know very little about construction, but I’m reasonably confident that if you read the previous piece on micro-housing, many of the concerns regulators were trying to address apply to “True Hope Village,” construction pictured above. I want you, dear reader, to read the questions about how we deliver housing in Seattle, and treat them as a mirror into how your organization delivers software. Really, please, go read “How Seattle Killed Micro-Housing” and the “Neighborhood Design Guidelines” carefully. Not because you plan to build a house, but as a mirror of your own security design guidelines.

They may be no prettier.

In some companies, security is valued, but has no authority to force decisions. In others, there are mandatory policies and review boards. We in security have fought for these mandatory policies because without them, products ignored security. And similarly, we have housing rules because of unsafe, unsanitary or overcrowded housing. To reduce the blight of slums.

Security has design review boards which want to talk about the color of the siding a developer installed on the now live product. We have design regulation which kills apodments and tenement housing, and then glorifies tiny houses. From a distance, these rules make no sense. I didn’t find it sensible, myself. I remember a meeting with the Microsoft Crypto board. I went in with some very specific questions regarding parameters and algorithms. Should we use this hash algorithm or that one? The meeting took not five whole minutes to go off the rails with suggestions about non-cryptographic architecture. I remember shipping the SDL Threat Modeling Tool, going through the roughly five policy tracking tools we had at the time, discovering at the very last minute that we had extra rules that were not documented in the documents that I found at the start. It drives a product manager nuts!

Worse, rules expand. From the executive suite, if a group isn’t growing, maybe it can shrink? From a security perspective, the rapidly changing threat landscape justifies new rules. So there’s motivation to ship new guidelines that, in passing, spend a page explaining all the changes that are taking place. And then I see “Incorporate or acknowledge the best features of existing early to mid-century buildings in new development.” What does that mean? What are the best features of those buildings? How do I acknowledge them? I just want to ship my peer to peer blockchain features! And nothing in the design review guidelines is clearly objectionable. But taken as a whole, they create a complex and unpredictable, and thus expensive path to delivery.

We express values explicitly and implicitly. In Seattle, implicit expression of values has hobbled the market’s ability to address a basic human need. One of the reasons that embedding is effective is that the embedded gatekeepers can advise, interpret in relation to real questions. Embedding expresses the value of collaboration, of dialogue over review. Does your security team express that security is more important than product delivery? Perhaps it is. When Microsoft stood down product shipping for security pushes, it was an explicit statement. Making your values explicit and debating prioritization is important.

What side effects do your security rules have? What rule is most expensive to comply with? What initiatives have you killed, accidentally or intentionally?