This page sets out some of the ways in which Three Rings keeps your organisation’s data safe.
Three Rings takes the security of your data very seriously. In developing the system, we’ve used as our guidelines recommendations normally reserved for developing financial services websites – we treat all data as being of equal importance to bank and credit card details.
All parts of the system, and our internal policies, are geared towards “failing safe” and minimising risk. We employ defence-in-depth practices, meaning that an attacker would have to penetrate multiple barriers in order to gain illicit access to the system, and we’ve sought guidance from a professional security consultant in order to ensure that data is as well-protected as possible.
We also keep frequent on- and off-site backups, which are tested regularly, and maintain emergency plans in case of “worst case” scenarios.
Security is quite a complex topic, and the question “is it secure” can mean many different things. The rest of this page will cover those different meanings.
Technologies Three Rings uses to help keep data safe
Specific technological solutions to security used by Three Rings include:
- Encrypted web connections – all access to the Three Rings service takes place over a high-grade encrypted connection (just like your bank uses). This includes not only usernames and passwords but the entire contents of every page you see. This prevents an attacker from “sniffing” your traffic and intercepting your data. (More information about “packet sniffing”…)
- Hashed passwords – your Three Rings password is stored using irreversible encryption, which means that not even Three Rings staff can see it. This is important because it means that even if a hacker can somehow find a way to steal your password from inside Three Rings, they still can’t use it. (More information about cryptographic hashing…). Our passwords are encrypted using individually-salted hashes and time-expensive hash functions – which makes us virtually immune to the kinds of attacks famously used against Sony, LinkedIn, Yahoo!, Last.fm, and eHarmony during 2011 and 2012.
- User-provided content is untrusted – any information provided to us by any user is considered to be “untrusted”, and is run through a “white-list” filter before is is displayed to them or to any other user. This prevents an attacker who has already gained access to the system (e.g. a legitimate user gone rogue) from performing Cross-Site-Scripting attacks, which can be used to steal passwords from other users or trick them into giving up extra permissions. (More information about cross-site-scripting…)
- All database access is run through a security-conscious framework – in order to prevent all of the most common website attacks, such as SQL Injection attacks and Path Traversal attacks, our website uses a security-conscious piece of data middleware that checks that data is of the type it expected before it will allow anything to be done with it (it won’t, for example, allow a word to be used when it expected to see a number). (More information about SQL injection… | More information about path traversal attacks…)
- “Secure by design” platform – the operating system and core software on which Three Rings is powered is designed to be secure from the ground up. Unlike operating systems like Microsoft Windows, the Linux system on which Three Rings runs is almost-completely immune to computer viruses and does not allow regular users to perform administrative tasks. (A paper on why Linux is more secure than Windows | More information about secure-by-design implementation…)
- Open-source systems with regular updates – the software that we depend upon is routinely kept up-to-date to the most recent versions. This helps to ensure that if a security vulnerability is found in the tools on which we depend, the window during which that vulnerability can potentially be exploited is made as small as possible. By using trusted open-source technologies, we help to ensure that any such security problems are spotted and fixed quickly (not hidden away by companies who gain little benefit from their publication). (More information about Kerckhoffs’s Principle, which explains why ‘open’ systems are more secure in the long term…)
- Output suppression – our server has been carefully-configured to leak no information about the specifics of the way that it works. It does not expose the types of software running on it, or their version numbers, and does not show detailed error messages when things go wrong. This “need-to-know basis” thinking minimises the attack profile of the system, and – in conjunction with the other security mechanisms we employ – makes it a lot harder for an attacker to find a foothold. (More information about the information-security concept of ‘compartmentalisation’…)
- Two-factor admin access – administrative access to the server itself on which Three Rings is run is locked-down to only be available over encrypted connections, and only where two-factor authentication is present. This means that Three Rings volunteers who’ve been vetted and allowed access to the server must present both a username and password and a special certificate file in order to gain access. (More information about two-factor authentication…)
- Uptime watchdogs – automated processes run by two independent third parties watch our server for any signs that it’s not working. If this happens, Three Rings volunteers are notified by text message and by email, in order that they can respond to any crisis.
What policies does Three Rings CIC have to help keep data safe?
Within Three Rings, we practice good security as a matter of course. Some of our internal policies that help to foster good security include:
- Openness and honesty – our policies and practices are open to scrutiny, and we welcome feedback. We try hard not to hide behind jargon, and we make ourselves accountable by explaining what we do and how we do it (in the matter of security, for example, we don’t just say ‘yes, we’re secure’ – we’re happy to explain why and how we’re secure, so you can make an informed choice. Internally, we practice this same openness: team members are encouraged to keep an eye on one another and spot opportunities for the improvement of security in each other’s work. We also try to notify our users as far in advance as possible of any potential disruptions to the service.
- Selective team membership – the whole Three Rings team are current or former volunteers at organisations that are supported by the service. As well as ensuring that they understand the needs of those organisations, this also helps to guarantee that they have the best-interests of those organisations at heart. On top of that, we only grant server admin access to those volunteers who need it as part of their work.
- The assumption of ill-intent – also known as the “trust no-one” principle, this extends to the way that we deal with others: Three Rings team members are encouraged to think critically and assume the worst-case scenario. For example, if a user emails us having forgotten their password, a Three Rings support team member will find themselves thinking “how can I be sure that this is who they say they are?”, “how can I be sure that they’re legitimately allowed access to the system?”, and so on. This leads inevitably to our more-practical security policies, such as that we won’t reset lost passwords where there’s somebody else at an organisation who can do so.
- Additive permissions – the Three Rings Roles/Permissions model is based on the idea of “additive” permissions: that everybody starts with no permissions and only gains what they’re specifically granted. As opposed to other models, this makes it easier for organisational administrators to maintain the Principle of Least Privilege, which helps to keep them protected from internal threats. (Information about the Principle of Least Privilege…)
- Protecting anonymity – we understand that many Three Rings users would prefer to keep their status as a volunteer at their organisation a secret, and anonymity is a form of security, too, so we take it just as seriously as every other kind. That’s one of the reasons why Three Rings times out if left unattended. It’s also why the login page doesn’t mention anything to do with helplines or your organisation: if somebody checks what websites you’ve been to, or sees the page over your shoulder, it doesn’t identify you as a volunteer of the organisation you’re at. Even our name – Three Rings – is deliberately vague and obscure, so as to not identify the kinds of services we help.
- Automated software testing – as we develop new versions of Three Rings, we use an automated software testing process to ensure that new features do not introduce bugs (and especially security bugs) into existing features. This reduces the likelihood of a critical bug slipping though (and our manual user-testing process acts as a second safety net, as well as a valuable exercise in gathering feedback on new features).
System Backups
The following backup strategy is employed for Three Rings:
- Live “inline”: increasingly, parts of Three Rings are becoming able to keep backups of themselves for a short period, in order to protect against accidental deletion by a volunteer at your organisation.
- Hourly on-site: once per hour, a backup of all of the most-important data (volunteer, rota, news, events, wikis, logs, program code, and configuration) is made to a different computer in the same building. These hourly backups are kept for a fortnight, enabling us to “roll back” to almost any point within the last 14 days (with a margin of error of an hour).
- Daily off-site: once per day, the most-recent hourly backup plus all volunteer photos, certificates, and filestore files are backed up to an off-site repository in a different country to the server (so that in the worst-case-scenario of the building being completely destroyed, we’d still have a recent backup). Each hourly-backup moved offsite in this way is stored for 30 days, giving us a month’s worth of “daily rollback”.
Please note: Three Rings backups are designed to protect the entire system from a major failure of the server: they aren’t intended to protect individual organisations from the accidental or malicious deletion of data by their own volunteers! Where this occurs, we will of course try to help, but organisations are encouraged to keep backups of their own most-important data.
We have a strategy in place, which is periodically tested as a drill, to allow us to bring up a new Three Rings server using the most-recent daily backup, within a few hours notice. The strategy is called the “meteor scenario”, because it holds that if a meteor struck the Three Rings server’s datacentre, wiping out both it and all of the hourly backups, we’d still be able to get the service up and running again within a day, using the previous day’s backup.
Our hourly and daily backups are currently tested every month or so, and we’re working on an automated test system which will perform experimental backup restoration once per day, and email Three Rings volunteers if anything seems to be amiss.