Protecting Your Payload

Information security has always been an important concern, but the growth and development of e-business has intensified the problem. Companies' e-business applications target the external world as users, so external users can now access applications and databases that were once the exclusive domains of trusted users. Companies also use releases of Web-accessible software that vendors speed to market after only a brief quality-assurance testing period. This software often includes new functionality that contains many vulnerabilities. Consequently, e-business has increased the opportunities for computer hackers and other malicious users to vandalize systems and steal information. Many of the widely published attacks on information systems in 2002 and 2003 have targeted database servers. In addition, the annual Computer Security Institute (CSI) and FBI Computer Crime and Security Survey—available at http://www.gocsi.com—consistently shows that most serious information-security breaches occur from within organizations. When you couple increasing external assaults with growing internal misbehavior, the case for more effective application and database security becomes clear.

The most important piece of application security is protecting and maintaining the integrity of application data—a major undertaking that requires security staff to work closely with DBAs and application developers. Guarding the data includes protecting against unauthorized use, theft, and poisoning of the data (injecting false information or compromising the integrity of the information), as well as managing privacy concerns and regulatory requirements. The data elements—the crown jewels of any organization—are almost always stored within relational databases such as SQL Server. Therefore, taking extra security precautions around SQL Server databases takes on new urgency. One of these precautions can be the installation of an SQL firewall. This article explains how SQL firewalls can enhance your application security and shows how you can implement them as part of an overall security program.

An Important Security Layer

Good security architecture consists of a set of security layers that protect components within your enterprise, and most companies have already adopted a variety of basic security measures. Writing safe application code—code that developers have systematically debugged, tested in various environments, and validated for correctness—is a crucial first step. Using that code safely and successfully in many different scenarios is an important follow-up. Savvy organizations also set up good SQL Server controls (e.g., controls on database-user access and password use in networked applications) and appropriately use traditional perimeter security products such as firewalls to segregate access between different subnets. As an additional security layer, you can install an SQL firewall to protect your application data. Note that an SQL firewall doesn't replace the security you already have in place; instead, an SQL firewall augments the measures you've adopted to make your servers more secure.

New Risks and Exposures

Let's look at a sample e-commerce problem that can occur when the most basic security layer—safe coding—is deficient. The new functionality that Web services, one of today's hottest technologies, brings to organizations can also increase your data vulnerability. Web services opens up huge potential for Web-based system interoperability, letting companies expose internal functions and transactions to other systems—both internal and external. Developers can expose functions such as Web services in many different ways, some of which are simple but unsafe. For example, XML for SQL Server 2000 Web releases (SQLXML) extend the built-in capabilities of SQL Server with technology to create XML Web services from SQL Server stored procedures. When you use SQLXML, you can call a stored procedure named, for example, sp_update_company_customers by using the XML template that Listing 1 shows.

This template makes building a stored procedure-based Web service easy—too easy. The original developer probably wrote the sp_update_company_customers stored procedure for use only from within a database application and in controlled environments. Let's assume that the sp_update_company_customers stored procedure uses the company name and updates all customers from that company by concatenating the company name to the WHERE clause. After a developer builds a new Web service around this stored procedure, anyone can call sp_update_company_customers from anywhere. A clever hacker can call this Web service and pass a query string such as ACME, with DROP TABLE customers as the argument, deleting a lot of data and probably bringing down the entire system.

Clearly, the designers of the described stored procedure and Web service should have done a better job of validating input and implementing an application-specific security check within the stored procedure. However, most system attacks, including the class of buffer-overflow problems that Microsoft products such as SQL Server have experienced, take advantage of unchecked parameters that result when developers take shortcuts. So, although a well-designed, well-coded, and well-tested application theoretically can be highly secure, current best security practices mandate the use of additional security layers that are external to the applications and that can augment good coding habits.

Content Firewalls: Implementing Security In-Depth

Most companies already have installed perimeter products such as traditional firewalls and intrusion detection systems (IDS) as additional security layers. Traditional firewalls function at a TCP/IP level and inspect only headers of TCP, IP, UDP, and other network-level protocols to determine which packets to allow through. Therefore, traditional firewalls block access only to certain ports and IP addresses because this type of information is the only kind available in the header. If you want to protect data that's entering or leaving your system, you need content-level, network-based firewalls, which inspect the entire packet, including the data payload, to determine whether a request is allowed. A traditional firewall inspects only about 10 percent of a typical packet, as Figure 1 shows, but a content firewall typically inspects much more information—almost 100 percent of the packet contents—in making its accept or reject determination.

Because content firewalls inspect the data payload, you can use them to implement security policies that are based on business rules and semantic concepts. This approach to security is much more powerful than simple reliance on blocking ports and IP addresses. You could have prevented a hacker from injecting a DROP TABLE customers string as an argument into the sp_update_company_customers stored procedure by using an XML or SQL firewall to inspect the packet contents. Many other kinds of content firewalls can exist, depending on the protocol that you use to make the requests.

An XML firewall inspects packets that come through the Web server and extracts XML fragments, parsing the XML in the fragments and applying the security rules you've set up based on elements, typing information, and data within the tags. Content firewalls sit inline with the communications streams they control. For example, SQL firewalls sit between the application server and the database server, as Figure 2 shows. In this figure, the application code running within the application server connects to the database not only through a conventional firewall that is part of the demilitarized zone (DMZ) but also through an SQL firewall. The SQL firewall's primary role is to protect the most important asset in most enterprises—the application data stored in the database. Like XML firewalls, SQL firewalls provide content-level inspection, but they inspect the SQL code that accesses and modifies the database rather than messages that come into the Web server.

How SQL Firewalls Work

Applications need to access and modify data that resides in the database, so you need firewalls that let you define and enforce data access and security policies. SQL firewalls compare the SQL code (regardless of the SQL dialect) that travels within network packets with your access-control rules, which limit which database client, application, and database user can perform which commands on which database objects. SQL firewalls can distinguish between authorized and unauthorized requests because they dissect the Net-Library and Tabular Data Stream (TDS) protocols and use advanced parsers to recreate the T-SQL. These processes verify a user's authorization (or lack thereof) to access a specific database object when the user enters the session from a specific application deployed at a specific IP address.

Figure 3 shows the main activities that an SQL firewall needs to perform in order to do full request authorization. The first task an SQL firewall performs is analyzing the TCP/IP stream to track the entire client session. The firewall needs to defragment these packets to compensate for packet fragmentation that occurs at the network level. Then, the firewall extracts the Net-Library packets from the TCP/IP stream. Next, the firewall extracts the TDS Protocol Data Units (PDUs), a step that again might include defragmentation, because SQL requests can involve lengthy commands that might not fit in a single Net-Library or TCP/IP packet. The dissector is a component that receives the defragmented packets and extracts the SQL string. This string is the input to the parser. In the case of a SQL Server stream, the string is the input to the T-SQL parser, which can process the full T-SQL grammar and needs to support multiple SQL Server releases. Note that because different SQL Server releases include slightly different T-SQL constructs, any enterprise-built SQL firewall needs to include a sophisticated parser that can support those different constructs. For example, even if you deploy only SQL Server 2000, your firewall must include a parser that supports SQL Server 7.0 because a client might use a SQL Server 7.0 driver, which generates traffic that uses SQL Server 7.0 T-SQL commands. However, if your organization runs multiple database platforms, you might need several different parsers. For example, you need separate parsers to process SQL Server T-SQL dialects and Oracle PL/SQL dialects.

The parser output is a full parse tree (a collection of nodes, each representing a piece of the SQL such as an operator, function, or value), which reflects all the SQL grammar. To determine whether the SQL fully conforms to your security policy, the firewall compares this parse tree with the rules you've devised. For example, your policy might let users execute SELECT operations but not UPDATE operations. Generally, the policy lets you define permissions based on who is issuing the request (database user), what content the user is trying to access (object), where the object is located (database and schema, as well as IP and network source), how the object is being used (SQL command), when the request is being made (time of day), and in complex implementations, even why the request is being made.

In the sp_update_company_customers example, an SQL firewall could easily enforce a rule that an argument passed to the sp_update_company_customers database can't include the DROP command. Further, an SQL firewall can limit or prohibit the use of any Data Definition Language (DDL) command because production application servers (as opposed to development servers) don't usually send DDL commands to the database. If a production application server is attempting this atypical operation, an SQL injection attack might be underway or an attacker might have compromised the application server to make changes to the database. An SQL firewall can even enforce a security rule that prevents a stored procedure's parameters from including any command except the SELECT command, making the database data read-only for certain users or scenarios. In addition, the firewall can go one step further: It can restrict the use of the SELECT command by table. In fact, SQL firewalls can block all SQL injection attacks and data access from illegitimate applications and sources.

Implementing SQL Firewalls

Content firewalls aren't appropriate in every situation. Like any other component in your infrastructure, content firewalls can be costly and complex. Content firewalls have been available for less than a year, so they tend to be relatively expensive compared with traditional firewalls—as much as 100 percent higher. Because content firewalls haven't yet become commodities, pricing isn't well published and is typically custom-fitted for each customer. However, you can expect to pay between $10,000 and $200,000 to secure your environment, depending on how many databases and networks you need to protect. (See the sidebar "Sample SQL Firewall Products" for information that can help you start researching available products.)

SQL firewalls are additional components of your network and require setup, administration, and maintenance. You also need to define the security policies for the firewall to follow. Because content firewalls deal with elements that are at an application level rather than at a network level, you should expect high implementation time—between 1 and 4 months—mostly for setting up security policies based on application-access patterns. During setup, you need to involve multiple groups, including the security, data, and application teams. Depending on the methodology you use, setup can be application-specific or generic. Application-specific policies include rules specific to the application tables and stored procedures you're securing, whereas a generic security policy follows general best practices such as limiting a database user's access to one application and a small number of IP addresses. Application-specific controls provide more security then generic controls but can easily expand the implementation time, depending on the number of applications you want to protect.

Content firewalls typically sit in-line between your application and database. This means that any communication between the application and the database must pass through the firewall. Installing a firewall creates not only an additional level of security but also an additional point of failure. Therefore, for mission-critical systems, you need at least two content firewalls to create a redundant configuration. In addition, firewalls carry inherent latency (small as it may be), which adds to the end-to-end system response time. Finally, whenever you perform a major upgrade (e.g., when you migrate your databases to the next SQL Server release), you also need to upgrade the parser components because major releases almost always involve a change to the underlying protocols, changes to the T-SQL grammar, or both.

Is an SQL Firewall Right for You?

Enterprises should view SQL and other content firewalls as an additional layer of security rather than as a replacement for built-in application security. Your application still needs to validate content when the content enters the application as arguments and when it exits as data sets. Likewise, SQL firewalls don't replace the security features within SQL Server; they augment them. Unless your organization has invested many years of effort in security-aware development practices and intensive security testing, consider adding a content firewall as an external level of protection.