Perimeter Security

You probably remember the "old days," when settingup security commonly meant using a firewall. Buteven then, this was a woefully narrow viewpoint.

Establishing perimeter security requires much more thanusing firewalls and detecting intrusions. A firewall is only onecomponent of perimeter security, and perimeter securityis just one component of security. Here are some things toconsider when establishing perimeter security and a checklist you can use to plan perimeter security in today'senvironment 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 thata 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.

Application Gateways
Every protocol and application is vulnerable to malformed data and irregularities inadvertently introduced by the designers and coders of the associated software. More and more applications are exposed to potentially hostile computers and malicious content or traffic on the Internet that can contain bad data. And the risk increases with the drive toward greater mobility. To provide a more transparent experience for mobile users, common practice is shiftingaway from virtual private networks (VPNs) to secure remoteaccess at the application level. For example, MicrosoftExchange 2003's support for remote procedure calls (RPC)over HTTP allows users to use Outlook inside or outside theLAN with no difference in the user experience. And moreand more companies are integrating processes with theirbusiness partners at the transaction level by using SimpleObject Access Protocol (SOAP) and related protocols. As aresult, organizations are exposing a larger attack surface atthe application level, and hackers are taking advantage anddelivering application-level attacks.

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 externalsystems fully up to date. Proactively installing all patches toOSs and applications is key to ensuring perimeter security.(Keep in mind that patching can be undermined by newlydiscovered vulnerabilities being made public before a patchis 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 gatewayscan look for specific known attack methods, but that's nottheir focus. An application-level gateway inserts a systembetween the Internet and the application server that understands the relevant application protocol that's in use. Thisapplication-level gateway's system appears to the outsideworld as the end-point application server, but in actuality,the gateway interprets each incoming request, reduces therequest to the application server's own internal lexicon, thenbuilds a new request from scratch discard or prevent anymalicious, malformed content from getting through. Thegateway then sends the new request to the actual applicationserver and processes the server's reply in a similar way. Forexample, an SMTP gateway that carefully deconstructs anincoming SMTP message and then rebuilds it from scratchwith strict adherence to the SMTP protocol specification discards any malformations such as invalid character sequencesor buffer overflows in the message.

Organizations have differing application gateway needs,but almost all use applications and protocols for Webbrowsing (via HTTP), email (via SMTP), and instant messaging (IM). These three protocols make applicationsparticularly attractive targets to four types of attacks: directattacks, malware infection, phishing, and outboundcontent 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 particularlyvulnerable to malware infection. These sameprotocols also allow social engineering attackssuch as phishing. The risks associated withthese protocols aren't limited to inboundcontent—outbound content (email messages,Web postings, and instant messages) sent fromemployees can expose organizations to risksthat endanger privacy, confidentiality, andregulatory compliance.

Although no product on the market provides application-level gateway support forevery protocol and application, Microsoft's ISAServer offers the widest native support (including for SMTP, HTTP, FTP, and RPC). ISA Serveralso supports a variety of partner-developedplug-ins for other protocols and applications.ISA Server's extensible architecture and Microsoft's successful collaboration with partnershelp position ISA Server as a type of universalapplication gateway, but you can also use someof the many best-of-breed solutions for specificapplications (e.g., FaceTime's solutions for IMsecurity and antispyware). Web-filtering solutions, such as those from Barracuda Networks,Websense, St. Bernard Software, and SurfControl, help you enforce policies that determinewhere internal users can go on the Web. Byusing keyword monitoring, such solutions alsohelp you monitor employees or block themfrom sharing confidential information or posting or accessing inappropriate content.

Beyond Web, email, and IM vulnerabilities, application-level perimeter risks alsocome from peer-to-peer (P2P) networks, Webconferencing, and XML. Many developersof application-gateway solutions originallydesigned for Web filtering and IM security areextending their solutions to support P2P andWeb conferencing.

The growing use of XML communications,especially in the form of SOAP, for businesstransactions poses problems different fromthose of the more end-user–based technologies I've been discussing. IT uses XML to linkmission-critical business systems with business partners' corresponding systems. Thetext-based nature of XML makes any securitysolution rely heavily on CPU and memoryresources because of the recursive parsinginvolved. Administrators are understandablyloathe to put an added load on applicationservers, and the number of application servers affected can quickly grow out of controlin organizations that use XML. If your organization uses XML, you'll want to add anappliance-based XML firewall to your arrayof 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.

VPNs and SSL VPNs
Despite the trend toward providing remoteaccess at the application level, VPN accessis still very important to mobile and remoteusers. VPNs have become confusing with theadvent of so-called Secure Socket Layer (SSL)VPNs. Let's talk about traditional VPNs, thenI'll define SSL VPNs and discuss their prosand cons.

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).

Intrusion Detection
Despite your best efforts to deploy an array ofperimeter security defenses, there's still the riskthat attackers can penetrate your network, soyou'll want to think about intrusion detectionand prevention. Intrusion detection systems(IDSs) and intrusion prevention systems (IPSs)use one or more of three basic technologies todetect intruders: packet examination, policyconfiguration, and pattern analysis. Most IDSand IPS solutions examine packets for knownattack signatures. The effectiveness of thisdetection method depends on how manyattack signatures the vendor builds into theproduct and how often it's updated. Most systems also let you configure policies that defineexpected network traffic patterns, but this method requires a lot of research and work,and you must maintain the policies as newapplications are brought on line and traffic patterns change. Some systems employ variousalgorithms and pattern analysis in an attemptto automatically detect anomalous traffic.These systems hold promise for the future, butright now they suffer from the same limitationsand false positives as do heuristics- and Bayesian analysis–based antispam solutions.

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.