Home Docs Tools Papers Talks Contact



1. What does Trike do?

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. Mostly, this means Trike automatically generates threats (and some attacks) based on a description of the system, but to get this, you have to describe the system to Trike and check out whether these threats & attacks apply. 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.

One often noticed feature of Trike is that the model is live. When you update part of the model, you see changes to the affected parts of the model right away – no need to press a button to recalculate.

2. How does Trike scale? Can Trike be used effectively on very large or very complicated systems?

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 current tool implementation suffers from performance issues right around this maximum human-comprehensible model size, and we do not plan to increase performance beyond what is usable for humans. 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. We do not currently have automated support for relating multiple threat models, but the current tool wouldn’t impede this in any way.

The Trike v1 methodology does not address the issues associated with particularly complex business logic better than any other available methodology. In the current tool implementation, when the rules for a particular action develop a large number of atomic clauses, operations involving the rules become slow, making this issue worse. 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.

3. When is the next release of Trike coming?

Good question. We don’t have a specific date yet. We do not plan to make another release based on the v1 methodology. We are actively coding for the first release for the v2 methodology, which we intend to be a Real Tool, vs. a prototype. Mainly, this means being able to read the files we write out (so that analysts can work together on models like normal people), and that we will write some documentation so you can actually use it. Since v1, we’ve learned even better ways to think about nearly every aspect of threat modeling, which means we are rewriting nearly every part of the back end code. We’ve also found a less buggy and troublesome set of UI widgets, which means we are rewriting nearly every part of the UI. Finally, we’re doing all this in our spare time. The earliest you should expect to see a v2 tool is Q1 2013.

4. What's with the weird UI?

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. In some ways, Squeak was a default decision since our most prolific developer to date doesn’t enjoy coding in any “normal” languages. But there are some objective reasons to use Squeak as well, including that we wanted something cross-platform with good diagramming support (we hope you’ll see this in v2). Squeak is ideally suited for the live feel and dynamic updating we wanted, which has to our surprise been the source of even more positive comments than automating this stuff at all. Finally, in many ways Trike is a research vehicle, and Squeak’s development environment is excellent for prototyping new models for us to experiment with.

5. Why doesn't it ...?

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. Let us know what you want.

6. How do I file a bug?

Please file a bug (or feature or support request) using our ticket system.

7. How do I decode Trike version numbers?

In theory, a Trike version number has 4 parts:

  • a methodology version number, indicating which version of the Trike methodology this version of the tool implements
  • a major tool version number; changes in this number indicate changes in the native file format such that older versions of the tool will not be able to read the default file format written by this tool
  • a minor tool version number; changes in this number indicate bug fixes or other changes which do not impact the native file format
  • possibly, a letter indicating quality:
    • a - alpha
    • b - beta
    • no letter - production release

For example, our next planned release will be named 2.0.0a: methodology version 2, tool version 0.0, approximately alpha quality.

Exceptions: Unfortunately, we numbered a few versions of Trike before deciding on a version numbering scheme. In chronological order,

  • Very early versions 1a-1c and 1aa were released only to our pre-alpha testers, and will not receive real version numbers.
  • Version 1.1.0a should have been released to the public at ShmooCon 2005, but was so buggy it never saw the light of day.
  • Version 1b5 (a.k.a. 1 build 5) was released to the public at ToorCon 2005, and should have been numbered 1.1.1a.
8. Have you seen so-and-so's work on ...?

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.

9. What other threat modeling tools are available?

We are aware of several other threat modeling tools, of varying features and quality. At some point in the future, we may post a threat modeling tool comparison chart. In the meantime, Google is probably your best bet.

10. Who's behind Trike?

Trike is a personal project of Brenda Larcom and Eleanor Saitta, and hopefully other individual developers in the future. Both Brenda and Ella currently work for Stach & Liu, which graciously allows the free flow of ideas to and from Trike and occasionally even funds some documentation or bug fixing, but does not control Trike.

11. How can I get involved in Trike?

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. Join our developer mailing list. 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 mailing list 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.

12. Why is it called Trike?

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.


Copyright © 2004-2008 Brenda Larcom, Eleanor Saitta, and Stephanie Smith. Copyright © 2009-2012 Brenda Larcom and Eleanor Saitta. All rights reserved.