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.

One of the worst mistakes you can make with perimeter security is to issue policies that forbid using certain technologies such as IM or Web conferencing. Users will ignore such policies, and service providers and developers will find a way around simple firewall rules designed to block "unauthorized" communications. Don't risk compromising your role and effectiveness as an IT professional by hindering rather than facilitating technology use. As you address security issues, facilitate adoption of new technology.

Traditionally, using VPNs for remote access simply meant establishing a connection over the Internet to the company LAN by using a tunneling protocol such as PPTP or L2TP. Once connected, remote users were virtual members of the internal LAN and could access IP-accessible resources on that LAN as if they were in the office (although access was much slower due to the latency of the remote connection).

True PPTP- or IPsec-based VPNs have an undeserved reputation as hard to administer and support (the biggest complaint is that you must install proprietary client software on all remote users' PCs). I don't understand why companies have relied so much on third-party VPN solutions rather than on the native Windows PPTP and L2TP support. Installing an RRAS server is easy, and Windows has had a built-in VPN client since Windows NT. Using PPTP is especially easy. If you want two-factor authentication using client certificates, you'll have to use L2TP and deploy client certificates (but that's true with any type of two-factor authentication). Using the Connection Manager Administration Kit (CMAK), you can create a wizard that automatically sets up the VPN connection in the user's Network Connections folder. You can distribute the wizard as an email attachment, on a CD-ROM, or as a Web download.

The biggest problem I've encountered with VPNs is caused by firewalls between the VPN server and the remote user. Most firewalls must be explicitly configured to allow PPTP or IPsec (L2TP rides inside of IPsec) pass-through for outgoing VPN connections, and not all administrators are willing to do this. These occasional connectivity problems are one of the reasons to use SSL VPNs instead.

Not all SSL VPNs are true VPNs—many are simply a reverse HTTP Secure (HTTPS) proxy. With a reverse proxy server, you can take browser-based applications originally deployed for access by internal LAN users and make them available to remote users without changing the internal application server. The proxy server poses as a secure Web server on the Internet; after remote users successfully connect and are authenticated using their normal Web browsers, the proxy server acts as middleman between the user and intranet server. ISA Server has been doing this for many years, but the term "SSL VPN" has come into use as new companies have gotten in on the reverse proxy game. The key advantage to using a reverse proxy is that you can easily make internal Web applications available to remote users without doing any client-side setup or installation and without modifying the internal Web application. And you don't run into the connectivity problems I mentioned earlier caused by firewalls blocking outgoing tunneling protocols.

Use a reverse proxy when you need to provide remote access to an internal Web application. Use SSL VPNs when you need remote network access to the internal network at the transport level (TCP/UDP). True SSL VPNs provide tunneling of IP traffic between the internal LAN and the remote user. OpenVPN is an open-source, true SSL VPN. For more information, read "Putting OpenVPN to Work" (May 2005, InstantDoc ID 45844). Other true SSL VPNs are available from ISVs such as Aventail and Citrix. SSL VPNs make a lot promises as to ease of use and administration and lower cost of ownership, but Windows native VPN options work well if you use the management capabilities of CMAK, Group Policy, and Certificate Services. If you must support non-Windows remote users, SSL VPNs can be a more compelling option. For an informative guide to SSL VPN products, see Buyer's Guide: "SSL VPN Products" (April 2005, InstantDoc ID 45612).

IDS and IPS solutions don't vary as much in detection features as they do in the ways they respond when they detect suspicious or unauthorized traffic. IDS solutions focus on logging and alerting. IPS solutions attempt to stop the intrusion by reconfiguring the firewall in real time or by issuing TCP resets. When IDS solutions get it wrong (return false positives), your Inbox fills up and your pager melts down from too many alerts. When IPS solutions get it wrong, important business processes are stopped dead in their tracks. Unless you can dedicate staff to an IDS or IPS, your resources might be better spent on direct perimeter security solutions.

Perimeter security used to be a matter of configuring firewall rules; now, perimeter security is a multifaceted, multi-layered, and much more complicated area of security, and it's much more than the boundary between the Internet and your intranet. Today, many applications straddle these two networks through logical connections that essentially circumvent your firewall. The first step in planning perimeter security is to identify all your connections, both physical and logical, to the outside world. It's important to remember that perimeter security changes constantly and additional perimeter connections crop up as new technologies to leverage the Internet are created. For example, remote-control–based services, such as GotoMyPC, are quickly gaining momentum. Users can easily subscribe to and use GotoMyPC for remote access, but when they do, they open up a worm hole directly into your network through their desktops.

As I mentioned earlier, resisting new kinds of connections to the outside world is futile and can be dangerous to your company. If you try to stop technical advances such as IM and Web conferencing, users will find a way around you, leaving your systems—and your job—less secure. Stay vigilant. Plan ahead. Stay safe.