We have found that systems with more than about a dozen actors and a dozen assets are difficult to model as one system using Trike v1. One human reader/user of a threat model must be able to read/use the model to hold some view of the entire system in his or her head. When a model contains too many assets or actors, it is hard for a human being (even one used to using the Trike tool's grids for visualization) to grasp the big picture all at one time. The solution is to break the system into smaller pieces, without losing anything important between the smaller systems that you decide to model. We have some experience doing this and plan to publish our results (both working and nonworking strategies) when we have time to write them up.

Trike v1 does not address the issues associated with particularly complex business logic better than any other available methodology. Our thoughts for Trike v2 (still unpublished, no, you didn't miss anything) look promising in this regard but we have not tested it on a sufficiently complicated system, and will be unable to do so until we have written a v2 tool.

Please assume that we haven't, even if it's really obvious to you. If you'd like us to know about it, please contact us so we can go take a look.

The goal of the Trike tool is to automate the repetitive parts of threat modeling, so that all an analyst has to do is analyze the system, i.e. think. Since it's the Trike tool, we're using the Trike methodology's view of what is automatable and what requires thinking. In general, later versions of the tool automate more than earlier versions. Different versions may try automating things in different ways, or with drastically different human interfaces. Each version's feature list is the final word on what a specific version does.

That's a good question; why don't you check back next week and maybe we can tell you then?

The current tool implementation suffers from the same scalability issues as the methodology. We do not currently have automated support for the suggested methodology workarounds, but the tool wouldn't impede them in any way.In addition, when the rules for a particular action develop a large number of atomic clauses, operations involving the rules become slow in the current Trike implementation. If this is causing trouble for you, please let us know -- large improvements are probably possible.

In some cases, it's that way because we've found some benefit in it. In other cases, that's the native behavior of our underlying platform, Squeak.

Probably, nobody wrote code for that yet. Maybe we haven't thought of it, or maybe we don't know how important it is to your process so we didn't make it a high priority. File a feature request in our bug tracking system so we know what you want.

Please visit our bug tracking system. If you got an error message inside Trike and pressed the file bug report button, we should already have your information & the bug will show up in the bug tracking system within a day or two. If it doesn't, please file the issue manually, and note in the bug that the automatic filing didn't work correctly for you.

We are aware of several other tools which purport to be threat modeling tools. We have not tried most of these tools, and in many cases do not know whether they would fit our definition of threat modeling tools. At some point in the future, we may post a threat modeling tool comparison chart.

Trike is a personal project of Brenda Larcom, Eleanor Saitta, Michael Eddington & Stephanie Smith. Trike does not have any corporate sponsors.

The first, most important thing to do is contact us. Send us links to interesting papers, or (relevant :) ) ideas you had in the shower this morning, or feedback on our papers. Try our tool and tell us what you like and don't like (be specific, so we have a chance to improve). File some bugs or feature requests. If you know or want to learn Smalltalk, try your hand at fixing some bugs (it would probably be least frustrating for you to announce on the IRC channel that you are about to do this, so we can be helpful). If you like to live on the edge, ask to be one of our early testers, and use early Trike pre-releases. If you are working on a related tool and would like to interoperate with us, we would love to interoperate with you; please contact us so we can work out the details.

Oddly, no one has ever brought this topic up without prompting. If anyone ever asks you, invent an answer. That's what we'd probably do.