metatron - check point software · 2 title styled after ken thompson’s acm turing award lecture,...

Security ServicesSecurity ServicesMetatronMetatron

Security ServicesSecurity ServicesMetatronMetatron

White Paper

Common Criteria Certification for Perimeter Security Products

Prepared for:

Last Edit Date: January 2007

Revision: 1.2 (draft)

This document contains proprietary information of Metatron Ltd., its customers or its partners and shall not be reproduced or transferred to other documents, disclosed to others or used for any purpose other than that for which it is furnished, without the prior written consent of the author.

All marks, trademarks, and logos mentioned in this material are the property of their respective owners.

Common Criteria Certification for Perimeter Security Products January 2007 Table of Contents

Table of Contents

Abstract ........................................................................................................................................... 3 Your Challenge ............................................................................................................................... 4

Information Flow Control............................................................................................................ 4 Integration into the Overall Security Solution............................................................................. 5 Trusting Trust .............................................................................................................................. 7

The Common Criteria ..................................................................................................................... 9 Introduction ................................................................................................................................. 9 The Art of Reading Security Targets......................................................................................... 10 Robustness ................................................................................................................................. 16 Common Criteria Recognition Arrangement ............................................................................ 18

Comparison of Evaluated Products............................................................................................... 20 Firewall/VPN Products.............................................................................................................. 20 IDS/IPS Products....................................................................................................................... 27

Additional Reading ....................................................................................................................... 32 Web Sites................................................................................................................................... 32 General Guidelines and Documentation.................................................................................... 32 Protection Profiles ..................................................................................................................... 32 Security Targets (on [NIAP VPL])............................................................................................ 33

Table 1 - Firewall/VPN Product Comparison............................................................................... 23 Table 2 - IDS/IPS Product Comparison........................................................................................ 30

© Metatron Ltd., 2006 - 2 - All Rights Reserved.

Common Criteria Certification for Perimeter Security Products January 2007 Abstract

Abstract

Perimeter security solutions are widely used by organizations to protect their internal networks from attack from without, as well as to control network traffic within the organization. These are products that may include firewalls, virtual private network (VPN) gateways, intrusion detection and prevention systems (IDS/IPS), anti-virus gateways, etc.

Customers today face a plethora of commercial products that vie for their attention. Performance, connectivity and security functionality are often key differentiators that are touted by product vendors.

Too often, customers install security solutions that do absolutely nothing for security.

It is often difficult for customers to determine whether any given solution will live up to vendor claims. This is especially true for security functionality; whereas performance and connectivity are relatively easily tested against normal organizational traffic, security functionality that restricts network traffic must by definition be judged by its capacity to correctly process abnormal traffic, maliciously crafted by an attacker in an attempt to bypass or deactivate security mechanisms. Too often, customers install security solutions that do absolutely nothing for security. As long as it doesn’t “get in the way”, the customer has little chance of finding fault in such a solution.

A Common Criteria evaluation provides assurance that security requirements would be met by the product as installed by the customer.

The Common Criteria (CC) are a set of internationally recognized criteria for third-party evaluation of security products, performed by accredited CC labs. An evaluation measures a product against a set of vendor-defined security requirements, and provides a level of assurance1that these security requirements would be met by the product as installed by the customer.

This paper’s objective is to provide guidance that might assist customers in using CC evaluation results for assessing the worth of commercial perimeter security products. In Your Challenge, the paper explains in more detail what these products do and why third-party evaluation is important. The Common Criteria is introduced in the following chapter, providing tips for what you should look for in evaluated products. Finally, a Comparison of Evaluated Products tabulates characteristics of products on the U.S. validated products list.

For more information, contact [email protected], or U.S. Federal Sales at [email protected].

1 Assurance: defined as “grounds for confidence”.


mailto:[email protected]

mailto:[email protected]

Common Criteria Certification for Perimeter Security Products January 2007 Your Challenge

Your Challenge

Information Flow Control

Perimeter security solutions are used to control information flow, enforcing an organizational network security policy.

Perimeter security solutions are used to control information flow at the boundary of the organization, or between different parts of a compartmented organizational network. A network security policy is enforced, so that:

• Authorized information is allowed to flow to its destination;

• Unauthorized traffic is blocked; and

• Unauthorized or suspicious information flows can be configured to trigger alarms or generate log records in an audit trail.

In addition, solutions may be required to provide capabilities such as:

• Authenticating the source or destination of information flows;

• Supporting non-repudiation of origin or of receipt;

• Providing cryptographic protection for information flows, e.g. Virtual Private Networks (VPN); or

• Translating or mapping information flows, e.g. for Network Address Translation (NAT).

Traffic that is required to support the organization should be authorized; other traffic should be considered unauthorized.

How do you create a network security policy?

In general, network traffic that is required to support the organization should be authorized; other traffic should be considered unauthorized.

The definition of authorized traffic is most often expressed in terms of source and destination addresses, user or host authentication, requested services and network protocols.

Attackers misuse protocols to gain control of their targets.

Network protocols dictate what communications are required to support a given type of information flow. For example, the File Transfer Protocol (FTP) distinguishes between control communication that is used to negotiate which files will be transferred, transfer methods, etc., and data communication that transfers the actual file contents between FTP client and server.

Attackers misuse protocols to gain control of their targets. Software applications are coded to expect certain behavior; too often, they fail miserably and catastrophically when presented with input that subtly or grossly differs from normal protocol behavior. Buffer overflows are a well-known example of this class of attack.



Some products provide only rudimentary support for defining what traffic is authorized; ideally, any traffic that does not strictly comply with network protocols as they are used by the organization should be blocked. Action should also be taken when identifying traffic that is “suspicious”, i.e. is either out of the ordinary, or matches known attack signatures.

A perimeter security product’s information flow control capabilities may be differentiated by:

• The granularity and number of protocols for which information flow control is being applied. For example, while some perimeter security products may examine only network-level protocols, others may parse and validate the application-level protocols, and even the data itself (which might contain active content such as viruses);

• Mechanisms available for identifying, blocking, and reporting suspicious traffic;

• Additional information flow control capabilities such as VPN; and

• Expressiveness and ease-of-use of the management interface.

Integration into the Overall Security Solution

The security solution that is put in place in order to enforce the organizational network security policy might be composed of many components, deployed across the organization. For example, a VPN implementation would include at least one VPN gateway at each physical site; or the solution might be integrated from multiple product types, e.g. firewalls, VPN gateways, IDS/IPS systems, etc.

In general, the problem of how to compose two or

more secure components into a secure system is hard

Ross J. Anderson / Security Engineering – A Guide to Building Dependable Distributed Systems

It is at the boundary between components that security vulnerabilities tend to appear. This can be caused by mismatching assumptions or design considerations made by different developers, by the sheer complexity involved in coordinating multiple administration interfaces and in installing an integrated security policy across the organization.



A unified, centralized administration interface should allow the administrator to define and maintain a coherent security policy that is then automatically distributed to all components.

A well-integrated security solution should have the following characteristics:

• Security requirements should be derived from a unified system-level security policy.

• Where different components are put together, care must be taken not to introduce a weak link component that can be subverted and used as a stepping stone into the network. All components that process external input should provide self-protection capabilities that are appropriate to the external threat.

• Security capabilities should be mutually supportive. For example, firewall functionality can protect VPN and IDS components; VPN-established authentication should be available to firewall and IDS components for incorporation into the enforced security policy; IDS components should be capable of analyzing, detecting, and blocking attacks against the other security components.

• Components should provide standards-based interfaces to support correct inter-component integration.

• A unified, centralized administration interface should allow the administrator to define and maintain a coherent security policy that is then automatically distributed to all components.

• Audit trails and alarms from all components should be collected, correlated and presented to the administrator coherently, in order to provide an integrated picture of security-relevant events.



Trusting Trust2

In computer security circles, the term trusted is used to denote the parts of a system that must be relied upon to enforce the security policy. This is in distinct contrast to a companion term, trustworthy:

trust·wor·thy (trust΄wûr΄thē), adj.

deserving of trust or confidence; dependable; reliable

Webster’s Encyclopedic Unabridged Dictionary of the English Language, copyright © 1989 by dilithium Press, Ltd.

Is your trusted firewall trustworthy? Is your VPN gateway? Will your perimeter security solution, as configured and maintained in your operational environment, correctly enforce the network security policy, withstanding any attackers who target your organization? Is your trusted

firewall trustworthy? Is your VPN gateway? The perimeter security solution is trusted in the sense that it is relied

upon to enforce the network security policy. If it fails to do so dependably and reliably (i.e. it is not trustworthy), the network security policy might be violated, and the internal network come under attack.

Such failure to perform may result from many factors3:

• The product doesn’t do what the vendor claims it does, because:

o It was never intended to by the vendor

o Its design was insufficiently rigorous to ensure all requirements were met

o It was incorrectly implemented; or

• Installation and configuration is unreasonably complex; or

• The product was maliciously or inadvertently modified in its development environment or during delivery to the customer.

Security components are themselves often targeted - they are the gateway into the organization. A subverted perimeter security product is a valuable foothold for an attacker because it has visibility both into the organization, as well as being externally accessible.

2 Title styled after Ken Thompson’s ACM Turing Award lecture, Reflections on Trusting Trust. 3 Of course, a failure to perform on behalf of the perimeter security solution might always be caused by unrealistic customer expectations, an inconsistent or irrelevant network security policy, etc. – these results can be achieved with any perimeter security product and are not considered further in this paper.



A subverted perimeter security product is a valuable foothold for an attacker because it has visibility both into the organization, as well as being externally accessible.

For example, an attacker might transmit network traffic maliciously crafted to cause a buffer overflow in a perimeter IDS/IPS product that is analyzing all cross-perimeter traffic. Once that product is subverted, it itself might become a stepping stone into the internal network.

It therefore is important that the perimeter security product be able to protect both itself and its security functionality against attacks that may be directed at the organizational network.

The concept underlying the perimeter paradigm is that there is a clear border between an internal network that must be protected, and an external environment that includes threat agents. Bill Cheswick has described this as “a sort of crunchy shell around a soft, chewy center.” Cost, performance,

bells and whistles must take second place to assurance that the organizational network security policy will be reliably enforced.

Unfortunately, just as in 1990 when this phrase was coined, internal networks are still very vulnerable, so that borders must still be drawn to keep attackers away from these networks.

Organizations must be confident that their perimeter security solution is trustworthy. It must perform reliably even in the face of attackers that attempt to bypass or to tamper with its security mechanisms. Cost, performance, bells and whistles must take second place to assurance that the organizational network security policy will be reliably enforced.

Customers need a trusted third-party evaluation process for security products that provide grounds for confidence that a product would meet its security objectives.

Very few organizations have the capability of determining this through their own efforts. One way to determine whether a given perimeter security product is trustworthy is to ask the product vendor. This method is not always effective.

What customers really need is a trusted third-party evaluation process for security products that provides grounds for confidence that a product would meet its security objectives. Such a process would determine on behalf of the customer that the failure factors described above do not apply to the product in question.


http://www.cheswick.com/ches/bio.html

Common Criteria Certification for Perimeter Security Products January 2007 The Common Criteria

The Common Criteria

Introduction

Luckily, there is a solution. The third-party security certification market is finally converging around a set of common criteria. Named “The Common Criteria for IT Security Evaluation”, these criteria have been adopted by twenty four nations to date, and have been accepted by the International Standards Organization (ISO) as ISO Standard 15408.

The Common Criteria (CC) provide a common language for the expression of security requirements, and the associated Common Evaluation Methodology (CEM) provides the evaluation methodology for the application of the CC.

This works as follows:

• The evaluation sponsor (usually the product vendor) writes a Security Target (ST) that describes the product and the constraints under which it is to be evaluated, states the security requirements that will be evaluated, and lists the assurance measures that will be employed as part of the evaluation.

• The sponsor contracts with an accredited evaluation facility to perform the evaluation. These facilities or labs operate under national Schemes in countries authorized by the international CC community to produce CC certificates. In the United States, this is the National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme (NIAP CCEVS).

• The ST is evaluated for coherence, internal consistency, and compliance with the CC. This determines that the vendor claims and expectations are stated in a clear, coherent, and common language that can allow the customer to perform an educated comparison between products.

• The lab applies the assurance measures listed in the ST to determine that the product itself and the product vendor’s processes meet the stated requirements.

• The sponsor receives a CC certificate from the Scheme. A Validation Report (VR) is produced describing the evaluation.

The CC certificate and the results of the evaluation are recognized by all countries that are participants in the Common Criteria Recognition Arrangement (CCRA).


http://niap.bahialabs.com/cc-scheme/defining-ccevs.cfm

http://niap.bahialabs.com/cc-scheme/defining-ccevs.cfm


The Art of Reading Security Targets

Too good to be true? There’s a catch. As you might have noticed from the introduction, it is the evaluation sponsor that determines what the evaluation parameters will be. Most vendors being the evaluation sponsor will select requirements that they believe they can meet. It is therefore not surprising that almost all evaluations end up passing.

The educated consumer can analyze the VR and ST to determine what if anything was achieved by the evaluation.

There are defined limits to the tricks that the vendor can play. The VR and ST are made public by the Scheme. The educated consumer can analyze these documents, together with the vendor’s product documentation, to determine what if anything was achieved by the evaluation, what security requirements were proved to have been met by the product, as well as any important caveats or constraints that were associated with this result.

A significant amount of information is sometimes hidden between the lines of the ST.

All STs are not created equal. Some contain more information than others. Different versions of the CC also affect the structure of the ST. You the reader must always keep in mind that the primary goal of the ST is to be a negotiated agreement between the vendor and the Scheme, leading up to the vendor’s product receiving certification. As such, the reader can sometimes find a significant amount of relevant information that is hidden away in various parts of the document.

There are three important pieces of information that must be included in any ST:

• What was evaluated?

• What was it evaluated for?

• How much assurance was gained by the evaluation?

The Target of Evaluation

The Target of Evaluation (TOE) is what was actually evaluated.

The Target of Evaluation (TOE) is what was actually evaluated. This is usually one or more products that are configured according to vendor-defined constraints. The ST defines the physical and logical boundaries of the TOE, and describes in natural language the security properties that were evaluated.

For example, the ST might state:

• The TOE is firewall software xyz15 version 15.2 installed on hardware platforms xyz-01, xyz-02, and xyz-03.

• The TOE is connected to two or more networks, and blocks any unauthorized network traffic between these networks.



• The TOE in its evaluated configuration must be maintained in a powered-down state at all times.

Example constraint on the logical boundaries of the TOE: “The TOE must be maintained in a powered-down state at all times.”

The example statement above constrains the evaluation in several interesting ways:

• The evaluators only looked at one specific software version, and only when running on specific hardware platforms. If the vendor has other versions available, these were not evaluated.

• The evaluators limited their attention to proving that unauthorized traffic through the firewall is blocked. Even if the product is described as doing other things, there’s no guarantee from the evaluators that it really does them.

• If the firewall product allows all traffic through once it is powered up, this is irrelevant to the results of this evaluation, because it is outside the evaluated configuration.

The ST may also make assumptions as to the operational environment. Assumptions are considered axiomatic. For example, if the ST assumes that the product is located in a physically secure area, the evaluators will ignore any vulnerability associated with physical access.

It is very common for the vendor to prepare specialized guidance that is tailored for the purposes of the evaluation.

In addition to the statements made in the ST itself, the TOE boundary may be further constrained by the guidance documentation. It is very common for the vendor to prepare specialized guidance that is tailored for the purposes of the evaluation. The evaluated guidance should be identified in the ST. There is an implicit (or sometimes explicit) assumption that the product is installed and operated according to this guidance. For example, if the guidance states that NTP support should not be enabled, the product is not examined for any possible NTP-related vulnerability.

Why does the vendor constrain the Target of Evaluation in this manner? There are several common reasons:

• CC evaluations are expensive. The vendor saves time and money by excluding parts of the product or some of its functionality from the evaluation.

• The excluded functionality would have violated one or more security claims. For example, suppose that the ST claims that all interfaces are authenticated; any common unauthenticated protocols (e.g. DNS) would have to be disabled in the evaluated configuration in order to meet this requirement. While the requirement may not be relevant to all customer environments, the end result is that these protocols were not evaluated.



• The excluded parts of the product or of its functionality have been found to contain vulnerabilities that could lead to a violation of the security policy. For example, if the evaluators find a buffer overflow exploit, excluding the relevant interface would allow the product to pass evaluation, and would be much easier and faster than actually fixing the bug.

• The excluded parts of the product were not developed by the product vendor (e.g. are open source, or are third-party components), and he has no idea as to their trustworthiness.

Customers must take a risk management approach to dealing with unevaluated parts of the product. Ask yourself: Customers must take a

risk management approach to dealing with unevaluated parts of the product.

• Do I care? A firewall product might come bundled with VPN functionality that was left out of the TOE. If you’re buying it as a firewall, just keep the VPN functionality turned off, and you should be O.K.

• Does it really matter? If some functionality is turned off in the evaluated configuration because it obviously violates some claimed security requirement that you don’t need, you might want to take the risk. For example, if there’s a command line utility that you’re not supposed to use, because it does not conform to stated requirements for authentication and auditing of administrator actions, but you have only one administrator and you trust her, you might let her use it anyway.

• Who will know? Is this something that stands a chance of being externally-visible? Could it conceivably be leveraged by an attacker? For example, suppose there’s a Web interface that’s supposed to be turned off. There’s a good chance that turning it on would leave the product vulnerable, and that this is the reason for its exclusion. However, if you disconnect the device from the network, use the Web interface to reconfigure it, and then turn the interface back off before reconnecting, risk seems to be minimized. Assuming you can turn it off, that is.

If you do decide to exceed the boundaries of the evaluated configuration, all bets are off.

In any case, if you do decide to exceed the boundaries of the evaluated configuration, all bets are off, and the evaluation results do not apply.

This means that if you’re out to buy a certified VPN product, even if you find a product called Super Duper VPN++, it might be a good idea to verify that the ST and guidance don’t include a statement that tells you that you shouldn’t use the product’s VPN functionality.



Security Functional Requirements

The CC provides a language for specifying security requirements, but it doesn’t make the vendor claim any specific requirements.

After setting out what is being evaluated and what the operational environment is assumed to be, the ST lists the set of security objectives and requirements that will be evaluated.

Theoretically, the objectives are designed to be readable by normal people, whereas the requirements say the same thing but in a language that even evaluators can understand. In practice, read the objectives if you like, but what really matter are the requirements, so it’s worth the extra effort.

Generally speaking, requirements come in two flavors: services and capabilities. Services are security functionality that the product provides: information flow control, user authentication and access control services, detecting suspected intrusions, etc. Capabilities are global properties that can be proven to exist: self-protection, auditing of all security-relevant actions, etc.

The CC provides a language for specifying security requirements, but it doesn’t make the vendor claim any specific requirements. Thus you can find evaluations of VPN products that don’t claim to provide VPN functionality, firewall products that don’t claim to be firewalls, etc.

In the xyz15 example given above, the vendor could have stated a set of security objectives as follows: “The TOE shall block unauthorized traffic from flowing through the TOE”, and “The TOE shall serve as a paperweight”; these are claims that can be evaluated to a high level of assurance, but are not necessarily sufficient for firewall customers.

Protection Profiles

By claiming compliance to a protection profile, and having that claim evaluated, the product vendor demonstrates that his product meets a set of minimum requirements defined by the customer.

Luckily for anybody who finds the CC requirements language a hard read, the CC provides a Protection Profile (PP) construct that lets customers publish generic Security Targets for a product type. By claiming compliance to a protection profile, and having that claim evaluated, the product vendor demonstrates that his product meets a set of minimum requirements defined by the customer.

U.S. DoD Instruction 8500.2 states that if an approved U.S. Government PP exists for a particular technology area, then DoD acquisition is restricted to those products that match the PP. By publicly publishing PPs and requiring vendors to evaluate their products against them, the U.S. Government is reducing acquisition complexity. Customers should still keep in mind that PP compliance does not necessarily mean that the product is useful or appropriate for use in any given scenario.



Resistance to Attack

Imagine a firewall application running on an operating system; it’s very nice if the application blocks unauthorized traffic, but if an attacker can hack into and subvert the underlying operating system, the attacker will be able to deactivate or subvert the firewall’s security mechanisms.

As discussed above, the security services provided by the evaluated product must4 be accompanied by self-protection capabilities. The CC specifies requirements for resistance to bypass of and tampering with the security functions. For example, imagine a firewall application running on an operating system; it’s very nice if the application blocks unauthorized traffic, but if an attacker can hack into and subvert the underlying operating system, the attacker will be able to deactivate or subvert the firewall’s security mechanisms.

One of the important measures for self-protection is that of attack potential. The CC defines three levels of attack potential: low, moderate, and high. Attack potential characterizes the expertise, resources and motivation assumed for attackers in the operational environment.

For example, if a ST claims resistance to low attack potential threats, only “obvious” attacks would be considered, i.e. attacks that invoke publicly-known vulnerabilities in the product. If the evaluator finds a buffer overflow vulnerability while reviewing the product’s source code, but cannot demonstrate that this vulnerability is publicly-known, the product would pass evaluation5. On the other hand, a Security Target claiming moderate resistance allows the evaluator to consider scenarios such as an expert attacker with sensitive knowledge of the product (e.g. source code access) working for a considerable period of time to uncover exactly such a flaw. In this case, the vendor could be required to fix the flaw as a condition for certification.

If there’s any risk of determined attack, “moderate” resistance should be required.

In general, we would recommend the following rules of thumb:

• If nobody’s out to get you, e.g. the product is deployed in a closed, trusted environment, “basic” resistance is good enough.

• If there’s any risk that the product would have to withstand determined attack (e.g. it is connected to the Internet), “moderate” resistance should be required.

• “High” resistance is required only where the attacker is capable and willing to expend nation-state resources to bypass security.

4 In point of fact, even though the CC explicitly mandates the inclusion of non-bypassibility (code named RVM) and tarmper-resistance (SEP) requirements in STs, there have been products successfully evaluated without claiming these requirements. The upcoming version 3 of the CC fixes this loophole by mandating that all evaluations consider protection capabilities against interference, logical tampering, and bypass. 5 The buffer overflow would possibly noted as a “residual vulnerability” in the Evaluation Test Report (ETR), which luckily for the vendor is considered proprietary information and is not released to the public.



Evaluation Assurance Level

We have seen that the Security Target (ST) defines the boundary of the Target of Evaluation, and specifies the security requirements that are to be evaluated. The ST also specifies what assurance measures will be used to generate grounds for confidence that the product meets its security requirements.

CC assurance requirements can be categorized as providing either deliverable or process assurances. The former examine the product itself; the latter examine the process of developing and delivering the product to the customer.

Assurance requirements can be further categorized as follows:

• Analysis of vendor-produced evidence (e.g. source code review) showing that security requirements have been met

• Functional testing demonstrating that the implementation is correct in respect to its specification and design

• Misuse and vulnerability analyses that attempt to find out-of-the-box methods for bypassing or tampering with security

As with functional requirements, the CC provides a language for specifying assurance requirements, but does not require any specific measure to be specified. However, the CC does group assurance requirements into hierarchical “packages” that are named Evaluation Assurance Levels (EALs). These range from EAL 1, which provides very little assurance, to EAL 7, which is limited to targets of evaluation with tightly focused security functionality that is amenable to extensive formal (read mathematical) analysis.

Assurance requirements don’t make the product more secure; they are intended to provide more assurance that the product meets its security requirements, whether these are effective or not.

In general, the higher the EAL claimed by the Security Target, the more assurance is gained by the evaluation. EAL 4 is the first level that requires source code to be examined by the evaluators. It is also the highest level that corresponds to commercial development practices, and the highest level that is internationally recognized under the CC Recognition Arrangement.

Assurance requirements don’t make the product more secure; they are intended to provide more assurance that the product meets its security requirements, whether these are effective or not. For example, the xyz15 product given in the example above could probably be evaluated to a high level of assurance; the evaluation would focus on the claim that unauthorized information cannot flow through the firewall in its unpowered state. This would probably provide limited customer value.



All STs identify a base EAL; they may then augment it with higher-level assurance requirements. For example, an EAL 4 augmented with AVA_VLA.3 would correspond to an EAL 4 evaluation for which vulnerability analysis was performed for resistance to “moderate” attack potential.

In order to avoid absurdities such as an EAL 7 evaluation of a product that can withstand only low attack potential attacks, EALs above 4 include assurance requirements for vulnerability analysis at the moderate or high attack potential levels.

Robustness

Any CC evaluation starts off with an evaluation of the Security Target. The evaluator determines that the vendor claims and expectations are stated in a clear and coherent language that can allow the customer to perform an educated comparison between products.

Theoretically, the CC also requires the evaluator to require that the Security Target be internally consistent and provide rationale for why the vendor claims are appropriate and compatible with the description of the product and its environment. In practice, this has been enforced unevenly; the traditional assumption has been that it is the customers’ responsibility to determine whether the ST provides any value and whether its claims are relevant.

The Common Criteria’s flexibility in allowing vendors to define meaningless or irrelevant Security Targets is one of its major weaknesses.

The Common Criteria’s flexibility in allowing vendors to define meaningless or irrelevant Security Targets is one of its major weaknesses. The EAL assurance scale alone is merely confusing if it is not accompanied by a corresponding measurement for the level of security provided by a product. For example, an EAL 6 evaluation (high assurance) of a VPN product that uses 40 bit DES would virtually prove that the product uses weak cryptography; customers might do much better with an EAL 2 evaluated product with 128 bit AES.

Protection profiles can be helpful because they encode a particular customer’s security requirements, and as such can be assumed to be meaningful for that customer and other similar organizations.

Many of the available Protection Profiles have been published by the U.S. Government. The U.S. DoD purchases a significant quantity of Information Assurance (IA) products, and has formally adopted the Common Criteria as an acquisition tool. In order to assist its protection profile authors in putting together meaningful collections of security requirements, the DoD uses the concept of Robustness, defined as a



characterization of the strength of a security function, mechanism, service, or solution, and the assurance that is implemented and functioning correctly.

The DoD defines three levels of robustness: high, medium, and basic.

The DoD defines three levels of robustness: high, medium, and basic. Required mechanisms are defined for each level (e.g. type of cryptographic algorithms), as well as assurance requirements that roughly correspond to the three levels of attack potential resistance described above. A robustness strategy identifies what environments require products evaluated to each of the defined levels of robustness.

In general, the DoD-required level of robustness is directly related to the likelihood of an attempted security policy compromise, a function of the value of what is being protected, and the level of exposure to unauthorized entities.

In particular, DoD Instruction 8500.2 mandates high-robustness products for protecting (encrypting) classified information traveling over lower-classified networks, and medium robustness products to protect sensitive information when it transits public networks or when the system is externally visible; inside the protected boundary, products used for access control, data separation or privacy must only satisfy the requirements for basic robustness.



The concept of robustness can be fruitfully applied to commercial as well as to defense environments. Perimeter security products that are exposed to external (unauthorized) access, e.g. firewalls and VPN gateways, should be selected from products that provide a higher-than-low resistance to attack and level of assurance. Less stringent standards can be applied to products that installed inside the protected enclave.

For example, an application-level firewall might validate that traffic conforms to published protocol specifications; if that traffic is then fed through an IDS product, the IDS product is effectively protected by the firewall from network and protocol-level attacks, and therefore requires evaluation to a lower level of assurance.

Because robustness is defined as a function not only of the level of assurance but also of its security functionality, a product can claim a level of robustness only if it has been evaluated to comply with a U.S. Government PP for the given level. To date, U.S. Government perimeter security-related PPs that have been used for product evaluations include PPs for the product types: firewalls (basic and medium robustness) and Intrusion Detection Systems (basic).

Common Criteria Recognition Arrangement

The CCRA extends only up to EAL 4. Evaluation of moderate attack resistance is not recognized across national borders.

The Arrangement on the Recognition of Common Criteria Certificates in the Field of IT Security (CCRA) has been signed by the national governments of a couple of dozen countries, to date. The arrangement Participants agree to mutually recognize Common Criteria certificates issued by certification bodies in other countries, with the goal of eliminating the burden for product vendors of duplicating evaluations in multiple countries.

Only about half of the signatory countries are recognized as Certificate Authorising Participants; the rest are considered Certificate Consuming Participants, which cannot issue mutually recognized certificates. Another constraint to mutual recognition is that Participants may decline to recognize a certificate for applications that involve protection of classified information.

However, by far the greatest limitation to the CCRA is that it extends only up to EAL 46. Because EAL 4 includes only evaluation relative to low attack resistance (AVA_VLA.2), an AVA_VLA.3 moderate attack resistance evaluation is not recognized across national borders.

6 Mutual recognition has been extended between some European nations up to EAL 7, by an extension to CC certificates of the 1998 SOGIS agreement on the mutual recognition of certificates based on the ITSEC criteria.


http://www.commoncriterialportal.org/public/files/cc-recarrange.pdf

http://www.commoncriterialportal.org/public/files/cc-recarrange.pdf


This limitation has been introduced for several reasons; one of them is that the different Participants may not agree on all of the particulars of how to perform medium and high assurance evaluations.

Two instructive AVA_VLA.3 perimeter security product evaluations are the Secure Computing Corporation’s evaluation of the Sidewinder G2 product, and the BorderWare Firewall Server 6.5 evaluation. Secure Computing Corporation performed an EAL 4 evaluation in the United Kingdom. It then performed a delta-evaluation in U.S., adding the AVA_VLA.3 assurance component. Because this augmentation was performed in the States, it is not recognized in the U.K., where the product is considered to be evaluated only to low attack resistance. Conversely, BorderWare performed its AVA_VLA.3 evaluation in the U.K.; this result is not recognized in the U.S.

Note that in the former case, Secure Computing Corporation repeated an evaluation of the Systematic Flaw Remediation assurance component in both the U.K. and the U.S., because flaw remediation is not a mutually recognized component (i.e. it is not included in EAL 4).

An interesting example for how different countries apply the CC differently is as follows: Microsoft has certified its Internet Security and Acceleration (ISA) Server 2004 in Germany. The Microsoft ST claims an assurance level of EAL 4, augmented with AVA_VLA.3 moderate attack resistance and basic flaw remediation. It does not claim compliance with any protection profile.

The ISA Server 2004 product is software that runs on the Windows 2003 Server operating system (which has not certified for operation in a moderately hostile environment). The operating system was defined outside the boundaries of the Target of Evaluation (TOE), i.e. its security properties were not included in the evaluation. In other words, the evaluation result is valid only as long as the attacker plays fair and does not bypass the TOE by targeting the underlying operating system.

The U.S. Common Criteria Evaluation and Validation Scheme (CCEVS) interpretation is that evaluations that claim non-bypassability (as does the ISA Server 2004 ST) must include the underlying platform in the TOE. It is therefore reasonable to assume that the Microsoft ST would not have been accepted for evaluation in the U.S. The German AVA_VLA.3 certification result is not recognized in the U.S., and the Microsoft ISA Server 2004 product is not listed in the validated products list on the U.S. CCEVS Web site.


Common Criteria Certification for Perimeter Security Products January 2007 Comparison of Evaluated Products

Comparison of Evaluated Products

This chapter examines STs for evaluated firewall, VPN, and IDS products, comparing them in terms of TOE boundaries, included and evaluated functionality, protection profile claims, assurance levels, attack resistance, and robustness levels.

The STs analyzed here are for perimeter security products that were listed (at the time this white paper was written) on the U.S. Common Criteria Evaluation and Validation Scheme (CCEVS) Web site. The analysis compares firewall and VPN gateway products that were listed as evaluated7 claiming moderate resistance or higher at assurance level EAL4 or higher. In addition, a separate analysis is provided for all listed IDS/IPS products at all8 assurance levels.

Although some of these products include additional functionality, we describe only functionality for which assurance was gained through CC evaluation. We have no grounds for confidence that unevaluated functionality could be used securely.

Firewall/VPN Products

The CCEVS listed9 moderately resistant firewall/VPN products were:

1. Check Point VPN-1/Firewall-1 NGX (R60) with HFA 03

2. Cryptek DiamondTEK F/W version 2.4.0.3

3. CyberGuard Firewall/VPN v6.2.1

4. Juniper Netscreen Appliances with firmware version 5.0.0r9

5. Secure Computing Sidewinder G2 Security Appliance with G2 Software v6.1.0.05.E51

7 CCEVS performs moderate resistance evaluations in two steps: the product is evaluated by the CCTL and an EAL4 certificate is issued; and then NSA performs additional moderate resistance vulnerability testing. Products that have completed the first phase can be considered here because their ST has been validated for consistency and has been made public. The comparison table below identifies those products that are still pending their NSA results. 8 IDS/IPS products are commonly evaluated at lower assurance levels, because they are often primarily intended for use in trusted, internal network environments. 9 Three relevant products that were not included in this analysis are Cisco Firewall Services Module, Cisco Secure PIX Security Appliances and Fortinet Fortigate Multi-Threat Security Systems. These three products are in evaluation (since March 2004 and March 2006 for Cisco and Fortinet, respectively) claiming moderate robustness. However, as they have not yet successfully completed their EAL4 evaluation (and there is no guarantee that they will in the future), their ST was not publicly available for this analysis.



The table presented in the following pages compares these products in terms of their evaluated functionality, presenting a general overview of the scope of the evaluation claims, evaluated management capabilities, as well as their evaluated firewall and VPN capabilities.

Check Point VPN-1 is the only medium robustness product evaluated as providing firewall, VPN, and IDS/IPS capabilities.

In general, the different evaluations vary in their functional focus: traffic filtering, application-level proxies, and VPN. The only evaluation including all three categories was that of the Check Point VPN-1 product. In addition to this distinction, Check Point VPN-1 is the only medium robustness platform evaluated to provide the IDS/IPS capabilities required for compliance with the U.S. Government IDS PP.

Traffic filtering is a basic firewall capability and was evaluated for the Check Point, CyberGuard and Juniper products. The Sidewinder evaluation excluded this functionality, allowing only application proxies in the evaluated configuration. Cryptek’s products are focused on cryptographic separation, and do not claim compliance with the traffic filter PP; however they do include very similar security requirements in their evaluated ST.

The three products providing evaluated application-level proxy capabilities (Check Point, CyberGuard and SideWinder) all provide support for the protocols identified in the PP: Telnet, FTP, SMTP and HTTP. Check Point’s ST is the only one that supports remote-access VPN as a supported authentication mechanism for these protocols.

Check Point VPN-1 outshines the other products in being the only product providing cryptographically strong, certificate-based VPN key exchange.

The evaluations differ greatly in terms of supported cryptographic functionality (see box below on the use of cryptography for VPN).

The SideWinder and CyberGuard evaluations excluded these products’ VPN capabilities from the evaluation. In other words, these products cannot be used as VPN gateways in their evaluated configuration. Juniper’s NetScreen product provides some limited VPN functionality.

Only Cryptek and Check Point provide a complete, standards-based VPN solution. Check Point outshines the other products in being the only product providing cryptographically strong, certificate-based VPN key exchange.

Check Point VPN-1 and Cryptek DiamondTEK also stand out in providing evaluated remote management capabilities. The other products require local access for management and log review. Remote management is critical for scalability in any distributed organization.


Common CriterCom

ia Certification for Perimeter Security Products January 2007 parison of Evaluated Products


On Virtual Private Networks (VPN) and Cryptographic Strength

Virtual Private Networks (VPNs) provide cryptographic separation for network traffic by encrypting packets flowing between VPN gateways or between remote access clients and VPN gateways. Cryptography is used to prevent unauthorized access to the data flowing between VPN peers:

• The peers establish a shared secret key and mutually authenticate;

• The secret key is used to encrypt packets to ensure confidentiality;

• The secret key is used to create keyed hashes that allow the peers to detect and reject any packets that might have been maliciously modified while flowing over the network, ensuring data integrity.

Cryptographic strength is usually measured in terms of key size, given in number of binary digits (bits). This determines the level of effort required for an attacker to bypass the cryptographic protection.

The U.S. National Institute of Standards and Technology (NIST) publishes Federal Information Processing Standards (FIPS PUB) for cryptographic algorithms and cryptographic modules, and validates products against these standards.

For confidentiality protection, 128 bits are considered a minimum. FIPS approved algorithms include AES-128 (and higher) and Triple DES. Integrity protection is commonly provided using a keyed version of the SHA-1 algorithm (HMAC-SHA-1).

Key establishment is the more challenging aspect of deploying VPNs. The Internet Key Exchange (IKE) protocol is the standard mechanism used for this purpose. The Diffie-Hellman (DH) algorithm is used for this purpose. NIST’s guidance is that 3072-bit DH keys (referred to as DH Group 15) or higher be used to provide 128 bits of encryption strength.

Peer authentication can be achieved using pre-shared keys that are manually entered by the administrator in each peer; however, this approach is neither scalable10 nor secure11. A certificate-based solution uses public-key algorithms such as RSA or DSA to create digital signatures for authentication. For these algorithms, key sizes of 1024 bits are commonly used, with some organizations transitioning to 2048 bits.

10 Pre-shared keys are not a scalable solution because a key must be established for every pair of VPN peers through which traffic might flow. For example, an organization with a hundred VPN gateways would require administrators to load 99 keys in each gateway, corresponding to the 99 possible VPN peers. In total, this organization would be required to manage, distribute, and periodically update some 9,900 different keys. In contrast, a certificate-based solution would require only a single certificate to be issued to each VPN gateway. 11 Pre-shared keys are not considered a secure solution because most administrators will not take the trouble (or have the capability) to generate keys that have 128 bits or more of randomness. Weak pre-shared keys can quickly become the Achilles’ heal of the overall cryptographic solution.


Table 1 - Firewall/VPN Product Comparison

Check Point VPN-1 CyberGuard Sidewinder

G2Juniper

NetScreenCryptek

DiamondTEK Comments

General

Evaluation performed in U.S. U.S.

U.K. (U.S. AVA_VLA.3, ALC_FLR.3)

U.S. U.S. Secure Computing performed their EAL4 evaluation in the U.K., and augmented in the U.S. with NSA moderate resistance testing and Systematic Flaw Remediation.

EAL EAL4 EAL4 EAL4 EAL4 EAL4 All reviewed products have been certified to Evaluation Assurance Level 4.

Resistance moderate moderate moderate moderate* moderate* Claimed attack resistance.

Robustness medium medium medium low† none Determined through conformance claim to U.S. Govt. low/medium robustness PPs

Flaw remediation

Systematic (FLR.3)

Systematic (FLR.3)

Systematic (FLR.3) none none Evaluated process for distributing updates

to customers if security flaws are identified.

Traffic Filter PP TFFW MRv1.4 TFFW MRv1.4 No TFFW LRv1.1† No

Application-level Firewall PP ALFW MRv1.0 ALFW MRv1.0 ALFW MRv1.0 No No

IDS PP IDSS v1.5 No No No No

A traffic filter firewall screens network traffic at the network and transport levels. An application-level firewall also provides proxies for protocols such as FTP and Telnet, and authenticates users. An IDS monitors for inappropriate activity and responds to detected intrusion attempts.

# of security requirements (SFRs)

64 28 29 29 40 The number of security functional requirements provides an additional metric for the comprehensiveness of the evaluated security claims.

* Pending NSA AVA_VLA.3 moderately resistant vulnerability testing. † A previous version of the Netscreen firewall (4.0.2r7.0) was evaluated against the U.S. Traffic Filter Firewall PP for Medium Robustness Environments PP (excluding VPN and other capabilities). This claim has been removed from the evaluation of version 5.0.0r9, which is currently in evaluation only against the corresponding low robustness PP.



Check Point Sidewinder Juniper Cryptek CyberGuard Comments VPN-1 G2 NetScreen DiamondTEK

Management

Remote management Yes No No No Yes

A remote management capability allows an administrator to manage devices from remote location. Without it, each device must be configured separately from a local management interface.

Centralized log collection Yes No No No Yes

Netscreen appliances store log records in memory; all records are lost in case of power failure. The evaluated configuration requires audit records to be sent to a syslog server (outside the TOE) as a backup.

Management Interface

SmartConsole GUI application Web Interface Admin Console

GUI application VT-100 CLI DiamondCentral GUI application

In general, GUI or Web-based administration interfaces provide more intuitive control than a command line interface (CLI).

Administrator authentication Certificate-based Reusable

passwords Reusable/single-use passwords

Reusable passwords

Reusable passwords

Reusable passwords are considered less secure than single-use or certificate-based authentication.

Administrator access control

Multiple permissions

profiles No Read/Write,

Read-Only

Root, Read/Write, Read-Only

No Administrator access control supports the principle of privilege separation, allowing restricted access to administrative users (e.g. a read-only auditor role).

NTP (time synchronization) Yes No No No No

Cryptek DiamondTEK timestamps all audit records on the management console, using the underlying DiamondCentral Microsoft Windows operating system clock.



Check Point Sidewinder Juniper Cryptek CyberGuard Comments VPN-1 G2 NetScreen DiamondTEK

VPN

Internet Key Exchange (IKE)

RFC 2409 compliant No No No‡ RFC 2409

compliant

IKE is used for securely exchanging keys with a VPN peer in order to protect VPN traffic.

Pre-shared key authentication Yes No No Yes Yes

[SP800-77]: Because of scalability and security concerns, pre-shared key authentication is generally an acceptable solution only for small-scale implementations with known IP addresses or small IP address ranges.

Certificate-based authentication Yes No No No No

Certificate-based authentication for IKE supports scalable deployments that do not require pre-shared keys to be configured between all possible pairs of VPN peers.

IPSec support RFC 2406 compliant No No Yes§ RFC 2406

compliant IPSec is used to protect VPN traffic.

Confidentiality protection Yes No No Yes Yes IPSec VPNs protect network traffic from

unauthorized disclosure.

Integrity protection Yes No No No** Yes IPSec VPNs protect network traffic from

unauthorized modification.

Site to site VPN Yes No No Yes Yes VPN between peer gateways.

Remote Access VPN Yes No No No Yes VPN between VPN client (on user

workstation) and VPN gateway.

‡ In the evaluated configuration, Netscreen appliances only support Manual Key authentication for VPN peers. § The Netscreen ST states that it uses IPSec to protect VPN traffic; however, IPSec was not expressed as a security requirement, and was therefore not evaluated. ** The Netscreen ST does not claim integrity protection for VPN traffic.




Check Point VPN-1 CyberGuard Sidewinder

G2Juniper

NetScreenCryptek

DiamondTEK Comments

Cryptography

FIPS 140-2 Validation Yes No Yes Yes Yes

U.S. Federal Government agencies are required by law to use only FIPS 140 validated cryptographic modules for the cryptographic protection of information.

RSA Key size 1024, 2048, 4096 bits No No No No RSA is used for certificate-based IKE

authentication.

Encryption algs. (confidentiality)

3DES, AES-128, AES-256 No No

DES, 3DES, AES-128, AES-192, AES-256

DES, 3DES DES is not a FIPS 140-2 approved algorithm. [SP800-77] recommends AES-128; 3DES is also considered acceptable.

Hash algs. (integrity) SHA-1 No No MD5, SHA-1 SHA-1 Note: MD5 is not a FIPS 140-2 approved

algorithm.

Diffie Hellman Up to 8192 bit MODP No No Not claimed Up to 1024 bit

MODP

[FIPS140-2 IG] recommends that where Diffie Hellman is used for 128-bit key establishment (e.g. AES-128), 3072 MODP DH keys should be used as a minimum.

Application-level Proxy Firewall

Protocols FTP, Telnet, SMTP, HTTP

FTP, Telnet, SMTP, HTTP

FTP, Telnet, SMTP, HTTP,

finger No No Application-level proxies are a requirement

of the Application-Level Firewall PP.

Third-party anti-virus interfaces CVP/UFP APIs No No

Embedded anti-virus engine in some models

No Anti-virus scanning can be performed on proxied protocols to detect data-level attack signatures.

User authentication mechanisms

IKE, RADIUS, SecurID

RADIUS (RSA ACE/Server

only) RADIUS No No

Application-level proxies can authenticate users using single-use authenticators prior to allowing access to protected resources.

Common CriterCom


IDS/IPS Products

The CCEVS listed IDS/IPS products were the following17:

1. Arbor Networks Peakflow X version 3.1.4

2. ArcSight 3.0

3. Check Point VPN-1/Firewall-1 NGX

4. Cisco IDS-4200 series Version 4.1(3)

5. Cisco IDS Module Version 4.1(3)

6. Enterasys Dragon-EALT IDS Version 1.0

7. ForeScout ActiveScout Version 3.0.5 / CounterACT Version 4.1.0

8. McAfee IntruShield IDS v3.1

9. ISS Proventia A Version 7.0, Proventia G Version 8.0, Network Sensor 7.0 and SiteProtector 2.0

10. Juniper Network Security Manager (NSM) 2006.1

11. Lancope StealthWatch Version 5.1.0

12. McAfee IntruShield IDS, v3.1

13. NFR Sentivist v.4.0.6

14. SecureNet Pro IDS Version 4.1 SP1

15. Sourcefire IDS version 3.2.3

16. Symantec CyberWolf, Version 2.0

17. Symantec Manhunt v2.11

18. TippingPoint UnityOne Version 1.2

The table presented in the following pages compares these products in terms of their evaluated functionality, presenting a general overview of the scope of the evaluation claims, evaluated management capabilities, as well as their evaluated IDS/IPS capabilities.

17 The following products listed on the CCEVS as IDS/IPS-technology products were excluded from the analysis because they are not relevant to the perimeter security product category: Sun Java System Identity Manager is an Identity Management (IdM) product; SecureWave Sanctuary Application Control is a host intrusion prevention (HIDS) product; Air Defense Guard is an IDS for wireless networks. Cryptek DiamondTEK was excluded because its evaluated recording, analysis and reaction functionality is limited to generating threshold-based alarms for TOE-audited events (e.g. access and authentication violations); it cannot be used to detect intrusion-related anomalies or attack signatures in network traffic.


Common CriterCom



Check Point VPN-1 provides a level of assurance that is far beyond any of the other IDS/IPS products.

The table is presented in decreasing order of resistance, PP compliance, and assurance level. The majority of the listed IDS/IPS products claim conformance with the NSA IDS PPs, which set basic IDS-related requirements for data collection, storage, analysis and review, for a reaction capability (intrusion prevention), and for self-protection and management capabilities.

Check Point VPN-1 provides a level of assurance that is far beyond any of the other products. It is the only IDS/IPS product evaluated at EAL4; it is the only product evaluated to provide moderate resistance to attacks18; and it is the only product with FIPS 140-2 validated cryptography.

Most of the network IDS/IPS products’ network traffic sensors operate passively, by using switch SPAN ports or using Taps.

Some products can collect network traffic-related events for intrusion analysis from other IDS or networking products, instead of tapping directly into the network flow: ArcSight, PeakFlow X and Symantec Manhunt and CyberWolf.

Inline topologies provide superior prevention capabilities and improved resistance to IDS evasion techniques.

The Check Point, McAfee and Juniper products can be deployed inline in the network traffic flow. This topology provides superior19 prevention capabilities and improved resistance to IDS evasion techniques, although it may impact network latency. In particular, the inline products’ reaction capabilities include blocking the suspected traffic, whereas passive topologies allow only indirect reaction functionality.

The listed IDS/IPS products vary in their intrusion analysis functionality. The most common techniques were attack signature matching and protocol anomaly detection. An evaluated mechanism for accepting signature updates is important to support such functionality. The Check Point, McAfee, NFR, SourceFire and Intrusion SecureNet products take this mechanism further by providing a pattern language that can be used by the customer to add custom attack signatures and patterns.

18 From [SP800-94]: “Securing IDP components is very important because IDPs are often targeted by attackers who want to prevent the IDPs from detecting attacks or want to gain access to sensitive information in the IDPs, such as host configurations and known vulnerabilities.” 19 From [SP800-94]: “Generally, organizations should deploy sensors inline if prevention methods will be used and passive if they will not.”

Common CriterCom



A less common capability offered only by Lancope StealthWatch and Arbor Peakflow X is to automatically profile valid network traffic during a learning period and then match traffic against that profile.

Other analysis techniques used by some IDS/IPS products include statistical analysis of network traffic, and event correlation used to group multiple events that are associated with a single intrusion attempt.

Centralized management and event collection should be considered a mandatory requirement.

For any non-trivial network, centralized management and event collection should be considered a mandatory requirement. Surprisingly, many of the product evaluations did not include such capabilities. The flow of information to and from the sensor components should be protected against modification. Standard protocols such as TLS should be preferred over proprietary solutions, especially in the absence of third-party cryptographic validation.

It must be noted that the Common Criteria evaluation of IDS products has focused almost exclusively on the security mechanisms provided by the evaluated products, and did not examine the breadth of coverage of known intrusion scenarios by any given product. In general, a product that provides flexible, updateable, user-definable signatures, patterns, or profiles should prove a better long-term investment than one that provides only hard-coded defenses.


Table 2 - IDS/IPS Product Comparison

Check Point VPN-1

McAfee IntruShield

ArcSight 3.0

NFR Sentivist

SourcefireIDS

Cisco IDS-4200

Juniper NSM

Tipping Point

UnityOne

LancopeStealth Watch

Enterasys Dragon

Symantec Manhunt

Cisco IDSM

ISS Site Protector

Arbor Peakflow

X

Intrusion SecureNet

Pro

Symantec CyberWolf

ForeScout Active Scout

EAL EAL4 EAL3 EAL3 EAL2 EAL2 EAL2 EAL2 EAL2 EAL2 EAL2 EAL3 EAL2 EAL2 EAL2 EAL2 EAL2 EAL2

Resistance moderate low low low low low low low low low low low low low none20 none none

IDS PP IDSS v1.5 IDSS21 IDSA22 v1.2 IDSS v1.4 IDSS v1.4 IDSS v1.4 IDSS v1.5 IDSS23

v1.4 IDSS v1.5 -24 - - - - - - -

Flaw remediation FLR.3 - FLR.1 - - - - - FLR.2 - - FLR.1 - - - - -

# of SFRs 64 24 18 27 23 27 22 29 22 28 10 26 13 20 11 17 19

Product Type appliance appliance software appliance appliance appliance appliance appliance appliance appliance software switch

blade appliance, software appliance software software software

Sensor topology inline passive,

inline

Nessus, Snort, Check Point

passive passive passive passive, inline inline passive passive

passive, RMON,

telnet passive passive passive,

Netflow passive ISS

RealSecure, snort

passive

Centralized management Yes Yes analysis-

only Yes Yes - Yes - - - Yes - Yes Yes - analysis-only -

Manage-ment roles Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes - - Yes -

20 The Intrusion, CyberWolf and ForeScout STs do not claim any resistance to tampering or bypass threats (FPT_SEP.1 and FPT_RVM.1, respectively), and do not allocate these requirements to the underlying IT environment. 21 McAfee IntruShield was not evaluated against the IDS PP; however, it was evaluated to comply with all IDSSPPv1.4 security requirements, except for FPT_STM.1 (secure time). Versions of the IDS PP released after IntruShield was evaluated relaxed the FPT_STM.1 requirement. The product is therefore considered in this analysis as PP compliant. 22 The IDS Analyzer PP covers only analysis functionality and excludes event collection. ArcSight collects and analyzes events from the listed sensor sources. 23 In addition to the IDS System PP version 1.4, the TippingPoint UnityOne Version 1.2 ST claims conformance to the three component PPs: IDS Analyzer PP v1.1, IDS Sensor PP v1.1, and IDS Scanner PP v1.1. The IDSSPPv1.4 is used as the baseline for the ST. 24 The Enterasys Dragon-EAL IDS Security Target states that “while not conformant to the Intrusion Detection System System Protection Profile (IDSSYPP), Version 1.4, February 4, 2002, this ST is based on that PP.” – the NIAP CCEVS validation report states that the ST incorporates much of the PPs elements and design, and provides an analysis of the differences between the ST and the PP.




Check Point VPN-1

McAfee IntruShield

ArcSight 3.0

NFR Sentivist

SourcefireIDS

Cisco IDS-4200

Juniper NSM

Tipping Point

UnityOne

LancopeStealth Watch

Enterasys Dragon

Symantec Manhunt

Cisco IDSM

ISS Site Protector

Arbor Peakflow

X

Intrusion SecureNet

Pro

Symantec CyberWolf

ForeScout Active Scout

Traffic recording - Yes - - Yes - - - - Yes Yes - - - Yes - -

Attack signatures Yes Yes Yes Yes Yes Yes Yes Yes - Yes Yes Yes Yes - Yes - -

Pattern language INSPECT UDS - n-Code snort - - - - - - - - - SNP-L - -

Signature updates Yes Yes - Yes Yes Yes - - - Yes - Yes - - Yes - -

Protocol anomalies Yes Yes Yes Yes Yes - Yes - - - Yes - - - Yes - -

Automatic profiling - - - - - - - - Yes - - - - Yes - - -

Statistical - Yes Yes - - - - - Yes - Yes - - - - - -

Correlation Yes Yes Yes - - - - - - - Yes - - Yes - Yes -

Response drop packet

reset session, drop

packet25, change

firewall rule, log traffic

execute script

reset session, execute script

-

reset session,

send cmd. to Cisco

element to block traffic

drop packet

reset session,

drop packet

- reset session

reset session,

trackback

reset session,

send cmd. to Cisco

element

- - reset session - -

Alerts Yes Yes Yes Yes - Yes Yes Yes Yes Yes Yes Yes - Yes Yes - Yes

Notification SNMP SNMP SMTP, SNPP - SMTP - - SMTP - SMTP SMTP,

SNMP - - - - - -

Intra-TOE transfer protection

TLS SSL SSL proprietary protocol

SSL, ssh, scp - proprietary

protocol SSL/TLS,

SSH - - proprietary protocol - - SSL proprietary

protocol proprietary

protocol -

FIPS 140-2 Yes - - - - - - - - - - - - - - - -

25 Packet dropping is available only in inline topology.

Common CriterCom

Common Criteria Certification for Perimeter Security Products January 2007 Additional Reading

Additional Reading

Web Sites

[CC Portal] Common Criteria Portal

[NIAP VPL] NIAP CCEVS Validated Products List

[NIAP in-eval] NIAP CCEVS In-Evaluation List

[CPGovWeb] Check Point Government Web Page

General Guidelines and Documentation

[SP800-41] NIST Special Publication 800-41 Guidelines on Firewalls and Firewall Policy, January 2002

[SP800-77] NIST Special Publication 800-77 Guide to IPsec VPNs, December 2005

[SP800-94] NIST Special Publication 800-94 (Draft) Guide to Intrusion Detection and Prevention (IDP) Systems, August 2006

[FIPS140-2 IG] NIST/CSE Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program, October 2006

[DoDI 8500.2] Department of Defense Instruction number 8500.2, February 6, 2003

Protection Profiles

[TFFW LRv1.1] U.S. Government Traffic-Filter Firewall Protection Profile for Low-Risk Environments, Version 1.1, April 1999

[TFFW MRv1.4] U.S. Government Traffic-Filter Firewall Protection Profile for Medium Robustness Environments, Version 1.4, May 1, 2000

[ALFW MRv1.0] U.S. Government Application-level Firewall Protection Profile for Medium Robustness Environments, Version 1.0, June 28, 2000

[IDSSPPv1.5] Intrusion Detection System System Protection Profile, Version 1.5, March 9, 2005


http://www.commoncriterialportal.org/

http://niap.bahialabs.com/cc-scheme/vpl/vpl_type.cfm

http://niap.bahialabs.com/cc-scheme/in_evaluation.cfm

http://www.checkpoint.com/products/industries/government/index.html


Security Targets (on [NIAP VPL])

[Arbor Peakflow X] Arbor Peakflow X Security Target, Version 1.0, July 8, 2005

[ArcSight 3.0] ArcSight 3.0 Security Target, Version 1.0, 29 September 2006

[Check Point VPN-1] Check Point VPN-1/Firewall-1 NGX Security Target, Version 1.2.2, August 2006

[Cisco IDSM] Cisco Intrusion Detection System Module (IDSM2) v4.1 (3) Security Target, Version 1, June 16, 2004

[Cisco IDS-4200] Cisco Intrusion Detection System Sensor Appliance IDS-4200 series Version 4.1(3) Security Target, Version 2.4, May 25, 2004

[Cryptek DiamondTEK]

Cryptek, Inc., DiamondTEK Security Target, Revision 2.0, December 30, 2005

[CyberGuard] CyberGuard Firewall/VPN Version 6.2.1 Security Target, Revision 1.3, September 30, 2005

[Enterasys Dragon] Enterasys Dragon-EAL Intrusion Defense System Security Target, Version 11, August 31, 2004

[ForeScout Active Scout]

ForeScout ActiveScout / CounterACT Security Target, Version 2.4, June 26, 2005

[Intrusion SecureNet Pro]

Intrusion, Inc., SecureNet Pro™ Intrusion Detection System Version 4.1 SP1 Security Target, December 20, 2002

[ISS Site Protector]ISS Proventia A Version 7.0-2003.167, Proventia G Version 8.0-2004.219, Network Sensor 7.0, and SiteProtector 2.0 Service Pack 4 Security Target, Version 2.25, April 11, 2006

[Juniper NSM] Juniper Networks IDP 4.0 & NSM 2006.1 Security Target, Version 1.0, November 1, 2006

[Juniper NetScreen] Juniper Networks Security Appliances Security Target: EAL4, Revision I, December 19, 2005, P/N 093-0896-000

[Lancope Stealth Watch]

Lancope StealthWatch Security Target, Version 1.0, July 14, 2004

CCEVS, Assurance Continuity Maintenance Report for Lancope Stealth Watch NC and StealthWatch Xe Appliances containing V5.1.0 Software, April 14, 2006


http://niap.bahialab.com/cc-scheme/st/ST_VID4045-ST.pdf


























http://niap.bahialab.com/cc-scheme/st/ST_VID4033-ADD2.pdf




[McAfee IntruShield]

McAfee Incorporated, IntruShield Product Family, Intrusion Detection System, Security Target, Version 0.97, August 25, 2004

CCEVS, Assurance Continuity Maintenance Report for McAfee IntruShield Intrusion Detection System, v3.1, March 23, 2006

[NFR Sentivist] NFR Sentivist™ v4.0.2 – Updated to v4.0.6, Sentivist Sensors 310C, 320C and 320F Models Security Target, Version 2.7, April 18, 2005

[Symantec Manhunt]Security Target for ManHunt: A Network Infrastructure Security product for Attack Detection, Analysis and Response, V.2.11, Version v.05, July 11, 2003

[Sidewinder G2] Sidewinder G2 Appliance Models EAL4+ with Medium PP Compliance Security Target, October 3, 2005, P/N 00-0943554-J

[Sourcefire IDS] Sourcefire Intrusion Detection System Security Target, Version 1.4, May 19, 2005

[Symantec CyberWolf]

Symantec CyberWolf v2.0 Security Target, Version 1.0, Revision 1.22, April 26, 2004

[Tipping Point UnityOne]

TippingPoint Technologies, Inc. UnityOne Version 1.2 Security Target, Version 2.3, August 14, 2003



















metatron - check point software · 2 title styled after ken thompson’s acm turing award lecture,...

Documents