E-Guide 5 Simple Steps to Secure Database Development Databases and the information they hold are always an attractive target for hackers looking to exploit weaknesses in database applications. This expert e-guide explains the 5 most common database-related vulnerabilities and offers technical advice on how to avoid them. Sponsored By:
E-Guide 5 Simple Steps to Secure Database Development Table of Contents How simple steps ensure database security Five tips for secure database development Resources from IBM Sponsored By: Page 2 of 7
How simple steps ensure database security Databases and the data they contain remain tempting targets for hackers, who look to exploit the many widespread weaknesses found in database-driven applications. Many of these weaknesses are created by poor configuration or implementation. The following five database-related vulnerabilities are among the most common: Poor password policies SQL injection Cross-site scripting Data leakage Improper error handling Incredibly, default or weak passwords are still often used by enterprises to protect an online asset as important as a database, but it's a problem that's easy to fix. The remedy is enforcing a strong password policy; that is, passwords must be changed regularly and be at least 10 digits long and contain both alphanumeric characters and symbols. With this policy, you will close down an attacker's easy route to your data. SQL injection also relies on poor database implementation, specifically in regard to how SQL queries are sent to the database. If the database accepts SQL queries generated from usersupplied data that has not been cleaned and validated, it is open to SQL injection attacks. For example, by modifying the expected input received from a Web-based form, an attacker can submit malicious SQL queries and pass commands directly to a database. To prevent this type of attack, it is essential to ensure that all user-supplied data is validated before letting it anywhere near your scripts, data access routines and SQL queries, and preferably use parameterized queries. Another reason to validate and clean data received from users is to prevent cross-site scripting (XSS) attacks, which can be used to compromise a database connected to a Web server. They work by injecting a client-side script such as JavaScript into a Web application's output via a Web form. These scripts are used to gather cookie data, which is often incorrectly used to store information such as a user's account login information. Sponsored By: Page 3 of 7
One problem that is often overlooked when building a database application is data leakage. This is where sensitive data is transferred or made available unintentionally. The classic mistake is failing to secure and control access to database backup tapes. A less obvious leak is via data inference. Often more sensitive data can be inferred from answers to valid queries on the data, such as an illness from prescribed medication. A common solution is to monitor query patterns to detect such activity. Closely related to data leakage is the improper handling of errors when an error occurs at the database. Many applications display a detailed message. These error messages can reveal information about the structure of the database, which can in turn be used to stage attacks. By all means, log the error for your own records, but make sure your application doesn't return any specific details about the error to users or to attackers. To fully secure your database, split the task into the following four areas in order to ensure a comprehensive check: Server security Application security Database connections Database and table access control A database server needs to be hardened in the same way as any other server to ensure that malicious hackers cannot attack the database via vulnerabilities in the operating system. Preferably, the database should sit behind its own application-layer firewall. To help with the process of securing database connections and defining access controls, create a data flow diagram that tracks how data flows through the application. Next, identify the places where data enters or exits another application and review the trust levels assigned to these entry and exit points. Also define the minimum privileges any external user or process requires to access the system. Configuring and building your database application with security as a key driver will ensure your data stays secure. Sponsored By: Page 4 of 7
Five tips for secure database development The secure operation of a database server requires a cooperative effort among IT professionals responsible for the secure operation of the network and servers, and those developing applications that interact with the database server. In the last Web Security Tip, we examined some of the issues surrounding administration of a SQL Server database. Today we'll look at some of the specific security issues that impact the application development process. As a security professional, it's important that you understand the basics of secure coding and educate your organization's developers to ensure that they comply with these policies. A single failure along these lines could completely undermine the security of your entire database server. Use database views instead of tables. Developers should create applications that interact with views (basically, predefined queries) rather than interact directly with the underlying table. This allows greater control over access to information, both at the row and column level. Make use of stored procedures. Developers should store their SQL code on the server and make it available to applications through the use of stored procedures. This limits the range of actions applications may perform on the database and allows for easy, centralized updates if security requirements change in the future. Don't embed SQL commands in application code. This goes hand-in-hand with the previous step. Developers should never include SQL commands in their applications. This creates a significant vulnerability if malicious users are able to later modify the application. Don't let developers have administrative power over users. Security professionals have long practiced the idea of separation of powers. It's a good idea to ensure that developers (who often control table structures, stored procedures and the like) are not able to create and/or modify user permissions. This prevents them from succumbing to the temptation of loosening access controls to make a program work "just while we're testing it." I've seen all too many cases where those "temporary" solutions have remained in place for years. Requiring developers to Sponsored By: Page 5 of 7
approach administrators for permission changes limits the likelihood of unnecessary change requests. Apply the principle of least privilege. In our last tip, we discussed the importance of only granting users the minimum set of permissions necessary to complete their jobs. This is also true for the administrative accounts used to execute application code. Ensure that these accounts have only the specific permissions they need to execute authorized functions. These basic tips will help you get started down the road toward ensuring the security of your database. Encourage the developers in your organization to review these principles and think "Security First!" when writing code. Sponsored By: Page 6 of 7
Resources from IBM AR report: The Forrester Wave: Database Auditing and Real-Time Protection, Q2 2011 IBM InfoSphere Guardium Data Sheet Gartner Report: Ten Database Activities Enterprises Need to Monitor About IBM At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. We translate these advanced technologies into value for our customers through our professional solutions and services businesses worldwide. Sponsored By: Page 7 of 7