Magic Quadrant for Network Intrusion Prevention System Appliances, 2H05
30 November 2005
Greg Young   John Pescatore   

Source:  Gartner
Note Number:  G00133189

The network intrusion prevention system appliance market is in a period of maturity and consolidation. A smaller group of vendors are getting an increasing percentage of the market, but the evolving threat means that those that fail to maintain innovation ahead of market demands will be left behind.

What You Need to Know 

Network intrusion prevention system (IPS) can detect and block attacks, such as worms, and act as a pre-patch shield for systems and applications. The Sasser and Zotob worms have driven network IPS to be ready for enterprise use. The market for network IPS appliances is entering a phase of maturity and consolidation. The significant benefits of an in-line attack-blocking technology can only be realized with a product that fits your security processes and is sized appropriately. The Magic Quadrant for Network Intrusion Prevention System Appliances is illustrated in Figure 1.

Strategic Planning Assumption(s) 

Sales of stand-alone IPS appliances will be less than 10 percent of overall next-generation firewall revenue by the end of 2008 (0.7 probability). Through 2007, in-house testing will have been done for 90 percent of new acquisitions of network IPS in appliances and next-generation firewalls (0.8 probability).

Magic Quadrant 

Figure 1.
Magic Quadrant for Network Intrusion Prevention Systems Appliances, 1H05

Source: Gartner (November 2005)

Market Overview 

The network IPS market has its roots in the improvement and often replacement of intrusion detection systems (IDSs). IPS contains all the detection features of IDS, with two critical areas of improvement: (1) Intrusion prevention moves beyond simple attack signature detection to add vulnerability-based signatures as well as anomaly detection capabilities; and (2) network IPS sensors have high processing rates to support in-line automated blocking or handling of attacks. Essentially, network IPS adds "block attacks and let everything else through" security enforcement to the "deny everything except that what is explicitly allowed" policy enforcement provided by the first generation of firewalls. By the end of 2006, most next-generation firewalls will likely use common processing engines to support both functions in one product.

The network IPS market for stand-alone appliances was approximately $246 million in 2004 (including product and maintenance but not services) and will increase to more than $400 million by the end of 2005. McAfee had the largest IPS market share of revenue, followed closely by TippingPoint and Internet Security Systems (ISS). This is a crowded market with several dozen vendors providing network IPS products, many with very small installed bases. Consolidation will likely continue because there already is increasing consistency of shortlists of vendors, particularly in larger enterprises. For more on this subject, see "The Network IPS Market Will Consolidate in 2005."

Vendor lineage is stereotyped in the products: IPS from security companies tends to be strong on security function and less impressive on network performance, which is the opposite of companies in which security is not their primary business (for example, network infrastructure vendors and startups). These differences will be reduced in the midterm and, in the long term, will become almost irrelevant as the next-generation firewall market increases (see "Network Security Platforms Evolving Into Single-Appliance Solutions.")

On average, solutions are priced to $50,000 per Gbps of deep inspection (this is an average, and many products provide less than 1-Gbps capability). Most vendors provide more than five models, with some entry-level products offered for less than $15,000. Maintenance fees vary considerably. Signature update fees also vary but are included with maintenance for most products. Most products include a local-management console, with dedicated management appliances resulting in an additional cost. The total cost of ownership and system management capabilities of network IPS products should be key evaluation criteria when comparing competing products.

Reliability and availability are also key criteria for any in-line device. Bypass unit modules allowing fail-open for copper ports are an additional charge for Reflex, Radware (except the DefensePro 3020), and Check Point Software Technologies (for the 410 and 610 products only). With other vendors, this is included in the base price for units in recognition that this is the standard deployment mode for most.

Market Definition/Description 

The network IPS market includes in-line devices that perform full-stream assembly of network traffic, and they provide detection, using several methods including signatures, protocol anomaly detection, and behavioral or other techniques.

Network IPS is also provided within a next-generation firewall, which is the integration of an enterprise-class network firewall and network IPS. The next-generation firewall market will subsume the stand-alone network IPS appliance market (which is the subject of this Magic Quadrant) at the enterprise edge. However, this will not occur immediately because of the following factors:

• Enterprise firewall vendors have been slow to imbue the IPS within their next-generation firewall products with the same capabilities as the stand-alone appliances they offer.
• The firewall refresh cycle for the enterprise is between three and five years, meaning many enterprises will not look at the next-generation firewall to replace established firewalls until as late as 2009.
• New network security technologies are often provided first through separate appliances before being included in other offerings.

The network IPS market is already in the first stage of consolidation, with Gartner seeing a more consistent list of vendors on our customers’ shortlists. With fewer companies receiving a larger share of the revenue, there are opportunities for the acquisition of companies providing quality products, but there are risks for buyers of products if the buyers are not increasing their installed base.

Inclusion and Exclusion Criteria 

Only products that met the following criteria were included:

• Products that meet Gartner’s definition of network IPS
• Operate as an in-line network device that runs at wire speeds
• Perform packet normalization, assembly and inspection
• Apply rules based on several methodologies to packet streams, including (at a minimum) protocol anomaly analysis, signature analysis and behavior analysis
• Drop malicious sessions — do not simply reset connections
• Achieved IPS product sales in the last year of more than $1 million within a customer segment that is visible (for example, a single sale of $1 million would not be considered)

Products and vendors were excluded if:

• They provide only a next-generation firewall platform, which is covered in "Magic Quadrant for Network Firewalls, 2H04." We should note that next-generation firewall vendors, which provide an IPS appliance, have that appliance included in this Magic Quadrant (Juniper ISG and Check Point with SmartDefense firewalls).
• They are in other product classes or markets, such as:
• Network behavior anomaly detection products. Products from companies such as Arbor Networks, Lancope, Mazu Networks and Q1 Labs. These products are not in-line IPS, but instead focus on networkwide detection of anomalies and provide only reactive capabilities, such as modifying access control lists. IPS vendors are beginning to implement feeds from network anomaly detection as one means of having intelligence from across the network, which can be used to prioritize blocking.
• Network access control (NAC) products are not IPSs and are covered in other Gartner research. NAC focuses on quarantining authorized endpoints that are infected or vulnerable, rather than actively shielding against attacks.
• Are host IPSs. Software is on servers and workstations rather than an in-line device on the network.

Evaluation Criteria 

Ability to Execute 

The Ability to Execute criteria include:

• Product service and customer satisfaction in deployments
• Overall business viability, including overall financial health and prospects for continuing operations
• Sales execution and pricing including dollars per Gbps, revenue, average deal size, installed base and use by managed security service providers (MSSPs)
• Market responsiveness and track record. Delivering on new features, such as receiving and acting on feeds from outside the IPS, rate shaping and quality of service, and solid multi-device management.
• Market execution, including delivering on features and performance, such as product vision, customer satisfaction with those features, and those features winning out over competitors in selections. Delivering products, which are low latency and multi-Gbps, have solid internal security, behave well under attack, have high availability, and are available ports that meet demands, is rated highly. Speed of vulnerability-based signature production was highly rated.
• Customer experience and operations, including management experience and track record, and depth of staff experience, specifically in the security marketplace. Also important is low latency, rapid signature updates, overall low false positive and negative rates, and how the product fared in events such as the Zotob and Slammer worms.

Source: Gartner

Completeness of Vision 

The Completeness of Vision criteria include:

• Market understanding and strategy. This includes providing the correct blend of detection and blocking technologies that meet the requirements for IPS, innovation, having vulnerability rather than exploit product focus, and integration with other security solutions. Also included is understanding and commitment to the security market and, more specifically, the network security market. Vendors that rely on third-party sources for signatures or have weak or “short cut” detection technologies score lower.
• Sales strategy includes pre- and post-product support, value for pricing, and providing clear explanations and recommendations for detection events.
• Offering strategy, with emphasis on product road map, signature quality, next-generation firewall integration and performance. Successfully completing third-party testing, such as the NSS Group IPS tests and Common Criteria evaluations, is important. Vendors that reissue signatures, are overreliant on behavioral detection and are slow to issue quality signatures do not score well.
• The business model includes the process and success rate for developing new features and innovation and R&D spending.
• Vertical, industry and geographic strategy includes the ability and commitment to service geographies and vertical markets (for example, MSSP and the financial sector).
• Innovation, including R&D, and quality differentiators, such as performance, management interface and clarity of reporting. The road map should include moving IPS into new placement points and better-performing devices.

Source: Gartner

Leaders 

Leaders demonstrate balanced progress and effort on all execution and vision categories. Their actions raise the competitive bar for all products in the market, and they can change the course of the industry. To remain in the Leaders quadrant, these vendors must have demonstrated a track record of delivering successfully in enterprise IPS deployments and winning in competitive assessments. Leaders produce products that provide high signature quality, offer low latency, and have a range of models. Leaders consistently win selections and have been consistently visible on enterprise shortlists.

A leading vendor is not a default choice for every buyer, and clients are warned not to assume that they should buy only from the Leaders quadrant.

Challengers 

Challengers have products that address the typical needs of the market with strong sales, visibility and clout that add up to higher execution than niche players. Challengers often succeed in established customer bases but do not yet fare well in competitive selections.

Visionaries 

Visionaries invest in the leading/bleeding edge features that will be significant in next generation of products and give buyers early access to improved security and management. Visionaries can affect the course of technological developments in the market, but they lack the execution skills to outmaneuver challengers and leaders. There are currently no IPS vendors that meet these criteria.

Niche Players 

Niche players offer viable solutions that meet the needs of some buyers. Niche players are less likely to appear on shortlists, but they fare well when given the right opportunity. While they generally lack the clout to change the course of the market, they should not be regarded as merely following the leaders. Niche players may address subsets of the overall market (for example, the small and midsize business [SMB] segment or a vertical market), and often they can do so more efficiently than the leaders. Niche players are often smaller firms, produce only software appliances, and/or do not yet have the resources to meet all of the enterprise requirements.

Vendor Comments 

3Com (TippingPoint) 

Acquired by 3Com earlier this year, TippingPoint did not suffer any significant drop in performance from this change. As a pure-play IPS vendor and not having to convert an IDS product, TippingPoint had the advantage of designing its products to perform well in a network environment. With a 5-Gbps product, TippingPoint devices have been shown to be well-behaved in-line devices and often win product selections in which low latency is heavily weighted.

If 3Com executes correctly, TippingPoint will be able to move IPS onto a switch and also utilize 3Com channels for the SMB market when they introduce sub-11-Mbps products. 3Com showed its commitment to advancing IPS as a key product area by appointing Tippingpoint’s CTO as the 3Com CTO. TippingPoint does not offer a network firewall on its IPS and will need to do so in order to enter the next-generation firewall market.

Check Point Software Technologies 

Check Point Software Technologies has not had a stand-alone IPS appliance for the enterprise edge. Check Point does provide a next-generation firewall in its Smart Defense offering, but it really has not had a purpose-built in-line sensor offering. Check Point InterSpect is its "internal IPS" offering, but this has had limited visibility in the network IPS appliance space, which is driven by edge requirements. To remedy this, Check Point announced its intention to acquire Sourcefire (the acquisition will be completed in the first quarter of 2006). This has the potential to provide a stronger deep-inspection engine across the Check Point platforms, particularly if Check Point integrates SourceFire RNA across its products. Check Point is financially strong, and its wide international support is important for deployments across the world.

Cisco Systems 

Cisco Systems entered the IPS space this year with an offering across an impressive number of platforms. In addition to the IPS appliance, Cisco IPS software can also be run on IOS platforms, on ISR routers, on IDS/IPS blades in Cisco switches, within the ASA appliance, on access routers and on PIX firewalls.

Cisco’s IPS appliance is its former IDS platform with the software upgraded and reconfigured for placement in-line. Enterprises that are nearly “all Cisco” in infrastructure are good candidates for Cisco IPS, especially enterprises in which Cisco IDS is already in place. With the IPS products less than 1 year old, Cisco is not often winning in competitive product selections against other IPS.

DeepNines 

DeepNines has pursued the "far edge" placement point with IPS offering a Layer 2 transparent (no IP address) in-front-of-the-router device. DeepNines expanded this line to include traditional IPS, which can be applied to a wider number of placement points. These software appliances are close in functionality to an all-in-one appliance and may be attractive to the SMB market because they include a firewall, gateway antivirus and some anti-spyware capability.

Internet Security Systems 

A security company with a strong history in IDS, Internet Security Systems has two significant assets outside its IPS appliance: its X-Force vulnerability research team and its MSSP business. Investing in vulnerability research has allowed ISS to be the leader in new signatures, and this capability has driven its product design around vulnerabilities rather than exploits, which is fundamental to good-performing IPS and sound signatures. ISS design investments in IPS have made it easier for it to add new protocols (for example, voice over Internet Protocol [VOIP]), for inspection within its Protocol Analysis Module (PAM). ISS has been successful in migrating its IDS customers to the Proventia G, but it is held back from greater success by not yet offering a high-performance purpose-built appliance. IPS management is integrated with other ISS products via the SiteProtector manager.

Juniper Networks 

Netscreen was an early innovator with deep-packet inspection after its acquisition of OneSecure. With the Juniper acquisition now behind it, innovation and new product features are again showing up in its IPS products, with full-featured appliances up to 1 Gbps inspecting a large number of protocols. As with its firewall competitor Check Point, Juniper is well-positioned in the next-generation firewall market (the hardware-based ISG firewalls provide up to 2 Gbps of deep inspection), yet Juniper has not maintained high visibility in the IPS appliance space with its IDP IPS products. Juniper’s software-based hardware IDP IPS appliance is popular with enterprises that already own Juniper infrastructure equipment. The Juniper IDP product has a range of models and a strong management console.

McAfee 

McAfee, known more for antivirus software rather than network security, has had considerable success in the IPS field through acquisition and enhancement of the IntruShield product. McAfee is often seen on enterprise IPS short lists with its purpose-built IntruShield IPS and performs well in throughput testing. IntruShield includes Secure Sockets Layer (SSL) acceleration/inspection technology and has a 2-Gbps appliance. McAfee has been including customization for MSSPs in recognition of the growing market for customer premises and “in the cloud” managed services. For more information on this subject, see "'In the Cloud' Security Services Will Change Providers' Landscape."

To maintain this lead, McAfee must incorporate a strong network firewall with its IPS (for example, a next-generation firewall), and integrate IntruShield with its other products through a unifying management console capability.

NFR Security 

NFR Security has leveraged its IDS lineage to move into the IPS space with its Sentivist product line. Although Sentivist IPS is a software appliance, NFR is seeing success at the enterprise and with the government deployments. With a separate management appliance as a mandatory, NFR is better suited to multiappliance deployments. Sentivist offers a good interface, good reporting, a minimum of configuration and is suited for sub-200-Mbps placement points. NFR recently released an Enterprise Series Sensor line for higher throughput placement points.

NitroSecurity 

NitroSecurity takes a nontraditional approach to IPS with an emphasis on the custom database within its software appliance IPS and detection weighted toward correlation and quarantine rather than signatures. NitroSecurity offers a Layer 2 transparent mode IPS that is seeing success in healthcare and education verticals. NitroSecurity proposes some innovative features on its IPS road map but requires increased signature emphasis, better support and financial strength to move up to competing effectively in enterprise shortlists.

Radware 

Radware offers purpose-built multigigabit IPS appliances up to 3 Gbps. Capitalizing on its network expertise, Radware DefensePro IPS includes solid in-line behavior, such as low latency and denial of service (DOS) features, including traffic shaping. Radware has increased its investment in vulnerability and IPS signature research but lags the leaders in proactive protection.

Reflex Security 

Reflex Security is a startup IPS firm offering a low-cost software appliance requiring a minimum of configuration designed for SMBs and Type C enterprises and the MSSPs servicing them. The Reflex product overlaps the all-in-one security appliance space as it includes firewall, gateway antivirus and anti-spyware; however, it is most often deployed for its IPS capabilities.

Sourcefire 

Sourcefire has leveraged its IDS lineage successfully into IPS. Sourcefire developed a purpose-built appliance this year, allowing it to compete more effectively at the enterprise.

Sourcefire IPS can now receive feeds from the Sourcefire RNA vulnerability assessment product to allow the IPS to make prioritized blocking decisions and have endpoint (clients and servers) visibility (see "Use Endpoint Intelligence to Improve Security Defenses". Although Sourcefire manages the open-source Snort IDS product, its IPS is full-featured and is not to be confused with in-line original equipment manufacturer (OEM) Snort implementations. Sourcefire IPS is also available via OEM through Nortel Networks and on the Crossbeam platform. Check Point announced it would be completing proposed acquisition of Sourcefire in the first quarter of 2006.

StillSecure 

Strata Guard (renamed from BorderGuard) is a software appliance solution suited to sub-Gbps placement points. BorderGuard IPS is integrated with the StillSecure VAM vulnerability management product supporting the reality that IPS is part of a process of vulnerability remediation (see "Intrusion Prevention Process Consists of Seven Steps". Having the vulnerability management feed widens the network view for more-intelligent IPS alerting and blocking decisions.

Symantec 

Symantec’s SNS 7000 series appliance has low visibility in the enterprise market, but this is consistent with Symantec’s focus on the SMB multifunction network security appliance space, and that the product is very new to the market. The SNS is friendly for administrators, uses the familiar LiveUpdate for signature updates, has clear incident viewing, and includes innovative elements, such as FlowChaser, which allows for identifying the source of DOS attacks. SNS has not done well in competitive IPS "bake-offs," primarily from a network performance perspective, but it is popular with enterprises that have a large Symantec investment.

Top Layer Networks 

Top Layer Networks’ lineage is load balancing and edge-of-network DOS. This has translated well to IPS, with Top Layer offering purpose-built hardware in the multi-Gbps placement points with its 5500 appliance. Top Layer provides a balanced blend of safeguards and detection methods, including network firewall, DOS protection and traffic shaping. Top Layer lags other players in the proactive protection of narrow blocking signatures, but it does have multidevice management capabilities, low latency and good post-sales support.

V-Secure Technologies 

V-Secure takes the approach that is weighted heavily toward behavioral detection in its software appliance. Signature detection was introduced in version 8.0 in recognition that signatures are a required detection technology. V-Secure signature release times are longer than the industry average.

Evaluation Criteria Definitions 

Ability to Execute 

Product/Service: Core goods and services offered by the vendor that compete in/serve the defined market. This includes current product/service capabilities, quality, feature sets, skills, etc., whether offered natively or through OEM agreements/partnerships as defined in the market definition and detailed in the subcriteria.

Overall Viability (Business Unit, Financial, Strategy, Organization): Viability includes an assessment of the overall organization's financial health, the financial and practical success of the business unit, and the likelihood of the individual business unit to continue investing in the product, to continue offering the product and to advance the state of the art within the organization's portfolio of products.

Sales Execution/Pricing: The vendor’s capabilities in all pre-sales activities and the structure that supports them. This includes deal management, pricing and negotiation, pre-sales support and the overall effectiveness of the sales channel.

Market Responsiveness and Track Record: Ability to respond, change direction, be flexible and achieve competitive success as opportunities develop, competitors act, customer needs evolve and market dynamics change. This criterion also considers the vendor's history of responsiveness.

Marketing Execution: The clarity, quality, creativity and efficacy of programs designed to deliver the organization's message in order to influence the market, promote the brand and business, increase awareness of the products, and establish a positive identification with the product/brand and organization in the minds of buyers. This "mind share" can be driven by a combination of publicity, promotional, thought leadership, word-of-mouth and sales activities.

Customer Experience: Relationships, products and services/programs that enable clients to be successful with the products evaluated. Specifically, this includes the ways customers receive technical support or account support. This can also include ancillary tools, customer support programs (and the quality thereof), availability of user groups, service-level agreements, etc.

Operations: The ability of the organization to meet its goals and commitments. Factors include the quality of the organizational structure including skills, experiences, programs, systems and other vehicles that enable the organization to operate effectively and efficiently on an ongoing basis.

Completeness of Vision 

Market Understanding: Ability of the vendor to understand buyers' wants and needs and to translate those into products and services. Vendors that show the highest degree of vision listen and understand buyers' wants and needs, and can shape or enhance those with their added vision.

Marketing Strategy: A clear, differentiated set of messages consistently communicated throughout the organization and externalized through the Web site, advertising, customer programs and positioning statements.

Sales Strategy: The strategy for selling product that uses the appropriate network of direct and indirect sales, marketing, service and communication affiliates that extend the scope and depth of market reach, skills, expertise, technologies, services and the customer base.

Offering (Product) Strategy: The vendor's approach to product development and delivery that emphasizes differentiation, functionality, methodology and feature set as they map to current and future requirements.

Business Model: The soundness and logic of the vendor's underlying business proposition.

Vertical/Industry Strategy: The vendor's strategy to direct resources, skills and offerings to meet the specific needs of individual market segments, including verticals.

Innovation: Direct, related, complementary and synergistic layouts of resources, expertise or capital for investment, consolidation, defensive or pre-emptive purposes.

Geographic Strategy: The vendor's strategy to direct resources, skills and offerings to meet the specific needs of geographies outside the "home" or native geography, either directly or through partners, channels and subsidiaries as appropriate for that geography and market.

You wouldn't go into battle without a trusted group of generals strategizing your best attacks and defenses, so why try to secure your data without an infosec team and plan? If you don't have a dedicated security operations center and staff, you'll be scrambling to shore up your defenses, even as the bad guys are invading your system.

A SOC can be as simple as a set of offices or cubicles next to each other, or as sophisticated as a standalone complex with extra-large displays, two-factor physical security and a budget to match. Typically, only the largest companies have the resources to build and staff a dedicated SOC. In a recent survey of Secure Enterprise readers, 72 percent of respondents with fewer than 5,000 employees had no plans to build a SOC. Among the 28 percent who have a SOC or plan to build one, 53 percent will collocate in the network operations center, which makes sense because an existing NOC provides the framework to build in the additional functionality required for a SOC. The rest plan to house the SOC in a separate location, either a building (25 percent) or a room (22 percent).

Most Wanted Skills Click to Enlarge

The tasks the security operations center handles can range from typical event management and incident response to account administration, investigations and forensics. Some companies choose to outsource their SOCs, because they want the expertise and 24-hour monitoring of a dedicated security team without staffing and building a SOC. For many, it makes sense to maintain an internal SOC, especially when a NOC already exists. See "How To Set Up a War Room", for a checklist of the essentials. Make sure you've got the budget to build out and hire. But remember, not everyone can speak Perl and decode a TCP/IP packet in three seconds. In "Most-Wanted Skills," we outline the various skill sets needed.

SOC It to Them

The SOC facility, like any other critical operations center, must be secure--both electronically and physically. Building a separate infrastructure is expensive and probably not worth the effort. Instead, try to use an existing, secure infrastructure. In many cases, the data center is a good fit, because it already has manned guard stations, cameras, security clearance and sign-in/sign out requirements and other physical security controls. Everyone who enters and leaves the SOC must be tracked to provide an access audit trail. Even a simple login sheet is better than nothing.

Latest Issue of Secure Enterprise Magazine Read more >>

And only specific employees should have access. Network engineers, application developers and business partners, for example, don't need physical access to the SOC. The SOC manager, or leader, provides access approval. While the CISO or CIO is too high a position to make day-to-day decisions, he or she would still be responsible for the governing policies.

Of course, the greatest threat to your SOC will come from malicious users gaining access to it over the network. Your SOC will access key security systems, such as firewalls, IDSs, IPSs (intrusion-prevention systems), and antivirus- and event-management consoles. It will also store confidential data, such as configuration information, trouble tickets and event logs.

So your security controls must ensure the integrity and confidentiality of the data and systems. Common and successful approaches to this end include having highly restrictive firewall policies for the SOC and placing an IDS--or better yet, an IPS--with restrictive policies inline between the SOC and the rest of the company network. A nonroutable internal address space inside the SOC will give it an additional level of obscurity. Also, make sure your firewall rules lock down the environment. If remote access to the SOC is needed from within the company network, require a VPN connection.

Devices within the SOC should be under the management of the SOC leader, and all changes to these devices must be tested and audited before being made. In addition, you might want to set up a VLAN (virtual LAN) to provide access to key network and security devices in the event the production network is unavailable or saturated with traffic so you can't get to it.

Network Connections

But it's not all about hiding the SOC. An additional network connection will give your SOC personnel an outsider's view of your network. This link could be a T1 line or even an inexpensive DSL connection, preferably from an ISP other than the one providing your primary Internet connections. With this external view, you can perform tests to determine vulnerabilities in the event of a perimeter compromise. And if your primary or secondary network connection goes down, the ancillary network connection can be used for sending e-mail, downloading updates and performing investigations.

Ideally, the account won't be tied to the primary company, nor will DNS entries indicate who owns the connection. This way, when investigating a suspected intruder or attacker, you can visit the Web site or server using an IP address that isn't traceable to your company so as not to let the culprit know you're aware of the attack.

This ancillary network connection must not be tied to your production network. If possible, use an air-gap approach where there's no physical connection between the two networks. You also can set up different VLANs on a single switch or different interfaces on a firewall with a strict set of rules in place. Undoubtedly, you'll need a wireless network in the SOC so workers can roam between conference rooms and offices. However, wireless access should be limited to only specific users and systems. One possible solution is to have wireless users access the SOC network over a VPN requiring two-factor authentication. The wireless network should have virtually no access to the SOC except over the VPN, ensuring that no wireless user can gain access to critical systems.

Coverage requirements are a key factor when proposing and designing a SOC. If you're seeking coverage past normal business hours, consider setting up a SOC in a remote time zone so its staffers can serve your after-hours needs without working the graveyard shift themselves. For some companies, it may make sense to maintain one SOC in North America and another in Asia or Europe, though additional security controls would have to be put in place to safeguard information flowing between the two.

No SOC is complete without a place to analyze suspicious programs and test possible solutions. This is especially true for organizations unlucky enough to be hit by a zero-day or unknown exploit, worm or virus. Most of the time, even unknowns are a variant of some known worm. The variant may use a different payload or a new propagation method. Still, it may be difficult to determine what's occurring and what you must do to stop it. Enter the sandbox.

A sandbox is a set of systems--or even a single system--that's separate from any other network in your organization and used to analyze the behavior of suspicious applications. You can also use a single system running a virtual machine application, such as VMWare. Set up multiple VMWare OSs to share a private network segment--for instance, you can have Windows System A as the infected system and Windows System B as the target system. Run a packet-capture tool, such as Ethereal, on System A to capture all packets going in and out of the system, then run Ethereal on System B and compare the two. Other useful tools for sandboxing, including regmon, filemon and diskmon, are available from Sysinternals. Of course, similar solutions can be found for your favorite Unix OS, too.

A SOC also demands a large display to monitor the health of network traffic and load, routers and firewalls, Active Directory, DNS, production-application servers and other key items.

A Series of Unfortunate Events

Security events can be generated from many devices and applications, including firewalls, routers, VPN concentrators, Web and antivirus applications, and IDS/IPS devices. The sheer number of events that many companies must collect, analyze and store can be staggering. To help, many SOC teams are turning to SEM (security event management) tools. Arcsight, GuardedNet and Network Intelligence are the leaders in this area. It's not uncommon to hear that some SEM tools process several thousand events per second.

But not every event must be captured and analyzed. Use aggregation and selectively choose which types of events get captured to reduce the volume of data. You can limit your analysis to only events coming from critical servers and systems, for instance. A SEM product working with a vulnerability assessment (VA) tool can help you identify those events that are targeted toward systems vulnerable to the attacks. Make sure your VA data is up-to-date and scans are done frequently. This can be challenging when dynamic IP addressing is used, because many VA products use only the host IP address as the unique identifier. Thus, if the workstation's IP changes over time, the VA solution may have difficulty tracking it and redundant scan information will be included.

As for storing the data generated from these events, the length of time to keep the logs depends on various government and industry regulations and standards, such as HIPAA, SOX and ISO 17779. Some of these don't define a retention time, but others specify a minimum of seven years. NIST, in its "Computer Security Incident Handling Guide, Special Publication 800-61," recommends retaining at least several months of data. The North American Electric Reliability Council says audit logs must be kept for three years. To help reduce log storage, some SEM tools can save log data by type. You may want to retain your IDS data for 60 days, for instance, but keep VPN logs for 120 days and application logs for years.

Any SEM tool--or any event collection/aggregation tool--must be able to keep working during abnormally high event counts. IDS/IPS devices and firewalls can generate an enormous number of events during a virus or worm outbreak. You can increase the SEM's availability with multiple horizontally partitioned databases. One database can be used for events generated recently while another database is used for historical analysis. The database used for correlation and reporting may be different from the database used for the short-term events. If everything is stored on a single database, the additional load on the server will hamper its ability to run reports.

You also can ensure information availability using other methods. A fault-tolerant design, for instance, keeps your system operational in the event of a network or physical infrastructure failure. With a fully redundant design, events from each device are sent to primary and secondary event collectors, which then send data to aggregation engines. Ideally, from a network-design perspective, these should all be located near the event source. Additionally, you could have two event-management databases--one at a primary SOC and the other at a secondary SOC.

Log Jam

Most security devices can send their logs to a syslog server, which acts as an event collector for these various devices, but the real integration challenge comes when integrating incident logs with application logs, such as those from a Web server or Web application (for example, someone logging in). The vendors of enterprise-class SEMs offer agents or wizards to help simplify this integration, but you must decide which data elements should be captured and written to logs. Some key data to include are date and time, IP address, action performed and user name.

Information on an event must be analyzed in order to be categorized as an incident. Once an event becomes an incident, the ability to track, monitor and document it becomes critical. You can record all this information on a spreadsheet or in an Access database, but these aren't scalable. Much better is a robust management program from the likes of Remedy.

Policies and Processes

Because the SOC will be the first place security events are collected and managed, there must be a clear and consistent set of processes through which to execute your organization's policies and procedures. (This consistent methodology will satisfy documenting requirements specified by SOX and other regulations.)

Incident-response guidelines dictate how incidents are prioritized, who performs what tasks and when to declare an enterprise-level incident. There are many models a company can use to build an incident-response process, including those from SANS, NIST, Carnegie Mellon University, IETF and RFC 2350.

The basic components of an incident-response process are identification, containment, removal, recovery and post-incident analysis. Most companies tend to do the first four steps very well, but truncate the last or never bother to implement the fixes recommended by post-incident analysis. Thus, companies will find themselves dealing with the same problems again and again.

Part of the process is identifying and training an incident-response team, which will usually consist of dedicated and nondedicated personnel. Having an incident-response team reduces chaos, provides consistency and ensures that all process elements, especially notification and documentation, are followed. In addition to the usual techies, such as firewall and server administrators and network operators, include a representative to communicate to the business side. This will guarantee that accurate and timely information is delivered to system users so backup and contingency plans can be implemented.

Jay Milne, CISSP, is a senior security consultant for a large healthcare provider in Northern California. He has 15 years of IT security experience and has consulted for companies such as Chevron and Genentech. Write to him at jmilne@nwc.com.

It's 6 p.m. All is quiet until you notice a growing number of hits in your IDS. Then you see a mess of trouble tickets from end users complaining about slow network performance. Resources dwindle and become unavailable. No one can get to the intranet or Internet. Servers crash. You've just been hit with an enterprise scope worm. Management, of course, wants answers--now.

Bringing together network staff, security folks, local IT support and management is a challenge, but you're prepared: You have a "war room" designed for such a crisis. The resources are available, and all your "generals" know where it is and how to get to it. Here are the bare essentials:

• Dedicated phone lines. The number of lines you need depends on the size of your SOC. Make sure you have at least two dedicated lines, one for conference calls and the other to make secondary calls.

• A fax line. When my company network went down because of the SQL Slammer worm, we used the fax machine to get remediation instructions out to the field offices.

• A dedicated printer with a local connection.

• Plenty of whiteboards and a large projector screen. Make sure everyone can see what needs to be done.

• A network connection to the Internet separate from your corporate network.

• A secure wireless network. Limit the range of connection, and only allow authorized access. When the war room isn't in use, disconnect the wireless network from the rest of the network.

• A small refrigerator stacked with Red Bull or Mountain Dew. No joke.

1. Does your organization have a SOC?
   
   

2. How well is your SOC staffed?
   
   

3. Does your SOC have additional Internet connections
   outside the corporate network?
   
   

top

top

top

Introduction

Computer security technology is still in its infancy. Technologies such as firewalls, antivirus, and IDS have migrated from research labs into production networks, and have become required mainstays both as essential defenses and as legally mandated compliance systems. Computer security systems are complex devices that need to meet a variety of conflicting goals: high performance, fault tolerance, easy administration – and rigorous security processing. Some vendors have staked their claim based on speed, others on cost, and still others on the defensive posture and security of their products. Unfortunately, it’s extremely difficult for the customer to sort through marketing fluff and dubious benchmarks, to determine which products actually work and which merely appear to work. Few customers are sufficiently sophisticated or willing to take the time to do their own testing and most are forced to rely on published results from trade magazines, recommendations from consultants, or industry analysts. Sadly, few of the trade magazines or analysts have the sophistication or time to perform adequate testing, either.

The author’s experience indicates that large numbers of products on the market have excellent and attractive user interfaces, good performance, reasonable costs, rave reviews from loyal fans – and have taken shortcuts in their design that make them significantly less secure than other alternatives. This is not a recent development; it dates back to the early days of the firewall "market." In this article, we examine the evolution of packet filtering firewalls and their current incarnation as "Deep Inspection" firewalls. We compare the fundamental design philosophies of packet filtering firewalls with proxy gateways, and will conclude with a few historical observations regarding the relative effectiveness of conservative design philosophies when compared to their less-rigorous counterparts.

Early Firewalls, Packet Filtering Firewalls and "Stateful Firewalls"

The first firewalls were based on either a proxy design or a simple packet filtering ruleset. The proxy firewall operates by interposing itself in the middle of the application protocol and interpreting it while applying security controls to the application commands and data, where appropriate. The original value proposition of a proxy firewall is that the proxy is essentially a security-oriented reference implementation of the application protocol – in some cases omitting dangerous operations entirely, or providing additional controls on certain security-critical commands. Proxies have always been considered a conservative security design because the proxy reduces the likelihood of protocol backdoors or side-effects since the proxy’s designer is effectively performing a security assessment of the application protocol’s features prior to implementing them. Early packet filter firewalls implemented a simple policy-table lookup based on { source-ip, destination-ip, source-port, destination-port, SYN-seen yes/no } permit or deny. Consequently, packet filters were extremely fast since they did very little computation. They were also extremely easy to implement since they required virtually no security expertise. The simple compute requirements of packet filters, and the fact that they required no security knowledge-base, made them easy to implement in silicon so they quickly became a feature of most routers. From the beginning, proxy firewalls were recognized as being more secure, because they effectively are implementing a correctness check upon the application protocols they gateway. This is still an important property of proxy firewalls. For example, when the author first implemented the FTP proxy in the DEC SEAL firewall, he simply left out unused FTP protocol commands that allowed users to issue remote commands to the FTP server. Years later, when hackers discovered those commands and attempted to exploit them, they simply did not work against proxy-protected networks because the proxy refused to gateway the command through to the target. Sites behind packet filtering firewalls were vulnerable, if the reachable systems behind the firewall were themselves vulnerable.

In 1993, "stateful" firewalls appeared on the market. The first popular stateful firewall, Checkpoint’s Firewall-1, implemented a simple connection-origin table that tracked whether a connection had originated behind the firewall and permitted response packets for that connection. A layer-7 hook to parse FTP PORT commands and update the state table allowed FTP to work transparently through the firewall. Subsequent versions of the stateful firewall added TCP sequence number interpretation, and DNS query/response matching to ensure that return packets were only allowed in response to queries that had originated from the inside. It is important to note that stateful firewalls added these features to overcome vulnerabilities in their design – attacks such as TCP RST flood attacks and DNS cache poisoning. Proxy firewalls never had these kinds of vulnerabilities. Stateful firewalls have continued to evolve; often in response to new types of hacking techniques as they have been discovered. Proxy firewalls have evolved, as well, but mostly in response to ever-higher requirements for performance and transparency.

Near-Term History of Intrusion Detection, Intrusion Prevention, and Firewalls

Intrusion detection technologies (IDS) have enjoyed a spectacular rise and fall. Since Dorothy Denning first proposed the concept in 1986, there were relatively few products until 1997, when a number of vendors began offering commercial network monitoring IDS. The IDS market grew rapidly through 2002, when Gartner researchers announced "IDS is the ‘pet rock’ of computer security" and recommended their customers focus instead on the up-and-coming new technology termed "Intrusion Prevention" (IPS). According to Gartner analyst Richard Stiennon, IDS was a failure for two reasons. First off, IDS generated too many "false positives" – alerts in which the IDS mistook legitimate traffic for an attack. Secondly, IDS didn’t actually do anything but generate an alert when the attack was seen. Stiennon rightly pointed out that, if you can correctly detect an attack, it would be nice to prevent it. By the end of 2003, virtually every IDS vendor was re-branding their product as an IPS, by adding in-line blocking modes to their sensors. Initially, virtually no customers used the in-line blocking modes of their IPS, because they were afraid of traffic interruptions.

Some of the first IPS on the market were not effective security devices: they used simple signature-matching techniques and "knew" how to recognize and block only a few dozen worms and popular attacks. They did not sell particularly well until the massive worm outbreaks of 2004: corporations were desperate to contain worms in their networks, and worms are sufficiently easy to recognize that the IPS did a decent job blocking worm traffic on the network. IPS began to sell. The feature-similarity between IPS, IDS, and firewalls as well as single-purpose spam and anti-virus gateways, has triggered a move to consolidate these technologies into a single platform. A number of vendors have embarked on a course of technology acquisition, with the intent of embedding IPS/IDS/Firewall/AV/VPN termination capabilities into switching platforms. These combined systems offer an attractive feature-set, high performance, and a good price point when compared to having to integrate a series of separate products. The strengths and weaknesses of such systems will depend on the quality of the underlying detection and firewall engines and its IDS knowledge-base.

Enter "Deep Inspection"

According to David Flynn, NetScreen’s Vice President of Marketing, a survey of 1000 network managers indicated their biggest security concern was "depth of protection" against worms, trojans, email viruses, and exploits against software vulnerabilities. Flynn is quoted as noting that these types of attacks "can traverse a traditional stateful firewall even if the firewall is deployed and working as it should be." Both NetScreen and CheckPoint have bolstered their stateful firewalls by adding application-oriented checking logic into their processing modules – essentially merging IDS signatures into the firewall traffic-processing engines of their products. What is "Deep Inspection"(DI) anyhow? According to NetScreen, DI firewalls "use an Attack Object Database to store protocol anomalies and attack patterns (sometimes referred to as signatures), grouping them by protocol and security level (severity)" Packet processing is typically described as "performing application level checks as well as stateful inspection." In other words, a "Deep Inspection" is just a catchy marketing term for a stateful packet inspection firewall with some IDS signatures and some application protocol anomaly detection rules. It is important to understand that a "Deep Inspection" firewall is going to provide all of the protections of a stateful firewall, as well as whatever signatures are loaded into it.

In the case of a NetScreen (circa 2003) the firewall "is designed to provide application layer protection for the most prevalent internet-facing protocols, such as HTTP, SMTP, IMAP, POP, FTP, and DNS." It is ironic to remember that one of the early complaints about proxy firewalls was that they only supported a small set of application protocols – what good is a DI firewall that only does DI on 6 of the "most prevalent" internet-facing protocols? That may be "deep" inspection but it’s certainly not very broad. When the NetScreen product was initially released, it included signatures to detect "over 250 application attacks." As far as an IDS signature set, this does not compare favorably to an IDS such as the open-source Snort, which at that time had signatures to detect over 3,000 attacks. Much like the early versions of the Snort IDS, NetScreen’s DI engine uses regular expression pattern matching to specify its signatures – a technique that most serious IDS product designers stopped using years ago because it is too simplistic to represent complex network/application states effectively. Regular expressions, however, are easily processed in silicon, using off-the-shelf regex engines that provide hardware speedups for matching, so it makes sense for a switch-based DI firewall to rely upon them.

Designers of DI firewalls will probably not be able to provide sophisticated IDS engines in their products because of the performance overhead necessary to execute complex signature analysis and state tracking. The history of the IDS market shows that IDS has always been a performance-sensitive proposition – which is why most line speed IDS appliances are using multiprocessor main boards to keep up with the load. The author suspects that, unlike IDS, the DI firewalls will only be looking for a small subset of the attacks that are known at any given time, due to performance concerns. Even the "only look for a few attacks" strategy will eventually fail; Gartner reported that last year that 70 new vulnerabilities were identified per week, or over 3,500 per year. If even 10% of those are vulnerabilities that replicate across network data, the firewalls are going to very quickly have to handle very large signature-sets. Hardware acceleration will help somewhat, but typical hardware implementations in the fast-path of a switch are going to have built-in limitations on how many signatures they can effectively load at one time. DI firewalls will eventually have to deal with all of the complexity issues that caused Gartner to declare commercial IDS a "dead end."

Protocol Anomaly Detection Meets The Proxy

Protocol anomaly detection is an IDS technique in which rules are written that track the states of an application protocol and look for deviations from a proper state. A simple example of a protocol anomaly detection rule for FTP might be "if the user name given during the login process is longer than 45 characters, alert that as suspicious." It is possible to very tightly track the process of a protocol, at a cost of increased computing and memory use. For example, the NFR IDS protocol anomaly detector for SMTP tracked the entire SMTP command series from start to finish and would generate alerts if the client issued a "MSG From:" command before a "RCPT To:" command, or issued a "HELP" command, etc. Such tight protocol tracking is extremely powerful, because normal applications always send a message using the exact same sequence of steps but human hackers sometimes get the order wrong or attempt to trigger errors by issuing commands deliberately out of sequence. Protocol anomaly detection is a very powerful technique that is used to great effect in all commercial IDS and most DI firewalls. For detection accuracy, protocol anomaly detection pales in comparison to the processing that is performed during the normal functioning of a proxy firewall. This is because the proxy, as part of its normal operation executes the protocol. Instead of having to follow along and try to figure out what the application protocol is doing, the proxy is the application protocol: protocol anomalies represent error conditions that the proxy detects. When the author implemented the first proxy firewall, the FTP proxy logged and error and shut down if, at any time, it received commands that were out of sequence or were incorrectly formatted.

Another topic of debate in the IDS and DI firewall community is the question of "detecting the exploit" or "detecting the vulnerability." When "detecting the exploit" the signature-writer develops a signature that will identify the particular attack tool. For example, the TESO mass-rooter for FTP daemons uses a specific set of buffer overruns against a variety of FTP servers. Coding to detect TESO, the signature-writer would write a minimal signature to identify the first steps of a TESO probe and generate an alert. To "detect the vulnerability" the signature writer would research the entire set of vulnerabilities that particular FTP servers might have, and then would develop a signature set that detected any one of them being exploited. Detecting the vulnerability takes considerably more research since it involves a larger number of signatures to develop. For the proxy firewall developer, this is a complete non-issue. If a new vulnerability is identified in an application, the proxy-writer assesses whether the attack vector is "legal" in the protocol, and, if it is not, the proxy wouldn’t have let it through in the first place. In the case where the attack vector is encompassed in the protocol, the proxy can be updated with a protocol-specific signature at the exact point of the protocol processing where it’s appropriate. In the long run, this approach is much more efficient and takes less work – both in terms of effort to keep the security knowledge-base up to date, but also in terms of processing speed. The proxy only needs to execute protocol-specific checks at the exact part of the protocol where they are needed, whereas a regular-expression based signature engine must compare each expression against each input as it arrives.

Some Philosophy About Security Design

Fundamentally, the tension between proxy firewalls and stateful filter + signature firewalls is a reflection of the deepest philosophic division that in security. It is a division that goes back to what we used to call "stance" back in the early days of firewalls:

• That which is not expressly prohibited is permitted (default permit)
• That which is not expressly permitted is prohibited (default deny)

The default deny stance is the default policy that virtually every credible firewall product executes unless told otherwise. In security, however, there are many places where we do not follow the rule of default deny. For example, antivirus products implement a "default permit" – "if you don’t know it’s a virus, then it’s OK to run it." IPS implement default permit – "if it doesn’t look like an attack, permit it." Fundamentally, default permit is not good security. A proxy firewall implements default deny. Unless the application that is talking to the proxy complies exactly with the protocol as executed by the proxy, the traffic is not going to go through. It’s not perfect, of course, since there might be an attack that is valid within the protocol, but is still damaging. That is why most proxies also add additional application specific signatures.

For example, the TIS Firewall Toolkit’s HTTP proxy not only mediated the entire HTTP transaction it performed URL sanitization and did not permit unusual characters in URLs. Several of the authors’ friends who still use components of the firewall toolkit were highly amused when a piece of software that was coded in 1992 successfully defeated worms in 2002 – 10 years before the worms had been written. Similarly, the DEC SEAL’s FTP proxy from 1990 defeated FTP bounce scans when the hacker community discovered them in 1995. Peter Tippett, the author of Norton Antivirus and founder of ICSA/TruSecure once famously commented "The current philosophy of antivirus is to know the 50,000 bad things that can happen to you. It’s much more sensible to enumerate the 50 things that you want to allow to happen, but the industry just isn’t ready to think that way, yet." Perhaps that is true in the antivirus arena, but the proxy firewall’s approach has always been:

• Nothing gets through unless it looks right

Rather than:

• Everything gets through as long as it doesn’t look bad

Security products that adopt the default permit philosophy will always be fundamentally at risk from new attacks. A signature-based DI firewall can only block attacks that are known by its signature set. When a new worm breaks out that takes advantage of a never-before-seen attack, the signature-based DI firewall will let it through. Once the signature set is updated, the firewall will be able to block the attack, however, the time between the release of the attack and the development of the signature might be a matter of hours or even days. While that window of vulnerability is open, the customer will have no alternative but to either patch host software or disable that service.

Historical Performance of Security Solutions

The history of computer security shows that many customers do not want to take the time to fully understand what they are buying. In the mid 1990’s the author was selling proxy firewall products that had a superlative history of resisting attack; yet the market leading products were simplistic "stateful" packet filters that were sold based on the fact that they were faster, cheaper, and more forgiving. Put differently: they didn’t perform as rigorous checks, so they could be fast. They were easier to code, so they were cheaper. They were more forgiving, because they were more permissive. There is ample anecdotal evidence that default deny security survives better in the long term than default permit. There is ample anecdotal evidence that default deny security is less susceptible to nasty surprises, and requires less patching. Systems that are based on the model "recognize a vulnerability and block it" inherently require "upgrade to fix the vulnerability of the week."

Customers need to understand their objectives and requirements, so they can best select technology that facilitates their mission. There are situations and circumstances where less-rigorous security systems can get the job done safely. The author believes, however, that few vendors take the time to explain the design tradeoffs inherent in their products to their prospective customers. With security being such a hot topic, it’s hard for a customer to make sense of a plethora of products, all of which are asserted to be "secure." Analogies are dangerous, but choosing a security product is similar in many ways to buying a car: the customer needs to have a good idea of what kind of on-road properties are needed. Does it need to be economical and corner well, or does it need to be able to tow a 6 horse trailer safely? Or, perhaps it needs treads and 3" thick armor. What is frustrating to the author is that in the computer security space, there are some vendors asserting that what they offer is a general-purpose high fuel-efficiency sports-car main battle tank. Can you believe that?

mjr.
The speaker break room, Interop (Mandalay Bay Hotel) and McCarran Airport Gate 33, Las Vegas, May 6, 2005

Appendix 1: Summary Matrixes

Summary observations: ASIC-based solutions are appealing to the customer for whom raw speed is a paramount consideration. Generally, where there is a choice between "doing things fast" and "doing things securely" the design decision of ASIC-based products is to "do things fast." This, necessarily, affects the system’s quality from a security standpoint. The author’s experience is that custom hardware-based security products tend to look more like "a switch with a bit of security bolted on" rather than "a security product that is really fast."

  Summary observations: Proxy firewall technologies have proven time and again to be more secure than "stateful" firewalls and will prove to be more secure than "deep inspection" firewalls. The main comparison point between stateful firewalls and proxy firewalls has typically been on performance, which is an orthogonal property to security. High-performance proxy firewalls are available, and some are capable of easily handling gigabit-level traffic. Customers need to be realistic about whether performance is really an issue in the expected deployment, and should be prepared to do operational testing. The author has seen many customers cheerfully settle for inferior security because of "performance concerns" that did not actually apply.

　　SSL VPN是一种新型VPN（虚拟专用网络），它在支持应用类型、认证集成以及其他一些安全功能方面都表现出独有的特点。

　　SSL VPN技术帮助用户通过标准的Web浏览器就可以安全访问重要的企业应用。这使得企业员工出差时不必再携带自己的笔记本电脑，仅仅通过一台接入了Internet的计算机就能访问企业资源，这为企业提高了效率也带来了方便。由于SSL VPN不像IPSec VPN那样要购买和维护远程客户端或软件，因而要比后者造价低很多。SSL VPN网关位于企业网的边缘，介于企业服务器与远程用户之间，控制二者的通信。

SSL VPN主要优点有哪些？

　　无需安装客户端软件：在大多数执行基于SSL协议的远程访问是不需要在远程客户端设备上安装软件。只需通过标准的Web浏览器连接Internet，即可以通过网页访问到企业总部的网络资源。这样无论是从软件协议购买成本上，还是从维护、管理成本上都可以节省一大笔资金，特别是对于大、中型企业和网络服务提供商。

　　适用大多数设备：基于Web访问的开放体系可以在运行标准的浏览器下访问任何设备，包括非传统设备，如可以上网的电话和PDA通讯产品，这些产品目前正在逐渐普及。

　　适用于大多数操作系统：可以运行标准的浏览器的大多数操作系统都可以用来进行基于Web的远程访问，不管操作系统是Windows、Unix还是Linux。可以对企业内部网站和Web站点进行全面的访问。用户可以非常容易地得到基于企业内部网站的资源，并进行应用。

　　支持网络驱动器访问：用户通过SSL VPN通信可以访问在网络驱动器上的资源。

　　良好的安全性：用户通过基于SSL的Web访问并不是网络的真实节点，就像IPSec安全协议一样，而且还可代理访问公司内部资源。因此，这种方法可以非常安全，特别是对于外部用户的访问。

　　减少费用：为那些简单远程访问用户（仅需进入公司内部网站或者进行E-mail通信），SSL VPN可以非常经济地提供远程访问服务。

　　可以绕过防火墙和代理服务器进行访问：基于SSL的远程访问方案中，使用NAT（网络地址转换）服务的远程用户或者Internet代理服务的用户可以从中受益，因为这种方案可以绕过防火墙和代理服务器进行访问公司资源，这是采用基于IPSec安全协议的远程访问所很难或者根本做不到的。

设备性能如何？

　　网络加密后会在一定程度上降低系统运行速度。这主要是因为SSL加解密过程中会涉及用户会话和握手两个过程，需要经过往返三次验证。通常情况下，由于CPU要忙于应付SSL加解密操作，因而占用了它比较多的资源，由此会影响处理其他操作的运行速度。

　　为了提高系统性能，有些设备采用了硬件加密技术，还有些设备使用专门的SSL硬件加速芯片，它是用来专门处理SSL加解密运算的，正是由于它的介入，将CPU解放了出来，使网络加速对系统运行速度的影响降至最低。

　　考察SSL VPN设备性能主要包括会话速率、转发速率及同时在线用户数等几项。会话速率指其每秒钟可以建立和终止的SSL会话数目（会话可以理解为客户端到网关的一次连接，即浏览器的一次Web 页面访问）。由于SSL 会话和HTTP 协议是基于连接的，因此这个参数很大程度上决定了用户能够体验到的连接速度。通常，达到100 左右数值的会话速率，一般可以满足大部分用户的应用需求。转发速率指SSL VPN网关到底有多快，它最快可以在每秒钟内转发多少数据流量。显然，在会话数不同的时候，转发速率也是不同的，这里指的是在不同会话数时最快的转发速率。用户应根据自己的实际需要加以选择。同时在线用户数也是一个非常重要的参数，即同一时间 SSL VPN 所能保持的会话数目，它通常在几百到几千之间，同时在线用户越多，每位用户所感受到的速度越慢。同时在线用户数指同时通过SSL VPN 来访问内部网的用户数目。

支持哪些应用类型？

　　SSL VPN网关至少要实现一种功能：代理Web页面。它将来自远端浏览器的页面请求（采用HTTPS协议）转发给Web服务器，然后将服务器的响应回传给终端用户。

　　对于非Web页面的文件访问，往往要借助于应用转换。SSL VPN网关与企业网内部的微软CIFS或FTP服务器通信，将这些服务器对客户端的响应转化为HTTPS协议和HTML格式发往客户端，终端用户感觉这些服务器就是一些基于Web的应用。

　　在进行代理和应用转换时，有的产品所能支持的应用转换器和代理的数量非常少。有的则很好地支持了FTP、网络文件系统和微软文件服务器的应用转换。用户在选择网关时，必须对自己所需要转换的应用有一个很明确的了解，并能够根据它们的重要性给它们排个先后顺序。

　　而有一些应用，如微软Outlook或MSN，它们的外观会在转化为基于Web界面的过程中丢失，此时要用到端口转发技术。端口转发用于端口定义明确的应用。它需要在终端系统上运行一个非常小的Java或ActiveX程序作为端口转发器，监听某个端口上的连接。当数据包进入这个端口时，它们通过SSL连接中的隧道被传送到SSL VPN网关，SSL VPN网关解开封装的数据包，将它们转发给目的应用服务器。使用端口转发器，需要终端用户指向他希望运行的本地应用程序，而不必指向真正的应用服务器。

　　一些SSL VPN网关还可以帮助企业实现网络扩展。它将终端用户系统连接到企业网上，并根据网络层信息（如目的IP地址和端口号）进行接入控制。虽然牺牲了高级别的安全性，却也换来了复杂拓扑结构下网络管理简单的好处。

互操作性怎样？

　　SSL VPN是否像厂商所声称的那样比IPSec VPN更易于建立和使用。SSL VPN所倡导的是安全和易用，因此在评估时既要考虑终端用户是否便于使用，也要关注一般水平的网络或系统安全管理员的工作难度。SSL VPN的互操作性指的不是不同品牌设备之间的互操作，而是设备与操作系统平台、浏览器平台等的互操作。由于用户的应用系统可能会非常复杂，因此SSL VPN设备应该支持多种操作系统与浏览器的组合，并尽量减少在这些平台上应用的错误。从用户的实际使用经验看，不同设备在不同平台上都表现出了一定程度上的差异。

有哪些访问控制？

　　作为安全设备，所有产品都能够启动或禁止使用组对应用进行访问控制。有的产品允许网管把Web应用定义为一系列的URL。一旦定义了应用，用户和组就允许或禁止访问该应用。有的产品可以提供细粒度的控制，不仅做到“允许”或“禁止”，还包括你所能访问的是什么资源，以及你能对这些资源做些什么。

　　有些SSL VPN网关在访问控制方面的表现不令人满意，比如控制对文件服务器的访问，它们一旦允许用户共享Windows网络，就不会再对用户可以去的地方以及可以做的事情做进一步的控制。与此成对照的是，有的产品则允许用户把读和写权限定义在单个文件的水平上。个别产品还提供了一个病毒扫描程序，可以在用户上载时扫描文件，看其是否染毒。

支持哪些认证集成方式？

　　识别用户并把它们归到某个组里是部署SSL VPN至关重要的一部分。

　　RADIUS服务器应用非常普遍。有的产品可以极为灵活地从RADIUS服务器里获得组信息。在其他产品里，RADIUS用户不得不通过一些手段镜像到组里去。

　　对于多数厂商而言，LDAP的支持与Active Directory的支持是同义的。有一些产品提供极为通用的LDAP实现，从而可以在各种各样的环境中运行。

　　因为SSL通常都是建立在证书基础之上的，因此，大家希望这些产品在其对公共密钥基础设施（PKI）的支持方面能够表现优异。从市场上看，只有很少一部分产品支持用证书进行认证。

　　有的产品却使用客户端证书来进行额外的认证，在SSL VPN网关的配置里定义访问控制时，管理员可以区分拥有证书和没有证书的用户的不同。

生成怎样的报告与日志？

　　作为安全设备，人们还希望SSL网关具有很强大的审计、日志和报告功能。希望看到有关每次修改配置的记录，希望看到会话数据，以显示用户何时登录、何时退出的，以及用户消耗了多少资源。也希望看到交易统计数据。

　　有的产品除了拥有需要的所有记录之外，还可以使用FTP、SMTP或者安全拷贝自动地把其记录上传至服务器的某个地方。还可以选择某些特殊的用户和应用，并提供日志水平。不论用户是出于调试目的，还仅仅是为了更密切地观察系统的某个部分，这都是一项很好的企业级性能。有的产品不仅能显示谁登录了，还能显示系统本身是如何运行的。可以显示多个图表，网管能够清楚地知道CPU、内存和I/O负载情况。

具有哪些其他安全功能？

　　由于SSL VPN为一种重要的安全设备，因此，许多厂商的设备还提供了许多其他的安全功能，为了能够获得更高的安全性，在这方面可以说“怎么做都不为过”。

　　有产品提供了一个独特功能，就是管理员可以按照公司的策略要求远程接入的系统必须安装或配置必要的安全软件，以保证远程访问在认可的安全级别下进行。拒绝不符合安全要求的终端的远程接入请求。 

　　客户端扫描对用户来说也是一个不错的功能。由于使用SSL VPN以后，用户可以使用任何设备访问内部资源，甚至可以使用网吧的电脑访问内部系统。如果远程访问的系统有病毒或安全漏洞，将危害企业内部的信息安全。客户端扫描功能可以大大降低病毒和黑客工具对企业信息的危害。

　　客户端缓冲区及临时文件清除功能就是在SSL VPN的远程访问结束后，自动清除留在远程访问设备缓冲区中的临时文件和数据。缓冲区功能不仅非常必要，而且，不支持这项功能的SSL VPN产品会对企业信息造成严重危害。IE浏览器为了提高速度，常常将访问的文件和数据放在临时文件中，并且在退出后不会自动删除。这样，有经验的客户可以通过浏览器提供的检查临时文件的功能，打开残留在临时文件目录中的文档，从而窃取企业机密。 为了简化用户重复登录时，反复输入密码的麻烦，浏览器有的时候会在缓冲区中记录用户口令信息，这样，在不关闭浏览器的时候，二次访问需要口令的网址的时候，浏览器会自动输入口令。因为SSL VPN的远程用户可能使用公共设备，如果不清除缓冲区，如果忘记关闭浏览器而离开，后面的用户可以登录到内部系统。所以，必须在会话结束后清除缓冲区。 是否支持这些清除功能是识别SSL VPN的重要标准。

　　有些设备还提供了URL隐藏功能。当使用统一入口方式的时候，用户选取某个应用服务器以后，SSL VPN会自动将访问指向该服务器，但是，在IE浏览器的URL框中，地址确是一串不能读懂的乱码，如：https://mycompany.com/%^()*)%^$FRUY。这种方式的好处是远程用户不能使用Ping命令找到该服务器的网址，因此可以避免对该服务器的网络攻击。

　　SSL VPN功能列表