Request for comment. Threat modelling

Grants
#1

I am not sure if this is the right place to post this.

Has any other MG recipients used threat modeler or threaglie before?

Open source:

Pay2Play:

If you watch the ThreatModeler youtube vid it explains why threat modelling is important and how to use it effectively. I would start with that video. The basic idea is moving from reactionary testing to proactive requirements based testing and development, the corner stone of a SDLC.

One huge advantage of using software and automating it is these people have put the OWASP guidelines and requirements in there already. This will save other projects a massive amount of heavy lifting and give you confidence that you are on the right track. The test team even if they have no previous OWASP experience can now also test OWASP stuff as part of their test cycle.

If you are going to submit your project to 3rd party security evaluation then having this done already will save you massive amounts of money and the 3rd party a lot of prep time, so they can spend more time testing.

I have always done the hours of thinking and STRIDE methodology. I am booking a meet with ThreatModeler. I encourage all ZOMG recipients to check it out.

Please post any comments/ideas/criticisms I really would like some feedback on this.

1 Like
#2

Thinking about security as early in the process as possible is definitely ideal. We’ve had the luxury of having security engineers embedded at ECC and before I even wrote a single line of code, they were talking to me about threat modeling. Not all projects have that level of access.

That demo video makes a very compelling sales pitch but that is probably expected since it’s presented by their Director of Sales. Having a tool that can force security conversations earlier in SDLC is useful as long as teams don’t overly rely on “the tool” and develop blind spots in the areas where they don’t use that tool effectively.

1 Like
#3

I agree it is not a silver bullet. but it starts conversations a gives coders guidance. I agree with the sales pitch angle. I am looking forward to talking to them.

One big advantage i can see is mixing this with STRIDE. if I know those requirements are in the database I can spend my time pruning them (I hope the software lets you put reasoning in for why you drop stuff) and use the thinking time to generate corner cases and testcases for things not covered by the OWASP (project specific code for example) not regoing over the spec and linking testcases/requirements that are in the OWASP for basic stuff. It does also seem to feed stuff in nice bite sized chunks to the development team so they are not overwhelmed. - developers not used to doing threat analysis can find it a bit daunting to start.

I really hope the software works how I think it does and how it looks to.

Thanks for the feedback, it is appreciated.

#4

I’ve never tried tools like these so I’m really curious how they end up working for anyone who might try them! For the Zcash light client threat model, I took an approach that kind of inverts the logic of more traditional STRIDE modeling. The key ideas were to:

  1. Keep the threat model simple by forcing it to be written in language users understand. This is important, because if there’s some security property that’s too complicated to understand, or that’s only effective when the user has to make complicated decisions themselves, then even though there may not be any “security bug” in the code, there is still a “secure usability bug” in the relationship between the user and the threat model.
  2. Instead of being a list of possible problems, it’s a list of security guarantees. The idea being you start with zero security guarantees and the team is responsible for shipping new guarantees as though they’re features: write the code, review it, and then add the guarantee to the threat model.

I haven’t really gotten to see how well this kind of inverted modelling (shipping guarantees like features) works in practice yet because our light wallet security guarantees have remained largely the same since I first wrote it, due to other priorities. It would be interesting to find out if doing it this way actually works or is any better or worse than STRIDE-like methodologies.

1 Like
#5

Thanks, I had not see this, it looks really good. It seems you have gone a bit more along the VAST lines - i am not too familiar with that and I havent read it all yet, so forgive me if im wrong here. I am normally quite sceptical of tools like this (ThreatModeler), but it does look useful if for nothing else than the testcases and requirements.

I like the visual aspect. I wonder how compatible it would be with your methodology, it looks flexible and they are VAST proponents.

I really like requirements based testing for SDLC’s ever since i was exposed to them in security testing products that need to guarantee a level of assurance (fintech and above). It works really well in my experience, but requires the developers to be on board with it and is virtually impossible to retrofit.

I think it could complement it, in a small team I still want to do STRIDE, but this should hopefully allow me to just conformance test the OWASP stuff freeing my time up to do the “holistic” security testing. It is going to be interesting. if the cost is right, i think we will try it out on zephyr, if it isn’t then nothing really lost. I really like the idea of giving the ZOMG the report showing how, what and why we are doing the test. I believe it will help them evaluate the product too.

Are you familiar with Process Flow Diagrams as apposed to Data Flow Diagrams, I have always used Data Flow, but they seem keen on Process flow, I am reading up on it but it is always good to hear from someone with real world experience.

Do you (or anyone) have any specific questions or areas you would like me to raise when I speak with them? the more questions I can get from different teams / stake holders the better. This goes for anyone who is reading this and has some questions.

I will ask about the OWASP mobile testing stuff and if they support it and how much of it they support. For my project, I really only need the OWASP stuff and the basic charting (I really think flow charts are the way to do this for developers and non security people.) so hopefully that might allow a discount. they seem to be bespoke pricing models.