Copyright © 1999–2018 FastMail Pty Ltd
This blog post is part of the FastMail 2014 Advent Calendar.
Technical level: low
This is the first of a series of blog posts on security, both FastMail's approach to various threats, and how the location of our servers interacts with security risks. We're not digging into the technical details yet, just looking at an overview of what security means.
I always recommend that people read this humorous paper by James Mickens at Microsoft Research (pdf). There are a ton of security in-jokes there, but he makes some really good points.
Another great place to learn more about security best practices is Bruce Schneier's blog. He's been thinking about this stuff for a long time, and is one of the world's acknowledged experts on computer security.
Security consists of three things: Confidentiality, Integrity and Availability. There's a good writeup on wikipedia and also a fairly good post on blog overflow - except that it falls for the trap of defining integrity as only protecting information from being modified by unauthorized parties.
Honestly, the biggest "security risk" to data integrity in the history of email has been the unreliable hard drives in people's home computers dying, and all the email downloaded by POP3 over the years being lost or corrupted badly in a single screeching head-crash. For us, the biggest integrity risk is hardware or disk failures corrupting data, and I'll write more about some of the corruption cases we've dealt with as well.
We care about all three security components at FastMail, and work to strike a sensible balance between them. There's a joke that to perfectly secure a server you need to encase it in concrete deep under ground, and then cut off the power and network cables. It's funny because there's a hint of truth.
To be useful, a server has to be online. And that server is running imperfect software on imperfect hardware, which may have even been covertly modified (not just by the NSA either - anyone with a big enough budget and no regard for the law can pull off something like that).
Thankfully, the same security processes and architectures that defend against system failures are also good for protecting again active attackers. We follow best practices like running separate physical networks for internal traffic, restrictive firewalls that only allow expected traffic into our servers, following security announcement mailing lists for all our software, and only choosing software with a good security record.
That's the baseline of good security. In the following blogs, we will look at some of the specific things that FastMail does to protect our systems and our users' data.