Perimeter Security

You probably remember the "old days," when setting up security commonly meant using a firewall. But even then, this was a woefully narrow viewpoint.

Establishing perimeter security requires much more than using firewalls and detecting intrusions. A firewall is only one component of perimeter security, and perimeter security is just one component of security. Here are some things to consider when establishing perimeter security and a checklist you can use to plan perimeter security in today's environment of increasing connectedness.

Beyond Firewalls
Perimeter security still begins with the venerable firewall. People often (wrongly) assume that a firewall scrutinizes every inbound packet. Firewalls are only a first line of defense, and they prevent only the most elementary attacks. Simply put, firewalls evaluate packets according to the message-access protocol and the state of the connection between the internal and external computer. If the packet matches a protocol allowed for incoming connections, or if the packet is part of an established outbound connection, the firewall allows it to pass. Any malicious content inside an allowed-protocol or outbound-initiated connection will pass through a firewall undetected. For example, if you have a mail server behind your firewall, you'll probably open up port 25 (SMTP) on your firewall for incoming connections and redirect such connections to your mail server. As soon as the firewall identifies that a packet is SMTP, it forwards the packet to the mail server.

Any firewall you buy today will include the two main features of a modern firewall: stateful packet inspection and network address translation (NAT). With stateful packet inspection, the firewall is intelligent about and attentive to connection-oriented protocols such as TCP, preventing attackers from sneaking malicious packets past the firewall by posing as an already-established connection. NAT conceals details about the internal network, such as the internal LAN's addresses and topology, by replacing the internal network address and port with its own Internet address and a new port number.

You can lower the risk of these higher-level application-specific attacks. To do so, you must first keep all applications that communicate with potentially untrusted external systems fully up to date. Proactively installing all patches to OSs and applications is key to ensuring perimeter security. (Keep in mind that patching can be undermined by newly discovered vulnerabilities being made public before a patch is available.)

You can take a more proactive approach to application-level network attacks by using an application-level gateway (also known as a reverse proxy). Application-level gateways can look for specific known attack methods, but that's not their focus. An application-level gateway inserts a system between the Internet and the application server that understands the relevant application protocol that's in use. This application-level gateway's system appears to the outside world as the end-point application server, but in actuality, the gateway interprets each incoming request, reduces the request to the application server's own internal lexicon, then builds a new request from scratch discard or prevent any malicious, malformed content from getting through. The gateway then sends the new request to the actual application server and processes the server's reply in a similar way. For example, an SMTP gateway that carefully deconstructs an incoming SMTP message and then rebuilds it from scratch with strict adherence to the SMTP protocol specification discards any malformations such as invalid character sequences or buffer overflows in the message.

Organizations have differing application gateway needs, but almost all use applications and protocols for Web browsing (via HTTP), email (via SMTP), and instant messaging (IM). These three protocols make applications particularly attractive targets to four types of attacks: direct attacks, malware infection, phishing, and outbound content risks. Direct attacks that use buffer overflow or other vulnerabilities specifically target weaknesses in email clients and servers, Web servers, and IM clients. Because HTTP, SMTP, and IM all support file transfers, all three are particularly vulnerable to malware infection. These same protocols also allow social engineering attacks such as phishing. The risks associated with these protocols aren't limited to inbound content—outbound content (email messages, Web postings, and instant messages) sent from employees can expose organizations to risks that endanger privacy, confidentiality, and regulatory compliance.

Although no product on the market provides application-level gateway support for every protocol and application, Microsoft's ISA Server offers the widest native support (including for SMTP, HTTP, FTP, and RPC). ISA Server also supports a variety of partner-developed plug-ins for other protocols and applications. ISA Server's extensible architecture and Microsoft's successful collaboration with partners help position ISA Server as a type of universal application gateway, but you can also use some of the many best-of-breed solutions for specific applications (e.g., FaceTime's solutions for IM security and antispyware). Web-filtering solutions, such as those from Barracuda Networks, Websense, St. Bernard Software, and SurfControl, help you enforce policies that determine where internal users can go on the Web. By using keyword monitoring, such solutions also help you monitor employees or block them from sharing confidential information or posting or accessing inappropriate content.

Beyond Web, email, and IM vulnerabilities, application-level perimeter risks also come from peer-to-peer (P2P) networks, Web conferencing, and XML. Many developers of application-gateway solutions originally designed for Web filtering and IM security are extending their solutions to support P2P and Web conferencing.

The growing use of XML communications, especially in the form of SOAP, for business transactions poses problems different from those of the more end-user–based technologies I've been discussing. IT uses XML to link mission-critical business systems with business partners' corresponding systems. The text-based nature of XML makes any security solution rely heavily on CPU and memory resources because of the recursive parsing involved. Administrators are understandably loathe to put an added load on application servers, and the number of application servers affected can quickly grow out of control in organizations that use XML. If your organization uses XML, you'll want to add an appliance-based XML firewall to your array of perimeter defenses. (For more information, see Market Watch: "SOAP/XML Firewalls," September 2003, InstantDoc ID 39755.) Solutions are available from DataPower, Xtradyne, Reactivity, and Layer7 Technologies.

   Previous  [1]  2  Next