National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Validation Report Securify SecurVantage™,Version 3.1 Report Number: CCEVS-VR-04-0056 Dated: 26 January 2004 Version: 1.0 National Institute of Standards and Technology Information Technology Laboratory 100 Bureau Drive Gaithersburg, MD 20899 National Security Agency Information Assurance Directorate 9800 Savage Road STE 6740 Fort George G. Meade, MD 20755-6740 ® TM Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 2 1. Executive Summary An evaluation of the Securify’s SecurVantage™, version 3.1, was begun 21 February 2003 and completed 26 January 2004. Securify SecurVantage™ is a system that enables customers to define a network security policy (typically describing the permitted network operations), monitor networks for compliance with that policy, and produce relevant network operational information (such as events that fail to comply with the policy). The product consists of a tool for network security policy development and security analysis (Studio), a real-time monitoring system to continuously verify conformance to those security policies (Monitor), and an optional enterprise management and trend reporting system that can merge reports from multiple monitors (Enterprise). The Target of Evaluation (TOE) includes those components developed by Securify, and not third-party components such as hardware and operating systems. The evaluation examined the threat of unauthorized users gaining control of the TOE, of attackers evading the monitoring implemented by the TOE, and of users raising their privileges in an unauthorized way. It is assumed that the TOE hardware and software will be located within controlled access facilities, preventing unauthorized physical access and protecting the TOE from unauthorized physical modification. The evaluation was performed by CygnaCom in the United States. The evaluation was carried out in accordance with requirements drawn from the Common Criteria CCv2.1, Part 3 for EAL2 [CC_PART3] and Common Evaluation Methodology for Information Technology Security – Part 2: Evaluation Methodology [CEM_PART2]. The assurance activities in this level offer confidence that evaluated configuration of Securify SecurVantage™ (with documentation and software deliverables as defined in sections 6. and 8., respectively) contains requirements that are: · Justifiably included to counter stated threats and meet realistic security objectives, · Internally consistent and coherent · Technically sound and · Free from vulnerabilities associated with obvious and known threats. CygnaCom, a Common Criteria Testing Laboratory [CCTL], is certified by the NIAP validation body for laboratory accreditation. The CCTL has presented CEM work units and rationale that are consistent with the CC, the CEM and CCEVS publication number 4 Guidance to CCEVS Approved Common Criteria Testing Laboratories [CCEVS_PUB 4]. The CCTL team concluded that the requirements of the EAL 2 have been met. Therefore, a pass verdict has been issued, by the CCTL, for Securify’s SecurVantage™, version 3.1. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 3 The information contained in this Validation Report is not an endorsement of Securify’s SecurVantage™ by any agency of the U.S. Government and no warranty of the product is either expressed or implied. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 4 1.1. Evaluation Highlights Dates of Evaluation: 21 Feb 2003 – 26 January 2004 Evaluated Product: SecurVantage™, version 3.1 Developer: Securify Inc., 1157 San Antonio Road, Mountain View, CA 94043. http://www.securify.com CCTL: CygnaCom Lead Evaluator: Nithya Rachamadugu (initially Kris Rogers) Evaluation Class: EAL2 PPs Claimed: None. Validation Team: David A. Wheeler, Institute for Defense Analyses (IDA) Version of CC: Common Criteria version 2.1, August 1999 Version of CEM: Common Evaluation Methodology 1.0, August 1999 Effective Date for Interpretations: All interpretations as of 21 February 2003. 2. Product Identification The Target of Evaluation (TOE) is Securify SecurVantage™, version 3.1. It consists of the following major components: · Studio 3.1 · Monitor 3.1 or Monitor LE 3.1 · Enterprise 3.1 (optional) The Monitor component can be configured in two different ways, depending on the processing speed required. High bandwidth solutions use Monitor 3.1, which has two subcomponents (Monitor SM and Monitor Harvester) each running on a different processor. For low bandwidth solutions, Monitor 3.1 LE is deployed, which uses the same software but uses a single hardware system that is shared between the two subcomponents. The product must run on top of hardware and an operating system, all of which are part of the environment (and thus not evaluated). Monitor and Enterprise run atop Red Hat Linux 7.2 (patched) and an x86 system. Although it is also sold separately, in the evaluated configuration the hardware and operating system for Monitor and Enterprise are provided by the vendor directly to the customer, along with a CD-ROM permitting local re-installation. Studio is a user interface component and runs on Microsoft Windows 2000 on an x86 hardware platform. Additional interfacing uses a web browser, and the system depends on third-party encryption libraries, neither of which are part of the target of evaluation (TOE). See the Security Target (ST) for more information. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 5 3. Security Policy The TOE, with support from its IT environment, provides the following security functions (beyond self-protection): · Auditing, · Access Control, · User Identification and Authentication · Security Management The primary purpose of the TOE is to permit administrators to define a network security (SecurVantage) policy, then monitor networks and report deviations from that policy. A SecurVantage Policy is a set of rules that describe the expected behavior of the systems within a network. Network objects represent systems. A network object can be one or many IP addresses. Each rule in the Policy describes how the system will log a network transaction between two network objects. All network transactions are logged and represented as an event. Each event represents the information contained in the headers of the actual packets within the network transaction. In SecurVantage, an output of the policy engine is created when network traffic is evaluated against a policy. A network event is a summary of the set of protocol events that make up a complete application level session on the network. For example, viewing a Web page creates a network event that summarizes the underlying IP association, TCP connection and HTTP Get protocol events. The policy assigns by default a severity to every event, such that all events are logged by default. These default values can be changed by the user of the system to accommodate specific security policies. A severity is one of the following options: Critical, High, Medium, Warning, Monitor, Informational, or Ok. All events other than Ok are fully logged in the system down to the protocol details level (source and target network object name, ip addresses, protocols, src port, dst port, tcp flags, udp association, etc). Events that have a severity value of “ok” are only logged at a summary level (source and target network object name and service name). Events logged as critical are also called alerts and copied to a separate alert table. Alerts can trigger SMTP and SNMP messages to other management systems. Effort was particularly expended to ensure that attackers could not easily inhibit or circumvent this monitoring. A given monitor can only implement one network security policy at a time. Multiple monitors may be part of a “domain”, which shares a common network security policy. Enterprise (when used) can support multiple domains. The TOE supports various user roles. Every user account is assigned one or more roles. The privileges granted to a user are the union of the privileges of that user’s role(s). All roles (and their privileges) are simultaneously active for a given user. For example, a user with the Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 6 role “operator” and/or “analyst” (and no other role) cannot upload a new network security policy (i.e., cannot change the policy). The various roles, and their privileges, are shown below: SecurVantage TM User Access Policy (from Security Target) Roles/Subjects Objects Operator Analyst Developer SV Manager Account Manager Super User Event Data View View View View Machines View Status View Status View Status View Status Start/Restart Stop Configure View Status View Status Start/Restart Stop Configure DMEs Download Download Download User Access Manage Manage Policy History View View View View Policies Extract Upload Revert Extract Upload Revert Extract Alerts Manage Manage Manage Manage Application Logs View View User Logs View View Details, including definitions of these objects, are given in the ST. 4. Assumptions and Clarification of Scope 4.1 Usage Assumptions The following usage assumptions were made for the TOE. It is assumed that administrators will have a strong understanding of the TOE, networking technology, and the network(s) they are monitoring. Fundamentally, the TOE allows an administrator to identify a policy of “normal” behavior, and the TOE will then report on all actions not corresponding to the policy. A knowledgeable administrator who creates a well- defined policy may find this TOE to be extremely effective at reporting just the events that need reporting. However, a poorly-defined policy (created by an administrator with insufficient understanding) may cause the TOE to report a voluminous number of unimportant events, and/or cause the TOE to omit events that were important to report. This Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 7 is not a fault of the TOE implementation; it is fundamental to the nature of its approach. Any TOE is best used by a knowledgeable administrator, but this TOE in particular requires a good administrator for effective use. Administrators should obtain training before use; the vendor makes such training available. Many deployments may want to ensure there are at least two trained administrators, to enable discussions of policy and to ensure continuous service if an administrator becomes unavailable. Administrator training and an understanding of the network being monitored are critical for effective and efficient use of this TOE. At a more fundamental level, this TOE requires that it be possible to (eventually) determine the expected or permitted activities on the monitored networks, so that this information can be captured as a security policy. If all actions are permitted by all network components, the TOE’s ability to compare actions with expected actions is far less valuable. A pre-existing written security policy, while very helpful, is not required; the security policy can be developed over time, starting with a more general policy and then repeatedly refining it. The TOE can also be used as a monitoring tool, so that actual network activity can guide formulation of the security policy. For nearly all real-life circumstances this is not a restriction. Most of today’s networks do have a set of expected activities that is a small subset of all possible activities. The TOE is normally used by plugging it into a switch’s SPAN port. Typically SPAN ports only report the packets that cross the switch, and not network packets that appear on a network but do not cross it. This is an aspect of the environment, not the TOE itself; the TOE can only log what’s reported to it. Since this is not an issue of the TOE itself, and many customers would expect this behavior anyway, it is not considered a vulnerability. However, administrators will need to configure their network and/or where they connect Monitor(s) so that what they wish to monitor can actually be monitored. Users of the system are trusted with the privileges they have been granted, and it is presumed that authorized users will not misuse their privileges. For example, operators are trusted with the ability to view event data (which would give operators insight into all network activity) and analysts are granted the ability to download DMEs and extract policies (which would give analysts the ability to download summaries of network activities and know exactly what policy is being checked). However, as clearly noted above, users of the system are not fully trusted with all privileges. The TOE specifically works to prevent authorized users from gaining additional unauthorized privileges. 4.2 Environmental Assumptions As stated in the ST, the hardware, operating system, and third-party cryptographic libraries are not included in the evaluation. As part of installation, the operating system used by Monitor and Enterprise (Red Hat Linux) is installed in a way that limits its functionality. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 8 While this should help, for purposes of evaluation it is assumed that this operating system is secure in its environment. Note in particular that the operating system running Studio (Microsoft Windows) must be secured separately, and that no attempt is made by the product to ensure this. The TOE uses encryption to protect data between its major components, but since this encryption is performed in the environment (not in the TOE) it is not further considered here. As clearly stated in the ST, the TOE only records IPv4 with normal Ethernet framing. Other kinds of data, particularly IPv6 and Ethernet jumbo frames (jumbograms), are not recorded. If all relevant network traffic is to be monitored, systems must be configured to reject these unrecorded packets. Many systems do this by default, so this is a plausible environmental restriction. If there are concerns that cooperating end-systems may surreptitiously send data between each other using other kinds of packets, then the network infrastructure should be configured to actively inhibit this kind of traffic. A particularly effective approach to doing this would be to insert network packet scrubbers that enforced these limits and regularized packets for monitoring purposes. The TOE is capable of using the Domain Name Service (DNS) for translating IP addresses back to machine names. By default, this capability is disabled. Enabling this capability can aid administrators by giving them simple names instead of IP addresses. However, these name values are dependent on the security of DNS itself. Subversion of the DNS service could provide incorrect names. Also, attackers may control DNS services of other domains (legitimately or not). Thus, the names provided by DNS could be misleading. Note that the TOE does not use DNS for security decisions—this data is purely informational. The TOE’s Studio component does include an ability to import DNS zone data from a file; ensuring that this zone data file is correct is outside the scope of the TOE. Administrators are warned about these issues in the installation guidance. The TOE is capable of using the Network Time Protocol (NTP) for keeping time values correct. By default, this capability is disabled. NTP can be convenient for accurately keeping time values current. However, it is difficult to secure. An attacker that sends malicious NTP reports, or takes over a relevant NTP server, could cause the timestamps of events to be incorrect (impacting any Monitor report). This could also negatively impact attempts to merge data from multiple Monitors (as Enterprise does). Administrators are warned about this in the installation guidance (in the Administrator Addendum). The TOE hardware and software must be located within controlled access facilities, preventing unauthorized physical access and protecting the TOE from unauthorized physical modification. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 9 4.3 Clarification of Scope All evaluations (and all products) have limitations, as well as potential misconceptions that need clarifying. This text covers some of the more important limitations and clarifications of this evaluation. Note that: 1. As with any evaluation, this evaluation only shows that the evaluated configuration meets the security claims made, with a certain level of assurance (EAL2 in this case). 2. This evaluation covers SecurVantage Version 3.1, not the later version 4.X series. Thus, these evaluation results do not automatically apply to version 4.X, and in particular additions in version 4.X (such as the Nessus security scanner) have not been considered by this evaluation. 3. As with all EAL2 evaluations, this evaluation did not specifically search for, nor seriously attempt to counter, vulnerabilities that were not “obvious” (as this term is defined in the CC and CEM) or “vulnerabilities” to objectives not claimed in the ST. A residual vulnerability (beyond the EAL2 level) was identified during the evaluation and was fixed by the developer. 4. In particular, the evaluation does not claim a resistance of the TOE to denial-of- service attacks, where an attacker intentionally causes a large load of traffic to mask different nefarious activities. This is a fundamental limitation of any passive monitoring tool. However, the TOE does log when its logging rates have been exceeded. Thus, although an attacker might be able to hide a nefarious action by overwhelming the TOE, the TOE will log when there was an opportunity to do so. Customers concerned about attackers who would use resource overwhelming attacks to hide other actions may consider purchasing the high-bandwidth Monitor, employing multiple Monitors, and/or employing network rate limiting components to slow network traffic to a monitorable rate. 5. Ideally, the monitoring system should log exactly what the receiving application would see. However, for a variety of reasons this is impossible for a passive monitoring system to do perfectly. In particular, when the TOE reassembles IP fragments, the TOE may reassemble them differently than the receiving system and thus report different results. This is a fundamental problem with all network monitoring systems, particularly passive monitoring systems ones like this. Since this case is a fundamental limitation of the technology, and would be expected by knowledgeable administrators anyway, this was considered acceptable. Customers who find this undesirable should counter this problem by inserting “network packet scrubbers” in their environment in such a way that the monitor and end-user receiving systems will see exactly the same data. 6. Network events can be a set of IP packets, not just one (e.g., initiating an HTTP request). If an event is halfway completed, but never actually completed, the TOE times out. However, the result of this time-out is logged, and the time-outs are longer than the standards required of receivers. This again raises the concern that receivers and the TOE may have a slightly different view of what is happening, but since there Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 10 is some logging no matter what the attacker does this was determined to be acceptable. 7. The purpose of the TOE is to report violations of policy, not identify network covert channels between cooperating parties. For example, two systems A and B could surreptitiously communicate with each other by communicating with a system C in accordance with a security policy, and then by monitoring each others’ communication with C, extract the separate data intended for each other. Alternatively, systems A and B could arrange for data or processing at C to be an indirect channel between A and B. Steganographic tricks combined with error- correcting codes could make such hidden data particularly hard to identify. Detecting such channels is not the purpose of this TOE. The purpose of this TOE is to watch ordinary protocols and report direct violations according to a customer-defined security policy. Customers worried about these covert channel problems should consider redesigning their networks (e.g., to completely isolate the systems) or other measures. 8. The TOE does not log every byte of every packet involved. In many of its intended environments, this would be an extremely stressing requirement, would severely limit the length of time the logged information could be stored, and is unnecessary. Instead, the TOE stores a summary of every network event, with more information on events that are not ranked “ok.” This information is sufficient for its intended purpose. 9. When a network event has a severity level of “critical,” its information is copied to the separate “alerts” log. Note that operators and analysts (as well as developers and the super user) can manage the alerts log, i.e., they can both view and modify it. This is intentional. The expected use is that any of these roles can review the alerts, and once they have addressed them any of these users can remove the alerts that have been addressed. Removing an alert does not remove its original from the event data. 10. Network event data is stored at the Monitor that recorded it. This includes the criticality of the event, which is treated as a constant (it is assigned using the policy active at the time the event was recorded). Network event data can be retrieved as a DME file (if the user is permitted to do so); Studio can then be run locally to recompute network event severities using a different policy. These recomputed severities do not change the severity recorded by the relevant Monitor. The ST does not claim conformance to any Protection Profile (PP), including the Intrusion Detection System (IDS) PPs. The TOE can be used for a variety of purposes, including monitoring network traffic to understand how the network is being used, or to enforce network policies having nothing to do with intrusion detection (e.g., to detect when authorized users of the network use network resources in a way that contravenes official policies). It is possible to configure the TOE to indirectly support intrusion detection, simply by defining a narrow policy of expected network usage. In this case, actions not in Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 11 accordance with the policy might indicate an intrusion. This is not always true; in particular, an intruder’s actions might conform with the policy (depending on the policy and the intruder’s actions). However, because of this general similarity, the IDS Sensor PP and the IDS Analyzer PP (both version 1.1, dated December 10, 2001) are worth comparing with this ST. Here is a brief comparison of the ST of this evaluation to the requirements of those PPs: 1. In general, the ST does not include in the TOE the hardware, operating system, and many 3rd party components (in particular, the encryption libraries). Instead, they are part of the environment. For example, the ST allocates encryption to the environment, as well as reliable time stamps. Meeting the PP would imply evaluation of many other components (by enlarging the definition of the TOE). 2. The ST does not include an inter-TSF availability within a defined availability metric, nor inter-TSF detection of modification (FPT_ITA.1, FPT_ITI.1). 3. The ST has fewer auditing requirements on TOE-specific actions (see FAU_GEN), i.e., reading of information from the audit records is not specifically required in the ST. 4. The ST does not require authentication failure handling (FIA_AFL.1). Note that this TOE is intended for a different purpose than an IDS. This TOE’s purpose is to detect violations of a security policy, not specifically to detect intruders. Nevertheless, the TOE is sufficiently flexible to support many kinds of intrusion detection if desired. Users who intend to use the TOE this way can use the above comparison to see if these differences are acceptable to them. Note that the TOE can also be used in parallel with a system specifically designed for intrusion detection; the IDS system can detect certain kinds of intrusions, while the TOE could detect other actions that violate policies (such as certain misuses of network resources by authorized users) which may also catch intruders that slip by the IDS. The ST provides additional information on the assumptions made and the threats countered. 5. Architectural Information SecurVantageTM consists of three major components: 1. SecurVantage™ Studio: provides a management interface that allows for the authoring of network security policy at multiple levels. 2. SecurVantage™ Monitor: captures and evaluates monitored network traffic according to the security policy 3. SecurVantage™ Enterprise: combines the information from multiple monitoring points into a single, real-time monitoring and management console. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 12 Users use Studio to define the network security policy using a proprietary policy language. This security policy defines the “correct” behavior of the network(s) being monitored. Users may use a web browser to communicate with Monitor or Enterprise over an encrypted (SSL) link. When initially connecting to Monitor or Enterprise, users are presented with a new self-signed server certificate, which they can verify by comparing these certificates to the values generated during Monitor/Enterprise installation. Users are first authenticated (using username and password sent over the encrypted link), and depending on their roles users may change data (such as uploading a new policy defined using Studio) as well as receive data (such as event data). Note that the web browser and third-party encryption libraries are outside the TOE. Studio also supports query-only direct access to Monitor or Enterprise. When using Studio in this way, Studio also uses an encrypted SSL link (to the same SSL/HTTP port). This access approach supports the username/password pair (it is the same mechanism as above), but in addition it also permits users to set up client-side certificates. If client-side certificates are set up, users need not separately log into Monitor or Enterprise simply to query data (the client-side certificates are instead protected by the operating system Studio runs on). Note that this direct access only permits query operations, so only users with the role of operator, analyst, developer, or super user can usefully use this access approach. This access approach cannot be used to modify information, in particular it cannot be used to modify policies. SecurVantage™ Monitor captures and evaluates in real time the packets flowing through the network at all levels of the protocol stack. It then makes decisions on whether the traffic is consistent with the policy specification. The result is a set of “network events” with each event including an attribute termed “criticality” in the ST. Monitor has two subcomponents: 1. Monitor Harvester, which obtains network traffic. It contains the Monitor Securify Packet Filter Module (SPFM), which actually captures the traffic. 2. Monitor Security Master (SM), which compares the harvested network traffic with the customer-defined policy. This contains the Security Policy Module (SPM), which actually compares the traffic to the policy. Monitor LE runs both subcomponents on a single processor, which lowers hardware costs but also lowers performance. Monitor (not LE) runs the components on two separate processors, with a completely private network connection between them. If an Enterprise system is deployed, Enterprise copies information from the Monitors connected to Enterprise and aggregates them into a local database. This database is accessible through the web interface for a period of 48 hours. The Enterprise serves also as a conduit to the Monitors' databases when detailed information is requested by Studio application. Enterprise can also deploy policies to multiple Monitors. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 13 When Enterprise is deployed, Enterprise and the Monitor(s) communicate using SSL. For this communication, certificates are initially verified the first time the Enterprise and Monitor components communicate. Both server and client certificates are used. Figure 1 shows a typical deployment of SecurVantage™, although SecurVantage™ Monitor can be placed anywhere on the network. It does not necessarily have to be on its own sub- network and does not have to be connected through a switch. Typically SecurVantage™ Monitor is connected to the SPAN port of a switch where there is traffic relevant to the policy. However, there are no assumptions about the source of the traffic. Figure 1: Typical SecurVantageTM Deployment SecurVantage™ consists of the policy development and analysis environment coupled with the monitoring system and the enterprise management system. Figure 2 shows the System Architecture. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 14 Figure 2: SecurVantageTM System Architecture See the Security Target section 2.2 for additional discussion of the TOE’s architecture, including more information on the tasks performed by each major component. 6. Documentation The documentation provided with the product to customers is as follows: · Securify SecurVantage 3.1 Deployment Guide. November 2002. · Securify SecurVantage 3.1 Installation Guide. November 2002. · Securify SecurVantage 3.1 Operations Guide. November 2002. · Securify SecurVantage 3.1 Release Notes. November 2002. · Securify SecurVantage 3.1 Common Criteria Addendum. January 7, 2004 · Securify SecurVantage 3.1 Administrator Addendum. January 21, 2004. This document complements the information contained in the SecurVantage 3.1 Operations Guide and the SecurVantage Common Criteria Addendum. For a longer list of the major pieces of evidence examined during the evaluation, see section 14 of this report. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 15 7. IT Product Testing 7.1 Examination of Vendor Tests The vendor provided test plans, procedures, test results and a test coverage document. The security testing was driven by the SecurVantage “Test Matrix,” a spreadsheet divided into three sections: (1) IT Security Requirements (as section 6 in the ST), (2) tests for Delivery, Installation and Configuration, and (3) other tests (that test important general functionality of the TOE instead of a specific requirement). The IT Security Requirements section (the first section) is further divided into three subsections: Studio, Monitor and Enterprise. These are indexed by the actual requirements in the ST’s TSS. Each test was performed by one of the following “test tools”: 1. Test Matrix: This is a document (supporting the spreadsheet) that specifies step by step how to perform a specific test. The document is indexed by a test case number. 2. Sentinel: This is an automated tool for testing web applications. The test case is usually mapped to a signature of the sentinel test. 3. By Inspection: Guidance necessary to perform the test. 4. By code inspection: Tests that can only be verified through a source code inspection For purposes of testing, a special test harness was used. Normally, the system is connected into a switch’s SPAN port. However, testing the system by directly connecting to a SPAN port and then generating data from multiple different networks would result in repeated tests not generating identical inputs to the TOE (due to different interleaving). Thus, for testing purposes, instead of connecting to a switch’s SPAN port, the TOE was directly connected to systems which replay data previously captured from a SPAN port. The evaluator and validator examined this configuration and were satisfied that the test harness produced the same inputs (as seen by the TOE) as the original network whose traffic had been captured (including Ethernet MAC addresses). The evaluator determined that the vendor tested (at a high level) most security-relevant aspects of the product. The evaluator determined that the developer’s tests were sound in their approach. The test document provided the configuration of the test hardware and software, the objective for each of the tests, and test procedures. The information provided was adequate to be able to reproduce the tests. The evaluators determined that the developer’s approach to testing the TSF was appropriate for this EAL2 evaluation. 7.2 Evaluator Independent Tests Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 16 The evaluator performed the tests at the developer’s site using the equipment provided by the developer. The tests were performed in two configurations; one configuration representing larger installations of the TOE which contained an Enterprise manager managing multiple (in this case two) domains and containing both (Monitor and LE) versions of the Monitor and one Studio. The second configuration represented a smaller implementation consisting of only a Studio and the Monitor LE. The enterprise and Studio were connected via separate network to the Monitor. Though this is not an imposed restriction, this is the most common field installation configuration. The same hardware was used for both configurations. The evaluator performed installation and testing on one configuration and then reconfigured and repeated the tests on the other configuration. The evaluator installed the TOE using the installation procedures. About 90% of the developer tests were repeated. The evaluator used the developer’s automated tool Sentinel for some of the tests. The evaluator repeated some tests manually to gain confidence in the tool. About 80% of the developer’s manual tests were also repeated. The developer provided a traffic generator tool that replayed the traffic from a previous session. This provided a varied sample of the traffic and helped to regulate the speed of the traffic as desired. Functions that were deemed critical to the operation of the TOE components (for example. DME creation, policy pushing, super-operator functions, creation and revoking of users, critical event viewing), difficult tests and unusual actions (like the rate limiting feature and data availability (database roll-over)), and the normal operation scenario were chosen as the basis for the evaluator’s tests. Critical messages were generated and the SNMP, SMTP message generation was verified for critical alerts. For the test repeated from the developer suites, the evaluator examined the test results and found them to be matching those of the developer. Any mismatches were purely due to data related inconsistencies. The overall verdict of the evaluator testing is that the TOE components perform the security functions in accordance with those specified in the ST and the developer’s test results match those of the evaluators. 7.3 Strength of Function Even if a TOE security function cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat it because there is a vulnerability in the concept of its underlying security mechanisms. For those functions a qualification of their security behavior can be made using the results of a quantitative or statistical analysis of the security behavior of these mechanisms and the effort required to overcome them. The qualification is made in the form of the strength of TOE security function claim. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 17 The security of this TOE depends on the strength of the passwords used to access Monitor and Enterprise. The original system analysis in the evaluation identified some concerns, because the web interface had a lax password policy (“at least 6 characters” with no other requirements). The vendor decided to modify the product to require stronger passwords. The TOE now enforces a safer (more stringent) password policy in its web (SSL) interface: · Minimum of 8 characters in the password (maximum 64 characters). · At least one lower case character. · At least one upper case character · At least one numeric character. The TOE enforces a requirement that console access passwords be at least 8 characters long. For both web interface and console access, the administrator guidance (given in the Administrator Addendum) requires that passwords for both the web interface and console meet these requirements: · Minimum of 8 characters in the password. · At least one lower case character. · At least one upper case character. · At least one numeric characters. · At least one printable character that is non-alphanumeric. · Cannot be a single dictionary word with non alphabetic characters appended and/or pre- pended. A strength-of-function analysis took these password requirements (as well as other information) and justified a ranking of SOF-basic. The overall SOF requirement for the TOE made in ST is expressed as an SOF rating, SOF-basic. Thus, the TOE meets the ST requirements. 7.4 Vulnerability Analysis Vulnerability analysis is a process for identifying potential vulnerabilities and determining whether potential vulnerabilities identified throughout the evaluation process could allow users to violate the TSP. See the CC and CEM for additional information on the requirements for an EAL2 evaluation. The vendor performed a vulnerability analysis in three parts, searching for: 1. Specific publicly-known vulnerabilities in the product (including third-party components) 2. Obvious vulnerabilities in the Enterprise and Monitor web interfaces. 3. Obvious vulnerabilities in the process of collecting, storing and presenting network traffic. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 18 For the latter two areas, the obvious vulnerabilities searched for were a set of well-known, publicly described attacks, such as buffer overflows. The vendor searched for publicly known vulnerabilities specifically related to SecurVantage, as well as publicly known vulnerabilities in the third-party products used by SecurVantage (and are in the environment of the evaluation). This search included searches in the information of Security Focus (www.securityfocus.com), Bugtraq (through Security Focus), Packetstorm (www.packetstormsecurity.org) and CVE (cve.mitre.org). No publicly-known vulnerabilities specific to SecurVantage were found. The known vulnerabilities in the third- party products were examined, and were either countered or shown to be unlikely to be a vulnerability in this circumstance. Searches for vulnerabilities in the web UI concentrated on these topics: 1. Parameter Verification. All user entry fields in the web UI to Monitor and Enterprise were tested for SQL injection, string manipulation, path traversal and buffer overflow type of attacks. Some of these attacks were performed via automatic tools like Spike or Securify’s proprietary Sentinel. a. SQL Injection. Parameters throughout the application were tested for SQL injection. The approach was to follow usual SQL injection attacks to try to stop the SQL command issued and concatenate a new SQL statement to be issued; or via SQL statements try to eliminate the constraints of the original SQL request. In every case the application returned an application level error and there was no indication that it would be susceptible to SQL attacks. Although not required by an EAL2 evaluation, the vendor also performed a selected code inspection of pieces of the code they thought were likely to be stressed and confirmed that the code properly validated the input strings. b. String Manipulation. The vendor attacked the web interfaces by adding special characters, or change expected string values for numeric values, different types of encoding, and so on. c. Path Traversal: Upload/Download. There are features of the UI that would allow an user to upload and download files from the system. The vendor attempted to download files other than the ones specified in the application without any success. The vendor further verified that the application has a very strict chroot environment and permissions were properly set throughout the file system, which enforced these restrictions. The vendor also attempted to upload files with names that would attempt some form of path traversal in an attempt of corrupting valid files in the system. The software upgrade feature of the system implements a digital signature, creating a further barrier. In short, invalid activities were prevented by the protection mechanism in the server. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 19 d. Buffer Overflow. The vendor tested many parameters for very large inputs from the user. Most of these tests were conducted using Spike. 2. User Role Model (malicious URLs). The vendor stressed the role model by attempting both breaking the assumptions in the provided UI and the model itself. The vendor attempted to bypass the user-role model by crafting specific requests (URLs) to the application. The user role model was correctly enforced by the system, as the server before performing any action would check the permissions on the credential making the request. 3. Corrupted Certificates. Vulnerabilities in the ability of the system to log and display network events emphasized these topics: 1. Rate Limiting. If the Monitor is configured to monitor a network where a specific transaction occurs at a high rate and this transaction is deemed critical by the policy it could slow the collection of other type of violation with lower level of criticality. The system was designed under the assumption that critical violations will always get properly logged and would have priority over other type of violations. So this behavior is consistent with the design of the system. An attacker could attempt to overwhelm the system, but that attempt would be clearly visible. The monitor implements rate limiting when the amount of data coming into the monitor is excessive. An attacker could decrease the effectiveness of the monitor by generating excessive traffic that is permitted by policy, causing the monitor to start to drop data. Theoretically, the monitor might not register a subsequent attack. The monitor software acts to prevent this possibility as follows: a. When possible, the monitor discards only data that is redundant with other data already collecting (e.g., drops the 1,000-20,000th instances of the same kind of event, while still collecting the 1-100th instances of a new kind of event). b. When the above is not possible, the monitor implements randomization algorithms to make it difficult for such an attacker to predict which events will be dropped, so it is hard for an attacker to guarantee that an attack goes unnoticed. 2. Buffer Overflow. The following cases were taken into consideration while performing the buffer overflow analysis to the data collection ability of the SecurVantage Monitor. a. Ethernet Jumbo Frames. Jumbo frames can theoretically overrun buffers when programs assume that all frames will fit into the Ethernet frame size of 1518 bytes any copy packets into such a buffer without first checking its size. Monitor does not support jumbo frames. Such frames are dropped without policy evaluation, and thus cannot be used to attack the monitoring itself. The Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 20 ST was clarified to clearly state that such frames are not recorded; see Jumbo Ethernet frames section below. b. Oversized IP Datagram Reassembly. The evaluator, working with the vendor, identified the need to ensure that oversized IP datagrams would not be a serious vulnerability. By manipulation of IP fragment fields, it is possible to construct from several frames a single IP datagram that is larger than the maximum allowed size of 64Kbytes. (This is the most obvious way of attempting to create a buffer overflow at the IP level). Monitor does not crash when presented with such datagrams. When such a datagram is encountered, it is reassembled correctly (the length field in the IP header will be incorrect due to overflow of the 16 bit value). Monitor will not crash or cause other untoward effects when this occurs. c. Long Data in Protocols. Many protocols allow variable length data. Examples are URLs in HTTP requests, filenames in an FTP session and so on. When processing such data the monitor must avoid buffer overflows or resource exhaustion. Not only must such data not overflow buffers, but SecurVantage™ must also avoid attempting to log infinitely large amounts of data to the database. So URLs, etc., must be truncated at some reasonable value. The vendor captured sessions where such extremely long values occur, in particular HTTP sessions with very long URLs and FTP sessions with very long filenames. The vendor replayed the captured sessions and verified that the Monitor would correctly capture and store these sessions. The vendor also verified that they were correctly displayed. By code inspection the vendor verified that information was truncated even prior of being stored in the database, so the risk of overflow in the database was handled as well. ICMP packets up to the maximum IP datagram size were crafted, and it was verified that Monitor logged them correctly. 3. DNS. Monitor can be configured to connect to a DNS server to resolve names to IP addresses. Resolved names are displayed in the web UI whenever a user positions the mouse cursor at an IP address in the data analysis pages. The vendor performed a code review on the DNS client implemented in the Monitor to assess a potential vulnerability. The assumption for this analysis is than attacker compromises the DNS server configured in the environment, or legitimately controls a DNS server (of a domain the attacker owns), and can send arbitrary DNS responses to a specific DNS query. The vendor considered the following cases: buffer overflows, abuse of DNS pointers, SQL injection, corruption of user interface, and crashing of the system by unexpected input. No way was found to use DNS to remotely interfere with the TOE security requirements. However, note that DNS data may be provided by an attacker, and thus the data may not have the value expected by users. Thus, guidance was added to suggest leaving the DNS access capability disabled, and warning about this issue if DNS access is turned on. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 21 4. Other techniques to avoid monitoring. One area of concern eventually resolved during the evaluation was that Monitor drops Ethernet jumbo frames. There was concern that an attacker could take advantage of this deficiency to try to exploit systems in the network, without being logged by Monitor, using Ethernet jumbo frames. This was countered by asserting that the environment does not accept Ethernet jumbo frames. However, the U.S. CCEVS does not accept STs with nonexistent or completely unrealistic environments, so the vendor had to briefly demonstrate that this specified environment was reasonable. The vendor showed that there were plausible infrastructure components (Cisco 4xxx, 5xxx, and 6xxx switches) and end-user systems (Windows 2000, Windows XP, Red Hat Linux 7.2 running Linux kernel 2.4, Sun Solaris) that by default drop any Ethernet jumbo frames they receive. Thus, this environmental requirement appears reasonable, because there are reasonable environments where this assumption is true. The evaluator determined that the product met the criteria of EAL2 for vulnerability analysis. 8. Evaluated Configuration The evaluated configuration was configured per the documents listed in section 6 of this report. The system was tested with DNS and NTP services disabled, as is its default (see section 4.2 for a discussion on these services). For additional information on how to securely deploy this TOE (beyond the referenced documentation), see sections 4 and 10 of this report. 9. Results of the Evaluation The validation team followed the procedures outlined in the Common Criteria Evaluation Scheme [CCEVS] publication number 3 for Technical Oversight and Validation Procedures. [CCEVS_PUB 3]. The validation team has observed that the evaluation and all of its activities were in accordance with the Common Criteria, the Common Evaluation Methodology [CEM], and the CCEVS. The validation team therefore concludes that the evaluation and its results of pass are complete and should be approved by the CCEVS. 9.1 Assurance Content The evaluation provides for Assurance at the EAL 2 level without augmentation. Therefore, this includes the assurance components as shown in the table below: EAL2 Assurance Requirements Assurance Class Assurance Family ST Evaluation ASE_DES.1 Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 22 Assurance Class Assurance Family ASE_ENV.1 ASE_INT.1 ASE_OBJ.1 ASE_PPC.1 ASE_REQ.1 ASE_SRE.1 ASE_TSS.1 Configuration Management ACM_CAP.2 ADO_DEL.1 Delivery and Operation ADO_IGS.1 ADV_FSP.1 ADV_HLD.1 Development ADV_RCR.1 AGD_ADM.1 Guidance Documents AGD_USR.1 ATE_COV.1 ATE_FUN.1 Tests ATE_IND.2 AVA_SOF.1 Vulnerability Assessment AVA_VLA.1 10.Validator Comments/Recommendations As with any evaluation, this evaluation shows that the evaluated configuration meets the security claims made, with a certain level of assurance. Be sure to note the assumptions and clarifications of scope in section 4 of this report. In particular: 1. As clearly stated in the ST, the TOE only records IPv4 with normal Ethernet framing. Other kinds of data, particularly IPv6 and Ethernet jumbo frames (jumbograms), are not recorded. If all relevant network traffic is to be monitored, systems must be configured to reject these unrecorded packets. Many systems do this by default, so at this time this is a plausible environmental restriction for many circumstances. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 23 2. Note that this tool is designed to report violations from a customer-defined network security policy. Thus, it is strongly advised that administrators be trained so that they can devise a good network security policy for their environment. 3. The tool is not primarily intended to be an intrusion detection tool, but it can be especially effective in detecting certain kinds of intrusions (see section 4.3 for a discussion of this). For many purposes, the TOE is useful as it is. However: 1. Consider connecting Enterprise (if present), Studio, and all Monitor(s) using a separate private (“command and control”) network solely allocated for this purpose. The evaluated configuration presumed that the network connecting the TOE components was accessible by an attacker, and examined the TOE resistance to attack in that circumstance. No EAL2-level vulnerabilities were found. However, using a private network can reduce even further the opportunities for an attacker to exploit the TOE or to assail it using denial-of-service attacks. A physically separate network would be even better than a logically separated one. 2. Firewalls may be useful to prohibit certain actions that should be simply prohibited. This would reduce the processing load on the TOE so it can use its processing power to monitor the subtler activity the TOE is capable of monitoring. 3. It may be prudent to pay special attention to the workstation(s) used to run Studio: lock down its operating system to be secure, rigorously maintain its operating system for patches, use it only for SecurVantage-related work (and isolate it administratively for just that purpose), and power down or unplug the workstation when it is not in use. TOE users with lower privileges should not have special privileges to the workstations’ operating system used by TOE users with higher privileges, since those special privileges could be exploited to gain control over the other TOE user. 4. Some high-risk environments that decide to use this EAL2 evaluated TOE may also find it useful to augment this TOE with other tools, since no one tool has all strengths and some tools are especially good complements for this TOE. One useful type of complementary tool would be a network scrubber (with rate limiting), to ensure that the end-systems and the Monitor see exactly the same data and that the data rate is loggable. Another such tool would be specialized intrusion detection systems (IDSs). IDSs could detect attack attempts (even if the communication is allowed by the TOE security policy), while the TOE can detect misuse of the network (including certain kinds of intruder activity) in a way that many IDSs would not detect. 5. Be careful when updating the security policy, since this interferes with capturing network events when the policy is being updated. Avoid updating the security policy at predictable times, and if collecting all network events is critical, consider temporarily disabling the network for a period of time while updating the security policy. As long as security polices are not updated at times known by an attacker, this is more of a theoretical problem than a real one. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 24 6. The safest course is to leave NTP and DNS access disabled. DNS can be enabled, but it’s important for users to understand that in some cases an attacker may provide the displayed DNS data. See section 4.2 for a discussion of these issues. The tool can detect and report violations of a security policy, but what happens after detection is a decision humans must make. If the goal is to detect authorized users performing certain prohibited actions, it will be important to ensure that users know (in a general way) what kinds of actions are allowed and what is prohibited. It may be necessary to develop a more detailed human-readable network policy so that authorized users will know what actions they may and may not take. The validator observed that the evaluation and all of its activities were in accordance with the CC the CEM, and CCEVS practices; and that the CCTL presented appropriate CEM work units and rationale. The validation team therefore concludes that the evaluation, and its results of pass, are complete, correct, and should be approved by the CCEVS. 11. Annexes None. 12. Security Target The Security Target is provided separately. It is Version 2.0, dated January 26, 2004. 13. Glossary The following acronyms are provided for reference: CC Common Criteria CCEL Common Criteria Evaluation Laboratory CCEVS Common Criteria Evaluation and Validation Scheme CCTL Common Evaluation Testing Laboratory CEM Common Evaluation Methodology CI Configuration Items CSC Computer Sciences Corporation DSA Developer Security Analyst EAL Evaluation Assurance Level EDR Evaluation Discovery Report ETR Evaluation Technical Report MRA Mutual Recognition Arrangement NIAP National Information Assurance Program NIST National Institute of Science & Technology NSA National Security Agency Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 25 OR Observation Report PP Protection Profile SAR Security Assurance Requirement SFR Security Functional Requirements SOF Strength of Function ST Security Target TCSEC Trusted Computer Systems Evaluation Criteria TOE Target of Evaluation TSC TOE Scope of Control TSF TOE Security Functions TSFI TSF Interface The following CC terms are provided for reference: User Any entity (human user or external IT entity) outside the TOE that interacts with the TOE. Human user Any person who interacts with the TOE. Authorized User A user that, in accordance with the TOE Security Policy (TSP) may perform an action. (As identified by group membership.) External IT entity Any IT product or system, untrusted or trusted, outside of the TOE that interacts with the TOE. Role A predefined set of rules establishing the allowed interactions between a user and the TOE. Identity A representation (e.g., a string) uniquely identifying an authorized user, which can be either the full or abbreviated name of that user or a pseudonym. Authentication data Information used to verify the claimed identity of a user. 14. Bibliography The evidence used in this evaluation is based upon the product, the security target, the user documentation (see section 6 for list), and the following documentation: 1. Performance Measures for SecurVantage, November 10, 2003 2. Securify SecurVantage 3.1 Auditing Matrix, December 2003 Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 26 3. Securify SecurVantage 3.1 CLI, December 2003, December 29, 2003 4. Securify SecurVantage 3.1 Configuration Mechanisms and Description, January 21, 2004 5. Securify SecurVantage 3.1 Configuration Parameters, December 16, 2003 6. Securify SecurVantage 3.1 Data Purging Specification, September 24, 2002 7. Securify SecurVantage 3.1 EM Coversheet, December 16, 2003 (EM stands for “Enterprise Manager”) 8. Securify SecurVantage 3.1 External Interfaces, January 7, 2004 9. Securify SecurVantage 3.1 High-Level Design (HLD), January 7, 2004 10. Securify SecurVantage 3.1 Manufacturing Procedures, December 16, 2003 11. Securify SecurVantage 3.1 Monitor Coversheet, January 7, 2004 12. Securify SecurVantage 3.1 Monitor Database Schema, April 22, 2002 13. Securify SecurVantage 3.1 Monitor LE Coversheet, December 16, 2003 14. Securify SecurVantage 3.1 Procedures to audit capture and storage of network events,December 16, 2003 15. Securify SecurVantage 3.1 RCR, January 7, 2004 16. Securify SecurVantage 3.1 Strength of Function Computation, December 11, 2003 17. Securify SecurVantage 3.1 Test Matrix, December 29, 2003 18. Securify SecurVantage 3.1_80.cvstags, December 16, 2003 19. Securify SecurVantage 3.1Physical Data Model, December 16, 2003 20. Securify SecurVantage Vulnerability Analysis, version 1.8, January 21, 2004 21. Test2.zip (Collection of Test documentation), October 24, 2004 22. Test3.zip (Supplemental collection of test documentation), October 29, 2004 23. Testing TCP Checksums, January 23, 2004 The evaluation and validation methodology was drawn from the following: [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated August 1999, version 2.1. [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional requirements, dated August 1999, version 2.1. [CC_PART2A] Common Criteria for Information Technology Security Evaluation – Part 2: Annexes, dated August 1999, version 2.1. [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance requirements, dated August 1999, version 2.1. Validation Report SECUREVANTAGE SECURIFY VERSION 3.1 PAGE 27 [CEM_PART1] Common Evaluation Methodology for Information Technology Security – Part 1: Introduction and general model, dated 1 November 1997, version 0.6. [CEM_PART2] Common Evaluation Methodology for Information Technology Security – Part 2: Evaluation Methodology, dated August 1999, version 1.0. [CCEVS_PUB 1] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Organization, Management and Concept of Operations, Scheme Publication #1, Version 2.0, May 1999. [CCEVS_PUB 2] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Validation Body Standard Operating Procedures, Scheme Publication #2, Version 1.5, May 2000 [CCEVS_PUB 3] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Technical Oversight and Validation Procedures, Scheme Publication #3, Version 1.0, January 2002. [CCEVS_PUB 4] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Guidance to CCEVS Approved Common Criteria Testing Laboratories, Scheme Publication #4, Version 1, March 20, 2001 [CCEVS_PUB 5] Common Criteria, Evaluation and Validation Scheme for Information Technology Security, Guidance to Sponsors of IT Security Evaluations, Scheme Publication #5, Version 1.0, 31 August 2000.