IT on a Budget: 7 Ways to Secure Your Database and Protect Donor Info

For nonprofit organizations, finding high-quality, low-cost IT resources can be a challenge. You may not have staff in-house with a deep enough background in technology to know what the best decisions are. Also, what you are told you need may exceed your budget. This is especially true when it comes to data protection.

Your donors are your greatest asset, and the last thing they want is to have to worry about whether or not you are preventing their personal information from being stolen. For many nonprofits, a database compromise could mean a severe curtailing of activities or even a collapse of the organization as donors would potentially stop giving due to a loss of trust in your ability to keep their personal data protected.

If you can’t hire full-time IT staff to manage your own server, one option is to contract with a hosting provider. A hosting provider will lease you space on its server, providing the administrative support, infrastructure and software needed to manage your website. This service firm should be the first place to look for improved security.

We live in an age of ongoing cyber wars, with hackers always on the prowl for their next victims. And with large for-profit companies like Target and Sony being hacked, every nonprofit needs to accept that they, too, are at risk. Given that reality, here are some best practices for nonprofit data security you should insist on from your IT staff or hosting provider. Yes, they mean more work for all users, but these measures could be all that stand between you and a devastating cyberattack.

1. Different usernames and passwords for each person who needs access to your database(s) and different passwords for each application. Database permissions (which give access to different parts of the database) are controlled based on user settings. It’s important not to have a shared, universal or even division-by-division username and password, because when you control permissions on a person-by-person basis, you can limit access to certain data, prohibit the imputing of certain data or even prevent the viewing of certain data. Also, in the event that a username and password are compromised, having limited the abilities of that username/password combination can reduce unauthorized access to sensitive data, and potentially reduce your risk of data loss or compromise.

2. Access to the database should not only be restricted by username and password, but also by IP addresses and virtual private network (VPN). With the exception of the necessary segue to access needed data through the VPN, no public access should be allowed to your database. This further reduces your risk of compromise in the event a username and/or password becomes compromised, as long as the person who has compromised the username and password data hasn’t also compromised the VPN or allowed IP addresses that will enable someone to hack the database by brute force. This is the process of attempting to access the database by systematically trying passwords and usernames until the correct one is found, and then connecting to and logging into the database. A brute force attack has the potential to take your site offline simply by filling your database logs with authentication errors.

3. Ensure passwords are 16 characters long and include at least one of each of the following: an uppercase letter, a lowercase letter, a number and a special character. Yes, this will cause users to complain, but it makes passwords harder to crack in a brute force attack.

4. If possible, have multifaceted authentication for any server access. There are third-party vendors that offer this type of service and give you one more way to reduce your risk of compromise.

5. If your organization is using Microsoft SQL Server (MSSQL), disable the user “SA” that was created in the installation stage. This is a well-known account and is the most easily brute-forced user in MSSQL. Instead, create a separate administrative username and password (make it difficult), and then insist that no one but your IT/database administrator knows these “admin" credentials.

6. Make sure your web and database engines are fully patched and up to date. New patches do more than fixing bugs—they also correct known vulnerabilities. Using outdated software and/or not applying patches can lead to serious problems. To find out if your version is outdated, Google its version (e.g., MySQL 5.1). If it has reached its end of life, the vendor is no longer supporting that version or patching its vulnerabilities, making you more susceptible to attacks and compromises.

7. Make sure your servers are Payment Card Industry (PCI) Data Security Standard compliant if you accept donations online, and that the database tables that include sensitive customer information, including credit card information, is encrypted. You can typically find a free trial or low-cost PCI scan provider by Googling “free PCI scan” or a similar search term. Examples include HackerGuardian (Comodo), TrustGuard and Security Metrics. These scans identify what needs to be fixed to make you PCI compliant—anything that is out of compliance is a known vulnerability that allows easier access to cyber terrorists and hackers. Any organization that accepts credit cards for donations or payments should, at minimum, be PCI compliant.

Nonprofit data security is a big deal, and a bigger challenge. This checklist will help you begin to ensure your database—one of the most valuable assets of your organization—has protections in place to reduce your risk of data compromise.