Category: threat modeling

Nature and Nurture in Threat Modeling

threat modeling No Comments

Josh Corman opened a bit of a can of worms a day or two ago, asking on Twitter: “pls RT: who are the 3-5 best, most natural Threat Modeling minds? Esp for NonSecurity people. @adamshostack is a given.” (Thanks!)

What I normally say to this is I don’t think I’m naturally good at finding replay attacks in network protocols — my farming ancestors got no chance to exercise such talents, and so it’s a skill I acquired. Similarly, whatever leads me to be able to spot such problems doesn’t help me spot lions on the savannah or detect food that’s slightly off.

If we’re going to scale threat modeling, to be systematic and structured, we need to work from a body of knowledge that we can teach and test. We need structures like my four-question framework (what are we working on, what can go wrong, what do we do, did we do a good job), and we need structures like STRIDE and Kill Chains to help us be systematic in our approaches to discovering what can go wrong. Part of the reason the framework works is it allows us to have many ways to threat model, instead of “the one true way.”

But that’s not a sufficient answer: from Rembrandt to Da Vinci, artists of great talent appear from nowhere. And they were identified and taught. The existence of schools, with curricula and codification of knowledge is important.

Even with brilliant artists (and I have no idea how to identify them consistently), we need more people to paint walls than we need people to paint murals. We need to scale the basic skills, and as we do so we’ll learn how to identify the “naturals.”

Photo: Max Pixel.

threat modeling No Comments

This is a really interesting post* about how many simple solutions to border security fail in the real world.

  • Not everywhere has the infrastructure necessary to upload large datasets to the cloud
  • Most cloud providers are in not-great jurisdictions for some threat models.
  • Lying to border authorities, even by omission, ends badly.

Fact is, the majority of “but why don’t you just…” solutions in this space either require lying, reliance on infrastructure that may be non-existent or jurisdictionally compromised, or fails openly.

The “post” was originally a long Twitter thread, which is archived, for the moment, at ThreadReader App, which is a far, far better UI than Twitter.

Threat Modeling as Code

Software Engineering threat modeling No Comments

Omer Levi Hevroni has a very interesting post exploring ways to represent threat models as code.

The closer threat modeling practices are to engineering practices already in place, the more it will be impactful, and the more it will be a standard part of delivery.

There’s interesting work in both transforming threat modeling thinking into code, and using code to reduce the amount of thinking required for a project. These are importantly different. Going from analysis to code is work, and selecting the right code to represent your project is work. Both, like writing tests, are an investment of effort now to increase productivity later.

It’s absolutely worth exploring ways to reduce the unique thinking that a project requires, and I’m glad to see this work being done.

Linkedin Learning: Producing a Video

threat modeling 1 Comment

My Linkedin Learning course is getting really strong positive feedback. Today, I want to peel back the cover a bit, and talk about how it came to be.

Before I struck a deal with Linkedin, I talked to some of the other popular training sites. Many of them will buy you a microphone and some screen recording software, and you go to town! They even “let” you edit your own videos. Those aren’t my skillsets, and I think the quality often shines through. Just not in a good way.

I had a great team at Linkedin. From conceptualizing the course and the audience, through final production, it’s been a blast. Decisions that were made were made because of what’s best for the student. Like doing a video course so we could show me drawing on a whiteboard, rather than showing fancy pictures and implying that that’s what you need to create to threat model like the instructor.

My producer Rae worked with me, and taught me how to write for video. It’s a very different form than books or blogs, and to be frank, it took effort to get me there. It took more effort to get me to warm up on camera and make good use of the teleprompter(!), and that’s an ongoing learning process for me. The team I work with there manages to be supportive, directive and push without pushing too hard. They should do a masterclass in coaching and feedback.

But the results are, I think, fantastic. The version of me that’s recorded is, in a very real way, better than I ever am. It’s the magic of Holywood 7 takes of every sentence. The team giving me feedback on how each sounded, and what to improve.

The first course is “Learning Threat Modeling for Security Professionals.”

Scaling Threat Modeling Training

threat modeling No Comments

For the last few years, I’ve been delivering in-person threat modeling training. I’ve trained groups ranging from 2 to 100 people at a time, and I’ve done classes as short as a few hours and as long as a week.

That training is hands on and intense, and I’m very proud that my NPS customer satisfaction ratings tend to come in around 60-70, up there with Apple and Nordstroms. At the same time, in person training doesn’t scale to the millions of developers, SRE, DevOps practitioners, and even security folks who could and should learn threat modeling.

That’s why I’m super-excited to announce that Linkedin Learning (formerly Lynda.com) has launched my new course: Introduction to Threat Modeling for Security Professionals.

I’m also pleased to say that the complete 42 minute course is free via that link.

Lastly, I see the offerings as complimentary: each fits a niche and has its own advantages and disadvantages. In person, students get all the time they want to ask questions. Online, you get videos in 4 minute chunks.

The Architectural Mirror (Threat Model Thursdays)

Threat Model Thursdays 1 Comment

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.

Theme: Ephemeris.

MENU

Navigation