Choosing a new database? Be sure to ask these security questions.

Security matters.

Hundreds (thousands?) of nonprofits around the world have been affected by Blackbaud's recent ransomware attack, including the National Trust, University of York, and Islamic Relief.

While it's certainly true that most data-breaches come as the result of human error (rather than a technical "hack"), technology providers have a critical part to play in keeping your data safe.

If you're choosing a new database for storing your supporter or client information, it's important to make sure that it's secure.

In this article, I'll sum up industry best-practice in 10 questions you can ask a potential provider about security. Let's jump right in!

1. Is our data encrypted-in-transit?

Encryption-in-transit means that your data is encrypted while it's moving around. For example, if you opened up your database to check a supporter's information, the data would "move" from your database to your browser.

If you're using a cloud-based system, the most important aspect here is that the URL that you access your database from should start with https:// like so:

Traditionally, this was known as an "SSL certificate", but SSL has known vulnerabilities - the successor to this is TLS.

Your database should be using TLS version 1.2, or greater.

2. Is our data encrypted-at-rest?

Encryption-at-rest means that your data is encrypted while it's being stored.

Theoretically, encryption at rest means that even if a bad actor were to gain access to the database files, they wouldn't be able to see any of it.

Usually, this is implemented at the "disk level", meaning that the disk drive itself is encrypted. This is just like enabling device encryption on Windows, except that it's done on your database.

You'll want to make sure that all of your sensitive information (supporter details, payment records) is encrypted at rest.

3. Is a firewall used to prevent the database from being open to the public?

Firewalls ensure that only authorised servers/users have access to the underlying database.

For example, if you wanted to try and connect directly to one of our underlying databases at Beacon, you couldn't, even if you had the access credentials!

That's because of firewalls - only our application servers have direct access. At Beacon, we use Amazon's Virtual Private Cloud for this.

As a side point, this is exactly why VPNs are often used for on-premise databases. You need to login into the VPN (to get behind the firewall) to be able to access the systems that matter. With most cloud-based systems, this isn't a requirement, as the database isn't stored on a server in your office.

4. Have you always supported two-factor authentication?

Also known as "multi-factor authentication", this gives you an additional layer of security on top of a password. Every time you login to a software provider (e.g. Outlook 365), you'll need to also enter a unique code - either from an app on your phone, or from an SMS sent to you.

Two-factor authentication ensures that someone can't access your database, even if they know your password.

It's really important that two-factor authentication is baked into the core of the product, not an afterthought. You should ask your provider how long two-factor authentication has been a feature, and be wary if it is a recent addition - it's a really fundamental security feature that should be there from day 1. I'd also really recommend you enable it on every system that supports it!

Interested to learn more? Here's a useful video from Duo explaining how two-factor authentication works:

5. If someone logs into my account on a new device, do you send me an email?

Chances are, when you login to your system, you'll be doing it from the same device(s) each time.

If someone unauthorised manages to get access to your account (i.e. they guess your password), you'll want to be notified immediately, so you can change your password to lock them out.

This email gives you that notification! Here's an example:

6. Do you have a strong password policy? What is it?

Strong passwords get a bad reputation, but they're important. Length of passwords is the most important aspect, but additional characters (e.g. numbers and symbols) also help to make passwords more secure.

Your database should force all users to create a password that's secure.

There are also publicly available lists of the most popular passwords in the world ("Password1", "manchest" and "truelove" are all in this list!).

Ideally, it shouldn't be possible to use any of them when setting up a new password.

7. Is our data backed up? How often? Are the backups encrypted-at-rest?

Accidents happen! It's sometimes possible to delete something you shouldn't have.

Additionally, the database provider should also have their own disaster recovery policy specifically to handle mistakes on their end.

Like the database itself, backups should also be encrypted-at-rest, ensuring that if a bad actor gains a copy of the backup, it's unusable.

8. Is card processing PCI compliant?

PCI compliance is a requirement if you're processing card details online. We've written about this at length previously on this blog.

If the system you're providing offers payment processing, it's important to verify that their credit card processing is PCI compliant.

If they're using a third-party provider like Stripe, the answer to this is usually "yes".

Stripe has a fantastic guide to PCI compliance, if you'd like to learn more.

Also, at this point I'd also like to emphasise that you should never store credit card details, in a database or otherwise. They should live securely with the payment gateways.

9. Do you keep your software packages up-to-date?

The majority of software products today depend on open source software. Security vulnerabilities are often identified in these software packages, making it important for any software product to keep up-to-date with the latest security patches.

Each company should have a process for keeping these up-to-date to ensure the security of their software isn't negatively affected by security issues with dependencies. GitHub for example, offers helpful alerts:

10. Is your software architecture designed to prevent against "brute-force" attacks?

One of the most common kinds of hacks today is a DDoS (Distributed Denial-of-Service) attack. These attacks work by trying to overwhelm a system to bring down its servers, and potentially discover a vulnerability in the process.

Modern cloud infrastructure is designed specifically to prevent this kind of attack, through the use of CDNs (content delivery networks) and otherwise.

There you have it! There's always more that technology companies can do on the security front, but these 10 questions are a great starting point.

Like onions (and ogres), security has layers. The more layers of security you have, the safer your data will be.