J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

How I Explain Threat Modeling to Customers

How I Explain Threat Modeling to Customers

  • Comments 5

Here's my trying to explain threat modeling (actually core modeling) to a customer …

My core theme of the modeling is this:

  • Define what good looks like (e.g. objectives)
  • Establish boundaries of good (constraints, goals -- what can't happen, what needs to happen, what's nice to happen)
  • Identify ests for success (define criteria ... entry criteria and exit criteria ... how do I know when it's good enough)
  • Model to play 'what if' scenarios before going down long-winded dead ends
  • Identify and prototype the high risk end-to-end engineering decisions (to provide feedback, inform the direction, update the objectives)
  • Use an information model (e.g. the web app security frame -- use 'buckets' to organize both decomposition as well as package up the principles, practices, and patterns) ... another trick here is that the frame encapsulates 'actionable' categories ... you're modeling to inform choices and build on other's knowlege
  • Leverage community knowledge. (The information/model frame also helps leverage community knowlege - you don't have to start from scratch or be a subject matter expert - to speak to the dev, you can use patterns, anti-patterns, code samples)
  • Model just enough to reduce your key risks and make informed decisions (look before you leap)
  • Incrementally render your information (you basically spiral down risk reduction ... you identify what you know and what you need to know next
  • Use a set of complimentary activities over a single silver bullet (use case analysis is complimentary to data flow analysis is complimentary to subject object matrix ... etc.; threat modeling does not replace security design inspection or code inspection or deployment inspection)

This is the approach I use whether it's security or performance or any other quality attribute.  In the case of threat modeling, vulnerabilities are the key.  These go in your bug database and help scope test.

  • J.D. --

    I'm not a security expert, but I'm far from clueless and this seems like a solid and useful approach.

    It reminds me, however, of my favorite all-time quote about models...

    "All models are wrong.  Some models are useful."  -- George Box, Industrial Statistician.

    The point being that models are, by design, simplifications of reality to aid in understanding and communication.  If they weren't simplifications, they wouldn't be models -- they would be replications!

    So my note to all your readers is this... Use models, they are powerful!  Don't over-use models, they can steer you away from major issues that will bite you when you least expect it!

    --

    Scott Barber

    President & Chief Technologist, PerfTestPlus, Inc.

    Executive Director, Association for Software Testing

    www.perftestplus.com

    www.associationforsoftwaretesting.org

    sbarber@perftestplus.com

    "If you can see it in your mind...

        you will find it in your life."

  • I always suggest conducting Threat Modeling even in advanced dev cycle stages, although it might seem

  • Threat Modeling is a way to identify potential security issues to help you shape your application's security

  • Threat Modeling is a way to identify potential security issues to help you shape your application's

  • When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and

Page 1 of 1 (5 items)