About a year ago, I wrote a post titled “Keeping E-mail Private“.  Thinking back over the last five months, my advice seems woefully inadequate.  To give the matter of private communications a more proper treatment, I’m going to write a series of articles on the topic of the security of communications systems.  I’m going to expand the scope beyond e-mail, though I’ll have to be picky so I’m not writing until the next century.  In this first article, I’ll be discussing threat modeling.  Later articles will delve into threats of insecure protocols, trusted third-parties and more.  Where possible, I’ll also discuss mitigation strategies so you don’t have to feel that the sky is falling (unless you want to.)
Threat modeling is a tool which allows us to decide which trade-offs we can make.  Some times we will give up security for the sake of convenience and others we will give up convenience for the sake of better security.

Threat Modeling

When we talk about security, it is helpful to know what information we want to secure and what threats exist to the security of the information.  It is not very helpful to say that your e-mail is secure if you don’t specify against what threats it is secure.  One teenager may say to another, “it’s okay to send me anything–my e-mail is secure.”  This implies a just-trust-me approach to security.  Instead, the teenager might say, “my parents don’t read my e-mail.”  (Ignore for a moment that most teenagers don’t bother with old-school technology like e-mail.)  A more common case would be the question of what you can send to your friends at their work e-mail addresses.  (This mattered more before everyone owned a smartphone.)
In the end, it comes down to a question of what information you want to protect and what the threats are to that information.  Information you may want to protect may be e-mail you’ve received (or sent), a password vault, all the information on your smartphone, or remote access to your company’s servers.  Threats against that information might be your parents, spouse or children, your boss, your competitors, bored teenage hackers, Anonymous, or a three-letter agency (TLA).  Each combination of protected information and threat may require a mitigation.

Threat Modeling in Software Design

By the way, threat modeling is not just something you do when you want to protect your e-mail address.  This is a valuable part of the software design process.  It is worth making security a core part of your software because you cannot bolt it on later.
A few years ago, I worked on a game for a large software company.  This company is well-known for writing insecure software, but has taken that as a challenge and has some rigorous processes in place to improve that reputation.  The threat modeling process was extensive, especially for a game, but it showed me that there is value in thinking this through before you start writing code.

A Simple Example

Suppose I have an Ubuntu 12.04 LTS Server running inside a virtual machine at a cloud server provider.  We’ll say that it is hosting a static web site, sshd for remote access and a game server.  (If that list gets too long, I won’t finish this article tonight.)  Let’s generate a quick list of information to protect and threats to that information.
Things to protect include basic functionality of the server, ssh access to the server, the static web site, the game server and many other things we don’t have time to address.  Let’s address these, starting with the static web site, as it should be the simplest.

Target: Static Web Site

I’ve chosen to discuss a static web site to avoid the rabbit trail of security for web programming.  We can discuss that another day.  The hard problems of serving a static web site have all been solved.  Even so, there are some possible threats:

• Denial of Service (DoS) attacks
• Server configuration problems
• Related: server failure under load

Denial of Service attacks are not a common problem for most web sites.  Unless your content is inflammatory or your site must be up, you may choose to accept the risk of this and do nothing.  Alternatively, you may use a service like CloudFlare to mitigate possible attacks.  (Personally, I let a professional host my static web sites.)
Server configuration problems are not likely to be a big problem with a simple site.  However, they may have a big impact.  You may accidentally configure the server to serve valuable information (e.g., the /etc hierarchy) or to fail to authenticate users before serving important information.  You may also be compromised if your HTTP server has a vulnerability in it.  Again, mitigation for these is to learn how to configure the server properly (how hard can it be?) or hire a professional.
Related to the above topics, your server may fail under load.  For example, if you’ve enabled logging of requests and you are on the receiving end of a DoS attack, your log files may fill up their allocated space causing your server to return an error status.  Mitigation for this might be to turn off logging, to log to a third-party service, to log to another host, or to configure log file rotation.  I would mitigate this by configuring log rotation.

Target: SSH Access

Gaining ssh access to a host is a goldmine.  There are lots of people who would be happy to have it on your server.  How might they get it?

• Protocol attacks against sshd
• Scripted attacks using common usernames and passwords
• Guessing a weak or reused password
• Man-in-the-middle attack against careless users

The sshd program, specifically the one from OpenSSH, is a hard target when properly configured.  It’s seen all of the most common attacks and plenty of unusual attempts to break it.  Still, it implements a complex protocol and has access to everything, so it may still be vulnerable.  Unless you are a blackhat at VUPEN or a TLA, you probably aren’t equipped to find vulnerabilities in sshd, so your best mitigation will be to limit IP addresses that can access sshd or use another method of access control like port knocking.
Scripted attacks against common usernames and passwords through ssh happen all day, every day.  Mitigation is obvious: disallow root login, disallow login with passwords and install fail2ban.  If you can’t disallow passwords that (because you let your friends use the system for shells), then do something to make your installation less susceptible (e.g., run a second sshd on a non-standard port and only accept password logins on that port.)
If an attacker guesses a weak or reused password, then you have a user problem.  The solution is education.  Mitigation may be to run a script that tries dictionary attacks against all accounts and locks the account when it succeeds.  If you can’t do this, then have it notify the user with lots of scary words like “Your account has been compromised.  Contact your system administrator immediately.”
If your system is on a hostile network, you and your users may face a man-in-the-middle attack.  Secure shell uses host keys for authentication to mitigate this.  However, if you are not able to use an out-of-band method of learning the host key, or if you are a user that automatically accepts whatever host key comes your way, then you are vulnerable to this.  A possible mitigation to this (aside from the obvious–using OOB communication to learn host keys) is to use something like The Monkeysphere Project.
My plan to protect the sshd is to disable password authentication, disable root logins, use fail2ban, and limit access to specific IP addresses.

Target: Game Server

Game servers are interesting targets.  Games are often the product of a rushed development process, thus their servers tend to be written to lower quality standards relative to other network-facing services.  On the other hand, the protocols are rarely documented, so attacking the protocol takes some effort.  Here are some potential attack vectors for game servers:

• DoS attacks
• Protocol attacks
• Social engineering attacks against unwary administrators

Because game servers are more complex, it is possible that an attacker could craft a request to the server that would consume substantial resources or cause responses to other clients to be slower.  This might be valuable to an attacker if the server is hosting a video game tournament of if the attack is a teenager just doing it for grins.  However, in this case, this is just a form of protocol attack.
Protocol attacks against game servers are often complex, but have a good chance of success because game servers are not often hardened targets.  I’ve heard of one game server that requires only a username for authentication.  That could make for some exciting exploits.  Since most operators are not developing the game server in question, we’ll assume you can’t fix this.  Mitigation is to run the game server as a separate user in a chroot jail.  This should prevent any compromise from becoming a disaster.  Even better would be to use something like Docker to contain the server.
Finally, social engineering is a common attack for game servers.  This works because game server administrators are not security experts and are vulnerable to peer pressure.  Many years ago, I was on a public TeamSpeak 2 server when a group of kids joined and started badgering an administrator.  They gave him a sequence of instructions that made one of them an administrator.  To my shock, the administrator followed the instructions.  The attacker was granted administrator rights and proceeded to make his friends administrators and strip the existing administrator of his rights.  Then they taunted everyone on the server for their foolishness.  It was a good lesson for a small price.  Mitigation for this is to limit the number of administrators and ensure that they are trained on maintaining the security of the system.  (Or you could just reinstall your game server every weekend on a new cloud server.  That seems safer.)

That Wasn’t So Hard

This was a simple example.  I avoided discussion of many other attack vectors like spoofing software updates, timing attacks and information leaks through the shared CPU caches, malicious employees at my hosting provider.  Despite its brevity, I gave you a starting point for modeling threats to your own information systems.
If you’d like to read more about threat modeling, you can read about Death Star Threat Modeling, Threat Modeling Against Apple’s TouchID (but see istouchidhackedyet.com), and XKCD’s take on our current Operating System authorization model.
In my next article, I’ll do some threat modeling of my communication systems and discuss my options for protecting them.  If there is a specific system you would like to discuss, mention it in the comments.