"I appreciate your software's simplicity, and that it's also complete, thorough and affordable! Thanks! Your technical support people are terrific as well."
|In a recent survey, more than 25% of respondents said FundRaiser Basic has directly contributed to an increase in donations!
|In a recent survey of FundRaiser Basic users, 90% of respondents indicated that Basic has solved their fundraising problems!|
In this article, we’d like to address some common security risks associated with online database transactions, explain some of the technology behind these interactions, and then describe steps that can be taken to mitigate the risks involved.
Secure By Design
The old cliché that “A system is only as strong as its weakest link” is certainly true when it comes to online database security. When considering connecting your donor database to the Internet, it is essential to evaluate every component in the system for security weaknesses. Your overall design approach must uphold secure data access as a primary requirement built into each component, policy, and practice. It is simply not sufficient to apply stopgap security measures as patches to an otherwise unsecured system. We’ll take a look at some designed-in risk mitigation techniques in a moment.
Maintaining Security is an Ongoing Process
Maintaining a secure online donor database will require an ongoing process of:
- monitoring log files and database transactions
- rotating user account credentials
- reviewing access policies and practices
Many of these tasks can be automated, but part of your planning should include budgeting staff time for security reviews.
Threats to Online Databases
Most computer users are aware of the common security threats that are now unfortunately an integral part of everyday computing in the workplace – viruses/worms, adware/spyware, email spam, etc. While these threats are very real - and very dangerous - they are not the focus of this article. Rather, we want to focus on the following 5 specific types of security threats inherent in connecting an existing donor database server to the Internet:
- 1. Unencrypted data transport
- 2. SQL Injection Attacks
- 3. Weak User Authentication Strategies
- 4. Unsecured Database Backups
- 5. Unencrypted data transport
Vulnerable security points inherent in connecting an existing donor database server to the Internet.
A good first step on the road to data security is to ensure that all data transferred across the Internet is transported using a secure encryption protocol. There are many different types of transport channel encryption, but the one most commonly used is Secure Sockets Layer (SSL) – or its successor Transport Layer Security (TLS). SSL is the encryption protocol in use whenever you connect to a web page with a URL beginning with ‘https:’ instead of ‘http:’.
In a typical scenario as illustrated in the diagram above: a potential online donor browses to a nonprofit’s web site and clicks a link to the organization’s online donations page. If this page is hosted on a secure web server, the donor’s demographic data and credit card information will be transported from the donor’s computer to the web server over an SSL-encrypted channel (# 1 in the diagram). If the online donations page is not hosted on a secure area of the web server, then that donor’s private data is transferred across the Internet as clear text and is therefore susceptible to theft.
The software resident on the web server that process the donor’s information (# 3 in the diagram) must in turn pass that donor data across the Internet to a third-party merchant gateway to process the credit-card transaction (# 1 in the diagram), and also to the nonprofit organization’s donor database server (# 1 in the diagram). Each of these transport channels must also be encrypted if the details of that transaction are to remain secure.
Be sure to work with your web site developer and/or your hosting provider to guarantee that your donor’s data is always transmitted over encrypted channels.
Unencrypted database files
A nonprofit organization’s donor database physically resides on a server located either at the nonprofit’s offices (# 2 in the diagram) or on a server owned by a 3rd-party service provider. In either case, the actual database files themselves need to be encrypted in some fashion in order to provide the maximum security possible.
Unencrypted database files are subject to the same common virus and spyware attack vectors as any other file on your computer. This is true even if your donor database server is not directly connected to the Internet – as long as the database server is networked to any computer that is connected to the Internet, the possibility of an attack on the database exists.
Most database vendors provide the option for you to encrypt your database tables. This means that the data in the database is protected by encryption while “at rest” on the server. When a request comes into the database from an external web page, the database software decrypts the requested data before delivering it to the web server – using an encrypted data transport channel as described above.
Work with your system administrator, your database administrator, and/or your donor management software vendor to implement an appropriate level of encryption in your donor database.
SQL Injection Attacks
A common attack mode for malicious Web users who are trying to obtain secure information from databases is to inject (insert) database language (“System Query Language”, or “SQL”) commands into text input boxes found on Web forms. Since basic SQL command syntax is common to every modern database product, a technically savvy hacker can form SQL command fragments and enter them instead of a username or password on a login form in order to retrieve information from multiple user accounts, or to corrupt or even delete entire database tables.
The only effective prevention against SQL injection attacks is due diligence on the part of the web programmer. The programmer must insure that all text entered into HTML input fields is validated and stripped of malicious SQL content before it is sent to the database. This is an example of the “Secure By Design” philosophy described earlier. Don’t hesitate to ask your web site developer to explain the security measures she has implemented in your web site’s software to prevent SQL injection attacks.
Weak User Authentication Strategies
The “front door” to any database is its user authentication mechanism (# 4 in the diagram). Obviously, when that “front door” is left unlocked, or is only nominally secured, the contents of the database are threatened. This is especially true when the “front door” can be accessed from anywhere on the planet through a Web page! Here are a few steps you can take to ensure that the only people accessing your database are those who are welcome…
- Indirect login – anytime you need to require a user to login on your web site, make sure the login credentials are for the web site only, and not the database itself. In other words, the only web component that should hold direct access credentials to the donor database is the web form processing code that has to interact with the database.
- Hidden access credentials – those donor database login parameters that the web form processing code needs to know about should not be included in the code itself – rather, they should be located in a configuration file that is stored on the web server outside the public web area. That way, standard web server security mechanisms can be used to protect access to those login credentials. Better yet, the login credentials would be stored in a configuration database table located on the web server, so that yet another layer of security can be employed. This is one of many examples of a “defense-in-depth” approach to online database security.
- Limited Login Attempts – on both the web server and the donor database, the number of login attempts should be restricted as a preventative measure against ‘brute-force” scripted login attacks.
- Appropriate Privilege Levels – on the donor database side, any account that is intended for use by the web server should only be granted the database privileges necessary to accomplish the task that the web page is designed for. For example, a web page that is designed to process membership renewals only needs access to the database tables that contain membership information. Judicious granting of privileges to database user accounts is a key element in limiting data exposure.
You should work with your database administrator and your web site developer to implement a strong user authentication strategy.
Unsecured Database Backups
One of the security threats that is often overlooked is the risk of compromised database backups (# 5 in the diagram). All of the file security precautions that apply to the donor database itself also apply to the backup files. One of the best prevention measures you can take would be to make offline backups onto removable storage media. Another approach would be to transfer your backups to a remote location, while of course using secure transport and storage strategies at the remote site.
Other Risk Mitigation Techniques
In addition to the techniques we have already discussed, here are a couple other mechanisms you can use to further reduce the vulnerability of your donor database:
- Firewalls – whether you are using a software application or a network component to implement your firewall, the approach is the same: inbound connections to your database server from the Internet can be restricted by the firewall to only occur on ports that you specify. Your database application can be configured to listen on a specific IP port for connections, and the firewall can be configured to only accept external connections on that port from a trusted IP address. The end result is that with proper firewall and database configuration, only the web server that hosts your customer portal web pages will be able to connect to your database from the outside world.
Your network administrator, server administrator, or database administrator can work with you to establish an appropriate firewall configuration for your network infrastructure.
- Database Transaction Logs - as a last line of defense, your donor database can be configured to automatically log any actions taken in the database by the web server user account(s). This will provide a record that can be examined periodically for any suspicious activity (this is part of the ongoing security process referred to above). This can be an especially effective tool when combined with source IP address and session tracking data collected by the web server for those web pages that allow donor database interactions.
Work with your database administrator or donor management software vendor to establish a database log file creation and review policy that makes sense for your organization.
Although security risks do exist when connecting your donor database to the Internet, these risks can be greatly reduced or eliminated when proper safeguards and practices are built-in to your online customer portal.
Todd Hollback is a former member of the FundRaiser development team. He now does data conversion for FundRaiser customer who are moving from other software into FundRaiser.