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