Database Application Best Practice Configuration Samples:
Secure Your Database
Your database is the foundation of your online business. Follow this advice to avoid compromising your strongest corporate asset.
Can you mitigate database security risks?
The up side:
- Separate web and database servers.
- Implement strict access controls and permissions.
- Use database views, stored procedures, and encryption.
The down side:
- It can be complicated.
- Some approaches to using individual keys for encryption may raise significant key management issues.
- encryption impacts system performance.
Online business applications are complex, consisting of many interdependent pieces, resting upon the all importantly database. Whether the database is a flat file, object oriented, or relational based, the database forms the foundation for all but the simplest online business systems. The roles of databases are many, including storing system configuration parameters and credentials, providing raw content for use in dynamic page generation, providing data for order fulfillment, employee identification data such as social security numbers, and storing customer data such as shipping addresses and credit card numbers.
Regardless of the specific application or product, the security and integrity of your data contained within the database is probably of great concern to your business. After all, this information keeps your online business running. Unauthorized modification of even a single piece of information within a database can lead to reputation damage, litigation, or the collapse of a business.
Despite the sensitive nature of these database systems, business, and customer information typically contained within databases, first-hand experience and reoccurring media coverage of compromised business web sites show us that databases are at risk.
Companies are failing to implement adequate security measures.
The risk is so great, in fact, that the world's largest payment networks, Visa and MasterCard have established mandatory Internet and Intranet security guidelines that merchants must follow known as the Payment Card Industry or PCI. American Express has gone one better with its Private Payments program, offering cardholders a unique, onetime use credit card numbers for each online transaction.
HORSE FACTS: Access connections to a server will either be through physical contact or a remotely accesses connection through connection interfaces such as network interfaces or modems.
Old school thought once recommended that external threats to your mission critical data stores came from devious hackers lurking outside your perimeter firewall defenses. Consider an easier approach. Consider approaching any connection to your database server regardless of whether it is a remote electronic connection through the systems network interface or locally originating connections initiated through physically connected consoles or other devices providing physical input or output to the server.
A critical aspect of maintaining the security and integrity of the data within a database involves the overall system and network security that supports the database server. Generally, an attacker who gains access to the operating system or physical server supporting a database can easily gain full access to all of the data contained within that database, regardless of the access controls enforced by applications or the database itself.
Key defenses: Eliminate or secure unnecessary network services, separate Web and database servers, patch known security vulnerabilities, and ensure correct file and device permissions.
Database software, like most operating systems and complex applications, provides a number of services that allow remote system management, distributed processing, and other network-related functions. In many cases, those services are enabled out of the box by default and these services are in many cases old protected by using a vendor-supplied default password or in some astounding cases no whatsoever. Those services can be attractive targets for an attacker, potentially allowing easy access to the system and database.
HORSE FACTS: Like the weakest link in a chain, peripheral systems in close proximity to mission critical systems may very well become staging grounds for attackers to launch more “trusted” attacks against other systems.
To mitigate risks associated with passwords, change all default passwords. Additionally, disable all unnecessary services on both the server and the database itself, such as Finger and remote administration, to block an attacker from using them as an entry point into the system. For required services, restrict access through filtering mechanisms, such as firewalls and routers, as described later in the article.
Separate web and database servers
Many online businesses place all their servers, including Web, application, and database servers, behind a single, dual-interface firewall or chokepoint router. While this prevents Internet traffic from reaching your database servers, it doesn't stop a malicious user from compromising your web server and using it to attack your database server. Should any single server be compromised, it can be used to subject the other servers to a full barrage of attacks. Even the most stringent network safeguards are insufficient when matched against a determined attacker.
Isolate your database servers, particularly those containing sensitive information, from a web site's demilitarized zone (DMZ), and locate them on a physically separate network segment from the web and other Internet accessible servers that support your online business. Ideally, partition your database server off from the web servers by a dedicated firewall. This firewall should only allow database traffic between the web server and database server. You should deny and log all traffic from any other location, or other types of traffic from the web server, such as Telnet or FTP. Partition your database and web servers by a dedicated firewall.
The following illustration provides an example of this scenario.
Caution: Through such partitioning, your database can, at worst, be attacked using only native database protocols. Exploiting weaknesses in the database communication protocols can still lead to a system compromise.
HORSE FACTS: In cases where it isn't possible to place a dedicated firewall between the Web and database servers—because of cost reasons, for example—it's still possible to receive some of the same benefit by implementing firewall-like filters directly on the database server. For UNIX servers, you may be able to use freely available security applications such as IP Chains, IP Filters, or TCP Wrappers. For Windows based system servers, you can use the filtering capability within the Network Connections "TCP/IP Security" configuration screen.
Eliminate known security vulnerabilities
As with applications and operating systems, database servers can also have vulnerabilities that lead to unauthorized data access, loss of integrity, or total system compromise.
Several previous versions of Oracle for UNIX, for example, include an incorrect permission setting on the oracles TCL command interpreter used in conjunction with the Intelligent Agent option. This incorrect setting lets any attacker open a command shell operating with unprivileged guest access to gain root or administrative access to the entire system. Once an attacker gains administrative access to a database server, all of the data stored therein are vulnerable with the perpetrator’s new found full access rights.
New reality: Other vulnerabilities can be exploited directly over the network, eliminating the need for an attacker to first gain access to an account local to the database server. One such vulnerability that's particularly devastating is the Remote Data Services (RDS) bug contained within certain versions of Microsoft's Active Data Objects (ADO) architecture. This bug has led to the compromise of many Web servers and their supporting databases, reportedly including those of Microsoft and U.S. federal agencies. This type of virtual domino attack is known as a “Cascading Attack”. A common vulnerability is used as a stepping stone to another vulnerability ultimately reaching the prize.
To minimize the impact of cascading vulnerabilities, keep your systems up-to-date with security patches released by vendors. Security patches on production systems are often not kept current. Many of these bugs are still being actively exploited today years after they were discovered and patches were released by vendors to fix the problem. It is unfortunately common for database applications to be vulnerable to remotely exploited attacks. Many of these attacks are successful without authentication. In other words, they may be exploited over a network without the need for a username and password. Search any vendors web support site or search engine for database vulnerabilities and you will find a plethora of information.
HORSE FACTS: Eliminating unneeded applications and services will reduce the need to maintain these patches. Some “Zero Day” attacks occur as a direct result of brand new exploitations of vendor’s applications and we eliminate our level of vulnerability by cleaning house. A proactive approach will provide information security whereas a reactive approach does nothing to eliminate known or unknown threats.
Practical advice: A layered approach is always best. Castle walls are a great defense mechanism to protect the occupants against marauders but the addition of a moat is even better. Additional countermeasures may be leveraged that will provide effective measures of security. Intrusion Prevention System’s such as SafetyNET provides signature, rule, and anomaly protection from the application layer down into the data layer of the OSI model. Never rely on just one level of protection.
Guarding permissions and the need to know
It would be prudent to use the “Nothing more, nothing less” approach. Incorrect or gratuitous file permissions can pose threats similar to or eclipsing even those of software product vulnerabilities. The damage potential that incorrect file, directory, and device permissions can cause is limitless. Overly liberal permission settings on a device might allow unauthorized access that can undermine the security of an entire file system or database; inappropriate permissions on a Windows system allows for the coping of the Security Account Manager (SAM) password database to be read by everyone or even processed by freely available password crackers. As mentioned before, those peripheral systems in close proximity to our mission critical systems may very well become the staging ground for an attack. These attacks will now be executed within the trusted confines of our perimeter defenses!
Practical advice: To protect against attacks that leverage inappropriate file permissions, the database or system administrator should investigate the nature of all critical files supplied with, or relied upon by, the database. In addition, applications should be run under the principle of least privilege, meaning that each application is run with the minimum set of permissions necessary to perform the required tasks.
While it may be easier to run every application with system-level privileges (examples include, root or administrator privileges), doing so virtually guarantees that attackers can compromise an entire system should they locate a single vulnerability.
On the other hand, if each application runs with the absolute minimum set of privileges required, an attacker that compromises one application would, at worst, is able to compromise other applications sharing the same set of privileges.
HORSE FACTS: To limit the damage that one compromised program could potentially do to other applications, it often makes sense to have each application running under a distinct set of limited privileges. Performing self assessments on a regular basis is advisable. Pre-production assessments should also be performed that are driven by a check listed company policy that will provide consistent results.
On the inside: Protect your data stores from any form of compromising access by rogue agents, transient agents such as independent consultants, or even your trusted agents employed by the company. It is a common fact that more damage to the company is perpetrated by our trusted employees. This damage may be intentional or accidental nonetheless prudent proactive prior planning is warranted.
Databases, particularly relational database management systems (RDBMSs), can be very complicated to install, configure, and maintain. In part because of this complexity, often combined with developers' or security practitioners' unfamiliarity with database configuration and internals, database security precautions are often inadequate.
Key defenses: Use database access controls, restrict access through views and stored procedures, and use encryption to protect the integrity and confidentiality of information. It is critically important to keep appropriately structured segregation of duties (SOD), structures in mind while planning and supporting database systems.
Use database access controls
Without the ability to selectively grant and restrict access to a database and its data, arbitrary users can add and delete information at will. Even if access controls are enforced by web applications, data contained within the database is still at risk if a malicious user circumvents the Web application and accesses the database directly.
Caution: Unfortunately, it's quite common for developers to place all access controls within the application itself, leaving the database exposed. This practice is typically reflected in the use of a generic application user ID that has full reign over the database tables and, in some cases, the entire database. In such a case, an attacker who circumvents application-enforced access controls could erase an entire database with a single “DROP DATABASE” command. Without current backups, all data would be lost and your online business at risk. Even with adequately maintained archives you should expect some level of down time which may likely affect the business adversely.
Most databases, however, support some form of access control that can restrict what users, groups of users, or applications can access or change the database. In their simplest form, database access controls may leverage the underlying operating system's file permission capabilities. More sophisticated databases, such as an RDBMS, provide multiple layers of fine-grained, object-level access controls that can minimize or eliminate the need to rely upon the Web application for database access control enforcement.
Limit access through views and stored procedures
Two powerful mechanisms for restricting access to data stored within an RDBMS are views and stored procedures. Used appropriately, these mechanisms can provide an effective means of protecting data by limiting the amount of information that an application, and malicious users attempting to exploit that application, can access.
A view is a virtual database object derived from a query against one or more database tables. A view contains no data, but can be thought of as a window into a subset of rows and or columns from the underlying tables it represents. Data is accessed through a set of public views which allow read-only access to selected tables. The diagram shows the entities and their relationships. A solid arrow indicates a containment relationship (for example, an OrgUnit contains N Processes). A dotted bidirectional arrow indicates an association relationship (for example, an Objective associates with one or more Risks). The next image illustrates a logical representation of a view. A view contains no data, but provides a window into a subset of rows and or columns from the underlying tables that it represents.
Most databases provide the ability to define a different set of access privileges to a view than the underlying tables. By creating views and assigning user or group permissions to those views, but not to the underlying tables, you can restrict access to selected columns and rows. Users then only have access to the data allowed by a view; the rest of the data is not visible or accessible.
At worst, circumventing application enforced access controls that operate against a view reveal the subset of data represented by the view. Compare that to circumventing application enforced access controls that operate against an entire table. Doing so would potentially reveal the contents of the entire table or tables. Even if column restrictions were enforced through the use of the access controls described previously, a malicious user would still be able to see all the records in the table(s), as table-level access controls can't be applied on a row-by-row basis. Depending upon the application, this could provide a malicious user with a considerable amount of sensitive information.
One more idea: While views provide a robust mechanism for enforcing read-only access, you can use stored procedures to enforce access controls on both read and write operations. Stored procedures provide a mechanism for encapsulating business logic within the database, thereby abstracting an application’s interactions with the database. As with views, a user typically requires only permission to execute a stored procedure, and not permission to access the underlying database tables.
By encapsulating all database access in stored procedures, and letting only stored procedures be executed against a database, a malicious user is prevented from originating or modifying queries and submitting them directly to the database for execution. At worst, this constrains a malicious user's access to the database using the defined stored procedures. As such, you can protect data within the underlying tables from direct manipulation.
Stored procedures can encapsulate complex logic such as validating user input, transforming it, and then executing dozens of individual SQL calls. This could, for example, let an application populate the dozen tables required to create a new account at an electronic commerce web site with a single parameterized stored procedure call.
- For example: ADD_CUSTOMER ('First', 'Last');
- For example: ADD_CUSTOMER ('First', 'Last');
Encrypt communication between servers
In much the same way that intercepting and potentially altering sensitive communications, such as credit card numbers, between web browsers and web servers is a concern, intercepting and altering the communication between Web application servers and database servers may also be an issue.
Caution: You may need to heighten this concern in cases where server-to-server communication occurs across a non-trusted network such as an organization's DMZ or the Internet.
Similar to the use of Secure Sockets Layer (SSL) encryption to protect data transmitted between web browsers and web servers, you can also use encryption for communication between web application servers and database servers. Depending upon your network architecture and the products deployed at your site, server-to-server encryption can encrypt all data transmitted using a mechanism such as IPSec, or only encrypt database-specific data using encryption-enabled database protocols. Oracle SQL*Net V2.0 and Net8, for example, support data encryption between systems.
HORSE FACTS: You can also use freely available tools like Stunnel to provide SSL encryption and server authentication to otherwise insecure protocols.
Encrypt data
Reality check: Despite employing all these mitigation strategies, it's still possible for an attacker to access the contents of your database by exploiting inappropriately configured security perimeters, a previously undisclosed product vulnerability known as a “Zero Day” event, or salvaging an inappropriately disposed of backup tape or hard drive. For a determined attacker, even the most stringent network safeguards, of which firewalls, IPS, and encryption mechanisms are a component, may still be insufficient.
Given the sensitive information that the typical online business stores in its databases, such as credit card numbers, customer identity information, and passwords, the risk of data and identity theft is very real.
In February 2005, Bank of America Corp. acknowledged that computer tapes with personal information on federal employees had been put on an airplane in December and then lost, putting 1.2 million people at risk of identity theft. In May 2005, Time Warner Inc. announced that it had shipped similar information by truck and lost it, too, compromising data on 600,000 employees. The next month it emerged that a unit of Citigroup Inc. entrusted unencrypted computer tapes with information on fully 3.9 million customers to United Parcel Service Inc.; the tapes never showed up at their destination. What's more, losing tapes in transit is only one way that companies can compromise personal data. In the most recent security failure, credit card companies admitted that hackers had penetrated the database of a payment-processing firm. As many as 40 million credit card numbers may have fallen into the hands of criminals.
Key defense: The last resort against such compromises is to encrypt sensitive, if not all, data that's stored in databases. While encryption won't prevent the attacker from retrieving the encrypted data stored in the database, it will prevent the attacker from being able to recover and use the plain text contents of the data. Unless the attackers can decrypt the data, they'll be left with meaningless gibberish.
Encrypting the data using a proven, strong encryption algorithm such as 3DES, Blowfish, AES, IDEA, or RC4, combined with strong keys and proper implementation, makes it impossible for an attacker to access the encrypted data without discovering the encryption keys used.
Recommendation: For symmetric encryption algorithms, use a key of at least 112-bit strength. Don't store encryption keys in their entirety in the application, on disk, or within the database. Instead, distribute raw components of key material throughout the application, and then assemble and transform it as needed. When no longer needed, destroy the key and overwrite the memory used to store the key.
HORSE FACTS: Exploits for the MD5 and SHA-1 algorithms have become known. You may wish to consider using one of the other database encryption described in this section instead. I recommend employing the encryption and decryption of data using the official Advanced Encryption Standard (AES) algorithm, previously known as “Rijndael.” It uses encoding with a 128-bit key length, but you can extend it up to 256 bits with little effort. A key of 128 bits is much faster than one of a higher key length and it is secure enough for most purposes.
Best case scenario: Ideally, a unique key protects each customer’s sensitive information or a single set of related information, thereby minimizing the damage that can be done should an attacker guess or use brute force to access a single encryption key. At best, guessing one key should reveal only one customer's information or related set of information. Some approaches to using individual keys may raise significant key management issues. Such issues must be thoroughly evaluated and understood prior to implementation. If possible, a cryptographic expert should help design and verify your cryptographic and key management plans.
The performance impact of encryption
Be prepared: Despite its benefits, encryption does exact a performance penalty against online business applications and servers. This performance penalty increases with the amount, type, and strength of encryption performed. Generally speaking, asymmetric, public key encryption has a greater performance impact than symmetric encryption. Further, stronger keys—that is, more bits—for a given type of encryption have a greater performance impact than smaller keys.
Reality check: Striking the proper balance between acceptable performance and acceptable security can be tricky. Unfortunately, offering blanket guidance on the appropriate balance isn't possible because that balance must be evaluated on a case-by-case, company-by-company basis. It is important to note however, that offloading cryptographic computations to specialized hardware devices can lessen the performance impact of encryption. Several vendors make hardware-based cryptographic accelerators, including Safenet, Sun Microsystems, Intel, and Rainbow Technologies.
A foundation constructed upon bedrock
As online business continues to flourish, so too do the security risks and exposures that you and your customers must face. Day-in and day-out, countless web sites ask customers to entrust sensitive information to their databases without any real assurance that the data contained therein is safe. High-profile exposures call for greater security measures from credit card companies, but reacting to the effects and not proactively mitigating the catalysts only underscore that far too many online businesses are built upon a foundation of sand. Understanding the exposures and mitigating actions outlined here are a strong first steps towards implementing your own strategy constructed on solid principles.
Database Specifics
Next are some configuration and assessment documents particlar to vendor specific engines.
Oracle Oracle Database Asset Protection Standards
Microsoft SQL Microsoft SQL Database Asset Protection Standards
MySQL MySQL Database Asset Protection Standards
DB2 DB2 Database Asset Protection Standards
Non-Stop Non-Stop Database Asset Protection Standards
Ingress Ingress Database Asset Protection Standards
--Mdpeters 14:48, 10 February 2007 (EST)