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.
End of Article
Prev. page
1
[2]
next page -->
