Brief Threat Model for Contact Page

Since this is a site on threat modeling, it makes sense to explain the threat model which led to this contact page. That is, what concerns should we have, how do those interact with requirements, and what can be done to address the threats? Since Adam knows a thing or three about threat modeling, the first approach was to brainstorm and come up with a list of expected threats.

Expected Threats

Based on experience, you might be worried about:

• Spam, spam, spam, and more spam
• Email falling into a black hole
• Vulnerabilities in custom mail code

A more structured approach

But perhaps you can do better than that? Let's see what happens when you apply the lessons of the book. That is, let's sketch a model of the system, use a more structured approach to walk through it, and then mitigate the threats you find. (Foreshadowing: you get different results!)

Build a model

So here's a model:

As you'll learn in chapter 1 of Threat Modeling: Designing for Security, the rounded rectangles are code Adam controls, while the sharp-cornered ones are entities outside his control. The dashed box is a "trust boundary," where everything interacts at the same privilege level.

Walk through the model

The model abstracts spam away from email addresses, and focuses on messages coming in (over some unnamed channel). So you think about that, moving from email to a web front end doesn't remove the spam, it just changes the form. Since we see "contact us" forms all over the web, you might jump to the idea that it's a superior pattern. But every blogger has good evidence that web forms get spam.

The next set of threats is that spam filters eat your email, and not the spammer's email. There's a related threat that your spam filter will eat Adam's response, but you're outside of his trust domain control, so he can't address that threat.

Requirements

There should be a want a way for you to contact Adam where it's easy to have a smart spam filter, that doesn't add risk of vulnerabilities, and is easy to maintain.

Mitigations

There are many ways to mitigate spam threats. Some of the most common are attempts to make mailto links that only work if the spammer is processing the page in some "right" way. You shouldn't trust those, there's too much evidence that spammers are smart about harvesting email addresses.

So what we've decided to do is to use an arbitrary email address and rotate in a new arbitrary email when Adam starts getting spam. (Of course, we'll need to be slightly clever to handle lag.)

Summary

This page gives you an example of a quick and dirty threat model. The model was built in under an hour as we were implementing the contact us page, and asking how to ensure that we don't have exploitable web vulnerabilities in the page. As we thought it through, we realized that the planned design exposed extra attack surface (in the web technologies), required a special anti-spam layer, and didn't provide a great user experience.

A threat model like this shows how you can go from worrying about expected threats to a more refined set of threats and mitigations. It doesn't need to be complex to add business value.