Application Protection: Where is it best applied?
David Piscitello, Core Competence, Inc.
Application Protection is a catchall term, applied generically to all security measures that protect application services. URL-based attacks, script exploits, malicious data injection to SQL, ORACLE, IBM DB2 and other databases, mail server attacks and DNS poisoning are all examples of application level attacks.
The distinction between application and network-based protection is a fuzzy one, since network-based is interpreted both as "attacks attempted across a network" as well as "attacks against the networking protocols (TCP, IP, ...)". But the distinction is not arbitrary, nor is it entirely market spin. Network, and specifically, Internet-based attacks attempt to compromise a system through a flaw in a Internet protocol standard or implementation; if successful, attackers often gain administrator privileges for the system and applications, and access to data. Fortunately, the set of Internet protocols we use is finite, and after nearly two decades, firewall technology, combined with improvements and patches to implementations of Internet protocols, has matured to where we can provide very good protection against network attacks (proper configuration notwithstanding).
But the set of applications, especially web-based applications, is essentially infinite. While standards exist for web protocols and services, for security purposes, each web presence - the combination of server application and OS platform, pages served, scripts, databases, and forms employed, and of course, the configuration of all these elements - is unique. Accordingly, attackers have infinite attack vectors, and so, too, are suitable locations for the deployment of defenses and countermeasures. Hence, the question, "Where is application protection best applied?"
Before we answer this question, let's examine where you can apply application protection.
At the Perimeter: Internet Firewalls & Network IDS
Many enterprise class firewalls and inline intrusion detection systems apply stateful packet inspection beyond traditional TCP/IP protocols, and examine application data streams. Through this deep packet inspection process, the best of application protection firewalls and inline IDS can distinguish known network-based attacks from legitimate traffic. Firewall and inline IDS hybrids - Intrusion Prevention Systems, or IPS - provide advanced intrusion and denial of service detection by distinguishing anomalous from normal traffic patterns and behavior.
The best of these breeds can identify and block long lists of known attacks against web applications, including malicious URL encoding, CodeRed and Nimbda worms, WebDAV, and chunked data encoding attacks. Several also protect SMTP server applications from flooding/DOS, worm, and relay attacks; FTP server applications from malicious operator and bounce attacks; and DNS server applications from protocol and database (zone) poisoning attacks. Depending on the product, protection is available for other services, from database (SQL, Oracle) to secure tunneling protocols (SSH, SSL), and even Voice over IP.
Within the Perimeter: Proxies
Proxies, either standalone or integrated within firewall or VPN appliances, terminate application streams and police the contents of that stream. For example, an SMTP mail proxy will collect all the application data that comprises a single email message, inspect the message, and apply whatever measures a security policy dictates: e.g., remove or modify unknown or potentially dangerous mail headers, block the delivery of potentially dangerous attachment and content types, etc. SMTP, FTP and DNS proxies customarily check for protocol anomalies. HTTP proxies check for protocol anomalies, strip scripts, active controls and other active code or content prohibited by security policy. Whether marketed as proxies or (Web) Application firewalls, these systems validate incoming and outgoing HTTP traffic, to prevent client-based attacks, web defacements, server mis-operation and other "web perversions" (this cleverism is courtesy of Sanctum, Inc.).Collapsed Perimeters: Interdepartmental IPS & Server Firewalls,
Application Protection at the Internet firewall has the benefit of performing security checks at a familiar aggregation point, the Internet access circuit. But increasingly, clients operating within the protected and trusted network are proven vectors for attack. This is particularly true in organizations with mobile and roaming workforces. Servers themselves are also vectors for attack against "fellow" servers. Application streams that form these internal attacks do not pass through Internet Firewalls so are not subject to inspection and prevention.Adding interdepartmental firewalls or placing firewall-capable switches directly in front of (literally, adjacent to) server farms provides a means of collapsing the perimeter around the assets (principally, servers) deemed most critical. This is commonly described as layered defense, or defense in depth. A variation on this theme does not require discrete and separate hardware appliances: application-level inspection and filtering on the target server platform itself - in a network adapter form factor, software, or embedded OS service (e.g., Microsoft ICF) - can be used to create very granular, compartmented borders. Both of these solutions act like water-tight hatches on a naval vessel, e.g., a submarine.
At the Server: Host Intrusion Prevention
Philosophically, it makes sense to protect applications, the platforms on which they run, and the data they use, as close to "the asset" as possible. Host Application Protection measures wrap a protective shell around applications, databases, Operating Systems and file systems. These act like intrusion detection systems, to block attacks at the system call level and protect critical system files (e.g., Windows Registry, *nix .conf files). Such products also provide additional access controls to protect web-accessible information from unauthorized access and modification. In some cases, policy synchronization across large server farms (and distributed server environments) proves difficult. These solutions can be construed as complementary to vulnerability assessment and mitigation, but are also commonly claimed to compensate for inherently weak security features available in server platforms. Whether you regard them as supplementary or complementary, they provide another layer of defense, close to the asset.At the Server (Redux): Vulnerability Assessment & Mitigation (Hardening)
Vulnerability assessment and mitigation are processes organizations can employ to thoroughly test all elements of a web presence, and systematically identify, then eliminate or minimize each threat until the web presence meets the intended security requirements and satisifies the desired risk profile. Vulnerability Assessment systems automate the process. System-level scanners search for overly-generous access permissions, weak passwords, default accounts, and missing web server patches, while web application vulnerability assessment scanners may look for exploitable cookie implementations, vulnerable forms, cross-site scripting, etc. The best of this breed provide detailed reports explaining the vulnerabilities discovered and methods to eliminate or minimize them. The actual process of configuring systems and applications following a vulnerability assessment is called "hardening", and it is labor-, knowledge-, and skills-intensive. In the case of (web) application vulnerability assessment, vulnerability assessment may reveal fundamental flaws in development; for example, a persistent failure to validate (data) input in web forms and database queries. These may lead an organization to conclude that a secure code review is required for all application code.Given these choices, where is application protection best applied?
A strategy I believe to be efficient and effective is one in which coarse- and network-level policy enforcement is done at the outer ("loose") perimeters. Increasingly stringent and application specific policies are enforced close to or at the location where a web or application presence is deployed. This is similar in principle to the "choke and screen" early firewall deployments used to create DMZs many years ago. You can apply application protection at Internet firewalls and proxies, but do not rely entirely on these. In the choke and screen deployment, your outermost firewall should implement the coarsest of policies. Implement more stringent application protection measures in firewalls, proxies and switches that protect server farms, to defend against attacks from external and internal hosts. Collapsing perimeters around server farms and enforcing per client security measures is a practical concession and reponse to the now omni-present and worrisome mobile workplace.Investing in host application protection to complement security measures you employ at the server and applications themselves is one of those "iffy" areas. Some security experts question, "how much better off is an organization that invests in these solutions than one that rigorously assesses risk, identifies vulnerabilities, and hardens servers and applications?" Perhaps your systems administrators are capable of hardening and configuring secure systems; your programming staff develops and maintaining securely written applications; and your daily operations staff are monitoring ninjas.
Perhaps you need some backup. If you do, one or even several of the several dozen companies listed in the sidebar may have an application protection solution that meets your needs.